Internet DRAFT - draft-foudil-spss
draft-foudil-spss
Network Working Group E. Foudil
Internet-Draft January 29, 2018
Intended status: Informational
Expires: August 2, 2018
The Security Policy Specification Standard
draft-foudil-spss-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Foudil Expires August 2, 2018 [Page 1]
Internet-Draft The Security Policy Specification Standard January 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. The Specification . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Disclosure Policy . . . . . . . . . . . . . . . . . . . . 2
1.2. Service-level agreement (Performance expectations) . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1. Excluded test types . . . . . . . . . . . . . . . . . 6
1.4.2. Excluded issue types . . . . . . . . . . . . . . . . 7
1.5. Proof of concepts . . . . . . . . . . . . . . . . . . . . 7
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Rewards . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Security considerations . . . . . . . . . . . . . . . . . . . 9
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Normative References . . . . . . . . . . . . . . . . . . 9
3.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. The Specification
1.1. 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] [1]. 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 security@example.com.
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:
Foudil Expires August 2, 2018 [Page 2]
Internet-Draft The Security Policy Specification Standard January 2018
* Make a good faith effort to avoid privacy violations,
destruction of data, and interruption or degradation of my
services.
1.2. 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:
o First response
o Reward (If the vendor offers any rewards - see "Rewards" section)
o 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.
1.3. 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
Foudil Expires August 2, 2018 [Page 3]
Internet-Draft The Security Policy Specification Standard January 2018
"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.
+-----------+-------------------------------------------------------+
| Symbol | Definition |
+-----------+-------------------------------------------------------+
| "*" | "All", as in any possible value. |
| | |
| "[80, | The set containing the values 80 and 443. |
| 443]" | |
| | |
| "[0-10]" | A range. In this example a range from 0 to 10. |
| | |
| "+" | In scope. This symbol can be substituted with simply |
| | placing the definitions under an "In scope" section. |
| | |
| "- " | Out of scope. This symbol can be substituted with |
| | simply placing the definitions under an "Out of |
| | scope" section. |
| | |
| "app:" | This directive refers to a native application. This |
| | allows one to link to a digital distribution service |
| | and make it clear that the native application is what |
| | is being referred to and not the actual page where |
| | you can download the native application. |
| | |
| "mailto:" | Refers to an email address as defined in [RFC6068] |
+-----------+-------------------------------------------------------+
Usage
The symbols defined above can be used as follows:
+-------------------------------------------+-----------------------+
| Example | Meaning |
+-------------------------------------------+-----------------------+
| "http://example.com/" | The top-level |
| | directory of |
| | example.com on port |
Foudil Expires August 2, 2018 [Page 4]
Internet-Draft The Security Policy Specification Standard January 2018
| | 80. |
| | |
| "*://*.example.com:*/*" | All protocols, |
| | subdomains, ports and |
| | pages with the |
| | example.com basename. |
| | |
| "example.com:[80, 443]/*" | All pages on ports 80 |
| | and 443 on the |
| | example.com basename. |
| | |
| "example.com:[22-443]/*" | All pages on ports 22 |
| | to 443 on the |
| | example.com basename. |
| | |
| "http://192.0.2.0/" | The top-level |
| | directory of the |
| | 192.0.2.0 IPv4 |
| | address on port 80. |
| | |
| "192.0.2.0/24" | CIDR notation to |
| | describe the IPv4 |
| | range from 192.0.2.0 |
| | to 192.0.2.255. |
| | |
| "2001:db8::/48" | CIDR notation to |
| | describe the IPv6 |
| | range from |
| | 2001:db8:0:0:0:0:0:0 |
| | to 2001:db8:0:ffff:ff |
| | ff:ffff:ffff:ffff. |
| | |
| "192.0.2.*" | All possible values |
| | within the last |
| | octet, ranging from |
| | 192.0.2.0 to |
| | 192.0.2.255 |
| | |
| "app:com.example.android" | The |
| | _com.example.android_ |
| | Android application. |
| | |
| "app:https://play.google.com/store/apps/d | The |
| etails?id=com.example.android" | _com.example.android_ |
| | Android application |
| | and not "https://play |
| | .google.com/". |
| | |
Foudil Expires August 2, 2018 [Page 5]
Internet-Draft The Security Policy Specification Standard January 2018
| "+ http://example.com/" | The top-level |
| | directory of |
| | example.com on port |
| | 80 is in scope. |
| | |
| "- http://example.com/" | The top-level |
| | directory of |
| | example.com on port |
| | 80 is out of scope. |
| | |
| "- *" | Everything that is |
| | not defined in the |
| | "In scope" section |
| | and not using the "+" |
| | symbol, is not in |
| | scope. The opposite |
| | does not exist ("+ |
| | *"). |
| | |
| "mailto:contact@example.com" | The |
| | "contact@example.com" |
| | email address. |
+-------------------------------------------+-----------------------+
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
- *
1.4. Exclusions
1.4.1. 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.
Foudil Expires August 2, 2018 [Page 6]
Internet-Draft The Security Policy Specification Standard January 2018
1.4.2. 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.
1.5. 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 [2]:
[...] 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.
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.
1.6. 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 [3])
Foudil Expires August 2, 2018 [Page 7]
Internet-Draft The Security Policy Specification Standard January 2018
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 [4].
Impact (Information Technology Infrastructure Library's definition
[5])
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
[6])
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.
1.7. 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.
Foudil Expires August 2, 2018 [Page 8]
Internet-Draft The Security Policy Specification Standard January 2018
+------------+--------------------+
| CVSS Score | Bounty Amount in $ |
+------------+--------------------+
| 5 | $50 |
| | |
| 6 | $86 |
| | |
| 7 | $137 |
| | |
| 8 | $205 |
| | |
| 9 | $290 |
| | |
| 10 | $400 |
+------------+--------------------+
2. Security considerations
Organizations creating a security policy will need to consider
several security-related issues. These include exposure to sensitive
information and attacks where limited access to a server could grant
the ability to modify the contents of the policy or affect how it is
served.
3. References
3.1. Normative References
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997,
<https://www.rfc-editor.org/info/rfc2142>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<https://www.rfc-editor.org/info/rfc6068>.
3.2. URIs
[1] https://tools.ietf.org/html/draft-foudil-securitytxt-02
[2] https://sites.google.com/site/bughunteruniversity/improve/alert-
1-considered-harmful
[3] https://www.oxforddictionaries.com/
[4] https://www.first.org/cvss/
Foudil Expires August 2, 2018 [Page 9]
Internet-Draft The Security Policy Specification Standard January 2018
[5] https://www.axelos.com/corporate/media/files/glossaries/
itil_2011_glossary_gb-v1-0.pdf
[6] https://www.axelos.com/corporate/media/files/glossaries/
itil_2011_glossary_gb-v1-0.pdf
Author's Address
Edwin Foudil
Email: contact@edoverflow.com
Foudil Expires August 2, 2018 [Page 10]
