Introduction to the OWASP Application Security Verification Standard (ASVS)

Originally published in Intopalo Digital's company blog:
https://www.intopalo.com/blog/2019-10-17-owasp/

This blog entry is about the OWASP Application Security Verification Standard (ASVS), and primarily intended as an introduction for people commonly involved in software acquisition and development projects. There are four high-level topics:

1. What is the ASVS
2.    Security levels of the ASVS
3. Reasons to use the ASVS
4. The ASVS structure

tl;dr: the ASVS is informative and authorative, which is to say, it is very useful, and most projects would do well to utilise it.

This text is primarily based on OWASP Application Security Verification Standard v4.0.

1 What is the ASVS

“The ASVS is a community-driven effort to establish a framework of security requirements and controls that focus on defining the functional and non-functional security controls required when designing, developing and testing modern web applications and web services.”

The ASVS version 4.0 was released in March 2019. It was developed in the open and is hosted in GitHub (https://github.com/OWASP/ASVS). As an open project anyone interested is invited to follow and participate in the development of future versions of the standard, for example, by submitting issues, pull requests and translations.

While there are other standards and practices covering software and information security issues, the ASVS 4.0 strives to become "the leading web applications and services standard, covering traditional and modern application architecture, and agile security practices and DevSecOps culture". With this goal in mind the ASVS 4.0 is aligned with other well-known projects and standards, such as Common Weakness Enumeration, NIST 80-63-3 Digital Identity Guidelines, and PCI DSS 3.2.1 Requirement 6.5.x for application design, coding, testing, secure code reviews and penetration tests.

As of version 4.0 the ASVS is intended to become the baseline ASVS for all other related projects, such as the Mobile Application Security Verification Standard (MASVS) and the Internet of Things Application Security Verification Standard (IoT ASVS), which is currently included in the ASVS 4.0 as Appendix C as an early preview.

2 Security levels of the ASVS

The ASVS has two stated primary goals:

1. to help organisations develop and maintain secure applications
2. to allow security service vendors, security tools vendors, and consumers to align their requirements and offerings.

To accomplish these the ASVS defines three security verification levels starting from basic and progressing to increasingly more demanding requirements. 

2.1 ASVS Level 1 - Basic

This is the bare-bones level for low assurance levels and should be considered as the minimum that (most if not) all applications should strive for. Level 1 is the only level that is completely penetration testable without having access to documentation, source code, configuration and/or the development team. However, while "black box" approach is possible it is by no means recommended as it is completely unable to cope with the harsh realities and security threats of running an application "in production".

In order achieve Level 1the application must "adequately defend against application security vulnerabilities that are easy to discover and included in the OWASP Top 10 and other similar check lists". As such this level is mainly intended for applications that do not handle sensitive data.

2.2 ASVS Level 2 - Standard

This is the recommended level for most applications. At very least it should be considered when the application handles significant business-to-business transactions or process sensitive (e.g. health care) information, implement business sensitive / critical functions, or is used in industries where integrity is a critical facet to protect business.

In order to achieve Level 2, the application must "adequately defend against most of the risks associated with software today" by having security controls in place, effective and used within the application. 

2.3 ASVS Level 3 - Advanced

This is the advanced level intended for applications that are used in areas such as military, government, health and safety or critical infrastructure - generally speaking Level 3 should be applied whenever significant levels of security verification is required.

In order to achieve Level 3, the application must "adequately defend against advanced application [of] security vulnerabilities and also demonstrate principles of good security design".

A Level 3 application should be meaningfully modularized with multiple layers of security and controls to ensure confidentiality, integrity, availability, authentication, authorisation, non-repudiation and auditing. In practice we are talking about topics such as proper use of data encryption, input validation, transactions, system scalability and logging. It should go without saying that proper documentation is also expected.

3 Reasons to use the ASVS

3.1 As Secure Coding Checklist

According to the OWASP, "one of the best ways to use the Application Security Verification Standard is to use it as a blueprint to create a Secure Coding Checklist specific to your application, platform or organization".

While using automated DAST (Dynamic Application Security Testing), SAST (Static AST) or IAST (Interactive AST) tools are recommended as part of the development process, it should be noted that no more than about half of the ASVS can be completed without human assistance. For example, finding flaws in business logic and access control are (at least in the foreseeable future) beyond the capabilities of automated tools.

3.2 As a framework for Guiding the Procurement of Secure Software

Any person who is about to buy an application or make an order development project would benefit from relying on the ASVS by specifying that the application must meet the requirements for the ASVS Level X. This should ensure that the delivery will meet certain level of expectations.

This works even better when combined with the OWASP Secure Software Contract Annex.

3.3 As detailed security architecture guide

Even if the ASVS is not directly used in a project, it is a great resource for security / software architects. It lists a wide variety of problems and risks while helping to come up with reasonable solutions.

3.4 As a guide for automated unit and integration tests

By turning the ASVS checks into automated unit and integration tests the quality assurance work can be improved greatly - especially when running these tests as part of the project's Continuous Integration / Delivery setup.

3.5 As support for secure development training

In many ways the ASVS defines what "secure software" in practical terms. It will help the developers to focus on proactive controls and reliable solution methods.

3.6 As a driver for Agile Application Security

The ASVS can be included in an agile development process to define specific tasks that need to be implemented in order to have a secure product. These tasks can be included the Product Backlog and discussed with stakeholders as much as they can be used to guide agile design work.

4 ASVS structure

The ASVS 4.0 is divided into 14 chapters.

V1: Architecture, Design and Threat Modelling Requirements

“Security architecture has almost become a lost art in many organisations. [...] Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single ‘correct’ answer.”

This chapter covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. All these aspects must be built in to the application, and usually cannot be meaningfully added as an afterthought at the end of the project.

V2: Authentication Verification Requirements

“Authentication is the act of establishing, or confirming, someone (or something) as authentic and that claims made by a person or about a device are correct, resistant to impersonation, and prevent recovery or interception of passwords.”

The classic combination of username and password is no longer enough, when security is considered. For example, NIST 800-63 considers these to be public information. A modern application requires much more robust approach to authentication.

V3: Session Management Verification Requirements

“One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or a device interacting with it.”

This chapter aims to ensure that an application satisfies the following high-level session management requirements:

• Sessions are unique to each individual and cannot be guessed or shared.
• Sessions are invalid when no longer required and timed out during periods of inactivity.

V4: Access Control Verification Requirements

“Authorization is the concept of allowing access to resources only to those permitted to use them.”

 This chapter aims to ensure that an application satisfies the following high-level requirements:

• Persons accessing resources hold valid credentials to do so.
• Users are associated with a well-defined set of roles and privileges.
• Role and permission metadata are protected from replay or tampering.

V5: Validation, Sanitation and Encoding Verification Requirements

“The most common web application security weakness is the failure to properly validate input coming from the client or the environment before directly using it without any output encoding.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Input validation and output encoding architecture have an agreed pipeline to prevent injection attacks.
• Input data is strongly typed, validated, range or length checked, or at worst, sanitised or filtered.
• Output data is encoded or escaped as per the context of the data as close to the interpreter as possible.

V6: Stored Cryptography Verification Requirements

 This chapter aims to ensure that an application satisfies the following high-level requirements:

• All cryptographic modules fail in a secure manner and that errors are handled correctly.
• A suitable random number generator is used.
• Access to keys is securely managed. 

V7: Error Handling and Logging Verification Requirements

“The primary objective of error handling and logging is to provide useful information for the user, administrators and incident response teams. The objective is not to create massive amounts of logs, but high-quality logs, with more signal than discarded noise.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• No collecting or logging [of] sensitive information unless specifically required.
• Ensure all logged information is handled securely and protected as per its data classification.
• Ensure that logs are not stored forever, but have an absolute lifetime that is as short as possible.

V8: Data Protection Verification Requirements

There are three key elements to sound data protection: Confidentiality, Integrity and Availability (CIA).

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Confidentiality: data should be protected from unauthorized observation or disclosure both in transit and when stored.
• Integrity: data should be protected from being maliciously created, altered or deleted by unauthorized attackers.
• Availability: data should be available to authorized users as required. 

V9: Communication Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• TLS (Transport Layer Security) or strong encryption is always used, regardless of the sensitivity of the data being transmitted.
• The most recent, leading configuration advice is used to enable and order preferred algorithms and ciphers.
• Weak or soon to be deprecated algorithms and ciphers are ordered as a last resort.
• Deprecated or known insecure algorithms and ciphers are disabled.

V10: Malicious Code Verification Requirements

“Finding malicious code is proof of the negative, which is impossible to completely validate. Best efforts should be undertaken to ensure that the code has no inherent malicious code or unwanted functionality.”

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Malicious activity is handled securely and properly to not affect the rest of the application.
• [Application] does not have time bombs or other time-based attacks.
• [Application] does not "phone home" to malicious or unauthorized destinations.
• [Application] does not have back doors, Easter eggs, salami attacks, rootkits, or unauthorized code that can be controlled by an attacker.

V11: Business Logic Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• The business logic flow is sequential, processed in order, and cannot be bypassed.
• Business logic includes limits to detect and prevent automated attacks, such as continuous small funds transfers, or adding a million friends one at a time, and so on.
• High value business logic flows have considered abuse cases malicious actors, and have protections against spoofing, tampering, repudiation, information disclosure, and elevation of privilege attacks. 

V12: File and Resources Verification Requirements

This chapter aims to ensure that an application satisfies the following high-level requirements:

• Untrusted file data should be handled accordingly and in a secure manner. 
• Untrusted file data obtained from untrusted sources are stored outside the web root and with limited permissions.

V13: API and Web Service Verification Requirements

This chapter aims to ensure that an application that uses trusted service layer APIs (commonly using JSON, XML or GraphQL) has:

• Adequate authentication, session management and authorization of all web services. 
• Input validation of all parameters that transit from a lower to higher trust level.
• Effective security controls for all API types, including cloud and Serverless API.

V14: Configuration Verification Requirements

This chapter aims to ensure that an application has:

•  A secure, repeatable, automatable build environment.
• Hardened third party library, dependency and configuration management such that out of date or insecure components are not included by the application.
• A secure-by-default configuration, such that administrators and users have to weaken the default security posture.

Note to self: Accessing GitHub via SSH

So, as a tech note to myself, this is how I set up access to GitHub.com via SSH both on Windows 10 and on Ubuntu Linux 18.10. In order to keep this short and to the point, let's assume that both SSH and Git has already been setup.

Windows 10

I'm using Git for Windows 2.21.0.

The Git installation comes with bundled OpenSSH, so I do not need the GIT_SSH environmental variable. If GIT_SSH exists, Git will use explicitly the specified application whenever it attempts to use SSH instead of the OpenSSH. 

This little detail really tripped me over for a while as because of some past setup I had GIT_SSH pointing to plink.exe while I had been eagerly configuring OpenSSH. How odd it was that Git kept failing with SSH (plink.exe) while direct SSH (OpenSSH) connections worked just fine...

Step 1: Generate a RSA key pair

$ ssh-keygen -t rsa -b 4096

In the dialogue that follows, I chose to store the new key as

/c/Users/<user>/.ssh/github_id_rsa

Mind you that the above notation is as it is used in the Git Bash. Two new files were created:

C:\Users\<user>\.ssh\github_id_rsa (private key)
C:\Users\<user>\.ssh\github_id_rsa.pub (public key)

 Step 2: Edit ssh config file

I added following entry to the C:\Users\<user>\.ssh\config (and if the file does not exist, just create a new one):

Host github.com
    Hostname github.com
    User git
    IdentityFile C:\Users\<user>\.ssh\github_id_rsa

Step 3: Store public key to GitHub account

I opened the C:\Users\<user>\.ssh\github_id_rsa.pub file, which contains a long string, which begins with "ssh-rsa ...", and then copied the text to clipboard.

In GitHub,

1. I opened my profile Settings / SSH and GPG keys
2. Clicked New SSH key
3. Named the key in Title
4. Pasted the public key's text into Key
5. Clicked Add SSH key

The page lists all added SSH keys. The new one shows at this point as Never used - Read/write.

Step 4: Test SSH connection to GitHub

In Git Bash I tried if the basic SSH authentication works. Note that one must always use the user git instead of own GitHub user account.

$ ssh -T git@github.com

If all goes well, the server responds:

"Hi <github user>! You've successfully authenticated, but GitHub does not provide shell access."

If the attempt fails, try ssh -Tv git@github.com and figure it out. I did, eventually.

Step 5: Add the private key to ssh-agent

If the ssh-agent is not already running, start it with following command:

$ eval $(ssh-agent -s)

If the agent is running it's pid is shown. Next add the private key to the ssh-agent (again, in Git Bash).

$ ssh-add /c/Users/<user>/.ssh/github_id_rsa

If successful, following message is shown.

Identity added: /c/users/<user>/.ssh/github_id_rsa (<user>@<host>)

Step 6: Clone a repository

One of my public repositories is mstenback/reference_java, which contains small reference applications. (While they are mostly small and simple, they provide a good reference point as I implement the same applications also in other langauges and scripts, such as Python, Bash, Golang and so on. It's works for me as way to learn new languages.)

$ git clone git@github.com:mstenback/reference_java

Note that the repository must be cloned by using the SSH notation instead of HTTPS.

Step 7: Commit and push changes

After making a small change to README.md I committed the change

$ git commit README.md

and then pushed the changes to GitHub

$ git push

At this point, after a long evening trying to figure this out, I allowed myself feel a bit pleased when the connection finally worked as intended.

Finally, as a minor detail, if I would check my SSH key status in GitHub profile, it would now show

Last used within the last week - Read/write

Ubuntu Linux 18.10

Essentially all the steps are the same, with couple of exceptions.

1) SSH key files are located in /home/<user>/.ssh/

2)  Using OpenSSH 7.7p1 (not that it makes any practical difference in this case).

An Arduous Journey: After father's death

It has been a while since I last contributed to this blog.

I turned forty in the February but there was nothing to celebrate; my father died of cancer two days prior my birthday. He began complaining about pains and lost his appetite for food in January and about a month later he died of liver cancer.

I did not have a chance to settle things with my father and it makes me feel... empty. Not particularly sad nor anxious (well,a bit certainly), but mostly I've been just emotionally deflated. When my father realised that he was going to die, in combination with his constant pains and malnourishment, he just closed himself from people around him. No final words to anyone in any form that I know of, but there was this one thing: I found the last video he recorded on his camera. It was just about five minutes of his wife working in the kitchen, preserving some vegetables in jars for later use. There was no talking or interaction, but as I watched that video I did get a strong feeling that my father had found some level of comfort, if also sadness, in that moment. Then he turned off the camera, and that was the last of it all.

Up until now I've had nothing to say or write. There have certainly been thoughts and emotions within me, but nothing that I felt like sharing with others. My relationship with my father was a bit complex and strained, but I had always hoped that we would still have an opportunity to find a way to reconnect as a father and son, but to be honest I do not know for certain if that was something my father also wanted. I'd like to think it was, but we did not talk after he got his diagnosis. I tried to call him several times, but he was not inclined to talk on the phone. I decided to go and see him in person (it's a 4-5 hours trip by car), but two days before I was supposed to travel he was hospitalised. I decided to travel and see him on the very next day, but in the morning as I was about to head out I got the word that he had died two hours after midnight.

He did leave a large collection of photos and videos that I'm going to take over along with his writings on his computers. Perhaps through that legacy I may still learn something about the man who was my father.

From my Arduous Journey's point of view the effects have been mostly subtle, I think. It has been more difficult to center and focus, and to find inner peace, but I  have not been feeling all that anxious or even depressed. Just... somewhat disconnected.

However, I have gained some weight, and that is a dead giveaway that not all is well; my weight is usually the best indicator that I'm getting a little out of balance but once I notice this I can usually begin to identify and address my issues. It's spring time and I'm about to have some vacation time so that certainly helps. Another obvious sign has been that I've spent too much time on my sofa watching YouTube videos (and/or sleeping), but now that I finally got around writing about this all I feel that I'm about to turn things around for the better.

Politics: You, the people, expect more from your representatives

As Finland's Municipal Elections are just few months away I find myself  being involved with it..

In the spirit of Stoic philosophy I do not concern myself with my paltry chances of actually becoming elected; in the end I have very little control over the matter. However, as an official candidate for a political party I am granted a voice and an opportunity to use it to appeal to the people: expect more from those who would become your representatives!

Demand your representatives to rise above partisan politics and to work for the common good of the whole society and not just for their personal gratification, party politics and various interest groups.

Demand your representatives to stand for the matters that unite us as a society instead of taking the low road by riding on issues of bigotry and hate, fear and suspicion, greed and envy, and all those other matters that would divide us and drive us all apart.

You, the people, must demand that those who ask for the power to influence your lives prove themselves to be worthy of your trust and respect. Demand that the people of influence and power within the society are to be held against higher standard!

Never let them forget that a government, be it local or national, serves at the pleasure of the people. Be not afraid to rise up and challenge all those who would argue that transparency, personal integrity, professionalism and careful consideration of all matters before decision should not be expected at all times in politics.

Challenge your canditates! Let them know that you expect them to be and to know better.  The people have a voice and when it is focused it is powerful and it will be heard.