The Internet of Things (IoT) enables the interconnection of physical and virtual devices based on interoperable communication technologies. Ultimately, this will result in a large portion of electronic devices having network connectivity – and every manufacturer of those devices will necessarily enter the software business. This puts embedded software at the center of the IoT technology evolution because it now serves as its critical technology foundation.

As a result of the IoT evolution, there is a redefined need for security due to the expanding scope of responsibility into an entirely new category of platforms and services. Gartner predicts that over 50 percent of Internet of Things (IoT) device manufacturers will remain unable to address threats emanating from weak security practices. While security vulnerabilities are problematic in any situation, with IoT applications, safety can become an issue when security is compromised because some of them power safety-critical products such as medical devices, automobiles, manufacturing equipment, and more.

Security vulnerabilities can enter a product as soon as developers begin writing code and, unfortunately, many are not detected until much later. IoT devices often do not use the traditional internet protocols where security mitigations are commonly focused. Instead, many use a combination of both traditional internet protocols and industry specific/proprietary protocols, which make existing penetration tools (such as those targeting HTTP interfaces or SQL injection attacks) harder to apply to IoT embedded devices. Embedded protocols are nearly immune to existing penetration tools simply because they don’t understand the protocols used.

Because of this, undiagnosed cybersecurity vulnerabilities could still be lurking. To combat this threat, security needs to be addressed during development, as it would be too costly to redesign these advanced systems after they have already shipped. Developing secure applications requires constant vigilance in all stages of development. This means using tools that are capable of detecting possible vulnerabilities when writing code, integrating modules, and testing compiled binaries on target hardware.

A new approach to identifying and testing security vulnerabilities

One of the most commonly used tools by security testers today is static application security testing (SAST). SAST is designed to analyze application source code, byte code, and binaries for common vulnerabilities, including coding and design conditions that might lead to potential security vulnerabilities. Adopting SAST is theoretically a good development practice, as it enables developers to know if there any issues with the software, how many there are, and what and where they are.

However, this method is not a catch-all solution because SAST tools do not actually execute the code. Instead, they attempt to understand what the code is doing “behind the scenes” to identify where errors are by analyzing elements such as syntax, semantics, and variable estimation, as well as control and data flow, to identify issues in the code.

SAST tools are also usually rule-based and run late in the development cycle, and the results when used alone can create potential false positives (when the tool reports a possible vulnerability that is not an actual vulnerability). This often leaves security engineers looking for a “needle in the haystack” when identifying the genuine vulnerabilities. Additionally, many SAST tools only help zero in on at-risk portions of the code to help developers find flaws more efficiently, rather than finding the actual security issues automatically. This can lead to time-consuming processes and incomplete analyses, which can be detrimental to the software development process.

To address these issues, there are new dynamic unit testing methods that actually expose software defects by generating a test case and confirming exploitability. Utilizing MITRE’s classification of a common weakness enumeration (CWE), the approach uses automated software testing methods to interrogate an application’s software code and identify possible weaknesses.

The community-developed CWE list serves as common language for describing software security weaknesses in architecture and code, and is a standard, common lexicon for tools detecting such potential weaknesses. In the CWE taxonomy, there are numerous weaknesses where the use of dynamic testing can highlight vulnerabilities – in particular, anything with hard errors such as the use of null pointers or dividing by zero.

Using dynamic testing, once a potential CWE is found, a test exploiting the identified issue is generated and executed. After execution, test tools can analyze the execution trace and decide if the potential CWE is a genuine threat. That issue can then be classified as a common vulnerability and exposure (CVE).

[Figure 1 | Dynamic unit testing methods can expose software defects by generating a test case and confirming exploitability. Once a potential CWE is found, a test exploiting the identified issue is generated and executed. After execution, test tools analyze the execution trace and decide if the potential CWE is a genuine threat, which is then be classified as a CVE.]

The approach is based on the “synthesis” of executions leading to specific software issues (e.g., the automatic construction of a dynamic test exploiting a given vulnerability), allowing for the identification and automatic testing of undiagnosed cybersecurity vulnerabilities. The construction of this exploit is then paired with its dynamic execution to determine if the vulnerability is exploitable. This type of dynamic testing performs an upfront analysis of the code to detect potential issues (similar to a static analyzer), which could contain false positives. However, once a potential issue has been identified, it then also attempts to perform “automatic exploit construction.”

Unlike static analysis-based approaches, this type of software security testing will only flag an issue if it is genuinely exploitable, mitigating the issues of false-positives. The generation of test artifacts allows for their future re-execution to demonstrate the mitigation of a potential issue after software redesign.

This becomes critical because security is more important than ever as new technologies continue to evolve that change the threat landscape. Every development team needs a comprehensive process to achieve its application security goals. Dynamic testing can further expose defects in software by generating a test case and confirming exploitability to find vulnerabilities more definitely, ultimately creating a more secure product.

Jeffrey Fortin is head of product management at Vector Software. In this role, he leads product management, driving business for all VectorCAST product lines into legacy markets as well as emerging market segments. Previously, Fortin served more than 16 years at Wind River. As director of product management, he oversaw product planning and strategy for Wind River’s Intelligent Device Platform (IDP), an IoT gateway software product. Also during his time there, he served as director of field engineering where he led field teams focused on Industrial, Medical, IoT, and Aerospace and Defense (A&D) applications.