Just like the real world, in the virtual world there is no such thing as being “completely secure”. A combination of simple and complex security measures are required to ward against threats, but ultimately it is the vulnerabilities you do not know about are the most concerning. In the online world, it can be difficult to measure the effective security of your application. One method is to use a security specification or framework such as the OWASP Application Security Verification Standard Research (ASVS) so you can at least cover the most likely threats to your application. ASVS encourages good standards and is organised to assist programmers to design, develop and test secure software.
Regardless of whether you are a business or developer oriented professional, you can use the OWASP ASVS as:
- A metric to assess the level of trust in a web application;
- Guidance for building security controls; and
- Specifying the level of security in business contracts.
Why ASVS?
The latest version of ASVS was 4.0 which was published in March 2019, but it is continuously being improved and updated by the OWASP community to stay relevant and become much easier to understand. The standard defines both functional and non-functional security controls which are required when designing, developing and testing modern web applications and services. The aim of the guide is to surpass all the issues of the OWASP Top Ten and look at security controls on a deeper level. The latest version of ASVS focuses on web application and service standards in applications architectures, whilst also considering agile security practices and DevSecOps culture. The standard is intended to be forward thinking, by giving advice to technical personnel to address future potential problems. Given the variable security requirements between organisations and applications, the guide helps to set the industry standard. The ASVS also covers architectural concerns over the development life cycle, threat modelling, agile security and configuration concerns. ASVS is highly regarded amongst web security professionals, and can be a useful tool for software distributors to gain an advantage in the market.
Security Levels
The purpose of the ASVS is to embody the principles and methodologies of OWASP and support the measurement, documentation, and classification of an application’s security. ASVS assigns applications from a level of one to three which allows businesses to build confidence in the security of their application. Each level contains a list of security requirements which are mapped to specific features and capabilities. While level one can be verified by both manual and automated testing tools, the second and third levels require access to documentation, source code, configuration and the people involved in the development process.
Level One
This is the bare minimum every web application should strive for and is a first step checklist for those beginning to focus on security. Level one will adequately defend against the most common security vulnerabilities and address all those appearing in the OWASP top 10. There are many cases where this level is sufficient for your application, however if you find the data processed or stored by your application is of high value, then you would not stop at just the first level. This level is designed to be self verifying and completely testable through unit and integration tests. However these types of tests alone are not suited for dealing with aggressive attackers, and it has been well documented that black box testing alone misses critical security issues. Fortunately for applications at this level, there is little motivation for attackers and limited value they can gain from breaches.
Level Two
This level describes the recommended security criteria for the majority of web applications. It describes applications with a higher level of valuable data and stricter security controls. This level of control is required for handling significant B2B transactions, processing healthcare information, or managing business functions and processes which are integral to protecting a business. When this level is required, attackers will use targeted tools and techniques to discover and exploit an application’s weakness.
Level Three
Level three is the highest level covered in the ASVS which will adequately defend against advanced application security vulnerabilities, and adheres to strong security design principles. It is reserved for areas of military, health and safety, and other critical infrastructures where there are high value transactions, such as sensitive medical data or things which require only the highest level of authorisation. This level is also required when a breach of security would significantly impact the organisation’s operations or survival. An in-depth analysis of architecture, coding and testing is required to ensure an application is modularised for scalability and resilience, and has a documented defence-in-depth approach for each layer of security. The confidentiality of user information, data integrity, availability, authorisation and auditing must all be considered, particularly when applications communicate with one another. In this stage, security should be considered for every phase of the development process by building layers of security and documenting implemented security procedures.
Adhering to the OWASP standards
The OWASP standards are made up of 14 different chapters which each reference guidelines, testing guides and cheat sheets to help developers implement each of the standards at the three levels. While many of the criteria are not applicable for certain levels, it is important for organisations to cover all bases regardless of whether they are building new applications or updating existing ones.
V1: Architecture, design and threat modelling requirements
This criteria considers the primary aspects of sound security architectural design from a high level perspective. Availability, confidentiality, processing integrity, non-repudiation and privacy. There is a focus on enabling developers with secure code checklists, training, mentoring, testing, building, deploying and configuring to ensure security controls are considered throughout an application’s life cycle. There are also references to cheat sheets, threat modelling, and resources for performing surface level security analyses.
V2: Authentication verification requirements
Claims made by an individual or device must be verified, they should be resistant to impersonation and prevent recovery or interception of passwords. A combination of passwords and other claims to prove the identity of a user is the recommended approach. Applications which allow registration without proof of identity cannot be trusted to reliably assert a user’s identity.
V3: Session management verification requirements
Security controls over how the application maintains and controls the state of the user or devices must be in place. Unique user sessions cannot be guessed or shared and must become invalidated after a period of inactivity or when no longer required.
V4: Access control verification requirements
The principle of least privilege ensures resources can only be accessed by people who hold valid credentials. A well defined set of roles and user privileges must be defined over the application.
V5: Validation, sanitation and encoding verification requirements
All inputs received from the client or environment must be validated before it can be used. This is the cause of most significant vulnerabilities in web applications, including cross site scripting XSS, SQL injection, interpreter injection, file system attacks, etc. Input validation and output encoding must therefore have an agreed process to prevent these types of attacks by using strongly typed validation and length checks. Due to the difficulties of providing robust input validation, it is critical for an application’s health to use APIs with parameterised queries and auto escaping web frameworks.
V6: Stored cryptography verification requirements
The use of cryptographic keys must be securely managed and use suitable random number generators where relevant. All modules should fail securely and error handling must not reveal information about the system. Any financial, personally identifiable or other sensitive information is stored in an encrypted format.
V7: Error handling and logging verification requirements
There is an important differentiation for error handling depending on the context and the user the error is being shown to. End users should not receive information from logs which disclose any unnecessary information, whereas administrators should have sufficient information to audit events, triage issues, and assist with resolving bugs or security loopholes. The challenge then is to provide useful information to each user type without creating an enormous list of logs, the audit logs should be easily monitored and can be analysed either locally or by a remote system. High quality logs will provide meaningful data to developers and security professionals whilst discarding noise and masking sensitive data. Logs should not contain sensitive data unless absolutely necessary, and are subject to retention policies because this information can be extremely valuable to attackers.
V8: Data protection verification requirements
This standard assumes data protection is enforced on a trusted system or server, which has sufficient internal protections. It is assumed that all user devices are compromised in some way and cannot be trusted. The primary principles of data protection include the following three concepts:
- Confidentiality: protecting data from unauthorised access in transit or when stored;
- Integrity: protecting data from being created maliciously, read, updated or deleted by unauthorised users; and
- Availability: data is available to users only as required.
V9: Communications and verification requirements
Transport Layer Security (TLS) or strong encryption is always used regardless of data sensitivity. Deprecated or known insecure algorithms and ciphers are disabled, with OWASP recommending to change TLS configuration frequently to avoid breaks for existing algorithms and ciphers.
V10: Malicious code verification requirements
Potentially malicious code should be handled securely by the application, removing any time based attacks, back doors or unauthorised code which can be controlled by attackers. Regular code reviews for functions which might access time, I/O or other network functions are recommended to help prevent malicious code or unwanted functionality.
V11: Business logic verification requirements
All business logic should be sequentially processed and cannot be bypassed, including limits to prevent automated attacks. For example, the continuous transfer of small funds or adding millions of friends simultaneously. Due to the business logic cases varying between each application, there is not one definitive check list that can be applied. It is therefore recommended to use threat modelling during sprints with tools such as OWASP Cornucopia or similar tools.
V12: File and resource verification requirements
Untrusted file data obtained from untrusted sources should be managed by a secure manager, which stores the files outside the web root and contains limited permissions.
V13: API and web service verification requirements
An application with trusted server layer APIs must have adequate authentication, session management and authorisation for all web services. Input validation must be present for all parameters transiting from lower to higher trusted levels within the system and include controls for cloud and serverless API where applicable. Input validation and parsing of JSON type objects must handle missing or extra elements according to the standards.
V14: Configuration verification requirements
The build environment should be secure, repeatable and automated such that insecure components in 3rd party dependencies and configuration which are out of date are not included in the application. Failure to keep up with technology and insecure dependencies is often cited as the root cause of the largest and the most damaging attacks. This standard therefore encourages automated deployment and testing scripts to warn or break builds to prevent unknown security issues being deployed into production, preventing irregular manual steps which are inherently inconsistently secure.
OWASP Standard Certification
OWASP itself does not directly certify or register applications as following ASVS. It is instead up to the organisations themselves to prove they meet the standards. For those organisations verifying the completion of ASVS security requirements, a summary of findings and tests including both passed and failed must be included in the report. If there are failing tests, they must provide clear instructions for how they can be resolved. Any other requirements which are not applicable to the organisations must also be included in the report. OWASP highly recommends the use of security tools at all stages in the development process, building these into continuous build pipelines to find potential security issues and remove them early in the development process. While these tools are immensely useful, they cannot complete more than half the ASVS checklist without human assistance. Therefore, a combination of automated tests, and online scanners are used in conjunction with unit and integration tests for business logic and access control.
Using the OWASP Standards
The need for secure web applications continues to grow, and as this happens, the response from security professionals will evolve to combat online risks. While malicious attackers may only need to find a single vulnerability in order to compromise a system, there are measures which can be taken to reduce this risk. There numerous benefits of conforming to the OWASP standards. ASVS provides a standard of security information management, and a common language for developers, engineers and other stakeholders to develop and maintain a safe environment for their applications, helping organisations gauge risks. This checklist covers the most common web applications, and helps organisations to focus on the most relevant security requirements for their specific project or environment. ASVS can be used as a replacement for off-the-shelf secure coding checklists, or as a blue print for creating a security checklist which is tailored to your application, platform or organisation. The ASVS provides a framework guiding the development of secure software, setting requirements that applications be built at certain levels, but it is ultimately up to the software distributor to prove it satisfies the intended ASVS level. OWASP recommends either choosing one of the levels as the standard, or forking ASVS for each application, to ensure traceability of each security requirement.
Written by Lindsay Spencer
Full-stack Developer
When Lindsay isn’t developing the Codebots products, you can track him down anywhere in the office simply by following the sound of his infectious laughter.
