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 concepts in the IoT - mapped to the AIA

Security concepts in the IoT – mapped to the AIA

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.

Dirk Slama: What are the key elements for an end-to-end security solution for an IoT application?

Thomas Wollinger: Cryptographic primitives can be utilized to protect IoT applications. Different security objectives may be relevant, depending on the use cases. For instance, the confidentiality of transferred data can be protected by data encryption. Many applications also require protection against data manipulation, which can be achieved using mechanisms such as digital signatures.

All cryptographic primitives operate on keys that have to be managed throughout the whole lifecycle of the application. This means that secure key management is essential, including secure key generation (with a true random number generator), secure key distribution, and secure key storage.

Dirk Slama: Is all of this available today or are there missing pieces that still have to be built?

Thomas Wollinger: The technology is already there, but it needs to be adapted for the specific purpose of the IoT application. First, the cryptographic primitives and parameters (key length, for example) have to be carefully selected to fit to the IoT platform. Most IoT platforms are quite restricted in terms of computing power and memory. Furthermore, in contrast to a desktop scenario, where you have user interaction, IoT applications usually operate without user input and thus are device-centric. Therefore, instead of user certificates, device certificates have to be used. But whatever the device or platform-specific requirements, security is not a feature that can be added to the device or application at a certain phase of its life. A truly secure device requires attention throughout the whole lifecycle, starting from design, through implementation, up to rollout. Each phase has its own relevance and challenges related to overall security.

Dirk Slama: How does a project manager address IoT security step-by-step? What does their checklist look like?

Thomas Wollinger: It is crucial to conduct a security analysis first, in order to identify all possible security threats and the appropriate countermeasures. From this analysis, the security requirements (primitives, protocols, parameters) can be derived, and these are then included in the design and architecture of the system. In addition, all supporting parts in the lifecycle need to be considered, the IT infrastructure for example. Subsequently, the system is implemented and tested. Code reviews and security tests should be mandatory before shipping the IoT system to the customer.

Dirk Slama: What about security testing for the IoT? How should a project manager go about this?

Thomas Wollinger: Security tests should form an integral part of the application development. Besides unit tests and integration tests, penetration tests including fuzz testing should also be considered.

Dirk SlamaAssuming there will never be a 100% secure solution – what does the contingency plan look like? What does the project manager have to consider before rolling out the solution?

Thomas Wollinger: Just for clarification purposes and to avoid misunderstanding – there will never be a 100% secure solution. Software can contain bugs, some of which are very hard to detect. The firmware of IoT systems is no exception. Furthermore, new vulnerabilities might arise in the future (buffer overflows in common libraries, for example). To make things worse, most IoT systems have quite a long lifecycle (several years, sometimes even decades) and are often not easily accessible (if they are embedded into a larger system, for example). Therefore, the system should be prepared for secure firmware updates. The most convenient and cost-saving method is an over-the-air update. It is important that the firmware’s authenticity is verified before it is written into the device, in order to ensure that the update originates from a legitimate manufacturer and to prevent malicious attacks. Again, cryptographic primitives and secure key management are the key factors here in the protection of the IoT device. We also recommend a frequent security analysis of the whole IoT system, for example every year. In this way, the latest attack vectors will be taken into account.