Identifying and Testing Undiagnosed Cybersecurity Vulnerabilities
Identifying and Testing Undiagnosed Cybersecurity Vulnerabilities
The Internet of Things (IoT), brings a new level of interconnectedness, and thus hackability to our world. What strategies should be used to secure IoT?
Join the DZone community and get the full member experience.Join For Free
Technologies such as the Internet of Things (IoT) have a profound effect on the software development industry because they enable the interconnection of the physical and virtual world based on interoperable communication technologies. Ultimately, this will result in a very large portion of electronic devices having network connectivity -- and every manufacturer of those devices will then enter the software business.
IoT has also expanded the scope of responsibility into an entirely new category of platforms and services, redefining security needs. Cybersecurity vulnerabilities are problematic in any situation, but IoT applications often power critical machines such as automobiles, healthcare devices, manufacturing equipment and much more, so safety can become an issue if security is compromised.
A New Era of Security Risks
In November of 2016, The Associated Press profiled a report issued by the Department of Homeland Security (DHS) that quoted former Homeland Security Secretary Jeh Johnson as saying, “Securing the Internet of Things has become a matter of homeland security." The DHS report recommended immediate action by software developers and other stakeholders in the development and commercialization of IoT devices.
Gartner predicts that the number of connected things in use will reach 25 billion by 2020.  Embedded software is at the center of the rapidly growingly IoT technology evolution because it serves as the critical technology foundation.
However, the requirements for securing IoT devices is complex, as these devices do not use the traditional web stack where security mitigations are commonly focused. Instead, they use a combination of internet protocols as well as embedded protocols, so it is hard to apply existing penetration tools (such as those targeting HTTP interfaces or SQL injection attacks) to such devices, given their development is typically done in C or C++. Embedded protocols are nearly immune to these because they don’t understand the protocol.
Because of this, undiagnosed cybersecurity vulnerabilities could still be lurking. Security vulnerabilities can enter a product as soon as the first few lines of code are written, but the real danger is if they are not detected until much later. Developing secure applications requires constant vigilance in all stages of development. Just like quality, security is a process that is best implemented at inception, and challenges need to be addressed during development because it will be too costly and complex to redesign these advanced systems after they have already been shipped. This means using tools that are capable of detecting possible vulnerabilities when writing code, integrating modules, and testing compiled binaries on target hardware.
Developing Secure Devices
Gartner also predicts that over 50% of IoT device manufacturers will remain unable to address threats emanating from weak security practices .
One of the most commonly used tools by security testers is Static Application Security Testing (SAST). This type of testing 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: are there any issues with the software; how many; and what and where are they? Assessing the code with a static analyzer will provide some direction, but is not a catch-all solution, especially when security is at stake. This is because SAST tools do not actually execute the code, but instead, try to understand what the code is doing "behind the scenes" to identify where errors are. They analyze elements such as syntax, semantics, variable estimation, as well control and data flow to identify issues in the code.
SAST is usually rule-based and runs 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). That leaves security engineers looking for a ‘needle in the haystack’ when identifying the genuine vulnerabilities. Furthermore, 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 as well as incomplete analyses, both of which can be detrimental in the software development world.
To address this, new dynamic unit testing methods are emerging that actually expose defects in software 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 formal CWE list serves as a 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.
In this dynamic testing approach, 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.
This 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 genuinely exploitable. This type of dynamic testing performs an upfront analysis of the code to detect potential issues (much like a static analyzer), which could actually contain false positives. However, once a potential issue has been identified, it also attempts to perform "automatic exploit construction."
Unlike approaches based on static analysis, 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.
As the threat landscape continues to evolve and change with the growth of new technologies, security becomes increasingly important – and complex. Static analysis security testing has benefits, but 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.
Opinions expressed by DZone contributors are their own.