security.txt-Datei des Schweizer Verkehrssektors

Nein. Alles, was hier gemessen wird, ist öffentlich und wird von jedem Besucher oder Mailserver ohnehin gelesen: die von der Startseite zurückgegebenen Header, DNS-Einträge, die bei jeder eingehenden E-Mail abgefragt werden, und die Datei security.txt, wo sie veröffentlicht ist. Hinzu kommen zwei öffentliche Datenbanken, die abgefragt werden, ohne die Organisation je zu kontaktieren: die in die Browser integrierte HSTS-Preload-Liste und die Routing-Datenbank des RIPE NCC (RIPEstat). Keine Penetrationstests, keine Suche nach Schwachstellen, keine Anmeldeversuche, keine abgeschickten Formulare. Eine einzige Anfrage pro Domain und Durchlauf dient allen Prüfungsfamilien zugleich, und der User-Agent der Sonden verweist auf diese Seite, damit ein Betreiber, der seine Protokolle prüft, weiss, woher der Datenverkehr stammt.

Zu veröffentlichen, dass eine bestimmte Website einen bestimmten Schutz nicht anwendet, kommt einer Liste von Angriffszielen gleich und hilft niemandem bei der Behebung. Diese Seite veröffentlicht daher aggregierte Werte: wie viele Organisationen die bewährten Praktiken anwenden, in welchem Umfang und wie sich die Lage entwickelt. Die Karte zeigt das Gesamturteil jeder Organisation, nie die Liste ihrer Mängel. Die Datei security.txt bildet eine Ausnahme und bleibt öffentlich, denn sie gibt an, wem eine Sicherheitslücke gemeldet werden kann.

Die verantwortliche Person für Informationssicherheit (CISO) der betreffenden Organisation oder des Gemeinwesens, dem sie angehört: Ein kantonaler CISO sieht den Kanton und alle Gemeinden dieses Kantons, ein kommunaler CISO die Gemeinde. Für Organisationen, die mehrere Einrichtungen koordinieren, gibt es branchenweite und nationale Zugänge.

Der Zugang steht den Sicherheitsverantwortlichen der erfassten Organisationen offen, auf Anfrage und nach Prüfung. In seinem Bereich bietet ein genehmigter Zugang das Detail Prüfung für Prüfung, die Liste der noch zu behebenden Punkte, den Verlauf jeder Organisation, ein PDF-Blatt sowie die konsolidierte Auswertung mit ihrem Massnahmenplan. Der Antrag erfolgt auf dieser Seite: Zugang beantragen.

Jede Prüfung hat ein Gewicht und einen Schweregrad. Das Ergebnis einer Prüfungsfamilie wird in drei Stufen bewertet: «Stark» ab 80 % der Punkte, «Teilweise» ab 40 %, «Zu verstärken» darunter. Danach gelten unabhängig von der Summe zwei Obergrenzen: Eine fehlgeschlagene kritische Prüfung führt auf «Zu verstärken» zurück, eine teilweise erfüllte kritische Prüfung oder eine fehlgeschlagene schwerwiegende Prüfung verhindert ein besseres Ergebnis als «Teilweise». Die Gesamtbewertung ist der Durchschnitt der Sonden, die ein Urteil geliefert haben, auf derselben Skala. Was nicht gemessen werden konnte, bleibt «Nicht bewertet» und fliesst nicht in diesen Durchschnitt ein. Mehr dazu: die Gewichte und Schweregrade im Detail, Prüfung für Prüfung.

Messwerte, die bei jeder Analyse erhoben werden, um zu informieren, ohne zu bewerten: IPv6-Erreichbarkeit von Website und Mailsystem, Eintrag in der HSTS-Preload-Liste der Browser, RPKI-Signatur der Route zum Server, im DNS verankertes Zertifikat der Mailserver (DANE), Werbe- oder Analyse-Tracker und Google Fonts, die von der Startseite geladen werden, sowie Betreiber und Registrierungsland der Adressen von Website und Mailsystem. Sie fliessen in kein Ergebnis ein: Diese Praktiken sind noch wenig verbreitet oder hängen vom Hoster ab, und eine Seite, die ohne Ausführung von Skripten gelesen wird, verrät nicht, ob ein Tracker auf die Einwilligung des Besuchers wartet. Das Land ist jenes, unter dem die Adresse registriert ist, in der Regel der Sitz des Betreibers, nicht der Standort des Servers. Die Öffentlichkeit sieht die Anteile pro Bereich; das Detail pro Organisation bleibt deren Sicherheitsverantwortlichen vorbehalten.

Jeder Bereich wird monatlich analysiert. Das genaue Datum der angezeigten Messung steht weiter oben auf dieser Seite am Anfang der Statistiken, und der Verlauf hält sie Monat für Monat fest. Eine Korrektur durch eine Organisation erscheint daher beim nächsten Durchlauf, nicht am selben Tag.

Es ist eine Textdatei, die unter einer festen Adresse veröffentlicht wird, /.well-known/security.txt, und durch RFC 9116 standardisiert ist. Sie gibt an, wem eine Sicherheitslücke gemeldet werden kann, in welcher Sprache und bis zu welchem Datum die Angaben aktuell gehalten werden. Wer sie veröffentlicht, legt vor dem Vorfall fest, wer Meldungen bearbeitet – eine Erwartung des BACS. Ohne sie muss die Person, die ein Problem entdeckt, improvisieren: allgemeines Kontaktformular, soziale Netzwerke oder ganz darauf verzichten. Bewährt ist, eine allgemeine Adresse anzugeben, die von mehreren Personen gelesen wird, statt der Adresse einer einzelnen Person. Felder, Offenlegungsrichtlinie, Pflichten nach NIS2 und CRA, Einführung in sechs Schritten: der vollständige Leitfaden zu security.txt.