As a security researcher, I’ve had this experience many times: discovering a security issue, or leaked databases, reporting the breach through a website contact form or to customer support, and receiving total radio silence in response. Worse than that was reading about the same security issue in the news months or years later after someone had used the leaked database or exploited a vulnerability to access user accounts or backend systems.
In almost all these cases the negative impact could possibly have been avoided, but nobody took action. I often wonder what happened to my emails. Did they ever reach a human? Were they read by the right person, but ignored? Where, exactly, did things go wrong?
That’s why I’m excited about the security.txt movement.
Security.txt
Security.txt is an effort to make life easier for security researchers and incident responders, and to increase the likelihood that the right people will get notified about security issues. The premise of the idea is that organisations add a ‘security.txt’ document under the ‘.well-known’ directory of websites so that people concerned about your organisation’s security know who to contact. Generally, this will be coupled with a ‘security@’ email address which goes directly to the person or team responsible for security.
Here are reasons why adding a security.txt file to your website is probably a good idea:
PROVIDES A CLEAR POINT OF CONTACT FOR SENSITIVE SECURITY ISSUES
The first use for ‘security.txt’ is to provide a clear point of contact for general security issues. Another use case is a reporting procedure for sensitive security matters where it would not be appropriate to notify the entire company.
LAYS OUT YOUR BUG BOUNTY POLICY (OR CLEARLY STATES THAT YOU DON’T HAVE ONE)
As well as giving people a means to contact you, ‘security.txt’ gives you the opportunity to outline your bug bounty policy. A bug bounty program is one where security researchers are given some type of reward (money, discounts, free product, or public acknowledgment) in return for disclosing issues. If you have a policy, you can lay it out here. If you don’t have one, it’s still worth mentioning that you don’t. This prevents any misunderstandings where security researchers may incorrectly expect rewards in exchange for disclosing issues.
If you don’t have a policy, I think it’s generally a good idea to implement one, even if you don’t provide rewards with a dollar value. You can sign up with a program to make it easy to manage, like HackerOne, or BugCrowd. Your reward can be as simple as giving credit to the reporter in any comms you do around the breach or vulnerability. Having a bug bounty program, however small, encourages people to contact you through the correct channels rather than going public about it first.
FITS INTO YOUR BROADER INCIDENT RESPONSE POLICY
More important than including contact details in your ‘security.txt’ document, is having a process in place for when messages do come through. This process should fit into your existing incident response plan. Make sure your team knows how to deal with security researchers, and just as importantly, understands that security researchers are generally only trying to help.
Many security researchers have had the unfortunate experience of being threatened with legal action upon privately disclosing a breach. Don’t shoot the messenger. Instead, assume their intentions are good until proven otherwise. They could be saving your organisation from thousands or millions of dollars in financial or reputational damage.
What should you do when an issue is reported?
A public ‘security.txt’ document is a step in the right direction, but it doesn’t count for much if there's no clear process for following up with contact from security researchers.
Here are my tips for having a robust end-to-end process for responding to security queries and concerns.
1. RESPOND QUICKLY
When a security researcher gets in touch, respond as quickly as possible. All you need to say is “Thanks, we’re dealing with it,” aside from any bug bounty processes you have in place. This lets the security researcher know they don’t need to take any further action.
2. COMMUNICATE SECURELY
Both researchers and security personnel can use voice chat over mobile phone as a simple, relatively secure way to communicate. You will often not want to discuss details over email when a company has been breached, due to the risk that an attacker could gain access to email accounts.
3. KNOW WHEN YOUR GOVERNMENT CAN HELP
As a security researcher, you might occasionally come across evidence of a breach affecting more than a single organisation. In Australia, it’s helpful to know how to deal with the ACSC. They are a government body that can help notify about data breaches involving a large number of organisations. As a company, reach out to your local CERT and ensure they have up to date contact details for you.
4. IDENTIFY THE POINT OF COMPROMISE
After letting the researcher know that you’re working on the issue, the next thing is to understand where the point of compromise is. Where did the person get into the environment? What was taken? Then move on to remediation. This involves things like changing passwords and reinstalling machines. Ultimately, you must know how the bad guys gained access, and ensure that they can’t gain access again.
5. BE WILLING TO SEEK HELP
If you think a breach is serious, or you’re not totally sure what to do, it’s wise to engage professionals early. A careless or uninformed response, like running a registry cleaner on a compromised machine before beginning an investigation, can end up removing important sources of evidence.
Another common mistake is failing to make sure that attackers can’t regain access to compromised systems. For example, don’t assume that the means by which attackers gained entry are the only way they can access your systems. One of the first things attackers often do when they infiltrate a system is create other backdoors they can use to regain entry to the system in the future when the original attack vector is remediated.
Finally, don’t start restoring from backups until you’re certain the attacker has been totally kicked out of your systems.
6. KNOW WHO YOU NEED TO TELL
There is mandatory data breach legislation in Australia. For any breach, you’ll need to determine whether it falls under the guidelines for mandatory reporting under the Privacy Act. If you’re not located in Australia, check the data breach reporting requirements for your country.
In addition to monetary losses, there can be significant reputational damage involved in a data breach. This is almost always worse when there is some evidence that your organisation had the opportunity to remediate the situation before the breach occurred.
Your response plan should involve dealing with media, and dealing with legal. A serious security issue or breach requires a coordinated response. You shouldn’t be coming up with your procedure in the middle of an incident. People need to have a clear idea of what to do, and what their ongoing role is.
7. ENSURE EVERY DEPARTMENT IS PREPARED TO HANDLE SECURITY-RELATED ENQUIRIES
Even with a ‘security.txt’ document in place, you can’t guarantee people will use it. It’s surprisingly common for reports from security researchers to end up with customer support, or marketing, or sales, or the social media team. When organisations don’t respond to contact from security researchers, I think it’s often not because the email was never read, but because people don’t know how to respond, so they don’t respond.
Train your non-security folks in how to respond to security reports. It can be as simple as routing anything that seems to be security related, or hacking related, to your security@ email address. This applies to social media posts as well. Make sure security queries are a branch of your help desk scripts.
8. TEST THE PROCESS YOURSELF
You can test your organisation’s process for responding to security queries yourself. Sign up for a temporary Gmail account and send an email about a fictional vulnerability or breach and see what happens. Does the process work? Does it not work? Do things improve once you make improvements?
9. CORRECTLY CONFIGURE YOUR SECURITY@ EMAIL ADDRESS
It’s important to set up your security@ email address in the right way. Turn off spam filtering and anti-malware, because researchers will often want to send you examples of problems that might get blocked if you have the usual protections in place. You need this email account to accept a raw feed. By the same token, you need to treat this email account as potentially compromised. You don’t want it going to people’s desktop Outlook, for example. I recommend funnelling emails to your @security email address into Jira tickets so that you know the status of whether something is being looked at, and whether someone has already responded.
Wrapping up
Adding a ‘security.txt’ document to your website is a positive step, but it’s not enough on its own. It needs to be part of a broader policy that ensures every public-facing person in your organisation knows how to respond when they’re told about a security issue.
Finally, the team responsible for security in your organisation should have an incident response policy in place specifically for around dealing with tip-offs from security researchers.