ASVS Requirements in Application Security
Do you want to understand more about what they are and what ASVS requirements do?
In the scenario of application development, the term Security Requirements – ASVS is constant, but do you know exactly how to apply it?
To better understand what ASVS is and what it is for, here are some basic concepts to help us build a solid path that ensures correct compliance with these requirements to improve application security.
After all, what is ASVS?
So let’s better understand the acronym: ASVS is short for Application Security Verification Standard, which is nothing more than a requirements checklist to ensure application security.
They act by helping to develop, maintain and test the security of these applications.
These requirements can be categorized into three levels of sensitivity: the more sensitive the data an application processes, the more requirements are necessary to keep that application secure. But first, let’s take a few steps back and better understand what the requirement itself is.
What is a Requirement?
Well, if we analyze the meaning of “requirement”, as an adjective it refers to something that was requested. However, if we use it as a noun, as in the AppSec world, the term has a new meaning which is something necessary to get to a place to obtain something.
Therefore, it is necessary to understand that to define requirements, we are also defining objectives to be fulfilled and points to be reached so the software is on with its attributions.
Taking into consideration the database definition related to computing science, engineering and areas, the IEEE Standard 729, we see that requirements are good conditions that must be reached by a system to satisfy a contract, a specification, a pattern or even a formality imposed by a document.
Another good definition that we can use as a base is done by OWASP SAMM, which defines requirements as being the necessity to identify security controls that are important within the secure software context.
Requirements within the SDLC process
In the Software Development Life Cycle (SDLC), the requirement phase is one of the first and also the most important.
Because at this point the necessary information to build software will be raised and followed as good practice, it will also determine what must be the security requirements to be reached by the software.
Therefore, as we foster the SDLC model developed by Microsoft, for instance, we can say that at this point we will have a clear view on how the software must behave and even see if there will be software build up.
3 important points in the Security Requirements
As seen above, by fostering the Software Development Life Cycle – SDLC model by Microsoft, we can have a better notion of how software behaves.
That is because it is just in the initial steps that we define requirements to establish patterns of activities for this software.
Though, it is in the requirement phase that we find 3 important points to be observed, in which we will approach next.
1. Creating a set of security requirements
The first important step is to create a functional set of requirements for security and privacy, that will be used as a base to the whole software.
This definition of security requirements can be performed with the help of experts, who can be the Security Champions of the development teams.
Security Champions are professionals who emerge within Development teams, speaking the same language as the rest of the team, and are therefore able to promote security from the inside out from the time the software is born.
2. The decision points to the software
In a second moment, it is time to create some decision points for the software. Quality gates or bug bars are points where code or even software evaluation will identify if there are conditions to proceed with the normal development cycle.
To take as an example, we can say that a quality gate is an evaluation that, when fulfilled, guarantees the sequence of software production.
Imagine a threat modeling: when we create the modeling we identify conditions that must be met, and that is quality gates.
3. Defining privacy and security requirements
The third point specifically addresses the definition of security and privacy requirements themselves: it is important to identify the functional requirements of the software that will need the most attention during their construction.
This way, the key points of attention for creating security requirements will be covered and you can count on the software being created in a more secure way.
Basic points when talking about security requirements
From a safety point of view, by documenting requirements we seek to ensure that safety best practices are met, but not only that. It is also important to observe adherence to market recommendations and or requirements, as well as compliance with legal and regulatory requirements.
In addition to these definitions and guidelines, the construction of a requirement document should also consider which quality gates will guarantee and validate each of them.
It is not our place here to talk about all the security requirements, but we can put some to start your way in creating your own requirement view.
Fundamental requirements of security
So, to know how we can determine what the basics are about, let’s take as a starting point concepts that are widely used in security requirements.
1. Confidentiality
In short, we can say that ensuring the confidentiality of data means that only authorized persons can access it.
And for that to be true, we have to consider controls that act directly on data in the three states known as at-Rest or stored, in transit, or even in the process.
One of the ways to ensure the confidentiality of this data is by adopting the use of encryption, thus ensuring the confidentiality of data.
2. Integrity
Data integrity requirements are necessary to ensure the accuracy or non-alteration of the data.
Confidentiality can be guaranteed by verifying that the functionality of the software provides the highest possible level of security for the data. Data accuracy is achieved by restricting access so that only the user who has permission can change the data.
In addition, another element that helps ensure integrity is digital signatures.
Specifications such as Protocols and Data Random Strength (eg Salt Length) should be evaluated as part of the Safety Checklist.
3. Availability
Availability security requirements are, as the name implies, to ensure that data or service is available whenever your user needs it.
This requirement is one of the most complicated and should be treated as a part of the Service Level Agreement (SLA) with components such as Maximum Tolerable Downtime (MTD) or even Recovery Time Objective (RTO).
When evaluated or even present in a Business Impact Analysis (BIA), they must have both quantitative and qualitative assessments.
4. Authentication
The basic concept of authentication we all know: we need to ensure the legitimacy and identity of the presenting system.
A clear example of this is when there is a request for someone to present a document, thus proving that their identity is, in fact, that of their claim.
And for our systems the process is no different: authentication is the validation of that supposedly informed identity, and this we will achieve with a validation mechanism such as a password.
There are other mechanisms that can and should be taken into account. Some examples might be 2FA (Double Authentication Factor) engines or even Single Sign-On (SSO) or Active Directory systems.
5. Authorization
Now that we have an authenticated user, we need to make sure that the desired actions performed by this user are actually the ones they are allowed to perform. This task is the authorization of the user. For development, authorization is to ensure that a user only performs actions that are truly tied to their work. And this can be ensured through validations on access arrays implemented in systems.
In short, our authorization process should ensure that every user performs only actions allowed to them.
6. Accountability
So if we can already guarantee access, functions, and actions in the system, we also need to ensure that when performing an action, it is individualized to the user who performed it.
Our system must be prepared to identify actions taken by the user, so it is possible to provide evidence of use and which actions brought some kind of compromise to the system or even to information.
How to define good requirements?
Now that we have understood the basic concepts of what must be searched when defining requirements, we also need to identify how these other requirements will be reached.
Though, there are some sources that we can leave behind. One of them is OWASP ASVS: a list of security requirements to be used in applications based on critical information treated by the system.
OWASP ASVS
OWASP ASVS is the result of a community effort in creating a list of possible security control that can be implemented on applications through a series of factors.
On its 4.0 version, ASVS’s basic premise is to deliver a framework of definitions to control all security requirements. Thus, it is possible to map functionalities and non-functionalities of security. In this version, ASVS brought as the main change the direct use of NIST-800-63-3, base document to Digital Identity.
Yet on this version, not only ASVS but also OWASP TOP 10 2017 reinforce a direct alignment with NIST 800-63. bear in mind not to confuse with the NIST-800-63-3 mentioned above.
This alignment is much stronger when placing authentication and session management controls.
Another significant change was the reconstruction of the numbering of controls, which are now more focused on correcting GAPs from previous versions.
Last but not least: the new version of ASVS has a new approach that addresses old community requests.
The first is a greater direct relationship with CWE, which is one of the most desired sources when thinking about vulnerabilities.
The second direct relationship was made with Section 6.5 of PCI-DSS 3.2.1, especially when we focus on coding, testing, code review, intrusion testing, and application design.
ASVS has also been following the evolution of models and technologies found in the development process and even in applications.
Now ASVS closely monitors the new changes by abandoning a purely monolithic model to address issues such as micro-services, DevSecOps, containers, CI / CD and more.
But all these points are more related to web applications, which in times of mobile applications may raise a question as to the application of these mechanisms in this type of application.
Secure Requirements for Mobile Application – OWASP MASVS
For those developing focused on mobile applications, the same concept presented here can be found in the ASVS mobile application controls version, known as OWASP MASVS, today in version 1.1.4.
Like ASVS, MASVS can also be used to identify what would be the basic controls for applications based on the criticality of your information and how ASVS also ranks your applications on 3 levels.
As we have shown, it is interesting for developers to be more aware of these models, seeking to use them as a basis for the safe construction of their applications.
For example, if your mobile application is geared towards the financial sector, it is recommended that you use the controls identified in MASVS.level 2.
This level already brings controls that can meet the requirements of regulations such as PCI-DSS or even SOX, which is an American Law focused on financial control and has a strong impact on corporate technology.
Where to go from now?
We understand that building secure software goes far beyond just creating a more secure code.
There is a process before reaching the end of development when the software becomes available.
Building secure software starts with a good understanding of technology, model, and language used to develop it. We talked about this in another article mentioning the important steps to consider when seeking training for the development team.
We understand that our role is to foster the developer’s curiosity about other issues that he may not have, but we believe to be as important as being updated with the framework and its news.
We need to create a community that can exchange information and answer questions about application security, to help on the matter we would like to invite everyone to join our DevSecOps community on Slack.
Come participate and exchange knowledge, contributing to the collaborative growth of AppSec!
