idnits 2.17.1 draft-foudil-spss-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... Vendors SHOULD use the SECURITY@dom...' RFC 2119 keyword, line 102: '...-level agreement SHOULD include the ex...' RFC 2119 keyword, line 140: '...rity researchers SHOULD not look for i...' RFC 2119 keyword, line 283: '... the vendor SHOULD structure each ex...' RFC 2119 keyword, line 353: '...wards (bounties) SHOULD be tied to the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document date (January 29, 2018) is 2279 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 400 -- Looks like a reference, but probably isn't: '2' on line 402 -- Looks like a reference, but probably isn't: '3' on line 405 -- Looks like a reference, but probably isn't: '4' on line 407 -- Looks like a reference, but probably isn't: '5' on line 409 -- Looks like a reference, but probably isn't: '6' on line 412 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Foudil 3 Internet-Draft January 29, 2018 4 Intended status: Informational 5 Expires: August 2, 2018 7 The Security Policy Specification Standard 8 draft-foudil-spss-00 10 Abstract 12 This document proposes a way of standardising the structure, 13 language, and grammar used in security policies. The goal is to 14 reduce ambiguity and confusion that stems from poorly-worded security 15 policies. Organisations and individuals can refer back to this 16 document if their security policy uses definitions found in this 17 document. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 2, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. The Specification . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Disclosure Policy . . . . . . . . . . . . . . . . . . . . 2 55 1.2. Service-level agreement (Performance expectations) . . . 3 56 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.4. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.4.1. Excluded test types . . . . . . . . . . . . . . . . . 6 59 1.4.2. Excluded issue types . . . . . . . . . . . . . . . . 7 60 1.5. Proof of concepts . . . . . . . . . . . . . . . . . . . . 7 61 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 62 1.7. Rewards . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2. Security considerations . . . . . . . . . . . . . . . . . . . 9 64 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 3.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. The Specification 71 1.1. Disclosure Policy 73 The "Disclosure policy" refers to the section of the security policy 74 where the vendor describes how someone can report a security issue. 75 Vendors SHOULD use the SECURITY@domain email address for 76 communications regarding security issues as per section 4 of 77 [RFC2142] and set up a security.txt file pointing to the security 78 policy as per [draft-foudil-securitytxt] [1]. This section also 79 establishes a safe harbour where the vendor declares that they are 80 ready to investigate legitimate reports and not take legal action 81 against the reporter if the reporter abides by the vendor's security 82 policy. 84 Example 86 You can report security vulnerabilities to security@example.com. 87 We will investigate legitimate reports and make every effort to 88 quickly resolve any vulnerability. To encourage reporting 89 security vulnerabilities directly to us, we will not take legal 90 action against you nor ask law enforcement to investigate you 91 providing you comply with the following guideline: 93 * Make a good faith effort to avoid privacy violations, 94 destruction of data, and interruption or degradation of my 95 services. 97 1.2. Service-level agreement (Performance expectations) 99 Since the disclosure process should be coordinated, the security 100 researcher will want to know what to expect from the vendor, 101 especially when it comes to the duration of the entire disclosure 102 process. A service-level agreement SHOULD include the expected time 103 to: 105 o First response 107 o Reward (If the vendor offers any rewards - see "Rewards" section) 109 o Resolution 111 Example 113 We will make a best effort to meet the following expectations for 114 security researchers participating in this security program: 116 * Time to first response: 2 business days or less. 118 * Time to triage: 3 business days or less. 120 * Time to reward: 3 business days or less. 122 * Time to resolution: 30 business days or less. 124 1.3. Scope 126 This section will define the grammar to be used when defining a 127 scope; this becomes especially useful when the vendor wants to 128 encourage security researchers to inspect the security of a product 129 and report by back with any findings. 131 In scope 133 The term "in scope" refers to any assets that belong to the vendor 134 and are within the security policy's boundary. Security researchers 135 are instructed to look for security issues in in-scope assets. 137 Out of scope 138 "Out of scope" is the opposite of "in scope" and refers to any assets 139 that do not belong to the vendor, and are not within the security 140 policy's boundary. Security researchers SHOULD not look for issues 141 nor report security issues located in out-of-scope assets. 143 Grammar 145 To make things very clear to the security researcher it is important 146 to have a clear and well-designed scope; one way of achieving this is 147 to have a standardised and detailed language to describe the asset in 148 question. 150 +-----------+-------------------------------------------------------+ 151 | Symbol | Definition | 152 +-----------+-------------------------------------------------------+ 153 | "*" | "All", as in any possible value. | 154 | | | 155 | "[80, | The set containing the values 80 and 443. | 156 | 443]" | | 157 | | | 158 | "[0-10]" | A range. In this example a range from 0 to 10. | 159 | | | 160 | "+" | In scope. This symbol can be substituted with simply | 161 | | placing the definitions under an "In scope" section. | 162 | | | 163 | "- " | Out of scope. This symbol can be substituted with | 164 | | simply placing the definitions under an "Out of | 165 | | scope" section. | 166 | | | 167 | "app:" | This directive refers to a native application. This | 168 | | allows one to link to a digital distribution service | 169 | | and make it clear that the native application is what | 170 | | is being referred to and not the actual page where | 171 | | you can download the native application. | 172 | | | 173 | "mailto:" | Refers to an email address as defined in [RFC6068] | 174 +-----------+-------------------------------------------------------+ 176 Usage 178 The symbols defined above can be used as follows: 180 +-------------------------------------------+-----------------------+ 181 | Example | Meaning | 182 +-------------------------------------------+-----------------------+ 183 | "http://example.com/" | The top-level | 184 | | directory of | 185 | | example.com on port | 186 | | 80. | 187 | | | 188 | "*://*.example.com:*/*" | All protocols, | 189 | | subdomains, ports and | 190 | | pages with the | 191 | | example.com basename. | 192 | | | 193 | "example.com:[80, 443]/*" | All pages on ports 80 | 194 | | and 443 on the | 195 | | example.com basename. | 196 | | | 197 | "example.com:[22-443]/*" | All pages on ports 22 | 198 | | to 443 on the | 199 | | example.com basename. | 200 | | | 201 | "http://192.0.2.0/" | The top-level | 202 | | directory of the | 203 | | 192.0.2.0 IPv4 | 204 | | address on port 80. | 205 | | | 206 | "192.0.2.0/24" | CIDR notation to | 207 | | describe the IPv4 | 208 | | range from 192.0.2.0 | 209 | | to 192.0.2.255. | 210 | | | 211 | "2001:db8::/48" | CIDR notation to | 212 | | describe the IPv6 | 213 | | range from | 214 | | 2001:db8:0:0:0:0:0:0 | 215 | | to 2001:db8:0:ffff:ff | 216 | | ff:ffff:ffff:ffff. | 217 | | | 218 | "192.0.2.*" | All possible values | 219 | | within the last | 220 | | octet, ranging from | 221 | | 192.0.2.0 to | 222 | | 192.0.2.255 | 223 | | | 224 | "app:com.example.android" | The | 225 | | _com.example.android_ | 226 | | Android application. | 227 | | | 228 | "app:https://play.google.com/store/apps/d | The | 229 | etails?id=com.example.android" | _com.example.android_ | 230 | | Android application | 231 | | and not "https://play | 232 | | .google.com/". | 233 | | | 234 | "+ http://example.com/" | The top-level | 235 | | directory of | 236 | | example.com on port | 237 | | 80 is in scope. | 238 | | | 239 | "- http://example.com/" | The top-level | 240 | | directory of | 241 | | example.com on port | 242 | | 80 is out of scope. | 243 | | | 244 | "- *" | Everything that is | 245 | | not defined in the | 246 | | "In scope" section | 247 | | and not using the "+" | 248 | | symbol, is not in | 249 | | scope. The opposite | 250 | | does not exist ("+ | 251 | | *"). | 252 | | | 253 | "mailto:contact@example.com" | The | 254 | | "contact@example.com" | 255 | | email address. | 256 +-------------------------------------------+-----------------------+ 258 Example 260 + *://*.example.com:*/* 261 + test.another-example.com:[80, 443]/* 262 + https://*.test.another-example.com/* 263 + http://pub.another-example.com:[22-443]/* 264 + app:https://play.google.com/store/apps/details?id=com.example.android 265 - * 267 1.4. Exclusions 269 1.4.1. Excluded test types 271 Excluded test types define what methods for discovering security 272 issues a security researcher is not permitted to use. 274 Example 276 Findings from physical testing such as office access are strictly 277 prohibited. 279 1.4.2. Excluded issue types 281 Excluded issue types are types of security issues that the vendor 282 does not want security researchers to report. To prevent confusion 283 the vendor SHOULD structure each exclusion in this section as a 284 description of the issue type followed by the reason why the vendor 285 does not want to receive reports concerning that type of issue. 287 Example 289 We do not want researchers to report Cross-site Request Forgery 290 (CSRF) with minimal security implications such as logout CSRF to 291 us. In order for CSRF to be a valid issue, it must affect some 292 important action such as deleting one's account. 294 1.5. Proof of concepts 296 The "Proof of concepts" section describes what the vendor wants the 297 security researcher to demonstrate in their proof of concept. This 298 section should also set boundaries to ensure that the security 299 researchers know how far they have to escalate their finding to 300 demonstrate the issue. 302 Example 304 Google's Vulnerability Reward Program states the following [2]: 306 [...] while alert(1) is the standard way of confirming that your 307 attempt to inject JavaScript code into a web application succeeded 308 in some way, it does not tell you where that injection happened, 309 exactly. That's particularly important for Google services 310 because of our use of sandboxed domains to safely render some of 311 the content we get from our users or retrieve from the Internet. 312 So, we always recommend our reporters to try 313 alert(document.domain) instead. 315 Encouraging security researchers to use alert(document.domain) in 316 their proof of concept allows Google and the security researcher to 317 quickly determine if the finding is a valid issue. 319 1.6. Terminology 321 The term "severity" is frequently used interchangeably with "impact" 322 or "priority". This section defines some basic terminology in order 323 to prevent any potential confusion. 325 Severity (Oxford Dictionaries' definition [3]) 326 The fact or condition of being severe. 328 Overall severity 330 The overall score determined using a vulnerability scoring system 331 such as the Common Vulnerability Scoring System [4]. 333 Impact (Information Technology Infrastructure Library's definition 334 [5]) 336 A measure of the effect of an incident, problem or change on 337 business processes. Impact is often based on how service levels 338 will be affected. Impact and urgency are used to assign priority. 340 Priority (Information Technology Infrastructure Library's definition 341 [6]) 343 A category used to identify the relative importance of an 344 incident, problem or change. Priority is based on impact and 345 urgency, and is used to identify required times for actions to be 346 taken. 348 1.7. Rewards 350 Some vendors reward security researchers for reporting security 351 issues either in form of a public acknowledgment, prizes -- often 352 referred to as "swag" -- and/or payments, so called "bounties". 353 Financial rewards (bounties) SHOULD be tied to the overall severity 354 of the reported security issue and not the security issue type. 356 Example 358 This is an example reward table where the bounty amounts are tied to 359 overall severity scores calculated using the Common Vulnerability 360 Scoring System. 362 +------------+--------------------+ 363 | CVSS Score | Bounty Amount in $ | 364 +------------+--------------------+ 365 | 5 | $50 | 366 | | | 367 | 6 | $86 | 368 | | | 369 | 7 | $137 | 370 | | | 371 | 8 | $205 | 372 | | | 373 | 9 | $290 | 374 | | | 375 | 10 | $400 | 376 +------------+--------------------+ 378 2. Security considerations 380 Organizations creating a security policy will need to consider 381 several security-related issues. These include exposure to sensitive 382 information and attacks where limited access to a server could grant 383 the ability to modify the contents of the policy or affect how it is 384 served. 386 3. References 388 3.1. Normative References 390 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and 391 Functions", RFC 2142, DOI 10.17487/RFC2142, May 1997, 392 . 394 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 395 URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, 396 . 398 3.2. URIs 400 [1] https://tools.ietf.org/html/draft-foudil-securitytxt-02 402 [2] https://sites.google.com/site/bughunteruniversity/improve/alert- 403 1-considered-harmful 405 [3] https://www.oxforddictionaries.com/ 407 [4] https://www.first.org/cvss/ 409 [5] https://www.axelos.com/corporate/media/files/glossaries/ 410 itil_2011_glossary_gb-v1-0.pdf 412 [6] https://www.axelos.com/corporate/media/files/glossaries/ 413 itil_2011_glossary_gb-v1-0.pdf 415 Author's Address 417 Edwin Foudil 419 Email: contact@edoverflow.com