Scaling the IoT product security lifecycle with automation

Recent events around the globe once again shine a limelight on the security issues the IoT community is facing. From claimed attacks on chlorine plants in Ukraine to potential threats to entire medical systems, IoT devices have left their users at a disadvantage against attackers, and the reason might just be that the security minds of our generation are still approaching product security in a traditional way – manually.

The IoT security value chain continues to use custom methodologies and ad-hoc approaches when it comes to choosing the security objectives and controls that should be included or tested in a product. This leads to the implementation of narrow and arbitrary security measures in IoT products which, along with the pressures of increased features and fast time-to-market demands, is one of the causes of the poor state of security in the industry. Today, automated methods can make every step of the IoT security process more efficient and comprehensive.

Define security requirements

Identifying the relevant security requirements for a product is the first step in developing a secure device. Although there are many security standards applicable to IoT products, and specifically to industries such as medical or automotive, manufacturers and integrators are having a hard time understanding which standards apply to their products. There are too many different requirements, some even contradictory, which places an undue burden on the implementers. An automated system which derives the relevant security requirements for each given product or use case could lift that burden.

To meet this need through an automated solution, a digital database of all security requirements, is necessary. The sources for this database may include official standards, security publications and guidelines, and internal or publicly available research such as vulnerability bulletins (CVEs). By maintaining references to each original requirement being incorporated, this database would allow product managers and engineers to substantiate and confirm any internal requirement using multiple external references as they build their product.

Assess vulnerability

Once an initial product is put together, the next phase is to analyze the device’s attack surface. To facilitate this, each individual requirement in the database can be connected with related objects. The most useful ones are the “device attributes”, a general term for device components, which serve as the vectors for the relevant attacks. Filtering the requirements by the attributes present in a device provides a list of security needs for each device, which can then be prioritized by the associated attacks’ risk level, resulting in a practical work plan for the engineering team. Furthermore, the security requirements should be augmented with detailed guidance for their implementation and resolution, accelerating the patching of any vulnerability.

For example, requirements that secure devices against attacks using open Telnet ports, such as the ones performed by the notorious Mirai botnet, are connected to the Telnet device attribute. This attribute can be detected in an automated manner by searching for the Telnet binary in the device’s firmware files, by parsing the device’s startup scripts, and/or by port analysis on a live device. Once the Telnet attribute is identified in a product, the development team can receive not only the standards and references that require it to be secured, but also all the guidance needed to secure it and comply with these standards. This simple requirement can help improve the state of security of many existing IoT products, as well as far more complicated requirements.

Validate

Further in the secure development lifecycle, automated testing should also be added to the verification step, preferably as part of the continuous integration and development environment used by the engineering and quality assurance teams. Firmware scanners can determine the status of each requirement as implemented or unimplemented, while also providing a detailed description and gaps report for each version produced. The verification process could even be aimed at a specific standard or any set of external requirements imported during the first phase, towards certification under these standards.

Monitor

Finally, automated verification tools should enhance the post-release integrity and monitoring of products. There are open-source and proprietary offerings on the market for software that can be installed on a device and perform multiple security functions based on real-time monitoring. However, these tools need to be carefully configured to perform their tasks without interfering with the device’s intended functionality. Automated scanners can generate such configurations based on their understanding of the device’s software and the weaknesses found therein.

These solutions become especially relevant when identifying security requirements with a severe impact, such as vulnerabilities introduced by the Linux kernel that require replacing the whole kernel. Manufacturers might deem this task too difficult or time-consuming to solve by design, but in many cases these issues are easy to solve through an active protection tool.

Conclusion

Robust and automatic analysis engines such as those described above are critical to reducing attack surfaces across IoT industries, limiting threats and eliminating the most common errors that have plagued the IoT security world to date.