Auf der DENOG17 stellte Sascha Heinemann unsere Erkenntnisse zur Einführung von security.txt in der deutschen Netzwerkbetreiber-Community vor. Was mit einer einfachen Frage begann: „Wer hält sich noch an die offiziellen Empfehlungen?" entwickelte sich zu einer Analyse, die sowohl Fortschritte als auch den Verbesserungsbedarf in der Branche aufzeigt.
Testen Sie Ihre Security.txt
Prüfen Sie, ob Domains eine gültige security.txt nach RFC 9116 implementiert haben. Nutzen Sie unseren kostenlosen Checker:
Bedeutung der Recherche
EdgeOps entwickelt unter anderem Whitelabel-Rechenzentrumsportale mit digitalisierten Prozessen für Zugangsanfragen und Cross-Connect-Bestellungen. Unsere Entwicklung ist Community-getrieben und wird durch echtes Feedback von Netzbetreibern wie denen bei DENOG geprägt. Als wir beschlossen, security.txt gemäß den offiziellen Empfehlungen zu implementieren, hat uns unsere Neugierde dazu veranlasst, zu untersuchen, wie viele Organisationen in unserer Branche dasselbe getan haben.
Was ist Security.txt?
Security.txt (RFC 9116) ist eine standardisierte Methode für Unternehmen, um Kontaktinformationen zum Thema Sicherheit zu veröffentlichen. Man könnte es als klaren Kommunikationskanal für Sicherheitsforscher und verantwortungsbewusste Offenlegung bezeichnen.
Der Standard definiert vier Hauptrichtlinien:
- Ein einziger Ansprechpartner für Berichte über Sicherheitslücken
- Verschlüsselung zur Gewährleistung der Authentizität durch PGP-Signaturen
- Ablaufdaten, um sicherzustellen, dass die Informationen aktuell bleiben (maximal ein Jahr)
- Klare Richtlinien, die Erwartungen an Sicherheitsforscher festlegen
Die Umsetzung ist unkompliziert: eine einfache Textdatei unter /.well-known/security.txt mit definierten Feldern wie „Kontakt" und „Ablaufdatum", die maschinenlesbar
formatiert ist. Sowohl die US-amerikanische CISA (2019) als auch das deutsche
BSI (2024) empfehlen diesen Standard offiziell.
Unsere Erkenntnisse
Wir haben 239 Organisationen aus verschiedenen Branchen analysiert, die auf der DENOG17 vertreten waren. Das sind unsere Ergebnisse:
- Nur 25 % (60 Organisationen) haben security.txt überhaupt implementiert.
- Von diesen 60 haben nur 25 % (15 Organisationen) eine gültige security.txt.
- Betrachtet man die Implementierung, einschließlich PGP-Signaturen und korrekter Ablaufdaten, erfüllen nur 7 Organisationen alle Kriterien.
Von 239 Organisationen setzen also nur 7 diese Sicherheits-Best-Practice korrekt um.
Aufschlüsselung nach Branchen
Die Akzeptanzraten variieren erheblich zwischen den einzelnen Branchen:
| Branche | Anzahl | Mit security.txt | in % | valide Implementierung | in % |
|---|---|---|---|---|---|
| Behörden | 3 | 2 | 67% | 0 | 0% |
| Bildung und Forschung | 20 | 8 | 40% | 3 | 15% |
| Internet Exchanges | 7 | 3 | 43% | 0 | 0% |
| Hosting & Cloud | 42 | 13 | 31% | 2 | 5% |
| Rechenzentren & Colocation | 16 | 4 | 25% | 0 | 0% |
| Consulting & Dienstleistungen | 70 | 15 | 21% | 5 | 7% |
| Carrier | 48 | 8 | 17% | 4 | 8% |
| Hardware | 18 | 3 | 17% | 0 | 0% |
| Sonstige | 15 | 4 | 27% | 1 | 7% |
Besonders waren wir überrascht, wie wenig Hardware-Hersteller und Händler die Richtlinie implementiert haben. Eine standardisierte Methode zur Meldung von Sicherheitslücken ist für alle Beteiligten von Vorteil. Mit einer Implementierungsrate von nur 17 % gibt es noch viel Raum für Verbesserungen.
Erwähnenswertes
Unsere Untersuchung hat einige interessante Sonderfälle aufgezeigt:
Heise.de: www.heise.de verfügt über eine security.txt, heise.de (ohne www) jedoch nicht. Die Lösung? Automatische Weiterlung an eine URL, um einen konsistenten Zugriff auf Sicherheitsinformationen zu gewährleisten.
BSI: Die security.txt des Bundesamtes für Sicherheit in der Informationstechnik läuft 2099 ab, das bedeutet, dass sie 74 Jahre lang gültig bleibt, länger als das BSI existiert! Das ist zwar kreativ, verstößt aber gegen die RFC-Anforderung, dass die Gültigkeit innerhalb eines Jahres ablaufen muss.
DE-CIX: Beweist, dass security.txt nicht langweilig sein muss. Leider führt die Verwendung von Sonderzeichen dazu, dass der Test zur Maschinenlesbarkeit fehlschlägt.
Warum Security.txt für Netzwerkbetreiber wichtig ist
Wir interpretieren den Umfang von security.txt nicht nur als „wir haben eine Schwachstelle auf Ihrer Website gefunden", sondern als zentrale Anlaufstelle für alle Sicherheitsfragen im Zusammenhang mit den Diensten eines Anbieters.
Ein Netzbetreiber ohne klaren Ansprechpartner für Sicherheitsfragen ist wie ein Gebäude ohne Notausgang.
Wenn Sicherheitsforscher Schwachstellen entdecken, benötigen sie eine zuverlässige, standardisierte Methode, um diese zu melden. Security.txt bietet genau das: eine maschinenlesbare, leicht auffindbare Kontaktmethode, die im gesamten Internet funktioniert.
Testen Sie Ihre eigene Security.txt
Nutzen Sie unseren interaktiven Checker, um Ihre eigene security.txt-Implementierung zu überprüfen:
Ausblick
Unsere Recherche gibt einen Überblick über die Community bei DENOG17. Wir würden dieses Thema gerne nächstes Jahr erneut aufgreifen, um zu sehen, ob die Akzeptanz zugenommen hat. Wir hoffen, dass wir durch die Hervorhebung sowohl der Vorreiter als auch der Lücken eine breitere Akzeptanz dieses einfachen, aber entscheidenden Sicherheitsstandards fördern können.
Besonderer Dank gilt der DENOG-Community für die Inspiration und allen Organisationen, die security.txt bereits implementieren
security.txt Checker
Enter your domain to validate its security.txt setup. The checker follows RFC 9116 and only requests /.well-known/security.txt over HTTPS/HTTP