As discussed in one of my previous blog posts[1], although most of the software vulnerabilities stem from a small number of common programming errors that are introduced by the developers during the Coding phase of the software development lifecycle (SDLC), a significant portion of the security vulnerabilities are also introduced during the Design and Requirement phases, mainly due to incorrect, vague, or missing security requirements. Although having appropriate tooling that enables the specification of security requirements in a uniform, concrete (i.e., well-structured), and clear way is necessary, it is not enough for ensuring that no security issues will be introduced. Even when security requirements are clearly defined and misinterpretations are avoided, they may be inherently incorrect (i.e., they may define a security criterion in a wrong or incomplete way) or they may imply additional security requirements to be covered by the system, which may have been unconsciously or deliberately omitted during the requirements specification phase. For instance, there may be a well-structured security requirement that may state that a specific cryptographic algorithm (e.g., DES or AES) should be used by the system for data exchange, but it may not provide any specification about the length of the cryptographic key, or the priority of the requirement may be different than the one required. In another example, the software engineer may have defined that “a user must be authorized before accessing an application or data” as a security requirement, without defining a dedicated security requirement about authentication, which may be considered implied. However, this may cause confusion during the development, as the developers will not know what type of authentication to implement in the system.
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/
