The Security Policy Specification Standard (SPSS)

This document proposes a way of standardising the structure, language, and grammar used in security policies. The goal is to reduce ambiguity and confusion that stems from poorly-worded security policies. Organisations and individuals can refer back to this document if their security policy uses definitions found in this document.

Please note, this is the informal specification; the Internet draft is located here: https://datatracker.ietf.org/doc/draft-foudil-spss/.

In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in [RFC2119].

Table of contents

• The Specification
  • Disclosure policy
  • Service-level agreement (Performance expectations)
  • Scope
  • Exclusions
    • Excluded test types
    • Excluded issue types
  • Proof of concepts
  • Terminology
  • Rewards

The Specification

Disclosure Policy

The "Disclosure policy" refers to the section of the security policy where the vendor describes how someone can report a security issue. Vendors SHOULD use the SECURITY@domain email address for communications regarding security issues as per section 4 of [RFC2142] and set up a security.txt file pointing to the security policy as per [draft-foudil-securitytxt]. This section also establishes a safe harbour where the vendor declares that they are ready to investigate legitimate reports and not take legal action against the reporter if the reporter abides by the vendor's security policy.

💡 Example

You can report security vulnerabilities to [email protected]. We will investigate legitimate reports and make every effort to quickly resolve any vulnerability. To encourage reporting security vulnerabilities directly to us, we will not take legal action against you nor ask law enforcement to investigate you providing you comply with the following guideline:

• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of my services.

Service-level agreement (Performance expectations)

Since the disclosure process should be coordinated, the security researcher will want to know what to expect from the vendor, especially when it comes to the duration of the entire disclosure process. A service-level agreement SHOULD include the expected time to:

• First response
• Reward (If there vendor offers any rewards -- see §Rewards)
• Resolution

💡 Example

We will make a best effort to meet the following expectations for security researchers participating in this security program:

• Time to first response: 2 business days or less.
• Time to triage: 3 business days or less.
• Time to reward: 3 business days or less.
• Time to resolution: 30 business days or less.

Scope

This section will define the grammar to be used when defining a scope; this becomes especially useful when the vendor wants to encourage security researchers to inspect the security of a product and report by back with any findings.

In scope

The term "in scope" refers to any assets that belong to the vendor and are within the security policy's boundary. Security researchers are instructed to look for security issues in in-scope assets.

Out of scope

"Out of scope" is the opposite of "in scope" and refers to any assets that do not belong to the vendor, and are not within the security policy's boundary. Security researchers SHOULD not look for issues nor report security issues located in out-of-scope assets.

Grammar

To make things very clear to the security researcher it is important to have a clear and well-designed scope; one way of achieving this is to have a standardised and detailed language to describe the asset in question.

Usage

The symbols defined above can be used as follows:

💡 Example

+ *://*.example.com:*/*
+ test.another-example.com:[80, 443]/*
+ https://*.test.another-example.com/*
+ http://pub.another-example.com:[22-443]/*
+ app:https://play.google.com/store/apps/details?id=com.example.android
- *

Exclusions

Excluded test types

Excluded test types define what methods for discovering security issues a security researcher is not permitted to use.

💡 Example

Findings from physical testing such as office access are strictly prohibited.

Excluded issue types

Excluded issue types are types of security issues that the vendor does not want security researchers to report. To prevent confusion the vendor SHOULD structure each exclusion in this section as a description of the issue type followed by the reason why the vendor does not want to receive reports concerning that type of issue.

💡 Example

We do not want researchers to report Cross-site Request Forgery (CSRF) with minimal security implications such as logout CSRF to us. In order for CSRF to be a valid issue, it must affect some important action such as deleting one's account.

Proof of concepts

The "Proof of concepts" section describes what the vendor wants the security researcher to demonstrate in their proof of concept. This section should also set boundaries to ensure that the security researchers know how far they have to escalate their finding to demonstrate the issue.

💡 Example

Google's Vulnerability Reward Program states the following:

[...] while alert(1) is the standard way of confirming that your attempt to inject JavaScript code into a web application succeeded in some way, it does not tell you where that injection happened, exactly. That's particularly important for Google services because of our use of sandboxed domains to safely render some of the content we get from our users or retrieve from the Internet. So, we always recommend our reporters to try alert(document.domain) instead. ^[source]

Encouraging security researchers to use alert(document.domain) in their proof of concept allows Google and the security researcher to quickly determine if the finding is a valid issue.

Terminology

The term "severity" is frequently used interchangeably with "impact" or "priority". This section defines some basic terminology in order to prevent any potential confusion.

Severity (Oxford Dictionaries' definition)

The fact or condition of being severe.

Overall severity

The overall score determined using a vulnerability scoring system such as the Common Vulnerability Scoring System.

Impact (Information Technology Infrastructure Library's definition)

A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.

Priority (Information Technology Infrastructure Library's definition)

A category used to identify the relative importance of an incident, problem or change. Priority is based on impact and urgency, and is used to identify required times for actions to be taken.

Rewards

Some vendors reward security researchers for reporting security issues either in form of a public acknowledgment, prizes -- often referred to as "swag" -- and/or payments, so called "bounties". Financial rewards (bounties) SHOULD be tied to the overall severity of the reported security issue and not the security issue type.

💡 Example

This is an example reward table where the bounty amounts are tied to overall severity scores calculated using the Common Vulnerability Scoring System.