1-888-PIVOT-POINT | 1-888-748-6876
turn
Select Page
GDPR & Privacy Shield - What They Mean for Your Business

Pivot Point Security will soon be among the first information security firms to begin using the OWASP Application Security Verification Standard (ASVS) across its application security testing practice. As I blogged about back in mid-August, this shift has several important benefits.

OWASP ASVS Testing Guide ThumbnailFree OWASP ASVS Testing Guide

If you are just learning about OWASP’s testing standard or are considering the best way to prove the security of an application, this guide is meant for you!

Get your download here!

But what does it really mean to “comply” with this emerging standard?

OWASP states they developed the ASVS for two basic use cases:  

  1. To test and verify web application security. 
  2. To specify development requirements for a secure web application; i.e., create a tailored and focused “secure coding checklist” to replace generic checklists and facilitate a security architecture review (or even help train developers).

OWASP Secure Coding Checklist Compliance 

Let’s cover the latter case first as it is more straightforward. To specify secure development requirements for an application, you start by identifying the application’s risk profile: Level 1, 2 or 3, with 3 being the highest risk. Each level provides progressively more in-depth security requirements that must be met to manage the risk the application inherently presents.

Developers, application owners, and other stakeholders have full flexibility to choose the right security level and security goals based on application criticality, budget and/or other factors. You can even develop the initial release to comply with ASVS Level 2, for example, and then upgrade security towards Level 3 compliance in future releases.

After choosing a risk level, you decide which of the nineteen categories of requirements pertain to your application, depending on its design and functionality. Mobile/API requirements may or may not be relevant to your application, for instance. (FYI – there are actually sixteen total categories, a few have been rolled together in the most recent OWASP ASVS updates.)

You then evaluate the application against the requirements in each relevant category that pertain to your previously identified risk level. For example, in the “V9: Data protection verification requirements” category there are eleven requirements to be met to achieve Level 3 compliance, versus just four for Level 1 compliance.

Compliance in OWASP ASVS Testing and Verification Scenarios

As a vendor-neutral nonprofit, OWASP does not authorize or “certify any vendors, verifiers or software.” But third-parties can still offer “unofficial” assurance services at a range of costs. Organizations can likewise “self-attest” their level of ASVS compliance.

Trust in a vendor offering attestation or testing services is therefore paramount. How rigorous is their testing? And what is its goal: to say you meet the requirements or to know you meet them?

Testing Requirements by Level

Level 1: Automation (?)

In terms of the mechanics of testing, verifying most Level 1 requirements could be accomplished by automation, without access to source code. Indeed, “the ASVS is designed to be highly testable.”

However, OWASP explicitly states that: “Whilst a large majority of requirements in Level 1 can be performed using automated tests, the overall majority of requirements [beyond and in some cases at Level 1] are not amenable to automated penetration testing.” OWASP further states that conferring even Level 1 “compliance” without access to source code is “not a leading practice.”

Level 2: Deeper Access

Verifying Level 2 “requires at least some access to developers, documentation, code, and authenticated access to the system.” Beyond black-box testing, this would encompass white-box penetration testing and, in most cases, architecture and/or code review.

Level 3: In-Depth Audits

To achieve complete coverage at Level 3, testing needs to go beyond penetration testing to encompass “review of system configuration, malicious code review, threat modeling, and other non-penetration testing artifacts”—in essence, an in-depth audit, preferably by an independent third-party.

In short: Whether you are procuring or selling a critical application, or looking to maximize the security of in-house software, independent security testing by experts with comprehensive security testing backgrounds can help ensure stakeholders know an application is designed and coded to deliver robust and comprehensive security controls.

Additional Information on ASVS Compliant Services

For more information on Pivot Point’s new ASVS-based services and how they can help your business develop, test, verify and/or procure secure and compliant applications, contact Pivot Point.