Software security requirements fall into two categories. First category consists of requirements for the software's security functions (such as cryptographic and user authentication functions). This is followed by software security requirements for the software's own security properties and consistently secure behaviors.
Not incorporating the core security services (confidentiality, integrity, availability, authentication, authorization and auditing) in the requirements phase of a software development project inevitably results in insecure software. Since software development follows a series of processes (the blueprint), it is of paramount importance that security requirements are determined alongside the functional and
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
business requirements. In other words, consider software security requirements to be an integral part of the blueprint itself, and involve a security professional.
Performing a software security requirements analysis requires a good understanding of security principles and their applicability in the design specification. This in turn makes this activity the foundation of creating secure software. I suggest that you engage an experienced security professional for performing a software security requirements analysis for mission-critical applications (different technologies and architectures) that mandate high levels of security. The primary responsibilities in such an engagement include:
• Conducting interviews with stakeholders: The goal of this activity is to engage stakeholders at the beginning to not only understand their business or functional needs but also to map software security requirements (including privacy and intellectual property protection). It is always a best practice to use a questionnaire or checklist (in simple language), since these work really well in uncovering software security requirements.
• Identifying applicable policies and standards: Identify and conduct reviews of security policies and standards, as well as map applicable security controls to functional specifications so that software development takes into consideration the established policies and standards. This not only helps you to incorporate a standard framework, but also to ensure internal policy compliance with audit requirements.
• Capturing and mapping regulatory, compliance and privacy considerations: During this activity, the approach is to create a regulatory compliance matrix and use the same as a checklist to identify applicable regulatory (legal), compliance, as well as privacy requirements. These considerations are not only local, but also international (depending on the industry and country of operations). The key to this activity is to correctly map the compliance requirements to security controls; it can be easily achieved using the checklist approach.
• Developing a confidentiality, integrity and availability (CIA) matrix: The CIA matrix is an important tool which helps to define the foundation of security controls, and is instrumental in creating a secure software design. The data classification policy helps in determining the CIA factors, mapping the access controls and auditing mechanisms (including prioritizing), and determining the appropriate level of security controls to be incorporated in the software.
• Identifying the security tollgates: Based on the security requirements, define the security tollgates or checkpoints. This helps the team to keep a track of the software security requirements, and ensure that they are being incorporated as specified to avoid any possible deviation.
• Conducting initial risk assessment: An experienced security consultant can help create standard questionnaires which can uncover the essential requirements of CIA, and help with a rapid risk-mapping model. Both of these are useful methodologies for initial risk assessment. This basically depicts the use or abuse cases.
While there's a growing shift from the traditional software development lifecycle (SDLC) to a secure SDLC, one of the most ignored parts of this change is the security requirement engineering process. Traditionally, the software security requirements gathering process has been more focused on business and functional requirements than an understanding of the security aspects.
Software security requirements engineering is the foundation stone, and should exist as part of a secure software development lifecycle process in order for it to be successful in improving the security of your applications. Unless this part of the puzzle is handled correctly, the development teams will not achieve the best possible results from any software security investments.
About the author: Puneet Mehta is the co-chair of OWASP India, as well as the co-founder and director of OWASP's Delhi Chapter. Mehta is a frequent contributor to TechTarget. He has authored many articles, as well as been quoted in national and international media. Mehta's focus areas include information security, risk management and vulnerability research.