Zusammenfassung

  • RFC 9116 standardisiert die Auffindbarkeit eines Meldewegs und die Gültigkeitsdauer seiner veröffentlichten Angaben; Zustellung, Fallanlage und operative Übernahme weist die Datei nicht nach.
  • Ein Meldekanal-Nachweis sollte die abgerufene Datei mit einem ungefährlichen Test, Transportergebnis, Eingangsbestätigung, Queue-Verantwortung, Eskalationszielen und erneuten Prüfereignissen verbinden.

Analyse

Die Datei liegt am richtigen Ort, wird über HTTPS ausgeliefert und enthält Contact, Policy und ein Ablaufdatum im nächsten Jahr. Das Asset-Inventar meldet Grün. Nach einer Umstellung des Mailsystems existiert die Adresse zwar weiter, nimmt aber nur noch Nachrichten aus dem internen Netz an. Erst ein externer Sicherheitsforscher entdeckt den dauerhaften Zustellfehler.

Das ist kein Versagen von RFC 9116. Es ist ein Kategorienfehler zwischen Dokument und Dienst.

Der Standard löst die Suche nach einer Meldemöglichkeit. Eine gültige Datei benötigt mindestens ein Contact-Feld und genau ein Expires-Feld. Für Webdienste ist /.well-known/security.txt vorgesehen, ausgeliefert per HTTPS als UTF-8-Klartext. Die IANA führt security.txt als permanenten Well-Known-URI-Eintrag; Änderungskontrolle liegt bei der IETF. Damit können Menschen und Werkzeuge dieselbe öffentliche Oberfläche finden und lesen.

Auch das Ablaufdatum hat einen klaren Wert. Nach Expires sollen die Angaben als veraltet gelten, wobei RFC 9116 weniger als ein Jahr im Voraus empfiehlt. Die Sicherheitshinweise warnen, dass falsche oder ungepflegte Verweise dazu führen können, dass Berichte die Organisation nicht erreichen oder an einen falschen Empfänger gehen. Regelmäßige Prüfung der Veröffentlichung ist damit keine Nebensache.

Das Datum bleibt jedoch eine Erklärung des Herausgebers. Es ist keine Empfangsbestätigung des Mailservers, kein Datensatz des Formularsystems und keine Übernahme durch eine Analystin. Wer die Datei aktualisiert, muss nicht über die Systeme dahinter verfügen.

Zwei Uhren, fünf Übergaben

Die Veröffentlichungsuhr erfasst Erstellung, Kontrolle und Ablauf der Datei. Die Betriebsuhr beginnt mit der Annahme einer Meldung und läuft über Bestätigung, Erstbewertung, Zuweisung, Eskalation und Ergebnisnachricht. Das Fortschreiben der ersten Uhr beweist keinen Schritt der zweiten.

Die erste Übergabe betrifft den Geltungsbereich. Nach RFC 9116 gilt eine Datei für die Domain oder IP-Adresse ihres Abrufortes, nicht automatisch für über- oder untergeordnete Domains. Eine Policy kann weitere Produkte einbeziehen, doch diese Verbindung muss ausdrücklich nachvollziehbar sein.

Die zweite Übergabe ist der Transport. Eine syntaktisch richtige Mailadresse kann externe Absender ablehnen. Ein Formular kann laden und nach dem Absenden scheitern. Eine Plattform kann einen Fall speichern, aber die Kundenbenachrichtigung an eine veraltete Gruppe schicken. Der erfolgreiche Abruf der Datei beobachtet keinen dieser Schritte.

Die dritte Übergabe ist Vertraulichkeit. Encryption verweist auf einen Schlüssel oder Fingerabdruck; der Schlüssel wird nicht in das Feld eingebettet. RFC 9116 überlässt dem Forschenden die Prüfung der Authentizität. Ein erreichbarer öffentlicher Schlüssel zeigt nicht, dass das Bereitschaftsteam den passenden privaten Schlüssel besitzt oder die Entschlüsselung nach einem Personalwechsel beherrscht.

Die vierte Übergabe ist die Eingangsbestätigung. Eine beständige Fallnummer oder zuordenbare Antwort macht aus technischer Annahme organisatorische Obhut. Eine automatische Nachricht ist nur dann belastbar, wenn sie zu einer überwachten Queue gehört und später mit der Bearbeitung abgeglichen werden kann.

Die fünfte Übergabe ist die Fallführung. Wer bewertet? Wer leitet Meldungen außerhalb des Geltungsbereichs weiter? Wer koordiniert Abhilfe und informiert den Absender? Die verbindliche operative Direktive 20-01 der CISA zeigt diese Ebene für die erfassten zivilen US-Bundesbehörden. Sie verlangt Verfahren zur Verfolgung bis zur Lösung, internen Koordination, Auswirkungsbewertung, Behandlung von Out-of-Scope-Berichten und Kommunikation. Außerdem verlangt sie Zielzeiten für Bestätigung, Erstbewertung und Lösung. Das sind weder Anforderungen von RFC 9116 noch weltweit geltendes Recht.

Die Direktive belegt vielmehr, dass Veröffentlichung und Betrieb getrennte Kontrollen sind.

Ein sicherer, kleiner Test

Der Nachweis beginnt mit der kanonischen Abruf-URI, dem Datei-Fingerabdruck, Abrufzeitpunkt, angegebenen Ablaufdatum und Geltungsbereich. Er hält den gemäß Reihenfolge bevorzugten Kontakt fest. Bei einem Formular kommt dessen Version hinzu, bei Verschlüsselung der beobachtete Fingerabdruck.

Danach folgt ein vom Empfangsteam genehmigter synthetischer Test. Er kennzeichnet sich als Routing-Prüfung, nennt den gewünschten Abschluss und enthält keine reale Schwachstelle, keinen Exploit, keine Geheimnisse und keine personenbezogenen Daten. Festgehalten werden Versand, Annahme oder Ablehnung, Bestätigungszeit, Fallkennung, funktionaler Queue-Verantwortlicher und Vertretung sowie Ziele für Bewertung und Eskalation.

Kein Ergebnis darf größer gemacht werden, als es ist. Ein positiver SMTP-Code belegt die Annahme an einem Übergabepunkt, nicht das Lesen. Eine Dankeseite belegt eine Antwort der Anwendung, nicht dauerhafte Speicherung. Ein Autoresponder belegt eine Regel, nicht menschliche Aufmerksamkeit. Nicht geprüfte Eskalationen bleiben als solche markiert.

Der Test selbst darf die Einsatzfähigkeit nicht belasten. Die empfangende Mannschaft genehmigt eine eindeutige Kennzeichnung. Erneut geprüft wird nach Mail- oder DNS-Migration, Formular-Release, Identitätswechsel, Schlüsselrotation, Lieferantenübergabe, Verantwortungswechsel, Policy-Revision oder neuer Domain. Ohne Ereignis genügt ein maßvolles Intervall vor Ablauf der Datei.

Präzise statt pauschal

Der Nachweis ersetzt security.txt nicht. Die Datei bleibt die offene Auffindbarkeitsoberfläche. Canonical, Policy, Preferred-Languages und Encryption beseitigen unterschiedliche Unklarheiten. Eine Signatur kann Herkunft und Integrität stärken.

Der Zusatznachweis fragt nur: Wann führte der angekündigte Weg zuletzt mindestens von öffentlicher Entdeckung zu erkennbarer organisatorischer Obhut? „Datei gültig, Mail angenommen, keine Bestätigung“ ist ein brauchbarer Zustand. „Formular legt Fall an, Besitzer bestätigt, Vertretung offen“ ebenso. Teilergebnisse zeigen die Reparaturstelle besser als ein Gesamtsiegel.

Für ein Dashboard reicht eine Zeile: Datei am 7. September abgerufen; Ablauf am 1. März; Test angenommen; Fall nach 14 Minuten bestätigt; Queue-Verantwortung geprüft; Eskalation nicht getestet. Jeder Abschnitt hat eigene Evidenz und Beobachtungszeit. Keiner verspricht, dass eine künftige Schwachstelle valide, richtig priorisiert oder rechtzeitig behoben wird.

Quellen

  1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
  2. IANA-Register der Well-Known URIs
  3. CISA Binding Operational Directive 20-01