Security

There is no shortage of scary hacks and security breaches related to the IoT. Take Stuxnet, a computer worm designed to attack industrial PLCs and SCADA systems, reportedly used to destroy hundreds of centrifuges used by the Iranian nuclear research program [ST1]. Or consider the hack of a certain type of pacemaker that enabled high-voltage shocks to be sent to patients 50 feet away [DR2]. Or look at how Charlie Miller and Chris Valasek showed at the DEF CON Hacking Conference that they could take control of the electric steering, braking, acceleration, engine, and other features of two well-known car types. It seems pretty evident that the IoT will only be successful if we manage to secure the solutions that we build. Many people would also agree that it will never be 100% possible to secure a complex, distributed IT system – so thinking the unthinkable and being prepared for the consequences should also be part of the equation.

Many leading companies in the IoT field are taking a very proactive approach to IoT security. For example, the electric car manufacturer Tesla Motors has hired the renowned white hat hacker Kristen Paget to oversee vulnerability testing and security for its cars. As one of her first tasks, Paget brought a Tesla vehicle to the DEF CON Conference, where Tesla was looking to recruit more hackers to help identify security vulnerabilities in the software that controls the vehicles [DR1].

Securing IoT Solutions

In the following, we will start the discussion by looking at the different security concepts in the IoT. The figure below maps the main security concepts to our Asset Integration Architecture, each of which we will briefly discuss.

Securing the On-Asset Hardware (1): Typically, it is relatively easy to prevent physical access to servers in a data center. However, this is very different in the IoT as the assets in this case are deployed in the field, and it will often be impossible to prevent physical access to the on-asset hardware. One important approach here is TPM (Trusted Platform Module) – an international standard for a secure crypto-processor that is designed to secure hardware by integrating cryptographic keys into devices. Hardware Security Modules (HSM) like the CycurHSM from Escrypt [ES1] are often used in the automotive industry. A HSM usually consists of a CPU core, different types of data storage, a memory protection unit, a memory encryption unit, sensors, and cryptographic accelerators. HSMs will usually support countermeasures against physical attacks, such as active sensors to detect fault and glitching attacks, and also employ cryptographic implementations that are hardened against side channel attacks [ES1].

Software-based security features that are deployed on the asset often include firewalls, port filtering, identity assurance, key management, and anti-virus functionality. The extending of traditional server-side security to operational technology in the IoT is an increasingly common strategy for companies such as Intel, whose strategic acquisition of McAfee allowed them to heavily extend their combined capabilities for the IoT.

Secure Communication (2): Ensuring secure communication between the asset and the backend is vital for many, if not most, IoT solutions. Most solutions utilize encryption technologies, either on the application layer (like Transport Layer Security or TLS), or on the IP protocol layer (like the Internet Protocol Security or IPsec). One key difference in these technologies is how they deal with firewall and NAT traversal, which has an impact on administration overheads for large-scale installations. In addition to encryption, technologies like Transparent Network Substrate (TNS) also deal with authentication.

Certificate Management (3): Certificates are an important part of Transport Layer Security (TLS). A certificate is an electronic document used to prove ownership of a public key. The certificate includes information about the key, about its owner’s identity, and the digital signature verifies that the certificate’s contents are correct. In large-scale IoT environments, efficient certificate management becomes essential so that assets and devices can authenticate themselves and communicate securely with the backend.

AAA (4): Authentication, authorization, and accounting – often simply called AAA – is a framework designed for controlling access to applications, enforcing policies, and auditing usage. In the IoT, this will become very important. To use a simple example: Which piece of construction equipment is requesting to leave the construction site? Is this equipment permitted to do so according to the current schedule? If so, let`s make a note that it has left.

Securing the Backend (5+6): And finally, we also have to secure the backend and its infrastructure. This will include prevention of Denial of Service (DoS) attacks, Intrusion Detection Systems (IDS), firewalls, packet filtering, and reverse proxies.

Security by Design

As we can see from the previous section, there are many different technologies and concepts that can, or must, be used to make an IoT system secure. From the solution architect’s perspective, it is important that security is built into the system from the ground up. This is also sometimes called Security by Design [SD1]. With Security by Design, malicious practices are taken for granted, and care is taken to minimize the impact when a security vulnerability is discovered. Another important feature is that everything works with the least amount of privileges possible.

In the “IoT Project Initiation” section, we actually recommend that security be a key element in the cross-cutting workstream. Only by explicitly manifesting this in the project organization will it be possible to achieve Security by Design across all the other workstreams in an IoT project.

IoT Security Testing

As much as we trust in the idea of Security by Design, every IoT project needs to have a solid security testing strategy. The best approach is to set up a dedicated team to perform what are known as penetration tests. These involve white-box testing, performed by staff from the project team with general knowledge about the systems, as well as black-box testing, involving an external, third-party team that performs security tests without internal knowledge, which is the more realistic scenario.

The Open Web Application Security Project (OWASP) Top Ten is the most popular list of potential risks in web applications. OWASP has now started to also publish an annual list of top 10 security issues in the Internet of Things [OW1]. Based on this list, the InfoSec Institute has proposed a concrete test strategy for IoT solutions [IS1]:

• Testing an IoT Device for Insecure Web Interface: OWASP recommends looking specifically for default credentials on IoT devices that should be changed during initial setup, ensuring complex passwords are enforced, checking for cross-site scripting, SQL injection, and cross-site request forgery vulnerabilities. A standard port scanner should be used to discover the web services that a particular device offers.
• Testing an IoT Device for Poor Authentication/Authorization: Includes standard tests for weak passwords by checking the initial installation, testing if the device will accept weak passwords or no password, and use of proxies and sniffers to look for unencrypted or weakly encoded passwords.
• Testing an IoT Device for Insecure Network Services: Includes the use of port scan tools like Nmap and penetration testing tools like Nessus or OpenVAS to look for critical services like Telnet, FTP, Finger, TFTP, or SMB.
• Testing an IoT Device for Lack of Transport Encryption: Basic tests to ensure communication is properly encrypted.
• Testing an IoT Device for Privacy Concerns: Tests performed to prevent access to sensitive data like personal data (home address, for example), financial data (credit card number, for example), health information, etc.
• Testing an IoT Device for Insecure Cloud Interface: The backend services of an IoT solution can suffer from the same problems as any other web application and need to be tested accordingly, including basic tests such as checking for the use of HTTPS, but also for authentication problems like user-name harvesting or brute-force guessing attempts.
• Testing an IoT Device for Insecure Mobile Interface: Some IoT devices may also act as wireless access points (WAPs) that need to be tested for security as well.
• Testing an IoT Device for Insufficient Security Configurability: Basic checks for password policy enforcement, data encryption, and different levels of access.
• Testing an IoT Device for Insecure Software/Firmware: This test has to ensure that all remote software updates are safely encrypted, to avoid installation of malware on the IoT device.
• Testing an IoT Device for Poor Physical Security: This final test checks ease of storage media removal, encryption of stored data, physical protection of USB and similar ports, ease of disassembly, and removal or disabling of unnecessary ports.

IoT Safety Program

While the above-mentioned technologies and processes are important in helping to secure the IoT, security will not come through the use of them alone. Developers of complex, highly security-relevant IoT solutions in particular will have to look at implementing an IoT safety program. This applies, for example, to the automotive industry: “I Am the Cavalry” is a grassroots organization focusing on the intersection between computer security and public safety. At the DEF CON Hacking Conference 2014 they proposed a five point Automotive Cyber Safety Program in an open letter to the automotive industry [FS1]. This program includes:

Safety by Design (1): The program should support published attestation of the Secure Software Development Lifecycle. Key elements include use of standards (ISO, NIST), traceable hardware and software supply chains, reduction of elective attack surface and complexity, and independent, adversarial resilience testing.

Third-Party Collaboration (2): The program should have a published coordinated disclosure policy that invites contributions from third-party researchers acting in good faith, including a positive “recognition & reward” system for bug reporting.

Evidence Capture (3): Vehicles should support tamper-evident, forensically sound evidence capture and logging that help to facilitate safety investigations.

Security Updates (4): Remote software updates for vehicles in the field should be enabled, to allow for prompt, reliable, and secure updates for critical bugs. This is of critical importance because increasing use of software is likely to produce the need for more updates and, with millions of vehicles deployed in the field, frequent factory recalls are not an option.

Segmentation and Isolation (5): Physical and logical isolation measures should be implemented and published to separate critical systems from non-critical systems.

IoT Privacy Policies

Finally, we need to take a look at IoT privacy policies (although strictly speaking they don`t really belong into a Technology Profile). Assuming that security has been established to prevent malicious attacks, the IoT solution provider will also proactively have to look at how his privacy policies should be defined. The IoT Security Laboratory has created a nice summary of the Google Nest privacy policies, which are defined as follows [IL1]:

• The privacy policy is easy to find by, for example, putting a link to the privacy policy on every page
• The privacy summary is written for humans, not for lawyers
• A note that privacy depends on security
• The buyer controls sharing and retention, i.e. who can see the data (sharing) and how long it can be used (retention)
• Clear separation between web and device privacy policies
• Data is made anonymous before publication, especially important in the age of big data
• A real privacy contact, for example, a direct email address that answers all remaining questions.

Since, for many consumers, privacy policies will determine their willingness to buy and use the product, IoT solutions providers need to take great care in defining and implementing these policies.

Summary and Outlook

In the following we talk to Dr. Thomas Wollinger, Managing Director of ESCRYPT, a leading embedded security solutions provider, about his vision for security in the IoT.