Applications are constantly under development, with new features being implemented and updated. Security requirements are necessary to ensure that your application properties are secure.
Imagine that your application was created to make only one query to the database and, through an attack, sensitive information leaks. But a failure caused damage to the business and problems with the regulatory sector and damaged the company’s reputation.
In this article, we intend to address security requirements in AppSec, how to implement them, and their importance when implementing security processes early in the development cycle.
A few fundamental questions
With all the representatives responsible for creating the application, we can start some fundamental questions to understand the business. Each application will have different functionality, so there is no standard, but some questions can guide you in this process:
- Will we be able to test all requirements at the end of the application?
- Will user-supplied data to the database and logs be verified?
- Can we verify that all security requirements are addressed equally, ensuring they are applied consistently at all levels?
- Are the requirements understood so the developer can implement and test them, or could anyone interpret them differently?
Requirements are not vulnerabilities
Security requirements are not vulnerabilities. They are just requirements generated through Threat Modeling, which is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, and enumerated and mitigations can be prioritized, with the aim of mitigating possible attacks.
When generating requirements, the application may already use some protection or solution that protects its environment. It means that some of the security requirements raised are already covered by the adopted tools.
Security requirements for applications must be thought of in the early stages, when the application’s functionality is defined, ensuring that the business logic is secure – involving everyone who is part of the project. After all, it is correct to think of application security as everyone’s responsibility.
Best Practices
It is important to think about the best practices of current frameworks, regulations, and legislation to meet application requirements. One such practice is to use ASVS (Application Security Verification Standard). This standard is developed by OWASP to ensure that controls have been implemented during the development cycle, as a basis for classification at each level.
We must also remember all the business functionalities in relation to that application and the possible breaches to attacks that could result in financial losses and data exposure in your company. Having an expanded vision means going further, that is, thinking outside the context of the business.
Similarly, application security requirements can be seen through architecture risk analysis. If an application uses a specific language, it should seek knowledge about attack patterns and vulnerabilities, defining requirements for developers to consider in the application.
It is worth mentioning defense in depth, that is, in addition to the requirements implemented in the application, we must also think about other layers of security, such as firewalls to protect networks and WAFs to protect applications.
The requirements must focus on the need for specific security, so we must be aware of specific vulnerabilities that may exist in an application, having generic knowledge is not enough – each application will have its specific needs and requirements.
Bring security to the early stages of development
In addition, we must take into account the suppliers that are part of the application development context, such as outsourced development. Just as third-party library security is part of the flow of application supply chains.
Security requirements are essential to prevent flaws or vulnerabilities in your application, helping developers to think more securely and in the future to avoid code errors that could lead to vulnerabilities.
Bringing security to the beginning of everything is essential to have more secure applications and with less risk to the business, thus avoiding rework and saving investments as well.
SAMM article series
- Governance according to SAMM: Strategy and Metrics in Application Security
- Governance according to SAMM: Policies and Conformities in Application Security
- Governance According to SAMM: Application Security Education and Guidance
- Design according to SAMM: Threat Modeling in Application Security
- Design According to SAMM: Security Requirements in AppSec
- Design according to SAMM – Secure Architecture in Application Security
- Implementation according to SAMM: Secure Build in Application Security
- Implementation according to SAMM: Secure Deployment in Application Security
- Implementation According to SAMM: Defect Management in AppSec
- Verification according to SAMM: Application Security Architecture Analysis
- Verification according to SAMM: Requirements-Driven Testing in Application Security
- Verification according to SAMM: Security Tests in Application Security
- Operations according to SAMM: Application Security Incident Management
- Operations according to SAMM: Environment Management and Application Security
- Operations according to SAMM: Operational Management in Application Security