What is the Application Security Verification Standard (ASVS)?

I was lucky enough to attend the OWASP London chapter gathering on the 25th February 2019 at Photobox.

The OWASP team treated us attendees really well by providing free food, drink and knowledge. I look forward to the next one.

I was also lucky enough to go the Science Museum on the afternoon of the same day for a culture mooch. There are pictures dotted throughout this post, just so we can look at them at remember what we considered “cutting edge”.

I digress, whilst at the OWASP Function Andrew Van Der Stock @vanderaj gave a presentation about the upcoming release of the “ASVS (Application Security Verification Standard) V4”.

This blog post is an explanation of the ASVS V3.

The key difference between V3 and V4 appears to be that in V4, the standard has incorporated some aspects of the NIST 800-63 (Digital Identity Guidelines).

So, what is the Application Security Verification Standard ASVS V3?

  • The ASVS is a community-driven effort by the OWASP organisation 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.

What is the point of the ASVS?

  • The point of the ASVS is to help organizations like yours to develop and maintain secure applications.
  • To allow security service vendors (like OIC Solutions), security tools vendors, and consumers to align their requirements and offerings.
Apple Lisa 1983

Right, lets roll our sleeves up.

The ASVS is split into three levels, 1, 2 & 3.

Level 1 – Low Assurance (V4) or Opportunistic (V3) – Akin to our Web Application Security Analysis service offering

  • Completely Penetration Testable and allows a “Black Box” approach.
  • Is the absolute minimum meant for all software.
  • Is about defending the “low hanging fruit” and against Web Application opportunistic attacks.
    • This “low hanging fruit” protection associates very clearly with the Cyber Security Essentials accreditation. However, the Cyber Security Essentials is about Infrastructure and the ASVS is about Web Applications. You can read more about the Cyber Security Essentials here.
  • Is about defending against easy to discover vulnerabilities including the OWASP Top 10 and SANS Top 25 etc.
  • If your application data has a high value you would rarely be satisfied with level 1 alone.
  • Level 1 controls can be ensured either automatically or by tools or simply by manual access and without having access to the underlying source code.
  • It is not possible to fully complete the ASVS using automated penetration testing tools alone.
  • The lines are blurry between “automatic” and “manual” testing.
    • Automatic tools are “tuned” by experts manually and manual testers often leverage automated tools.

It is possible to test and verify all Level 1 issues without requiring source code access, but this is making life more difficult and the testing not as thorough.

Level 2 requires at least some access to developers, documentation, code and authenticated system access.

Complete coverage at level 3 via penetration testing alone is not possible because it involves activities like system configuration, malicious code review and threat modelling activities.

Level 2 – Most Applications (V4) Standard (V3)- Akin to our Web Application Security Testing service offering

  • Designed for applications the contain sensitive data and requires protection.
  • Is an adequate defense level against “most” of the risks associated with software today.
  • Level 2 is about defending your application against “skilled and motivated” attackers.
  • Level 2 is about ensuring that “Security Controls” are in place and that they are effective and used within the application.
  • Is designed for protecting applications that handle significant B2B transactions including those that process health care data or deal with “sensitive” information or assets.
  • Level 2 is also aimed at systems that could provide “Transactions up to $100,000 or involve PII” quote from the v1 of the ASVS Standard.

Level 3 – High Value, high assurance or high safety (V4) Advanced (V3)

  • For “applications that could Run or Destroy the world” (@vanderaj, 2019). Maybe overkill, but you get the idea. Specifically applications dealing with high value transactions, sensitive medical data or any application that requires the highest levels of trust.
  • Level 3 is aimed at applications in the Military, Health and Safety and Critical Infrastructure etc.
  • Used by organisations who, if the application fails, could significantly affect their operations and even survivability.
  • Unsurprisingly Level 3 requires more in depth analysis, architecture, coding and testing than at other levels.
  • The Application becomes modularised to aid in secure development, management and monitoring.

You must be skeptical about any party, company or organisation that claims to have a specific ASVS assurance level. The ASVS levels are not officially vetted or authorised by OWASP or anyone else.

I could claim I operate a Level 3 validated app.

Alan Turing a man who saved us from the Nazis and then got done over by his own Government.

As OIC Solutions do not provide Level 3 assurance, it will be largely skipped over in the following sections.

If reference is made to “Level 1, 2 & 3” it is indicating that this is a base level consideration.

  • 1) Architecture, design and threat modelling
    • Level 1
      • Application components are identified and have a justified reason for being there.
    • Level 2
      • The architecture is defined and the code adheres to the architecture. Verify all components such as library modules and external systems that are not part of the application but that the application needs in order to function are identified and free of vulnerabilities.
  • 2) Authentication verification requirements
    • Level 1, 2 & 3
      • The application verifies the digital identity of the sender
      • The application ensures that only those that are authorised are able to authenticate and that credentials are transported in a secure manner.
      • Authentication controls are server side and fail securely.
      • Verify that “forgotten password” functionality and other recovery paths do not reveal the current password and that the new password is not sent in plain text.
      • Password best practice. If 2FA is used, passwords must be at least 8 characters. If no 2FA is used, passwords must be at least 12 characters.
      • Verify that no weak or default passwords “admin/password” are being used anywhere.
  • 3) Session management verification requirements
    • Level 1, 2 & 3
      • Sessions must be unique to each individual and cannot be guessed or shared.
      • Sessions must be invalidated when no longer required and timed out during periods of inactivity.
      • Sessions must be invalidated when the user logs out.
      • All successful authentication and reauthentication generates a new session and session_id.
      • The application should have limits on the number of active concurrent sessions possible.
  • 4) Access control verification requirements
    • Level 1, 2 & 3
      • Application users accessing resources must have valid credentials to do so.
      • Users must be associated with a well defined set of roles and privileges.
      • Roles are permissions metadata are protected from replay or tampering.
      • Always implement the principles of least privilege.
  • 5) Malicious input handling verification requirements
    • Level 1, 2 & 3
      • Input is validated to be correct and fit for the intended purpose.
      • Data from an external entity or client should never be trusted and should be handled accordingly.
      • Verify the run time environment is not susceptible to buffer overflows.
      • Verify that no SQL, LDAP or OS command injection vulnerabilities exist.
  • 6) Cryptography at rest verification requirements
    • Level 1, 2 & 3
      • Ensure that all cryptographic modules fail in a secure manner and that errors are handled correctly.
      • A suitable random number generator must be used when required.
      • Access to keys must be managed in a secure manner.
      • Confirm that cryptographic algorithms have been validated against FIPS 140-2.
      • PII information must be encrypted at rest and only communicated via secure channels.
  • 7) Error handling and logging verification requirements
    • Level 1, 2 & 3
      • “High quality” logs will often contain sensitive data and must be protected as per local data privacy laws, most likely the GDPR for the locale of OIC Solutions customers.
      • Ensure that sensitive information that is not specifically required is not logged or collected.
      • Ensure that the logged data is handled securely and protected based on its data classification.
      • Log storage and retention should not be treated as a “forever +1 day” exercise. Logs must only be kept for as long as justifiably required and no longer.
      • The application must not display verbose error messages.
      • Time Sources should be synchronised.
  • 8) Data protection verification requirements
    • Level 1, 2 & 3
      • Ensure the application satisfies the following classic page 1 Information Security concept that I learnt on Day 1 of my MSc studies, the CIA Triad.
        • Confidentiality
          • Data should be protected from unauthorised observation or disclosure both in transit and at rest.
        • Integrity
          • Data should be protected from being maliciously created, altered and/or deleted by unauthorised attackers.
        • Availability
          • Data should be available to authorised users when required.
        • Other requirements include implementing anti client side caching and never passing sensitive data through URL Parameters.
  • 9) Communications Security verification requirements
    • Level 1, 2 & 3
      • Ensuring that TLS is used for the transport of sensitive data and that strong algorithms and ciphers are used at all times.
      • Verify that Certificate paths are trusted and that TLS settings are in line with current security best practices.
A very old Router. I bet there are some Network Engineers with Bad Backs today.
The height of Yuppie Cool and Chic at one point.
  • 10) HTTP security configuration verification requirements
    • Level 1, 2 & 3
      • Verify that the application satisfies the following high level requirements.
        • The application server is suitably hardened from a default configuration and that the HTTP responses contain a safe character set (e.g. UTF-8 or ISO 8859-1) in the content type header.
        • Verify that the application accepts only a defined set of required HTTP request methods such as GET and POST and unused methods (e.g TRACE, PUT and DELETE) are explicitly blocked.
  • 11) Malicious controls verification requirements
    • This requirement is not required at levels 1 and 2 and cannot be tested as part of a Security Assessment/Penetration Test.
      • Level 3 Only
        • Ensure that malicious activity is handled securely and properly so as not to affect the rest of the application.
        • Ensure that the application has no Time Bombs or other other time based attacks built into them.
        • Ensure that the application cannot do a “phone home” to a malicious or unauthorised destination and that the application does not have back doors, Easter eggs, Salami attacks or logic flaws that can be controlled by an attacker.
        • Malicious code is rare but extremely difficult to detect. Manual line by line code review can assist in looking for logic bombs.
        • This section is not possible without full access to the source code, including as many third party libraries as possible.
  • 12) Business logic verification requirements
    • Levels 2 and 3 only
      • This verification standard moves beyond Level 1 requirements.
      • Ensure that the business logic flow is sequential and in order.
      • Business logic must include limits to detect and prevent automated attacks, such as continuous small fund transfers or add a “million friends” at once etc.
      • High value business logic flows have considered abuse cases and malicious actors and have protections against spoofing, tampering, repudiation, information disclosure and elevation of privilege attacks.
  • 13) File and resources verification requirements
    • Level 1, 2 & 3
      • Back to the more straightforward things to consider and protect against.
        • Ensure that untrusted file data is handled accordingly and in a secure manner.
        • Ensure that untrusted data is not stored outside of the web root and with limited permissions.
  • 14) Mobile verification requirements
    • Level 1, 2 & 3 verification requirements specifically for Mobile Applications.
      • Mobile applications should have the same level of security controls within the mobile client as is found in the server, by enforcing security controls in a trusted environment.
      • Sensitive information assets stored Locally on the device should be done so in a secure manner.
      • All sensitive data transmitted from the device should be done with TLS in mind.
      • Among other things you must ensure that information like UDID or IMEI numbers are not used as authentication tokens or that sensitive data is not stored unprotected on the device and memory management concepts like ASLR are used.
  • 15) Web services verification requirements
    • With regards to RESTful or SOAP based web services at Levels 1, 2 & 3.
      • Ensure adequate authentication, session management and authorisation of all web services.
      • Ensure input validation of all parameters that transmit from a lower to a higher trust level.
      • Ensure the basic interoperability of SOAP web services layer to promote API use.
      • Verify consistent encoding style between client and server and that XML and/or schema is in place and verified before accepting input.
  • 16) Configuration
    • Level 1, 2 & 3
      • Ensure that the application uses up to date libraries and platforms, a secure by default configuration and sufficient hardening that user initiated changes to the default configuration do not unnecessarily expose or create security weaknesses or flaws to underlying systems.
      • Ensure that unneeded configuration such as folders, documentation and example/default users are removed.

OIC Solutions operates and can provide all the skills, services and consultation that you require for a Level 1 or Level 2 application.

An overview our Level 1 and Level 2 Service offerings are available here.

Specifics about our “Level 1” Service offering is available here.

Specifics about our “Level 2” Service offering is available here.

Ooooooo! a whole 18MB of Space!!
Summary
Article Name
What is the Application Security Verification Standard (ASVS)?
Description
What is the Application Security Verification Standard (ASVS) from a presentation at the OWASP London Chapter. Also some pictures from the Science Museum.
Author
Publisher Name
OIC Solutions

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close