Below is the updated list of the top 25 most dangerous software weaknesses of 2022, which is maintained by the Common Weakness Enumeration (CWE)^[1].
Figure 1: The list of the top 25 most dangerous software weaknesses of 2022 as  maintained by the Common Weakness Enumeration (CWE)

This list contains the most common and impactful from a security viewpoint weaknesses of software systems. It is interesting that weaknesses like “Out-of-bounds Read”, “Out-of-bounds Write”, and “Improper Input Validation” rank so high in the list. This shows that these relatively simple mistakes can have significant consequences on a software system, whereas, although they are issues that can be easily fixed in the code, they are still among the most common weaknesses found in software systems. In order to stress how easily those critical vulnerabilities could be avoided with simple code checks, we provide the following examples that are presented in the table below:

Table 1: Examples of common vulnerabilities along with their fixes

The first example, which is depicted in the table above, corresponds to a Buffer Overflow vulnerability. This vulnerability is popular in unsafe programming languages like C and C++. This security issue arises when the software application does not perform bounds checking and allows input to write beyond the end of an allocated buffer, overwriting in that way adjacent memory locations. These locations may contain data or executable code, leading the program to unexpected behavior including memory access errors, incorrect results, and crashes. In the given example, the function fun() receives a parameter str and copies this parameter to the buffer array, without checking their bounds, potentially leading to an overflow. This issue is addressed by properly checking the sizes of the two buffers before performing the copy.

The second example that is presented in the table above corresponds to an OS Command Injection vulnerability. This vulnerability arises when the software product constructs an OS command using user-defined (i.e., tainted) inputs, without proper validation or neutralization. This could allow attackers to execute unexpected and dangerous commands directly on the operating system. In the given example, the p variable receives user-defined data from a user request, and these data are directly used for executing a command. In order to mitigate this issue, as shown in the figure above, the user-defined input should be checked for illegal characters (i.e., input validation), and in case that illegal characters are present, it should be sanitized by removing these illegal characters (i.e., input sanitization/neutralization). In addition, instead of string concatenation, the final command should be constructed by using a special method (i.e., parameterization). Alternatively, the command and the data could be passed as individual parameters to a ProcessBuilder object instead of using the Runtime.exec() method.

The above examples provide further support to the common belief that the majority of the critical vulnerabilities are introduced by relatively simple code mistakes made by developers during the implementation, which could have been easily avoided at first place. It also stresses the need for mechanisms (e.g., static code analyzers, etc.) able to help developers detect and eventually fix those simple issues prior to the release of the software on the market.

In order to address the aforementioned challenge, within the context of the IoTAC project and as part of our Security-by-Design (SSD) Platform, we propose the Security Evaluation Framework (SEF). It is a framework that applies security-specific static analysis in order to detect security issues (i.e., potential vulnerabilities) that reside in the source code of a given software application and provide feedback on how these issues can be fixed. The regular execution of SEF during the development of software applications could lead to the identification and elimination of critical vulnerabilities prior to their release on the market, leading to more secure solutions. More information about the SEF component of the SSD platform can be found in one of our previous posts.

^[1] https://cwe.mitre.org/top25/archive/2022/2022_cwe_top25.html

The post Simple coding mistakes that can lead to critical vulnerabilities appeared first on IoTAC.

To this end, a lot of effort has been dedicated in the literature to the prediction of vulnerable software components using software attributes extracted by the source code. In these studies, researchers commonly train machine learning models based on either software metrics (e.g., cohesion, coupling, and complexity metrics) or text features, in order to predict whether the analyzed component is potentially vulnerable or not. However, these approaches do not predict the number of vulnerabilities in future versions. An indication of the expected number of vulnerabilities and the trends of their occurrences can be a very useful tool for decision makers, enabling them to prioritize their valuable time and limited resources for testing an existing software project and patching its reported vulnerabilities. For this purpose, there is a need for forecasting models that can predict the trend and the number of vulnerabilities that are expected to be discovered in a specific time horizon for a given software project.

In an attempt to address the aforementioned challenges, within the IoTAC project, and as part of the Security by Design (SSD) Platform, we built models for forecasting the future evolution of the number of vulnerabilities that a given project may have. More specifically, we empirically examined the capacity of statistical and deep learning (DL) models to forecast the future number of vulnerabilities that a software product may exhibit and we compared their performance. The high-level overview of our methodology is depicted in the figure below:

Figure 1: The high-level overview of our approach for building and evaluating the statistical and deep learning models for forecasting the evolution of software vulnerabilities

As can be seen by the figure above, in order to build the forecasting models, we initially collected the historical vulnerability data of five popular software applications (Microsoft Office, Apple macOS X, Ubuntu Linux, Internet Explorer, and Google Chrome) for a duration of 20 years from the National Vulnerability Database (NVD). These data were used in order to construct the training and testing sets that are required for building the models. Based on these data, we built several statistical models (e.g., ARIMA, Croston, etc.) and Deep Learning models (e.g., MLP, RNN, CNN, etc.) that are able to predict the future number of vulnerabilities for a horizon of 24 months, and we evaluated their performance based on their goodness-of-fit, as well as on their Mean Absolute Error (MAE) and Root Mean Square Error (RMSE) when applied to previously unseen data. The results of the analysis are depicted in the figure below.

Figure 2: The Mean Absolute Error (MAE) of the best statistical and deep learning models of each studied software application

Figure 3: The Root Mean Square Error (RMSE) of the best statistical and deep learning models of each studied software application

As can be seen from the figures above, the DL models demonstrate slightly better predictive performance compared to the statistical models in terms of their MAE and RMSE in all five studied projects. However, after applying hypothesis testing, we figured out that this difference is not observed to be statistically significant. Hence, based on the above analysis, we can state that both DL and statistical models demonstrate almost similar predictive performance. In addition to this, another interesting observation is that it seems that the capacity of the models to provide sufficient predictive performance seems to depend on the project itself rather than on the type of the selected forecasting models. More details about our work can be found in the associated published paper.

The post Forecasting the evolution of software vulnerabilities appeared first on IoTAC.

These issues manifest themselves as actual vulnerabilities in the source code of the software system during the Coding phase, unless they are detected and mitigated promptly.  Moreover, these types of vulnerabilities are more difficult and expensive to be fixed later on, as they require the software engineers to revisit the original requirements and make changes to the design and source code of the underlying system in order to be in line with the new specifications. This results in an increasing need for extensive refactorings to the existing code base, but also in potential corruptions of previously secure code, which in turn introduces new bugs and vulnerabilities^[2]. Hence, there is a need for methods and mechanisms able to verify and validate the correctness and the completeness of security requirements defined by stakeholders (e.g., software engineers, security experts, etc.) upon their definition and propose potential recommendations for corrections/improvements, in order to help software engineers identify and eliminate potential inconsistencies early enough during the overall SDLC, when their correction is relatively cheap and easy.

In order to address the aforementioned issues, within the context of the IoTAC project, and as part of our Software Security by Design (SSD) platform, we designed and developed the Software Security Requirements Verification and Validation (SSRVV) mechanism, whose purpose is to verify and validate the correctness and the completeness of the security requirements that are defined by the user and provide recommendations for their improvement. In particular, the novel security requirement evaluation mechanism that has been developed (i) compares a given security requirement to a curated list of well-defined security requirements (normally retrieved from international standards and other projects) based on similarity checks, (ii) identifies inconsistencies, and (iii) proposes refinements^[3]. The high-level overview of the aforementioned mechanism is depicted in the figure below.

As can be seen by the figure above, the mechanism receives as input the Ontology instances of a security requirement that requires evaluation. In fact, the Ontology instances, which are the main requirement-specific semantic concepts (e.g., Action, Actor, Object, etc.) are produced by the Software Security Requirements Specification (SSRS) mechanism of the SSD platform, which was described in one of my previous posts^[4]. Subsequently, those instances are compared to the ontology instances of the carefully curated list of security requirements that are stored in the Software Security Requirements Knowledgebase. In particular, similarity checks are performed between the user-defined requirement and those of the curated list, utilizing popular Natural Language Processing (NLP) toolkits (e.g., WordNet with NLTK^[5]). Based on the value of the similarity score reported by the similarity checks, several recommendations for improvement are provided. These recommendations include: (i) rephrasing the analyzed security requirement based on a highly similar requirement found in the curated list, (ii) inclusion of additional security requirements that are observed to be closely related to the analyzed requirement, and (iii) changing the priority of the analyzed security requirement based on the priority that is set to similar requirements in the curated list. Hence, the proposed mechanism helps software engineers improve the correctness and completeness of the list of security requirements that they define for a specific software project.

^[1] https://iotac.eu/software-security-requirements-specification/

^[2] https://ieeexplore.ieee.org/document/7819389

^[3] https://ieeexplore.ieee.org/document/9742019/

^[4] https://iotac.eu/software-security-requirements-specification/

^[5] https://www.nltk.org/

The post Software Security Requirements Verification and Validation appeared first on IoTAC.

In order to address the aforementioned issues, within the context of the IoTAC project, and as part of our Software Security by Design (SSD) platform we propose a novel Software Security Requirements Specification (SSRS) mechanism, able to automatically identify the main concepts of a given set of security requirements expressed in natural language by applying syntactic and semantic analysis, and subsequently turn them into more well-structured form, i.e., ontology objects. The purpose of the SSRS component is to help software engineers formally specify security requirements in a well-defined and structured way, without having to utilize tedious templates or learn complex formal specification languages. The high-level overview of the SSRS component is illustrated in the following figure.

As can be seen by the figure above, the proposed mechanism receives as input security requirements expressed in natural language (i.e., pure text). Then the textual security requirements are processed, through a process that consists of two main steps, namely the Syntactic Analysis, which identifies the main grammatical terms (e.g., noun, verb, etc.) of the processed requirement along with their grammatical relationships (e.g., subject-verb-object, etc.), and the Semantic Analysis, which identifies the main semantic concepts (e.g., Action, Actor, Object, etc.) of the requirement along with their semantic relations.

The Syntactic Analysis step receives as input the requirement expressed in natural language and applies tokenization in order to split the sentence into word tokens, as well as lemmatization in order to derive the uninflected form of each word token. Subsequently, it applies part-of-speech tagging, in order to identify the grammatical category of each word and dependency parsing to determine the grammatical relations between them. For the above procedure, the Mate Tools^[2] were utilized, which are well-known tools for performing syntactic analysis.

In the next step, the results of the Syntactic Analysis step, and particularly the identified grammatical terms and relations, are provided as input to the Semantic Analysis mechanism, in order to be mapped to semantic terms and semantic relationships. Initially, a semantic role labeling process is performed to assign labels to words or phrases that indicate their semantic concept in the sentence, using the semantic role labeler provided by the Mate tools. However, since this semantic role labeler is able to detect only generic thematical concepts and relations (e.g., acceptor, property, etc.),  it has been extended in order to also detect the main requirement-specific concepts (i.e., Actor, Action, etc.), based on a set of custom rules. In brief, as can be seen by the figure with the overview of the SSRS component above, initially the Priority and the Action of the requirement are identified. Subsequently, for each Action, the associated Actor and Object are identified. Finally, for each identified Object, several Properties (e.g., requirement prerequisites, etc.) are detected and reported.

All the identified requirement concepts are stored in a dedicated Ontology, the Security Requirements Knowledge Base. The schema of the aforementioned ontology is illustrated in the following Figure.

As can be seen by this figure, the ontology captures the main concepts of a security requirement along with their relationships. The ontology is an important element of the SSD Platform, as it forms the reference point for the verification and validation of user-defined security requirements, as well as of the requirement adherence check mechanism that will be developed. It should be noted that the ontology along with the security requirements that will be collected throughout the project will be made publicly available in order to facilitate future research.

^[1] G. McGraw, “Software security,” IEEE Security & Privacy, 2004
^[2] https://code.google.com/archive/p/mate-tools/

The post Software Security Requirements Specification appeared first on IoTAC.

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.

2. 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/

[v] https://www.bsimm.com/

[vi] https://www.sonarqube.org

[vii] https://pmd.github.io/

[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

The post IoTAC Software Security Evaluation Framework appeared first on IoTAC.

Vulnerability prediction is responsible for the identification of security hotspots, i.e., software components (e.g., classes) that are likely to contain critical vulnerabilities. For the identification of potentially vulnerable software components, vulnerability prediction models (VPM) are constructed, which are mainly machine learning models that are built based on software attributes retrieved primarily from the source code of the analyzed software (e.g., software metrics, text features, etc.). The results of the vulnerability prediction models are highly useful for developers and project managers, as they allow them to better prioritize their testing and fortification efforts by allocating limited test resources to high-risk (i.e., potentially vulnerable) areas.

Text mining-based VPMs have demonstrated the most promising results in the related literature [1]. The first attempts in the field of text mining vulnerability prediction focused on the concept of Bag-of-Words (BoW) as a method for predicting software vulnerabilities using text terms and their respective appearance frequencies in the source code. Researchers have recently shifted their focus from simple BoW to more complex approaches, investigating whether more complex textual patterns in source code can lead to more accurate vulnerability prediction. In particular, a common approach that is adopted recently is the transformation of the source code into word token sequences and their utilization of deep neural networks capable of learning data sequences (e.g., Recurrent Neural Networks).

Since neural networks operate on numerical data, the token sequences need to be properly transformed. In the literature, word embedding vectors are widely used for this purpose. Word embedding refers to the representation of words for text analysis, which is typically in the form of a real-valued vector that encodes the meaning of the word in such a way that words that are close in the vector space are expected to have similar meanings. Existing VPMs follow mainly two different approaches for embedding the tokens into vectors, either by training the embedding layer alongside the vulnerability predictor, or by using an external word embedding algorithm (e.g., word2vec) to generate the vector representations of the tokens and use the produced embeddings as input to the vulnerability predictor (which is trained separately). Although both approaches have their merits, limited focus has been given on comparing them with respect to their ability to lead to accurate vulnerability predictions.

The aim of the research is to demonstrate the value of sophisticated embedding algorithms (e.g., word2vec, fast-text) in text mining-based vulnerability prediction by showcasing their contribution to the effectiveness and efficiency of the VPMs and comparing them to the use of a trainable embedding layer that updates its values during VP classifier training.

2. IoTAC Vulnerability Prediction Models

Within the context of the IoTAC project, as part of the Software Security-by-Design (SSD) Platform, we developed vulnerability prediction models based on deep learning, utilizing as input the sequences of word tokens that reside in the source code of the component, and word embedding vectors for their effective representation. We have focused both on utilizing a trainable embedding layer and external word embedding algorithms, in an attempt to evaluate which of the two option leads to better predictive performance. A high-level overview of the proposed models is illustrated in the figure below.

Figure 1 – The high-level overview of the Vulnerability Prediction Models of the IoTAC project

As illustrated in the figure above, the source code of a software component is provided as input to the model and, subsequently, text tokenization is applied in order to extract the word tokens and construct their corresponding sequence. Then, the token sequences are transformed into numerical vector, through the utilization of word embedding. The derived word embedding vectors constitute the word embedding layer, i.e., the input layer of the DNN, which is the core element of the model. As already stated, for constructing the models, we consider both internal word embeddings (i.e., a word embedding layer that is trained along with the prediction model) and two popular word embedding algorithms to generate the word embedding vectors, namely word2vec[1] and fast-text[2].

The output of the model is a vulnerability flag (i.e., a binary value between 0 and 1) indicating whether the given component is potentially vulnerable (i.e., 1) or not (i.e., 0), and a vulnerability score (i.e., a continuous value within the [0,1] interval) denoting how likely it is for the component to be vulnerable. The developers can utilize the output of these models for prioritizing their testing and fortification efforts. For instance, the software components can be ranked based on their vulnerability score and the refactoring activities can start from those components that are more likely to contain vulnerabilities.

The evaluation results led to some interesting conclusions regarding the effectiveness of word embeddings in vulnerability prediction. As can be seen by the figure below, all the models that are built utilizing word token sequences are in general effective in predicting the existence of vulnerabilities in software. In addition to this, the utilization of external word embedding algorithms and specifically of the word2vec leads to better predictive performance, indicating that the utilization of external word embeddings may be a more promising solution for vulnerability prediction.

Figure 2 – Evaluation results of the text mining-based Vulnerability Prediction Models using “internal” and “external” embedding vectors

More information about the work presented in this blog post, including information about the construction of the machine learning models and the evaluation results, can be found in a recent publication that is available here. More information about the SSD Platform can be found in our previous post.

[1] https://radimrehurek.com/gensim/models/word2vec.html
[2] https://radimrehurek.com/gensim/models/fasttext.html

References
[1] S. Chakraborty, R. Krishna, Y. Ding, and B. Ray, “Deep learning based vulnerability detection: Are we there yet,” IEEE Transactions on Software Engineering, 2021.

The post Vulnerability prediction based on Natural Language Processing Techniques appeared first on IoTAC.

A software vulnerability is defined as a weakness in the specification, development, or configuration of software such that its exploitation can violate a security policy. The exploitation of a single vulnerability can have far-reaching consequences both for the user and for the owning enterprise of the compromised software, including financial losses and reputation damages. For instance, Equifax Breach (CVE-2017-56381) allowed criminals to expose the personal data of more than 143 million Equifax customers, leading to a total cost of $1.35 billion according to the company’s financial results of the first quarter of 2019. In fact, critical security breaches, including Equifax Breach and Heartbleed (CVE-2014-0160) were caused by flaws that resided in the source code and could have been avoided if these flaws were detected and eliminated in the first place. Hence, in order to avoid potential damages, software development enterprises are seeking mechanisms able to assist the identification and elimination of vulnerabilities as early in the development cycle as possible.

One such mechanism is static analysis, which is a white-box testing technique that searches for potential software bugs (including vulnerabilities) in software products by analyzing their source code without requiring its execution. Automatic static analysis (ASA) is considered an important technique for adding security during the software development process. This belief is expressed by several experts in the field of software security (e.g., Gary McGraw, Brian Chess, and Michael Howard), while almost all the well-established secure software development lifecycles (SDLCs), including the well-known Microsoft’s SDL[1], OWASP’s OpenSAAM[2], and Cigital’s Touchpoints[3], propose the adoption of static analysis as the main mechanism for adding security during the coding phase of the SDLC. In addition, ASA is a security activity commonly adopted by major technology firms like Google, Microsoft, Adobe, and Intel, as reported by the BSIMM[4] initiative.

Despite its effectiveness in detecting security vulnerabilities early enough in the development process, the practicality of ASA is hindered by the fact that it produces a large number of warnings (i.e., alerts) that need to be manually inspected by developers in order to decide which of those require immediate care. More specifically, ASA produces a large number of False Positives, i.e., alerts that do not correspond to actual issues, due to the approximations that ASA is obliged to make in order for the analysis to complete in a reasonable time, whereas even some of the actual issues that are reported by ASA (i.e., True Positives), may not be critical from a security viewpoint. Hence, there is a strong need for more accurate static code analyzers, or mechanisms able to post-process the results of static code analyzers and report those warnings that are more critical from a security viewpoint. Since building a flawless static code analyzer is considered an undecidable problem in the literature, researchers have shifted their focus towards the latter approach.

2. IoTAC Security Alerts Criticality Assessor

Within the context of the IoTAC project, in an attempt to address the aforementioned problem, we proposed a novel mechanism for assessing the criticality of security-related static analysis alerts. In particular, we developed a self-adaptive technique, the Security Alerts Criticality Assessor (SACA), for classifying and prioritizing security-related static analysis alerts based on their criticality, by considering information retrieved from (i) the alerts themselves, (ii) vulnerability prediction, and (iii) user feedback. The proposed technique is based on machine learning models, particularly on neural networks, which were built using data retrieved from static analysis reports of real-world software applications. The high-level overview of the tool is presented in the following Figure.

Figure 1: The high-level overview of the Security Alerts Criticality Assessment (SACA) mechanism

As can be seen in the figure above, a software project is provided as input to the system. Initially, security-specific static analysis is employed in order to retrieve the static analysis alerts that are relevant to the selected project. In addition to this, vulnerability prediction models are employed in order to compute the vulnerability scores of its software components, which reflect the likelihood of each component to contain vulnerabilities. Then, the alerts along with the vulnerability scores are provided as input to the Security Alerts Assessor (SAA), which is a neural network that assesses how critical each one of the alerts is from a security viewpoint. More specifically, for each one of the received alerts it reports (i) a criticality flag (i.e., a binary value between 0 and 1, with 1 denoting that the corresponding alert is considered critical and with 0 denoting that the alert is considered non-critical), and (ii) a criticality score (i.e., a continuous value in the [0,1] interval denoting how likely it is for the alert to be critical from a security viewpoint). Hence, the developer can filter out those alerts that are not marked as critical by the model, or rank the alerts based on their criticality score, starting by fixing those alerts that are more likely to correspond to critical vulnerabilities first, increasing, in that way, the probability of detecting and mitigating actual vulnerabilities.

As illustrated in the figure above, the user can also correct the outputs of the model, and the SAA can be retrained (on demand) based on the received user feedback. In that way, the SAA adapts to the specific characteristics of the software product to which it is applied and provides more accurate assessments for the selected product. This is important since the criticality of specific alerts (security weaknesses) also depends on the type of the product to which they belong. For instance, cross-site scripting (XSS) weaknesses may be important for web applications, but irrelevant for offline applications. Hence, the self-adaptiveness of the proposed approach enables it to fit the assessments to the needs of the corresponding software project to which it is applied.

The Security-related Alerts Assessor (SAA) is built as part of the Security Assurance Module of the Software Security-by-Design (SSD) Platform of the IoTAC Project. More information about the SAA, including information about the construction of the machine learning models and the evaluation results, can be found in a recent publication that is available here. More information about the SSD Platform can be found in our previous post.

[1] https://www.microsoft.com/en-us/securityengineering/sdl
[2] https://owasp.org/www-project-samm/
[3] http://www.swsec.com/resources/touchpoints/
[4] https://www.bsimm.com/

The post The IoTAC Software Security Static Analysis Alerts Assessor appeared first on IoTAC.

The high interconnectivity that characterizes modern IoT Systems, along with the increasing accessibility of their devices through the Internet, renders their security an aspect of major concern for IoT users and providers. The importance of securing IoT Systems is further supported by the important security incidents that have been reported in IoT Platforms recently (e.g., Mirai IoT botnet^{[1] [2]}, Silex Malware^[3]), which led to the infringement of critical security requirements, including privacy, integrity, and availability, as well as to important financial losses and reputation damages to the owning companies (i.e., IoT Providers).

An effective way of securing an IoT Platform is by securing its architecture, which can be achieved through conformance to International IoT Security Standards and the deployment of security countermeasures, such as intelligent attack detection, prevention, and mitigation mechanisms, security gateways, honeypots, etc. Apart from the IoT Architecture, in order to effectively secure an IoT System, the software that is running on the different nodes of an IoT System (or Platform) should be also considered. If this software contains vulnerabilities, the security of the overall system could be compromised, regardless of how secure the overall architecture may be, following the “security of the weakest link” principle. Hence, in order to ensure the security level of an IoT Platform, the security level of the software that it is running on its nodes should be assessed, optimized, and, ideally, certified.

Traditionally, software security was considered an afterthought in the overall Software Development Lifecycle (SDLC), being added after the software application has been deployed or even used, by deploying mechanisms aiming to prevent malicious individuals from exploiting their vulnerabilities. However, the ability of the attackers to bypass the deployed countermeasures has forced recently software development enterprises to shift their focus towards the concept of Security by Design, i.e., towards building software that is highly secure (i.e., vulnerability free) from the ground up. According to the Security by Design concept, security should be monitored and optimized at all phases of the SDLC, and essentially to be the concept that will guide the overall development (decisions). This concept is depicted in the following figure.

Figure 1: The traditional Software Development Lifecycle (top) and the Software Development Lifecycle that adopts the Security-by-Design paradigm (bottom). According to the Security-by-Design concept, security is added at each phase of the SDLC, through the provision of suitable security mechanisms.

To this end, IoTAC, apart from proposing a secure IoT Architecture, will attempt to provide solutions for assessing, optimizing, and certifying the security of IoT Software Applications, in order to provide a holistic approach in securing a given IoT System. It will provide proactive mechanisms for monitoring and optimizing security throughout the overall SDLC of IoT Software Applications.

2. The IoTAC Software Security by Design (SSD) Platform

Within the context of the IoTAC Project, an independent platform, the Software Security by Design (SSD) Platform, will be developed, with the aim to provide solutions for assessing, improving, and certifying the security level of IoT Software Applications throughout the overall SDLC. An overview of the envisaged SSD Platform is provided in the figure below:

Figure 2: The high-level overview of the IoTAC Software Security by Design (SSD) Platform.

As can be seen by the figure above, the SSD Platform will consist of 3 core modules, namely (i) the Design and Requirements module, (ii) the Software Security Assurance (or Assessment) Module, and (iii) the Software Security Certification Module. The main functionalities of these modules are described in what follows.

• Design and Requirements Module: The purpose of this module is to provide means for monitoring (i.e., measuring) and improving (i.e., optimizing) the security level of a software application during the Design and Requirement phases of the SDLC. To this end, this module will provide the following core functionalities (i.e., components):

• • Software Security Requirements Specification: This component is meant to facilitate (simplify) the specification of the security requirements of a given software product. It will enable the user to define the desired security requirements into natural language, avoiding enforcing them to use tedious templates.

• • Software Security Requirements Verification and Validation: The purpose of this component will be to evaluate the correctness and completeness of the software security requirements that are defined by the user and provide recommendations regarding their improvement.

• • Software Security Requirements Adherence Check: This component is responsible for evaluating whether the final IoT software application adheres to the originally imposed security requirements.

• Software Security Assurance Module: The purpose of this module is to provide means for monitoring and improving the security level of a software application during the Coding and Testing phases of the SDLC. To this end, this module will provide the following core functionalities (i.e., components):

• • Quantitative Software Security Assessment: The purpose of this component is to provide a quantitative expression of the internal security level of an IoT Software application, based on the existence of potential security issues that may reside in their code. This component will be based on state-of-the-art concepts from the fields of software quality and software security evaluation, as well as on popular decision-making techniques.

• • Vulnerability Prediction: This component is responsible for identifying security hotspots, i.e., software components that are likely to contain security vulnerabilities. It will be based on vulnerability prediction models that will be built based on advanced machine learning techniques (mainly deep learning) and popular vulnerability datasets.

• Software Security Certification Module: The purpose of this module is to provide solutions for certifying the security of a given IoT Software Application, based on project-specific security evaluations and on conformance to international security standards and best practices. As can be seen by the figure above, this module will take into consideration: (i) the adherence of the software application to the originally imposed software security requirements, (ii) the security of its source code based on the code-level security assessment and vulnerability prediction reports, and (iii) the adherence of the application to requirements retrieved from international security standards and best practices. The module will produce a certificate, certifying the security level of the analyzed software, along with a report of things that require fix.

From the above analysis, it is clear that the IoTAC Project, apart from introducing a Secure IoT Architecture, will provide solutions (i.e., mechanisms) for monitoring, improving, and certifying the security level of the software applications that are running on IoT Platforms, implemented as an independent platform, the Software Security by Design (SSD) Platform. Hence, IoTAC will provide a holistic approach for securing IoT Platforms, through the provision of a novel Secure Reference IoT Architecture, as well as a platform for securing the software that is running on IoT Platforms.

^[1] https://ieeexplore.ieee.org/document/8538636
^[2] https://ieeexplore.ieee.org/document/9011598
^[3] https://www.sciencedirect.com/science/article/pii/S1877050920319487

The post The IoTAC Software Security by Design (SSD) Platform – Concept and Preliminary Overview appeared first on IoTAC.