A clear system for publishing vulnerability disclosure policies and contact info
Security.txt standardised as RFC 9116
Publication of RFC 9116 earlier this year has provided organisations with a straightforward means of publishing their vulnerability disclosure policies and contacts details. The system involves the publication of a file called security.txt on the organisation's website, written in a specially developed text format that is readable by both machines and people.
Standardisation is intended to bring order to the existing chaos of scattered and/or outdated policy pages and disclosure channels. Instead, the security.txt file serves as a standard vehicle for communicating current policies and contact info.
Security investigators and white-hat (ethical) hackers can refer to a site's security.txt file to find out what the organisation's disclosure policy is, and who they should approach if they come across a security issue. That in turn helps the detection report recipient – a company from which documents have been stolen and offered for sale on the dark web, for example – to promptly take action to prevent or mitigate harm. If the new system is widely adopted, the availability of security information in a clear and accessible form may also be expected to encourage reporting and thus reduce the number of incidents.
Unfortunately, it is by no means unusual that someone who discovers a vulnerability is unable to find a channel for reporting it, or bring it to anyone's attention. As a result, the discoverer either doesn't bother reporting the matter, or proceeds straight to full disclosure. Hardliners tend to see that as the best way to punish careless organisations or shame them into putting their houses in order.
By contrast, responsible disclosure, now also known as Coordinated Vulnerability Disclosure (CVD), gives organisations opportunity to work with the discloser to investigate the problem, find a solution and roll it out.
As well as the company's disclosure policy and relevant contact information, the security.txt file can include details of any bug bounty programme or alternative financial compensation scheme the organisation may offer.
DTC notification service
Until now, there has been no general consensus on where a disclosure policy should be published. However, the e-mail address security@example.nl has previously been proposed as a universally recognised disclosure channel. Another widely used channel is, of course, the contact information for the domain name, as recorded by the relevant registry (the organisation responsible for managing the top-level domain, e.g. SIDN for .nl).
"For us, and many others, the contact information is the most important thing," says Kim van der Veen, Project Leader at the Ministry of Economic Affairs and Climate Policy's Digital Trust Centre (DTC), which provides advice and tools to help SMEs and others to improve their security.
Last summer, the DTC added a notification service to its support package, through which individual organisations can be proactively contacted about serious system vulnerabilities or tangible threats. "As part of the service, we call companies, warn them about specific cybersecurity threats, and where possible advise them on countermeasures, such as patching software or changing system configurations."
Manual investigation
"The input for disclosures is provided to us by organisations such as the NCSC, which obtain information about targets and victims," continues Van der Veen. "In most cases, we start with nothing more than an IP address. We then use reverse DNS lookup to try to establish what the associated domain name is. Once we've got a domain name, we can go to the website in search of a disclosure channel. If we're lucky, the site provides a general contact number or e-mail address for the organisation. After that, it's just a question of hoping that our warning reaches the right person and gets followed up."
Operating that way, the DTC handled 4,600 reports last year, most provided in the form of a list of IP addresses. However, the approach does mean a lot of manual investigation in situations where rapid action is needed. The information in the security.txt file should therefore be a real boon to the DTC. "Access to the personal data in the Whois database is now controlled, and a service provider or SIDN naturally has to be cautious about sharing a registrant's contact details with us. We've now started discussions with SIDN to explore the possibility of using the Whois to send notifications in situations where no security.txt file is available. However, a lot of the contact information in the Whois is out of date or incorrect, partly because customers can't update their own details. So we really want to encourage everyone to publish at least contact information in their security.txt file."
Campaign
A few weeks ago, the DTC therefore began a campaign [1, 2] to promote the use of security.txt. The campaign involves explaining the basic steps an organisation should take, and making a dedicated information page available to IT service providers, detailing the information fields in the security.txt file.
"Our notification service has now been going just over a year," continues Van der Veen. "For us, the security.txt file has major benefits, but we didn't want to start plugging it until the formal RFC appeared. However, we did work with the NCSC to provide input and feedback during development of the RFC. We pushed for the addition of the standard to the Internet.nl test portal, and we have suggested adding it to the Forum for Standardisation's 'use-or-explain' list. That idea is currently being looked at."
Nevertheless, Van der Veen says that embracing a new RFC is a tense affair. "Government bodies are usually more reactive than proactive, but we're convinced of this standard's potential. And so are many other stakeholders and ambassadors, including SIDN."
The security.txt file format
The information in the security.txt file is structured in a very straightforward way, as a series of text lines, each consisting of a field name and a field value. For example:
Contact: mailto:security@example.nl Contact: tel:+31-654322345
A total of 8 fields are currently defined. For details, see the RFC specification.
Comment lines can also be included, each prefixed by a hash symbol:
# Comments
Finally, the publisher can end the file with a digital signature (based on OpenPGP).
The security.txt file is published at the following location:
https://example.nl/.well-known/security.txt
For historical reasons, https://example.nl/security.txt is also supported as an alternative location. To prevent the file being tampered with in transit, it can be accessed only using HTTPS.
The RFC also provides a definition for the contents of security.txt in ABNF, a specification from which software (a parser) can be directly derived for automatic processing of the contents.
SIDN's security.txt file
Our security.txt file is available here:
https://www.sidn.nl/.well-known/security.txt
It has been written by Technical Security Officer Melvin Elderman. Notably, a lot of information has been added in the form of comments (which are not machine-readable), suggesting that various fields need adding to the security.txt file format. Elderman is unconcerned, however. "I like the concept, and the idea of publication being standardised. What I think is lacking is anything about the expertise level: security specialists are inclined to produce highly technical reports, on the basis that a vulnerability has to be reproducible. That's all very well for a large organisation with its own IT department and security budget. But you've also got to think about a small shopkeeper, whose only option is to pass reports on to their service provider, which may itself be a small business with limited expertise. But, for now, you can at least put that kind of information in your security.txt file as a comment."
Another point is that the security.txt file can be signed using OpenPGP, but here at SIDN we no longer use OpenPGP. Elderman explains: "We used to have a key pair, but people disclosing vulnerabilities didn't use it. So we switched to offering an S/MIME key for sending us encrypted messages. However, publication of the new standard has pushed us to revive OpenPGP within SOC sooner rather than later."
Your own security.txt file
As explained above, the security.txt format is so simple that it's easy to manually compile your own file. And it's even easier to generate one using this online tool:
You can then check that everything's right by visiting the Internet.nl test portal:
Although the contact information is the most important thing for the DTC, Elderman emphasises that the underlying process and policy need to be in order as well. "Otherwise, you're creating expectations that you can't fulfil, and you're going to disappoint people. The process doesn't need to be complicated, though. A mailbox that is actually monitored and a policy that says a discloser will get a preliminary response within a week will suffice."
The time isn't yet considered right for financial incentivisation of security.txt support, like the incentivisation of DNSSEC and IPv6 support. Nevertheless, our scans indicate that security.txt is now supported by 61,819 (1.3 per cent) of domains with active websites in the .nl zone. In a few months, SIDN Labs intends to publish a report on the development of security.txt use in the .nl zone.