It has been said that “Without software requirements, software will fail and without software security requirements, organizations will”.
Security requirements are the non-functional requirements that need to be addressed to maintain confidentiality, integrity and availability of the application. Software development projects that lacks properly gathered and documented requirements face lot of issues like poor quality, scope creep, increased cost to re architecture, user or customer dissatisfaction. Similarly, software projects that lacks security requirements additionally suffer from the threats to confidentiality, integrity, and availability. This can lead to unauthorized disclosure, alteration, and destruction. It is really not a question of “if” but “when,” because it is only a matter of time before software built without security considerations will get hacked, provided the software is of some value to attacker.
Security is first and foremost viewed as a nonfunctional requirement. In an organization that has to deal with functional requirements owing to the constraints posed by budget, scope, and schedule (iron triangle constraints), security requirements are considered to be an additional expense (impacting budget), increased non value added functionality (impacting scope), and were time-consuming to implement (impacting schedule).
Depending on the security knowledge of business analysts who translate business requirements to functional specifications, security may or may not make it into the software requirements.
Sources of Security Requirements
There are multiple internal and external sources that translates into security requirements. Below are some of major sources
Standards like ISO27001, NIST, OWASP, BSIMM, Safecode, OpenSAMM
Patterns and practices
The end user business functionality or customer contract
Compliance requirement like PCI-DSS, HIPPA, SOX
Geographical requirements like GDPR
Types of Security Requirements
Security requirements can be classified into various types.
Characteristics of an Effective Security Requirement
Often when security requirements are specified, they are specified merely as high level non-testable implementation mechanisms and listing of security features. Few examples include “Passwords need to be protected”, “Secure Sockets Layer (SSL) needs to be in place” or “a web application firewall needs to be installed in front of public facing web sites”. It is extremely important to explicitly articulate security requirements as complete and in testable form. For example, “The user password will need to be protected against disclosure by masking it while it is input and hashed when it is stored”.
Security requirement should be SMART
Specific –Wordings should be clear and precise. It should not be wage and generic
Measurable –Should have clear way to test if requirement was met or not
Actionable –Developer should get clear understanding of what they need to do
Realistic –Implementable in realistic time considering all constraints
Timely –Should have right priority associated with it
Approaches and Methodologies to gather/discover Security Requirements
The determination of security requirements is also known as protection needs elicitation (PNE). PNE is one of the most crucial processes in information systems security engineering. For PNE activities to be effective and accurate, strong communication and collaboration with stakeholders is required. This is especially important if the stakeholders are nontechnical business folks and end users. Some common methodologies for security requirement elicitation are depicted below
Other common techniques for PNE includes Brainstorming, Surveys (questionnaires and interviews), Policy decomposition, Data classification. In the requirements gathering phase of the software development life cycle (SDLC), we are only required to identify which requirements are applicable to the business context. Details on how these requirements will be implemented are to be decided when the software is designed and developed.
Successful software development projects require the identification of requirements:
– Functional requirements
– Non-functional requirements
– Internal standards and policy
– External requirements and legal obligations
Be safe, develop safe !!