security.txt: Standardised contact information for IT security disclosures

Video: Industrial control systems with security gaps pose a danger. Attacks on networks not only cause economic damage, but can also have an impact on the health of employees. Who is responsible when a critical vulnerability becomes known? Every company should define a fixed contact person and make their contact details easy to find, e.g. with the international standard RFC 9116.

Gaps in IT security are a problem of our digital, networked world. They are usually a result of design and programming errors and can be a threat to a wide range of different systems: sometimes a webcam can be hacked, and sometimes login data is exposed, with some attackers even gaining access to machine control systems.

When security researchers or government agencies identify a critical security problem in a product or in the network of a company, the relevant information must quickly be passed on to the responsible IT professionals. However, experience has shown that website forms and general contact data on sub-pages are unsuitable for this purpose. Important information often needs to be passed on through complex processes and is sometimes even lost completely. Furthermore, any security researcher who wishes to report a vulnerability does not know whether their communications need to be encrypted (and if so, how) and has no information about any further agreements that may apply.

However, the most crucial factor is: How do I know if my warning is even welcome? Could identifying a vulnerability in a company’s IT infrastructure result in me being viewed with suspicion? Due to legal grey areas (in Germany, for example, the "hacker paragraph", clause 202c of the German Penal Code [StGB]), security researchers have to fear the possibility of being charged with a crime and facing severe penalties. Time and again, dedicated professionals that make operating companies aware of a problem are reported to the authorities.

It is important to remember that the well-intentioned, responsible disclosure of identified security vulnerabilities is an important part of ensuring a secure IT infrastructure. A practical solution to this is provided in the form of an international technical specification that allows all parties involved to engage in a trustworthy exchange of information:

To achieve this, a simple text file with the fixed name security.txt is used to store contact information and information about encryption in a specified format. This file is then uploaded to the web server in the .well-known/ directory below the root directory. The text file is then available for everyone over HTTPS using the URL with the following scheme:

https://www.example.com/.well-known/security.txt

This location is known by all security researchers around the world, which is why this specification is already used by many companies, such as the German Social Accident Insurance (DGUV):

https://www.dguv.de/.well-known/security.txt

The definition of the technical specification is available free of charge online as a Request for Comments (RFC) (RFC 9116). However, this process also offers even more advantages for both sides: Anyone who uncovers a serious security vulnerability will be mentioned under the “Acknowledgements” field and may even receive a financial reward for their information. Under the “Hiring” field, companies list attractive job roles for security professionals and find qualified young professionals.

According to a new draft regulation that will be published in the near future, manufacturers of digital products will be required to provide an easily reachable contact and may face heavy fines if they fail to do so. The security.txt specification puts companies in a much better position in this context too.

If you would also like to use the security.txt specification for your company, you can find a simple generator at https://securitytxt.org/ that will help you to create the file.

The technical specification recommends setting the file validity period to a maximum of one year. All technical details and the complete definition of the technical specification can be found in RFC 9116 from the Internet Engineering Task Force (IETF).

FAQ - Frequently Asked Questions about RFC 9116

Q: Could I receive unsolicited messages at this contact address?
A: Yes. On the operator side, the usual measures must be taken to combat unsolicited mails. It is important to be reachable without major hurdles. This goes hand in hand with the fact that senders can also write unsolicited messages to the emergency contact. However, even web forms and websites with captcha are not protected from this. However, disabling HTML can significantly increase security when reading e-mails.

Q: How can I prevent e-mails from being read by strangers via security gaps in my company?
A: Mails can be encrypted for this purpose.

Q: Does the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) also recommend creating a security.txt file?
A: Yes, the BSI also recommends this, because, "One of the biggest challenges in the CVD process is identifying the right contact person." (CVD = Coordinated Vulnerability Disclosure).

Q: Any tips for setting up the mail distribution list?
A: It makes sense to use functional mailboxes (such as security@example.com); in addition, topic-specific contacts can also be specified. This is particularly practical for large manufacturers, who can separate incoming information about their own company and their products directly.

Q: How often does the file need to be updated?
A: The technical specification recommends setting the validity period of the file to a maximum of one year.