- Quantitative Security Assessment based on Static Analysis
Software security was traditionally treated as an afterthought in the overall development cycle of software products, being introduced after the software product was implemented (or even used) mainly through the inclusion of external protection mechanisms (e.g., intrusion detection and prevention techniques). According to this approach, software was developed without security in mind, leading to potential introduction of security vulnerabilities, whereas the purpose of the external mechanisms was to prevent malicious individuals from exploiting any of the vulnerabilities that the product may contain. However, the increasing number of successful breaches that is observed lately[i], along with the devastating consequences that they have caused (e.g., Equifax Breach, Heartbleed, etc.) has led more and more software industries to shift their focus from those reactive techniques to more proactive approaches towards strengthening the security of their software products. In fact, the goal is to produce software that is as vulnerability-free as possible from the ground up, reducing, in that way, the potential exploitation points that can be utilized by an attacker, in case that the external protection mechanisms fail to prevent them from accessing the system.
The vast majority of the vulnerabilities that a software product contains stem from a small number of common programming errors, which are introduced by the developers during the coding phase, mainly due to their lack of security expertise and the accelerated production cycles that do not allow them to focus on the quality of the code they produce. Hence, appropriate tools are required to encapsulate the required security expertise and to help developers and testers detect and fix potential vulnerabilities early enough in the overall development cycle (i.e., preferable prior to the release of the software). One such mechanism is static analysis, which is a testing technique that allows the identification of potential issues (including security weaknesses) that reside in the source code of a software application, without requiring its execution. In fact, static analysis is considered one of the most effective mechanisms for detecting potential vulnerabilities that reside in the source code, and its adoption is highly recommended by well-known Secure Software Development Lifecycles (SSDLCs), including Microsoft’s SDL[ii], OWASP’s OpenSAAM[iii], and Cigital’s Touchpoints[iv]. According to the BSIMM initiative[v], static analysis is one of the main security activities that major technological firms such as Google, Microsoft, Adobe, and Intel use.
Static analysis provides important security-related information that could potentially be leveraged for measuring the security level of a given software application. In fact, being able to measure the security level of a software product under development frequently during its development cycle is very important for improving its security, since it is a common belief that “you cannot control something you cannot measure”. Hence, quantitative security indicators are crucial for the development of secure software. To this end, several models and mechanisms have been proposed recently in the literature that attempt to provide high-level quantitative security indicators (i.e., measures) that reflect important security aspects of a software application, by aggregating the low-level results produced by static analysis. The low-level warnings generated by static code analyzers, as well as the high-level measures derived from their sophisticated aggregation, are expected to aid the development of more secure software, as they can significantly aid decision making during the overall development.
To that end, one of the goals of the IoTAC project through its Software Security-by-Design (SSD) Platform is to provide a framework for monitoring and improving the security of software applications through static analysis that is properly configured to detect security issues. Most importantly, it aims to provide security evaluation models dedicated for IoT Software applications, which will leverage the outputs of the security-specific static analysis framework, as well as the expertise of security and IoT experts, in order to produce high-level measures that quantify important security aspects of IoT Software.
- IoTAC Software Security Evaluation Framework
Within the context of the IoTAC project, as part of the SSD Platform, we developed the Security Evaluation Framework (SEF), which is a mechanism that evaluates the security level of the source code of a given IoT software application in a quantitative manner, based on the results of security-specific static analysis. More specifically, SEF (i) integrates popular static code analyzers (e.g., SonarQube[vi]) that are properly configured to detect important security issues, and (ii) enables the calculation of high-level security measures by aggregating the low-level results of the security-specific static analysis. The high-level security measures are more intuitive and easily understandable (compared to the raw static analysis results) even by stakeholders with little or no technical knowledge, such as project managers, facilitating in that way decision making during the overall development of the software application. The high-level overview of SEF is illustrated in the Figure 1 below:
Figure 1: The high-level overview of the Security Evaluation Framework (SEF) of the IoTAC project
As can be seen by Figure 1, SEF receives as input a software product that needs to be analyzed with respect to its security. Then, it employs static analysis in order to detect potential security issues (i.e., security-related static analysis alerts) that may reside in the software. This is achieved mainly via the SonarQube platform, which is a popular static analysis platform, through its internal security profiles. Several popular open-source static code analyzers are utilized, including PMD[vii], CppCheck[viii], and FindBugs[ix], which are integrated into the Sonar Qube platform through dedicated plugins. Both the internal security profiles of SonarQube and the external static code analyzers are properly configured in order to detect important security issues (i.e., potential vulnerabilities) (e.g., SQL Injection, Cross-site Scripting, Memory Leaks, Weak Cryptography, etc.). Subsequently, the low-level static analysis alerts are fed to the Security Measures Computation mechanism, which aggregates them in order to compute the high-level security measures. IoT-specific security models are utilized (which leverage concepts from state-of-the-art security[x] and quality models[xi]) in order to determine (i) the high-level security measures that should be computed, and (ii) which low-level static analysis results should be aggregated (and in what way) in order to quantify those security measures. The output of SEF is a report containing the detailed results of the analysis, and particularly: (i) the calculated high-level security measures, and (ii) the low-level static analysis alerts that were utilized for computing those measures. Based on this report, project managers and developers can better plan their testing and refactoring activities in order to produce more secure software.
[i] https://www.comparitech.com/blog/information-security/cybersecurity-vulnerability-statistics/
[ii] https://www.microsoft.com/en-us/securityengineering/sdl
[iii] https://www.opensamm.org/
[iv] http://swsec.com/resources/touchpoints/
[vi] https://www.sonarqube.org
[viii] https://cppcheck.sourceforge.io/
[ix] http://findbugs.sourceforge.net/
[x] https://link.springer.com/article/10.1007/s11219-021-09555-0
[xi] https://www.sciencedirect.com/science/article/abs/pii/S0957417417303883
