There have been multiple cases where attempts to contact security teams have had a bad outcome due to missing/unclear security disclosure policies and the general lack of information on how to find a relevant security point of contact within a company.
Security disclosure gone wrong
Take the case where a danish parent/hacker found a security flaw in a kiosk system used to check-in/out kids attendance in the kindergarten, that enabled him to see personal information on some of the other kids that were also registered in the system. The case went sour after he failed to get a contact to the security department of the system supplier and they ended up suing him due to - what seems to be a sub-optimal process from both parties. The common problem seems to be in these cases, that the companies in question does not have a proper process to effectively handle the disclosure situation.
This have been a continues topic over the years globally on how to get a hold of, and handle disclosure of security flaws to vendors, companies and organizations.
Danish EnergiCERT has also recently reported that they have had a case where they needed to contact 10 of the biggest companies in order to warn about a security related finding.
“None of the companies had the security.txt file in place. Therefore, we used quite a lot time to find the right people and worse was that we had to give up on some of the companies” says Kenneth Jørgensen from EnergiCERT.
For those unfamiliar with EnergiCERT – it’s the Danish Energy Sectors Computer Emergency Response Team which handles high level incident response for the critical sector.
Other times security researchers or security interested individuals might even give up and discard their findings without sharing them due to effort required to identify the contact point with the entity or due to the risk of possible legal actions against them, as entity’s security disclosure policy is unknown.
The new proposed IETF draft for security.txt sets out to help fix that.
Minimum required information
The proposed standard require that you have a
security.txt file within the entities site
.well-known folder with at least a contact point in form an mail form/address and/or phone number for the entity’s information security team. The last required element is information about when the security.txt information is to expire so that validity of the information can be confirmed.
- Encryption - A link to a public encrypt key which security researchers should use to securely communicate to the security team.
- Acknowledgments - A link to a web page where the entity can acknowledge security researchers who have helped the security team.
- Preferred-Languages - A comma-separated list of language codes that the entities security team can communicate in.
- Canonical - The URLs for accessing your security.txt file. It is important to include this if the entity is digitally signing the security.txt file, so that the location of the security.txt file can be digitally signed too.
- Policy - A link to a policy detailing what security researchers should do before searching for or reporting security issues.
- Hiring - A link to security-related job openings within the entity organization.
There is even a great security.txt generator on https://securitytxt.org/ to help generate a security.txt file.
You should also take a look at policymaker at disclose.io which aims to create a “one-stop-shop” policy generator for anyone launching a vulnerability disclosure program and among other things, generate a security.txt file.
Danish Security.txt hall of fame
Disclaimer: the list is compiled from a scan on the 1st of September 2021, please feel free to do a pull request to this post/article to update the list.
What can we do as a community?
Reach out to your local security department and inform them of the security.txt IETF draft and point them to https://securitytxt.org/ You can use this Danish/English template:
To the IT security department at xxxx.
I’m writing on behalf of a non-profit IT security community in Denmark called VSec, to inform about a new internet standard. The standard aims to create publicly available guidelines for structured contact to security departments in connection with the discovery of IT security-related vulnerabilities in companies, organisations and associations.
If you are interested in knowing more, you can read the following article: https://vsec.dk/using-securitytxt-to-improve-communication-and-collaboration/ and the draft standard: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-12 or go directly to the free security.txt generator at https://securitytxt.org/ to create your security.txt file with information and guidelines for external contact to your security department.
The IT security community VSec in Denmark.
Til IT-sikkerhedsafdelingen hos xxxx.
Jeg skriver på vegne af et non-profit IT-sikkerheds fællesskab i Danmark kaldet VSec, for at informere om en ny internetstandard. Standarden har til formål at skabe offentligt tilgængelige retningslinjer for struktureret kontakt til sikkerhedsafdelinger i forbindelse med fund af IT-sikkerhedsrelaterede sårbarheder hos virksomheder, organisationer og foreninger.
Hvis du er interesseret i at vide mere, kan du læse følgende artikel: https://vsec.dk/using-securitytxt-to-improve-communication-and-collaboration/ og denne draft standard: https://datatracker.ietf.org/doc/html/draft-foudil-securitytxt-12 eller gå direkte til den gratis security.txt generator på https://securitytxt.org/ for at lave jeres security.txt fil med informationer og retningslinjer for ekstern kontakt til jeres sikkerhedsafdeling.
Med venlig hilsen
IT-sikkerheds fællesskabet VSec i Danmark.
Security.txt for security researchers
Security scanning service shodan.io decided in January 2021 to include security.txt directly in their asset scanning results and all danish scanned IP’s with a associated security.txt can be found through this query (login requried).
History of hackers.txt and the new proposed IETF standard
Interested in the history about how security.txt came to be and why it’s a proposed standard today?
You should checkout this article about the history of the hackerstxt and securitytxt files by Ben Peachey.
This article was written by Kristian Bodeholt on behalf of the VSec Community.
A big thank you goes out to Jonas Smedegaard, Kenneth Jørgensen and Klaus Agnoletti for contributing to the community article, giving feedback/constructive criticism and in general just for being awesome.