Eine Textdatei, die dir eine Sicherheitslücke früher meldet

Unter der Adresse /.well-known/security.txt liegt auf unserem Server eine Textdatei mit vier Zeilen. Sie sagt, an welche Adresse jemand schreibt, der bei uns eine Sicherheitslücke findet, in welchen Sprachen wir antworten und bis wann die Angabe gilt. Die Datei ist ein paar hundert Byte groß, kostet im Monat nichts und ist in zwanzig Minuten eingerichtet. Sie ist der Unterschied zwischen einer Meldung, die am selben Tag bei einem Menschen landet, und einer Meldung, die es nie gibt.

Was in der Datei steht

Das Format ist in RFC 9116 festgeschrieben, reiner Text, Feld für Feld. Zwei Angaben sind Pflicht, der Rest ist Komfort:

• Contact: eine Mailadresse oder eine URL, an die gemeldet wird. Mehrere Einträge sind erlaubt, der oberste gilt als der bevorzugte.
• Expires: das Datum, ab dem die Datei als veraltet gilt. Das klingt nach Bürokratie und ist der nützlichste Teil, dazu unten mehr.
• Preferred-Languages: de, en erspart dem Finder das Rätselraten.
• Policy: eine Seite, auf der steht, wie du mit Meldungen umgehst und wie lange du für eine Antwort brauchst.
• Encryption: ein öffentlicher Schlüssel, wenn du verschlüsselte Meldungen annehmen willst.

Die Datei gehört ausgeliefert über HTTPS und unter genau diesem Pfad, weil dort automatisierte Werkzeuge nachsehen. Eine Kontaktseite mit Formular ersetzt sie nicht: ein Finder, der zwanzig Domains prüft, ruft zwanzig Mal denselben Pfad ab und nicht zwanzig Mal ein Impressum.

1,8 Prozent, und der Rest schweigt

Eine Untersuchung deutscher Webseiten kommt darauf, dass nur 1,8 Prozent überhaupt eine security.txt bereitstellen. Bei den übrigen 98 Prozent muss jemand, der etwas gefunden hat, raten: Impressum, info@, Kontaktformular, LinkedIn. Jeder dieser Wege führt zu einer Person, deren Aufgabe etwas anderes ist als Sicherheitsmeldungen. Und jeder dieser Wege kostet den Finder Zeit, die er nicht bezahlt bekommt.

Das ist der Punkt, an dem eine Meldung stirbt. Nicht aus Böswilligkeit, sondern weil der Aufwand größer wird als die gute Absicht.

Die teuerste Meldung ist die, die niemanden erreicht

Rechne den Ablauf einmal durch. Fall eins: Jemand findet eine falsch konfigurierte Freigabe, schreibt an die Adresse aus deiner security.txt, bekommt am selben Tag eine Antwort, ihr klärt es in zwei Tagen. Kosten: ein halber Arbeitstag und eine Änderung an der Konfiguration.

Fall zwei: Dieselbe Freigabe, kein Meldeweg. Der Finder gibt auf oder schreibt öffentlich darüber. Im schlechteren Verlauf findet sie ein zweiter, der nicht meldet. Jetzt läuft es nicht mehr über deinen Kalender, sondern über den von jemand anderem, dazu kommen Fristen aus der Datenschutz-Grundverordnung, Kundenanrufe und eine Nacht, in der jemand geweckt wird.

Der Unterschied zwischen beiden Fällen sind vier Zeilen Text. Das ist keine Sicherheitsstrategie, das ist eine Klingel an der Tür.

Wer die Adresse liest

Eine Adresse, die niemand liest, ist schlimmer als keine, weil sie eine Zusage macht, die nicht eingehalten wird. Bei uns läuft die Cloud, der Mailserver, der Passwortmanager, der Git-Server und diese Website auf einem Server, den wir selbst betreiben. Das Postfach hinter der Adresse liegt auf demselben Mailserver, es geht an uns beide und liegt zusätzlich auf den Telefonen. Wir sind zwei, also ist die Zuständigkeit nicht die Frage, sondern nur die Erreichbarkeit.

Wir sagen offen, wie klein das ist: Bei uns ist bisher keine Meldung eingegangen. Das ist kein Verdienst, das ist Statistik. Aufgesetzt ist der Weg trotzdem, weil du ihn nicht in dem Moment baust, in dem du ihn brauchst.

In einem größeren Betrieb ist die Frage dieselbe, nur mit mehr Namen: Wer öffnet das Postfach, wer antwortet, wenn diese Person im Urlaub ist, und wer darf entscheiden, dass ein System kurzfristig abgeschaltet wird. Genau diese drei Zeilen gehören in ein Dokument, das aufgeschrieben ist. Bei der Wahl des Postfachs hast du dieselben Stufen wie überall: eigener Mailserver, gehostetes Postfach bei einem Anbieter in Deutschland, oder ein Dienst, der Meldungen als Tickets verwaltet. Wichtig ist nur, dass die Adresse dir gehört, also unter deiner Domain liegt. Dann bleibt der Anbieter dahinter austauschbar.

Automatisch prüfen, von Hand entscheiden

Zwei Dinge lassen sich der Maschine überlassen. Erstens die Erinnerung an das Expires-Datum: Unsere Datei wird zusammen mit der Website ausgeliefert und liegt im Git-Server, das Datum steht als Termin im Kalender. Läuft es ab, ohne dass jemand die Angaben bestätigt, ist das ein Fehler wie ein ablaufendes Zertifikat. Zweitens die Vorsortierung eingehender Meldungen: viel von dem, was an eine öffentliche Sicherheitsadresse kommt, sind Massenmails und Berichte aus automatischen Scannern ohne echten Befund.

Was nicht automatisch passiert, ist die Bewertung. Ob eine Meldung ein Fehlalarm ist, ob ein Dienst sofort abgeschaltet, eine Version zurückgerollt oder erst einmal nur beobachtet wird, entscheidet ein Mensch. So bauen wir auch unsere Automatisierungen: das System schlägt vor, freigegeben wird von einem Menschen. Bei einer Sicherheitsmeldung ist die falsche Reaktion oft schädlicher als die Lücke.

Warum das jetzt drängt

Die Zahl der gefundenen Schwachstellen steigt, weil Suchen billiger geworden ist. Die Chefin von Google Threat Intelligence sagt, es gebe dank KI mehr Zero-Days als je zuvor. Für dich heißt das nichts Dramatisches, aber etwas Praktisches: Die Wahrscheinlichkeit, dass jemand in deinen Systemen etwas findet, ist heute höher als vor zwei Jahren. Die Frage ist nur, ob dieser Jemand weiß, wohin er schreiben soll.

Was du diese Woche tun kannst

1. Prüfe, ob unter deinedomain.de/.well-known/security.txt etwas liegt. Wahrscheinlich nicht.
2. Leg eine Textdatei mit Contact, Expires und Preferred-Languages an. Als Kontakt eine Adresse unter deiner Domain, kein persönliches Postfach.
3. Schreib auf, wer dieses Postfach liest und wer im Vertretungsfall antwortet.
4. Setz das Expires-Datum auf höchstens ein Jahr und trag es als Termin ein.

Unspektakulär, und genau deshalb belastbar. Wenn du wissen willst, wie so ein Postfach und der Rest des Betriebs bei dir aussehen könnte, schreib uns.