How do I write a good security policy?

In order to really explain how to write a good security policy, we will use security.txt's security policy as an example.

Project description

Start your security policy off with a brief description of your company or project. This is the equivalent of a meta tag description on a website. This allows the hunter to get a brief overview of what you do.

Disclosure policy

Explain exactly what your disclosure policy is.

"We will investigate legitimate reports and make every effort to quickly resolve any vulnerability. To encourage responsible reporting, 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 our services."

Process

security.txt uses this section to make it clear what their disclosure process is, from initial report to final fix and bounty. The program actually includes a diagram to describe the process as seen below:

Languages

This is an optional section and inspired by Google's Vulnerability Reward Program (VRP). Include a section listing all the various languages that you accept your reports in. Remember some hunters might feel more comfortable describing their finding in their native language, so have a solid language base can be a big help.

Scope

A wise hunter once said:

"Where is the bloody scope?!"

Now I doubt any program would ever want to hear that about their security policy. So to solve this problem I have a golden secret which is directly related to the example program that I am using in these explanations. Use security.txt files to define your scope. Then all the hunter and your team have to do in order to verify whether the asset is in scope is:

$ curl http://example.com/.well-known/security.txt
# This project is in scope!
Contact: [email protected]
Policy: https://example.com/security-policy.html
Signature: https://example.com/.well-known/security.txt.sig

Also, state what assets are not in scope. It is essential that you also do not encourage hunters to go out of scope by rewarding them. In my opinion, an acceptable exception to this rule is if the vulnerability is in the high to critical range.

Contact: (description) Encryption: (description) Acknowledgement: (description) Policy: (description) Signature: (description)
Generate security.txt file

Rewards

Now you can start talking money. Follow the guidelines in "How do I determine the bounty amount?" and place a table with all your bounty amounts into this section.

Service-level agreement (Performance expectations)

Fill in the template below with what the hunter should expect from your program performance-wise.

Time to first response: 2 business days or less.
Time to triage: 3 business days or less.
Time to resolution: 5 business days or less.

Exclusions

For this section of your security policy, you can state what test types and then what issue types are excluded from the scope of your bug bounty program. Test types consist of strategies that hackers might use while hunting; issue types are vulnerability categories that your program usually does not accept. For the test types, you can use the examples below and adapt it according to your program's rules.

The following test types are excluded from the scope:

- Findings from physical testing such as office access (e.g. open doors, tailgating).
- Findings derived primarily from social engineering (e.g. phishing, vishing).
- Findings from applications or systems not listed in the "Scope" section.
- Vulnerability reports with video only proof of concepts.
- Reports that state that software is out of date or vulnerable without a proof of concept.
- Highly speculative reports about theoretical damage. Be concrete.
- Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue.
- Issues in third-party services should be reported to the respective team.

When it comes to the issue types section, it is probably best that you do not only list the issue types but also state the exact reason as to why you do not accept those findings — remember communication is key. The security.txt bug bounty program uses a Markdown table to accomplish this.

Proof of concepts

Use this section of your policy to describe what you want the hunter to demonstrate in their proof of concept. For instance, in order to quickly determine where a cross-site scripting vulnerability lies, alert(document.domain) is the most common method of quickly verifying.

Advice

Give the hunter a bit of advice. security.txt links to two books from the "What books should I read?" list and then states that if the hunter has any questions they can contact the team at any time.

We encourage hackers to read Web Hacking 101 and Breaking into Information Security: Learning the Ropes 101 to get a good idea of the type of issues that we are looking for. If you have a question, please do not hesitate to include it in the report. We are always here to help. You may also contact us directly via Twitter DMs or Keybase. If your messages contain sensitive information, we would prefer you use the latter.

Terminology

Since a lot of terminology may be used interchangeably, it is a good idea to define your terms in order to prevent any potential confusion. The security.txt program defines the terms "severity", "impact" and "priority" — essential terminology, frequently used during the disclosure process.