Development teams are constantly challenged to assure the confidentiality, integrity and availability of their IoT products. Well known vulnerabilities are continually left exposed in connected products. Developers often lack the expertise and time required to identify and close new vulnerabilities. Tools that help developers and security engineers accomplish their goal of secure IoT products are required.
In the early days of software development, code was manually analyzed for quality defects and vulnerabilities. This type of code inspection is still used in agile peer review processes and potentially for high-value code within an application, but does not scale to meet the needs of modern technology. A report from McKinsey and Company noted for example that there are over 150 million software lines of code (SLoC) in a modern automobile. Attempting to manually review this code and still get the product to market on time would be impossible.
Identify Security Requirements
In order to define automated security tests, a team must first acquire an understanding of product threats. A threat model should be the first activity that any team undertakes. Threat models are often static documents that are rarely read, however, there are tools today that link threat model data with user stories and support the creation of automated tests that can be run throughout the dev process. Figure 1 shows an automated process for identifying device-specific security requirements.
click for larger image
Figure 1: Security Requirements Identification Process (Source: VDOO)
One useful example is the Robot scripting library from WE45. The Robot Framework is used by Quality Assurance teams to create Behavior Driven Development (BDD) tests. WE45 has developed scripts that allow engineers to define misuse cases attached to user stories within a threat model and then link those misuse cases directly to automated tests. This is based on the use of additional tools such as YAML scripts, OWASP ZAP, and other SAST/DAST tools.
Whether using a framework such as this or starting from scratch, teams must be able to build up a security requirements backlog. Security requirements can be derived from numerous sources. Product teams tailor requirements based on regulatory mandates, best practice guidelines, security technical implementation guides (STIGs) and of course threat models. These requirements are captured as either functional user stories or acceptance tests within the product backlog.
This effectively creates a Security Requirements Traceability Matrix (SRTM) that can be used to support the creation and execution of automated security tests. Security user stories can be flagged as security stories within the backlog. Additionally, these stories should include metadata that allows linkages back to the source of the security requirement (for example an IA control number or a STIG identifier) and should also include metadata related to the automated tests derived from the requirement (e.g., an automated test ID). This allows automated frameworks or other tools to have full traceability back to the original requirement.
Infrastructure or peer application emulators can also prove useful when needed to test new types of functionality enabled by the IoT. One example – an emulator previously developed to test a complex automotive cryptographic certificate management system supporting Vehicle-to-Vehicle (V2V) communications. The test team defined mis-use cases at project inception and designed an emulator to automatically run through those mis-use cases. This worked by identifying functional security requirements for the system at the application layer and then building negative test cases into the emulator that test entire threads of functionality. For example, the tool could automatically and continuously attempt to initiate a certificate management transaction and then analyze whether appropriate access restrictions were in place and whether an event was written to the log file.
Integrate Security into Product Design
Once security requirements are documented, the product design phase can benefit from approaches such as model-based security testing (MBST). MBST can be used to validate that security requirements have been met within a product design. MBST is based on the formal modeling of requirements. Today’s product teams employ agile development methods which means that the design process is iterative over a series of development sprints. This allows designers to continuously re-evaluate the cyber security posture of their design based on feedback from security tools executed on code developed during the sprint.
For example, a scan of an IoT product might find that read access to sensitive configuration files was not properly restricted within the device. The results inform the developer of the need to implement more restricting privileging within the file system. Tools can be setup to also automatically open an issue within JIRA to revisit the design of the access control model for the product in line with applicable industry best practice recommendations, such as “implement role-based access controls” and “require elevated privileges for access to sensitive data”, allowing the design team to make updates to the security architecture.
The security tools that perform these scans during each sprint can be configured to run automatically. Open source automation frameworks such as Guantlt provide plug-ins directly with git to support pre-commit checks that automatically alert a developer on his or her desktop that basic errors have been introduced. This allows the developer to correct the mistake before committing.
Continuous integration tools such as Jenkins, Bamboo, Travis, Buildbot, Thoughtworks and others can be setup to integrate security test tools that automatically run on each build. Jenkins for example incorporates the Warnings Next Generation Plugin that collects and visualizes issues collected by various security analysis tools. This includes code analysis and run-time application security tools. Tools are also available (e.g., CodeBurner) that effectively manage the execution and reporting of multiple static analysis test tools.
Different security tools can be automated to identify known vulnerabilities. For example, static code analysis can identify and report on known signatures in code. These are useful for identifying issues such as configuration issues, hard-coded credentials, vulnerabilities in third-party libraries, and vulnerabilities mapped to CVEs.
Binary analysis of IoT device firmware analysis can also be used to efficiently identify known vulnerabilities and there are tools available today such as VDOO’s Vision that can analyze IoT products based on Linux, Android and Widows platforms. Tools typically used to identify quality issues in code can also be run automatically within the CI and can support the quick identification of basic issues. These include findbugs, sonarqube and tools such as copy/paste detector (CPD) as examples.
More in-depth testing can be incorporated into the CI to begin identification of potential zero-day vulnerabilities as well. These are vulnerabilities that are not yet known but may be found by a dedicated security researcher or bad actor. Tools based on symbolic execution are efficient at finding unknown vulnerabilities but may take hours to run for even small binaries. Symbolic testing analyzes programs to determine the inputs that cause a program to execute. Some tools such as VDOO’s Vision can be integrated into the CI environment to provide developers with both fast firmware analysis and more in-depth analysis capabilities aimed at identifying both unknown and known vulnerabilities.
Know the Basics
Although security automation is a powerful tool, it is not a panacea for secure development of IoT products. Development teams still require some minimum level of cyber security knowledge and expertise to identify unique product threats and interpret test tool output as well as to secure the integration of IoT hardware and software components. It is the responsibility of all developers to have at least a basic level of understanding of security issues associated with their products and each product team should have security engineering support that understand how to run and interpret automated security tool outputs.
Brian Russell is a Security Advisor for VDOO and Chair of the Cloud Security Alliance (CSA) Internet of Things (IoT) Working Group. He is also a Chief Engineer for Cyber Security Solutions at Leidos – a Fortune 500 Government Contractor where he has led Research and Development (R&D) for secure cloud systems, autonomous vehicles, permissioned blockchain networks, and cryptographic key management systems. Brian is an adjunct professor with the University of San Diego (USD) in the graduate Cyber Security Operations and Leadership Program and co-author of the book Practical Internet of Things Security. He is also a SANS Analyst.