I am aiming to cover types and categories of software security requirements in this blog, that is essential to build into software architecture, design, testing and maintenance. Types are divided into two like traditional software requirements.
1) Functional requirements
2) Non-functional requirements
When creating security specific functional requirements, it is important to take Threat model into consideration. Clear understand of sensitive data, data storage, data in transit, data in memory access controls will help to shape risk assessment and threat modelling into actional security requirements.
Industry standard compliance and regulatory requirement like, PCI DSS, Secure Software Framework or HIPAA drive number of functional requirements. Inactive login period, password complexity, encryption key management are some of the functional requirements.
Non-Functional Requirements (NFRs)
To deliver functional requirements as expect to the users of the software, non-functional requirements build the qualities to facilitate to perform. For example, while doing online payment, users do not want it to take 15 mins to authorise the transactions as well as do not want to see system malfunction errors to meet the functional objective of the application. Reliability, speed is tightly coupled to meet software functional objectives. Non-functional requirements modify how the software does its job, not what it does. They do not typically describe specific characteristics of inputs or outputs
Non-functional requirements fall into number of categories, mainly
• Data Integrity
NFRs are often referred to as “ilities.” We can often recognize a non-functional requirement because the word ends in “ility.”
Software Security Requirements Categories
With the context in place let’s zoom in in software security requirements. These requirements fall under following high-level categories:
Compliance requirements are legal and regulatory requirements. These are key drivers for Software security requirement. GDPS PCI DSS, HIPAA, NIST, Cloud Security Alliance are some of the explains of compliance requirements. These requirements are mandatory and imposed by legal framework or governing body. PCIDSS is governed and manages by PCI SSC council and mandated for all payment applications that processes Mastercard, VISA, Diners, AmEx etc cards.
In this data driven world, data privacy is not only driven by organizations’ policies to respect users’ or customers’ privacy, but also by legal frameworks such as the EU’s General Data Protection Regulation (GDPR). GDPR can be considered as the world’s strongest set of data protection rules, which enhance how people can access information about them and places limits on what organisations can do with personal data. The California Consumer Privacy Act (CCPA), adopted on 28 June 2018, establishes one of the most comprehensive data privacy regulations in the US.
Security requirements are heavily influenced by business directives and decisions. Financial and commercial considerations play a significant role when it comes to software security. For example, security be a competitive advantage. Competition in most cases will drive your requirements as well: your application cannot be less secure than your competition’s. Some industries also have specific, de facto requirements (for example, financial services, payment processing, and healthcare). If your software will be used in this context, you will have to fulfil these requirements.
Service-level agreements, liabilities, and contractual commitments can significantly affect software security requirements. Customers may enforce specific requirements either directly or indirectly by demanding certain guarantees and levels of service. In some cases, organizations put together extensive lists of specific security requirements that you need to comply with.
Setting clear requirements for acquired software and including them in RFP, procurement specifications as well as contracts and SLAs enables you to push software producers to meet their security obligations and fix security bugs that are found. Frameworks like the OWASP Application Security Verification Standard (ASVS) can be used to set a specific level of software security requirements. Security requirements for software acquisition can include the following:
• Implementing specific security features with a minimum set of specifications, such as encryption, integrity, and access control
• Checking for and eliminating known security vulnerabilities, such as those included in the OWASP Top 10
• Having a third party validate security through penetration testing or code review