IANAL for IoT

Presented at Chcon 2021:
https://2021.chcon.nz/talks/tom/

A lot of people in infosec have talked about how IoT is a flaming pile of crap, myself included. My personal belief is that things are only going to improve with either standards that force manufacturers to be compliant or labelling schemes that allow consumers to choose secure products. But how’s that all going?

Transcript

1. IANAL for IoT Tom Isaacson @parsley72 (I am not a lawyer)
3. General Data Protection Regulation (GDPR) Came into force on 25th May 2018 Covers any organisation collecting data concerning any EU citizen. Required to “implement appropriate technical and organisational measures” for handling and processing of personal data: • Pseudonymisation and/or encryption. • Ensuring ongoing confidentiality, integrity, availability and resilience. • Regular testing. Fines: • 10M EUR (~17M NZD) or up to 2% of global gross (whichever is greater) for violations of record-keeping, security, breach notification and privacy impact assessment obligations. • 20M EUR (~34M NZD) or up to 4% of global gross (whichever is greater) for violations related to legal justification for processing, lack of consent, data subject rights and cross-border data transfers.
4. Fully Encrypted Device Data Device Phone Public key Encrypted data
5. Tesla’s “Sentry Mode Live Camera Access” You can now remotely view your car's surroundings when parked to confirm the safety of your environment before returning to your car. Live Camera is end-to-end encrypted and cannot be accessed by Tesla. To enable or disable tap Controls -> Safety & Security.
6. California Senate Bill 327 (SB-327) Came into force on January 1st 2020 Requires all IoT devices sold in the state to be equipped with “reasonable security” (except devices under federal law, regulations or guidance; for example FDA-regulated medical devices). The only IoT security requirements that SB 327 explicitly spells out are for manufacturers to equip any device “with a means for authentication outside a local area network” with this “reasonable security feature”: • Either: The preprogrammed password is unique for each device manufactured. • Or: The device requires a user to generate a new means of authentication before granting first access. Further defines “reasonable security features” as being: 1. Appropriate to the nature and function of the device. 2. Appropriate to the information the device may collect, contain or transmit. 3. Designed to protect the device and any data on it from unauthorized access, destruction, use, modification or disclosure. California Attorney General’s Office has clarified that “reasonable security” includes being aligned with “an authoritative information security standard” like ISO 27001 or the Center for Internet Security’s Critical Security Controls.
7. SB-327 in action? Security startup Verkada hack exposes 150,000 security cameras in Tesla factories, jails, and more - 09/03/2021 “Verkada, a Silicon Valley security startup that provides cloud-based security camera services, has suffered a major security breach. Hackers gained access to over 150,000 of the company’s cameras, including cameras in Tesla factories and warehouses, Cloudflare offices, Equinox gyms, hospitals, jails, schools, police stations, and Verkada’s own offices” Surveillance Camera Hack Raises Legal Risk of Digital Device Use “A California law which took effect last year, SB327, could also come into play”
8. First Responder Network Authority (FirstNet) Developed in response to 11/9 which “highlighted the inability for deployed public safety networks to handle a true crisis situation.” Contract finally awarded to AT&T in 2017 for a First Responder mobile network using band 14 (not shared). Need to be in one of these groups to get a SIM card: • Law enforcement • Fire protection services • Emergency (911) call dispatching • Government Public Safety Answering Points • Emergency planning and management offices • Emergency medical services
9. FirstNet devices
10. FirstNet Security Requirements 1. Only required network listening services are running on the device by default. 2. Network listening services running on the device are dynamically tested for vulnerabilities and have all Critical, High, and Medium-level findings remediated with a plan. 3. Remote access services running on device communication interfaces are secure. 4. Default, hardcoded credentials are unique between devices within the same model. 5. Default credentials are a minimum of 10 characters and alphanumeric with capitals complexity. 6. Non-unique, default user credentials require user reset on initial use. 7. Sensitive data is not sent over clear-text communication channels. 8. Sensitive data or files are not stored in clear-text on the device. 9. Device user interface logins can be changed – and a complexity level is required. 10. User Interface logins implement timed lockout on failed number of attempts. 11. A secure boot process is implemented and validated through testing. 12. Firmware files are remotely updated automatically by default. 13. The owner or user of the device receive continuously notification of available and critical firmware updates for the device. 14. Firmware files are accessed and transferred securely. 15. Firmware files are either not publicly accessible or are encrypted at rest. 16. Firmware images are digitally signed and validated as legitimate before installing. 17. Linked OSS libraries are inventoried and tracked for new vulnerabilities. 18. Linked OSS libraries are up to date with all Critical, High, and Medium severity security patches. 19. System software is statically and dynamically tested for vulnerabilities and has all Critical, High-level findings remediated with a plan. 20. JTAG, UART and other serial interfaces are secure against privileged system access. 21. Compiler and chipset security hardening is implemented in compiled binaries. 22. Remote login and file transfer services are disabled by default on WAN interfaces. 23. Device logging for system faults and security events is enabled if system supports logging. 24. PAN/LAN wireless connections use best practice authentication & encryption measures. 25. Management connections from/to external systems use two-factor or mutual authentication. 26. Connections to external services utilize industry best practice authentication & encryption libraries and configuration. 27. Web APIs running on the device and connected to by the device are dynamically tested for vulnerabilities and have all Critical, High, and Medium level findings remediated with a plan. 28. Device operating system configuration implements industry best practice security hardening measures. 29. The device OEM has a public contact mechanism for “security inquiries” clearly visible on the device web site for submission of discovered device or service vulnerabilities. 30. The device OEM has established capabilities, either in-house or contracted to conduct ongoing vulnerability testing of the device and associated backend services they operate.
11. OWASP Top 10 IoT Vulnerabilities (2018) 1. Weak, Guessable or Hardcoded Passwords 2. Insecure Network Services 3. Insecure Ecosystem Interfaces 4. Lack of Secure Update Mechanism 5. Use of Insecure or Outdated Components 6. Insufficient Privacy Protection 7. Insecure Data Transfer and Storage 8. Lack of Device Management 9. Insecure Default Settings 10. Lack of Physical Hardening
12. 1. Weak, Guessable or Hardcoded Passwords • Default, hardcoded credentials are unique between devices within the same model. • Default credentials are a minimum of 10 characters and alphanumeric with capitals complexity. • Non-unique, default user credentials require user reset on initial use. • User Interface logins implement timed lockout on failed number of attempts.
13. 2. Insecure Network Services • Only required network listening services are running on the device by default. • Network listening services running on the device are dynamically tested for vulnerabilities and have all Critical, High, and Medium-level findings remediated with a plan. • Remote access services running on device communication interfaces are secure. • Remote login and file transfer services are disabled by default on WAN interfaces. • Web APIs running on the device and connected to by the device are dynamically tested for vulnerabilities and have all Critical, High, and Medium level findings remediated with a plan.
14. 3. Insecure Ecosystem Interfaces • PAN/LAN wireless connections use best practice authentication & encryption measures. • Management connections from/to external systems use two-factor or mutual authentication. • Connections to external services utilize industry best practice authentication & encryption libraries and configuration.
15. 4. Lack of Secure Update Mechanism • A secure boot process is implemented and validated through testing. • Firmware files are accessed and transferred securely. • Firmware files are either not publicly accessible or are encrypted at rest. • Firmware images are digitally signed and validated as legitimate before installing. • Firmware files are remotely updated automatically by default.
16. 5. Use of Insecure or Outdated Components • Linked OSS libraries are inventoried and tracked for new vulnerabilities. • Linked OSS libraries are up to date with all Critical, High, and Medium severity security patches. • System software is statically and dynamically tested for vulnerabilities and has all Critical, High-level findings remediated with a plan. • Device operating system configuration implements industry best practice security hardening measures. • The device OEM has a public contact mechanism for “security inquiries” clearly visible on the device web site for submission of discovered device or service vulnerabilities. • The device OEM has established capabilities, either in-house or contracted to conduct ongoing vulnerability testing of the device and associated backend services they operate. • Compiler and chipset security hardening is implemented in compiled binaries.
17. 7. Insecure Data Transfer and Storage • Sensitive data is not sent over clear-text communication channels. • Sensitive data or files are not stored in clear-text on the device.
18. 8. Lack of Device Management • Device user interface logins can be changed – and a complexity level is required. • The owner or user of the device receive continuously notification of available and critical firmware updates for the device. • Device logging for system faults and security events is enabled if system supports logging.
19. 10. Lack of Physical Hardening • JTAG, UART and other serial interfaces are secure against privileged system access.
20. FirstNet ongoing support • Linked OSS libraries are inventoried and tracked for new vulnerabilities. • Linked OSS libraries are up to date with all Critical, High, and Medium severity security patches. • System software is statically and dynamically tested for vulnerabilities and has all Critical, High-level findings remediated with a plan. • The device OEM has a public contact mechanism for “security inquiries” clearly visible on the device web site for submission of discovered device or service vulnerabilities. • The device OEM has established capabilities, either in-house or contracted to conduct ongoing vulnerability testing of the device and associated backend services they operate. • The owner or user of the device receive continuously notification of available and critical firmware updates for the device. • Firmware files are remotely updated automatically by default.
21. Obsolescence
23. ETSI EN 303 645 European Telecommunications Standards Institute Adopted on 19 June 2020 1. No universal default passwords. 2. Implement a means to manage reports of vulnerabilities. 3. Keep software updated. 4. Securely store sensitive security parameters. 5. Communicate securely. 6. Minimize exposed attack surfaces. 7. Ensure software integrity. 8. Ensure that personal data is secure. 9. Make systems resilient to outages. 10. Examine system telemetry data. 11. Make it easy for users to delete personal data. 12. Make installation and maintenance of devices easy. 13. Validate input data. https://iotsecuritymapping.com/ maps global IoT security and privacy recommendations to the ETSI standard.
24. IoT Alliance Australia (IoTA / IoTAA) Internet of Things Security Guideline V1.0