Application Security Verification Standard version 4 - clearer requirements and easier reading

OWASP has recently published a new version of their Application Security Verification Standard (ASVS). Now at version 4, ASVS provides a categorized list of security requirements and controls that help in developing and designing secure software. ASVS also helps in testing that an application meets suitable security requirements.

For those unfamiliar with ASVS, it is divided into levels:  

1. Level 1 is for simple applications where confidentiality is not important, and there is little motivation for attacking the application. The security controls protect from easily discoverable vulnerabilities. 
2. Level 2 is something most applications should aim for. Implementing these controls protect from most software risks, such as bypassing authentication, invalid access control, information closure, injection flaws, input validation errors and so on. The list of requirements is detailed enough, so it’s easy to cover special cases as well.
3. Level 3 is for applications that handle more business-critical functions or health data. Meeting those requirements also means that you need to take security into account in every phase of your software development, build layers of security and document your efforts.

What's new?

From a security testing point of view, version 4 of ASVS does not add that many new things. A skilled and thorough tester will check all these things and threat modeling will cover the rest even if the security assessment is using the previous version, ASVS version 3, as a testing baseline. However, version 4 is definitely easier to read and works as a more thorough checklist. More importantly, it seems to be more useful for one of the main audiences of ASVS: developers.

At first thought the idea of totally renumbering items as announced in the ASVS document preface does not sound appealing. But after looking at the table of contents and the rest of the document, the new categorization of security controls is actually clearer than before. The categories help you find the area you are looking for (such as password recovery or HTTP headers) but also help you to skip an entire section if you are not using a specific feature or technology. For example, in the session management requirements section, there are some fundamental requirements and then subchapters for cookie-based and token-based session management so you can pick the correct one.

The contents have been modernized to include cloud, containers and DevSecOps. The authentication and session management requirements are aligned with the NIST 800-63-3 Digital Identity Guidelines, and authentication mechanisms are extended to software and hardware tokens and biometric devices. Version 4 also includes a mapping to Common Weakness Enumeration (CWE) categories. CWE is a common language for describing types of vulnerabilities so this can help in comparing results of vulnerability management tools and other testing reports.

New ASVS version promotes threat modeling

ASVS version 4 mentions threat modeling in several parts of the document, starting from the first section of the document. I was really pleased to see the requirement 1.1.3: Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile". These are evil user stories in practice, although they weren't called as such. You can read more about using evil user stories from my previous article "Things that security auditors nag about, part 5: No security requirements".

Business Logic Verification Requirements section has also been expanded, and it now promotes threat modeling with requirement 11.1.5, "Verify the application has business logic limits or validation to protect against likely business risks or threats, identified using threat modeling or similar methodologies". First of all, threat modeling helps to make secure choices in the design phase. In addition, an existing threat model is a useful input for security testing, as it can identify the riskiest parts of the system.

Much better wording and important new requirements can also be found from the Data Protection Verification Requirements and Configuration Verification Requirements sections. For example, detecting abnormal numbers of requests and configuration tampering, testing backup restoration and build automation are now listed as signs of a secure application. However, these requirements are something that usually falls out of regular technical testing scope and can be difficult to test as such – so again, threat modeling or developer interviews become important.

Highlights of changes

I picked 20 of my favorite additions and changes to ASVS and listed them below with an explanation, why I think this is a welcome change.

Authentication and session management

Password related requirements have been modernized regarding password complexity and replacement requirements. New requirements better support using password managers and other authentication tokens than passwords.

Data protection

There is a whole new section concerning privacy controls. Backups, caches and other secondary data storages have been added to the list of assets to protect.

More detailed testing advice

Renumbering the document and splitting the requirements to subchapters makes the document easier to read for security testing purposes.

Monitoring, alerts and operations security

The Business Logic Verification Requirements section extends the advice on monitoring that was already brought up in the Data Protection Verification Requirements section. DevSecOps practices have been added.

I really recommend sparing some time to familiarize yourself with the new Application Security Verification Standard version 4 to enhance your software development security. And remember that this document is not just for security folks, spread the word to development teams as well. You don't need to change to this version immediately, though: thorough testing and threat modeling will cover version 4 requirements even if you're using version 3.