Control Stories and Scenarios

[mario-platt]

As part of the Open Security Summit, we've developed a number of Control Stories and associated scenarios to add to ASVS.

We've developed (Mario Platt, DIdar Gelici, Cillian Lyons and Luis Servin) some relating to requirement 8 and 14 (content below). You can find some of the content below, meant to be a first pass at creating these for all ASVS requirements:

ASVS - 14.4 Configuration Verification.md

ASVS Section 14

Id: ASVS-4.0-V14.1.1

Feature: Automation of build and deployment process

    As a Security Engineer
    I want to have repeatable and secure process to deploy my application
    So that I can avoid human error and have continuous validation of the security of my application

Scenario: Verify that a repeatable and scripted pattern validates the security of my app

    Given a build and deployment process
    When I deploy my application
    Then I have a repeatable pattern which validates its security

Id: ASVS-4.0-V14.1.2

Feature: Verify compiler flags for memory protections

    As a Security Engineer
    I want to verify that compiler flags are providing *adequate* protections against memory attacks
    So that I reduce the likelihood of memory corruptions resulting in unauthorized code execution

Scenario: Verify that compiler flags appropriate to the programming language are enforcing memory protections 

    Given a compiling process
    And selecting compiler flags for memory protection
    When I compile my application
    Then I verify that *protections* are in use
    And break build if unsafe pointers, memory, format string, integer or string operations are found

    protections = {stack randomization, data execution prevention}

Id: ASVS-4.0-V14.1.3

Feature: Hardening configuration of application server and framework

    As a Security Engineer
    I want to apply a hardened configuration to my application server and frameworks
    So that I avoid security misconfigurations

Scenario: Apply documented security best practices to application server and frameworks

    Given an application server and/or framework
    When I configure my application
    Then I apply the vendor recommended security best practices

Id: ASVS-4.0-V14.1.5

Feature: All security verifications are under version control

    As a Security Engineer
    I want to ensure the integrity of all security-relevant configurations
    So that I can detect any tampering attempts by unauthorized administrators

Scenario: All security verifications are managed through version control

    Given a build and deployment process
    When I deploy my application
    Then I want to be assured that only authorized administrators made changes to security verifications

Id: ASVS-4.0-V14.2.1

Feature: Identification of known vulnerable dependencies at build or compile time

    As a Security Engineer
    I want to ensure known vulnerabilities are identified when I build/compile my application
    So that I can identify and remediate vulnerable dependencies

Scenario: Integrated vulnerability checker software into the build/compile process

    Given a build and deployment process
    When I deploy my application
    Then I ensure I’m identifying any potentially vulnerable dependencies

Id: ASVS-4.0-V14.2.2

Feature: Ensure only required artefacts in the production environment are deployed

    As a Security Engineer
    I want to ensure that I identity and remove any *artefacts* that aren’t required to run my application in production
    So that I can reduce the attack surface of my application

Scenario: Ensure there are no unnecessary *artefacts* in my production environment

    Given a build and deployment process
    When I deploy my application
    Then I define the *artefacts* which aren’t deployed into production

    artefacts = {features, documentation, samples, configuration, users}

Id: ASVS-4.0-V14.4.1

Feature: HTTP response content type header specifies safe character set
    In order to prevent unsafe character sets which could obfuscate malicious activity
    As a Security Engineer
    I want to allow only safe character sets in HTTP responses

Scenario: Specify allowed character sets
    Given an HTTP response
    And an HTTP Security header
    When specifying allowable character sets
    Then only UTF-8 OR ISO 8859-1 should be allowed

Examples:
| text/html; charset=utf-8 |
| text/html; charset=iso-8859-1 |

Id: ASVS-4.0-V14.4.4

Feature: HTTP response prevents browsers from overriding response content type
    In order to prevent MIME-based attacks or MIME sniffing
    As a Security Engineer
    I want to ensure only the server-provided Content type is allowed

Scenario: Secure Content type responses from being modified by server
    Given an HTTP response
    And an HTTP Security header
    When determining Content type options
    Then nosniff is enforced

Examples:
| x-content-type-options: nosniff |

ASVS - 8.1 General Data Protection.md

ASVS Section 8

Id: ASVS-4.0-V8.1.1

Feature: Do not cache sensitive data in server components

    As a Security Engineer
    I want to avoid having sensitive data in server-side caches
    So that I can prevent information disclosure of sensitive data

Scenario: Sensitive data and application cache clearance
    Given sensitive data inbound from client side 
    And we have application caching before processing
    When finished processing user input
    Then we clear the application cache after processing

Scenario: Sensitive data in web form and using load-balancer
    Given a web form with sensitive data inbound from client side 
    And we have ‘Cache-Control: no-store’ in the HTTP Header
    When using a load balancer 
    Then no data from the web form will be stored on the LB

Id: ASVS-4.0-V8.1.2

Feature: No unauthorised access to temporary data stores with sensitive information

    As a Security Engineer 
    I want to avoid unauthorised access to sensitive data in server-side temp data stores
    So that I can prevent information disclosure of sensitive data

Scenario: Restrict temp directory's ACL to process UID
    Given there is an application server process run by a unique UID
    And there is data stored in a temporary directory
    When the temp directory is created as part of installation/configuration process,
    Then assign ACL permissions restricted to the specified UID only

Scenario: Restrict temp file's ACL to process UID
    Given there is an application server process run by a unique UID
    And there is data stored in temporary files
    When the temp files are created as part of data input processing,
    Then set ACL permissions restricted to the specified UID only

Scenario: Remove/purge data after processing
    Given there is an application running 
    And it is storing data in temporary files
    When finished with data input processing,
    Then overwrite the files on disk and then delete them with for example ‘cat /dev/null > tempFile’

Id: ASVS-4.0-V8.1.3

Feature: Minimisation of parameters in a request

    As an Engineer
    I want to avoid unnecessary parameters present in a request
    So that I can prevent information disclosure to client-side

Scenario:
    Given there is a need to keep state  
    When creating parameters to be sent from the client side 
    Then consider whether you can retrieve the same information without storing it in the client side

[mario-platt]

Second stage would be to extend this to include the Compliance as Code checks to go along with it, this would be an example using Chef Inspec for it. Any suggestions on how best to organise it in the repo would be welcomed

[mario-platt]

I've created a slightly different version for the tests part, by providing greater clarity on the test title and adding ASVS and (in this instance) ISO 27001 mapping in the test itself through the use of tags. this approach/template can help in a) greater clarity on the title for the test and b) help orgs adopting it to get the metadata on what the tests helps them evidence across their required security compliance needs

[danielcuthbert]

Picking this one up, what's the best way to get it integrated in I wonder? I agree that this is more of a 4.1 milestone, so @mario-platt are we good to add it there you think?

[mario-platt]

@danielcuthbert apologies for having missed this. What would it mean to be on 4.1?I have a few more of these and beginning to need to do some of these for work purposes. Keen on hearing thoughts on the best way to capture this information in this repo.

[jmanico]

4.1 is the next major release that I work working on right now. There are tons of edits that went into main. What's your plan?

[mario-platt]

@jmanico I started consolidating in its own repo until I can understand if there's interest and in which format this information (Stories, Scenarios and related links to technical validations) could live in. It's currently sitting here: https://github.com/mario-platt/ASVS-Agile-Delivery-Guide We'll be having some Open Security Summit sessions to get contributions, so I think a realistic timeline of 3 months would be needed to have all the content ready for all ASVS (I'm currently only focusing on Level 1 stuff).

Do you think this would sit well in the main ASVS repo or another OWASP project ?

[jmanico]

I don't have a big charge over this, but I am worried that there are numerical risk factors and other data that might not be in line with ASVS. I am inclined to think this should be a separate project, but what do you think @tghosth @vanderaj @danielcuthbert and @elarlang ?

[elarlang]

In general I think every project (including ASVS) should contain as minimum amount of content and dependencies as possible. There is reason why ASVS and Testing Guide are different projects.

In this case I'm failing to understand - what is the extra value what user-story gives? Is only one role perspective enough? Maybe "As an attacker I should not be able to do..."?

But here again - if there is huge amount of changes in ASVS - who is able to "duplicate" and "synchronize" this constantly to "another language"? For whom it is? Does not seem realistic. ... or I just don't get the point for entire issue :)

Recommendation for this project - link requirement precisely to ASVS version. For example v4.0.2-14.4.1. In some future version of ASVS requirement number may present some other meaning.

This kind of projects should be mentioned somewhere in ASVS: "Examples how ASVS is in use" or something like that but even for that should be clear criterias for linked projects - link and dependency will be linked to ASVS release forever.

My response also applies for #898

[danielcuthbert]

We fully support the ideas being proposed here and think it's better suited as a separate project. We are closing this for now, if you have a reference, let us know and we will look at it.