Diese Analyse fasst die Ergebnisse der Cybersicherheits-Scans zusammen, die an kritischen Infrastrukturen in der Schweiz durchgeführt wurden. Dabei wurden drei Bereiche untersucht: security.txt (Kontaktstelle zur Meldung von Sicherheitslücken), Sicherheits-Header und E-Mail-Sicherheit (SPF, DMARC, DNSSEC).
Stand 11 Oktober 2026 Quelle : Exploitants et autorités des transports : chemins de fer à voie normale et à voie étroite, transports urbains, cars et bus régionaux, navigation lacustre, aéroports et navigation aérienne, transport par câble, fret ferroviaire et transport combiné, organismes de régulation et de tutelle.
Erfasste Einheiten
74
74 gemessen · 0 nicht erreichbar
Art kritischer Infrastruktur
Verkehr
Flughäfen und Luftraum, Konzessionierte Schifffahrt, Konzessionierte Seilbahnen, Normalspurbahnen, Ortsverkehr (Tram, Trolleybus, Metro), Regionaler Busverkehr, Regulierung und Aufsicht, Schienengüterverkehr und kombinierter Verkehr, Schmalspurbahnen
Zusammensetzung des Bereichs
Art der erfassten Einrichtungen, unabhängig von ihrem Ergebnis.
- Regionalbahnen 21
- Ortsverkehr 12
- Seilbahnen 9
- Flughäfen und Luftraum 8
- Schifffahrt 7
- Regionaler Busverkehr 6
- Schienengüterverkehr 5
- Regulierung und Aufsicht 3
- Normalspurbahnen 3
Ergebnisse
Konformitätsgrad
Über alle gemessenen Einheiten, einschliesslich jener, die nichts veröffentlichen.
- Stark 4
- Teilweise 19
- Zu verstärken 51
| Ergebnis | Einheiten | % |
|---|---|---|
| Stark | 4 | 5 % |
| Teilweise | 19 | 26 % |
| Zu verstärken | 51 | 69 % |
Vergleich der Bereiche
Alle kritischen Infrastrukturen im Vergleich, gesamtschweizerisch.
- Stark
- Teilweise
- Zu verstärken
Vergleich der Institutstypen
Anteil konformer Einrichtungen, pro Institutstyp – vom besten zum schwächsten.
- Stark
- Teilweise
- Zu verstärken
Zu behebende Probleme
Aufgetretene Fehlertypen, nach Schweregrad geordnet und nicht nach Häufigkeit. Der Anteil nennt die betroffenen gemessenen Einheiten.
| Schweregrad | Kontrolle | Betroffen | Empfohlene Korrektur |
|---|---|---|---|
| Kritisch | security.txt-Datei veröffentlicht STXT-PRESENT | Unter /.well-known/security.txt der Website eine Textdatei mit mindestens einer Zeile « Contact: » und einer Zeile « Expires: » veröffentlichen. Eine allgemeine Adresse wählen, die von mehreren Personen gelesen wird (zum Beispiel sicherheit@…), nie das Postfach einer einzelnen Person. | |
| Kritisch | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC | Einen TXT-Eintrag unter _dmarc.<Domain> veröffentlichen : mit « v=DMARC1; p=none; rua=mailto:dmarc@beispiel.ch » beginnen, die Berichte einige Wochen auswerten, dann auf « p=quarantine » und schliesslich auf « p=reject » verschärfen. | |
| Kritisch | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF | In der DNS-Zone der Domain (beim Hoster oder Registrar, der sie verwaltet) einen einzigen TXT-Eintrag veröffentlichen, der mit « v=spf1 » beginnt, alle legitimen Versanddienste auflistet und mit « -all » endet. Bis geprüft ist, dass alle legitimen Versender aufgeführt sind, kann « ~all » als Zwischenschritt dienen. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS | Ein gültiges Zertifikat für den Namen der Website installieren (Let's Encrypt ist kostenlos und erneuert sich automatisch), es mit seinen Zwischenzertifikaten ausliefern und prüfen, dass die automatische Erneuerung funktioniert. | |
| Erheblich | Erzwungene SMTP-Verschlüsselung im Transit (MTA-STS) EMAIL-MTA-STS | Einen TXT-Eintrag unter _mta-sts.<Domain> veröffentlichen (« v=STSv1; id=… »), dann die Richtliniendatei unter https://mta-sts.<Domain>/.well-known/mta-sts.txt, zuerst mit « mode: testing », nach der Prüfung mit « mode: enforce ». | |
| Erheblich | Signierte und überprüfbare DNS-Antworten (DNSSEC) EMAIL-DNSSEC | DNSSEC beim Anbieter der DNS-Zone aktivieren (oft eine einfache Option) und den DS-Eintrag beim Registrar der Domain veröffentlichen lassen – viele erledigen das automatisch. | |
| Erheblich | Browser zu dauerhaftem HTTPS gezwungen (HSTS) HEAD-HSTS | Sobald die Website vollständig per HTTPS ausgeliefert wird, den Header « Strict-Transport-Security: max-age=31536000 » (ein Jahr) hinzufügen ; « includeSubDomains » ergänzen, wenn auch alle Subdomains per HTTPS erreichbar sind. | |
| Erheblich | Automatische Weiterleitung auf HTTPS HEAD-REDIRECT | Den Server oder das Hosting so einrichten, dass jede http://-Adresse auf ihre https://-Entsprechung weiterleitet, vorzugsweise dauerhaft (301 oder 308). | |
| Erheblich | Automatische Weiterleitung auf HTTPS HEAD-REDIRECT Weiterleitung auf eine Nicht-HTTPS-Adresse | Bereits beim ersten Schritt direkt auf https://<gleiche Domain>/ weiterleiten, ohne HTTP-Zwischenschritt. | |
| Erheblich | Gültigkeitsdatum angegeben (Feld Expires) STXT-EXPIRES Gültigkeitsdatum überschritten | Das Datum im Feld «Expires:» erneuern (ISO 8601, zum Beispiel in einem Jahr) und eine Erinnerung vor dem nächsten Ablauf einplanen. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=quarantine» | Von «p=quarantine» zu «p=reject» (Ablehnung) wechseln, sobald die rua=-Berichte geprüft und Fehlalarme ausgeschlossen wurden. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=none» (nur Beobachtung) | Von «p=none» zu «p=quarantine» (Quarantäne) wechseln, später zu «p=reject» (Ablehnung), sobald die rua=-Berichte geprüft wurden. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=quarantine» ohne «rua=» | «rua=mailto:…» hinzufügen, um Berichte zu erhalten, dann von «p=quarantine» zu «p=reject» (Ablehnung) wechseln, sobald diese Berichte geprüft und Fehlalarme ausgeschlossen wurden. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise endet mit «~all» | «~all» am Ende des Eintrags durch «-all» ersetzen, sobald die berechtigten Absender vollständig erfasst sind («~all» ist nur als Testphase gedacht). | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=none» ohne «rua=» | «rua=mailto:…» zum Eintrag hinzufügen, um Aggregatberichte zu erhalten: ohne sie ist nicht feststellbar, wann auf «p=quarantine» oder «p=reject» verschärft werden kann, ohne legitime E-Mails zu blockieren. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=reject» ohne «rua=» | «rua=mailto:…» zum Eintrag hinzufügen: die Ablehnungsrichtlinie bleibt unverändert, aber die Domain erhält endlich Berichte über Missbrauchsversuche und kann prüfen, ob ihre Konfiguration weiterhin wie erwartet funktioniert. | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise Subdomains schwächer geschützt | «sp=reject» hinzufügen oder verschärfen, um die Subdomain-Richtlinie an die Hauptdomain anzugleichen – mindestens «sp=quarantine». | |
| Erheblich | Richtlinie für betrügerische E-Mails (DMARC) EMAIL-DMARC teilweise «p=reject» nur teilweise («pct=») | «pct=» schrittweise auf 100 erhöhen (oder entfernen, 100 ist der Standardwert), sobald die rua=-Berichte geprüft wurden. | |
| Gering | Eingeschränkte Zertifizierungsstellen (CAA) EMAIL-CAA | In der DNS-Zone der Domain einen CAA-Eintrag veröffentlichen, der die genutzte(n) Stelle(n) nennt, zum Beispiel « 0 issue "letsencrypt.org" ». | |
| Gering | Berichte über SMTP-Verschlüsselungsfehler (TLS-RPT) EMAIL-TLSRPT | Einen TXT-Eintrag unter _smtp._tls.<Domain> veröffentlichen (« v=TLSRPTv1; rua=mailto:tls-berichte@beispiel.ch »). | |
| Gering | Zugriff auf Browserfunktionen eingeschränkt (Permissions-Policy) HEAD-PERMISSIONS | Eine Richtlinie hinzufügen, die Ungenutztes schliesst, zum Beispiel « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Gering | Liste erlaubter Skripte und Ressourcen (CSP) HEAD-CSP | Eine auf die Website zugeschnittene Richtlinie festlegen, sie zuerst im Modus « Content-Security-Policy-Report-Only » testen, das Gemeldete korrigieren und sie dann anwenden. | |
| Gering | Eingeschränkte Informationen an externe Links (Referrer-Policy) HEAD-REFERRER | Den Header « Referrer-Policy: strict-origin-when-cross-origin » hinzufügen. | |
| Gering | Dateityp nicht vom Browser neu interpretiert (nosniff) HEAD-NOSNIFF | Den Header « X-Content-Type-Options: nosniff » in der Serverkonfiguration hinzufügen. | |
| Gering | Schutz vor Einbettung in unsichtbare Rahmen (Anti-Clickjacking) HEAD-FRAME | « X-Frame-Options: SAMEORIGIN » oder die Direktive « frame-ancestors 'self' » in der CSP-Richtlinie hinzufügen. | |
| Gering | Verschlüsselungsschlüssel veröffentlicht (Feld Encryption) STXT-ENCRYPTION | Eine Zeile « Encryption: https://beispiel.ch/pgp-schluessel.asc » hinzufügen, die auf den öffentlichen Schlüssel des Sicherheitsteams verweist. | |
| Gering | Geschützte Cookies (Secure, HttpOnly, SameSite) HEAD-COOKIES | Jedem von der Website gesetzten Cookie die Attribute Secure, HttpOnly und SameSite (mindestens Lax) hinzufügen. | |
| Gering | Softwareversion nicht offengelegt HEAD-VERSION | Den Server so konfigurieren, dass die Versionsnummer in den Headern Server und X-Powered-By verborgen bleibt (zum Beispiel ServerTokens Prod und ServerSignature Off bei Apache, expose_php = Off bei PHP). | |
| Gering | Datei mit und ohne www erreichbar STXT-BOTH-VARIANTS | Dieselbe Datei unter beiden Varianten ausliefern oder die eine auf die andere weiterleiten. | |
| Gering | Geschützte Cookies (Secure, HttpOnly, SameSite) HEAD-COOKIES teilweise | Jedem von der Website gesetzten Cookie die Attribute Secure, HttpOnly und SameSite (mindestens Lax) hinzufügen. | |
| Gering | Liste erlaubter Skripte und Ressourcen (CSP) HEAD-CSP teilweise nur Report-Modus | Sobald die Reports ohne Fehlalarme geprüft sind, dieselbe Richtlinie unter dem Header «Content-Security-Policy» (ohne «-Report-Only») veröffentlichen, damit sie tatsächlich angewendet wird. | |
| Gering | Browser zu dauerhaftem HTTPS gezwungen (HSTS) HEAD-HSTS teilweise Dauer (max-age) zu kurz | max-age auf mindestens 15552000 (6 Monate) erhöhen – idealerweise 31536000 (1 Jahr) mit includeSubDomains. |
Ausführliche Leitfäden (auf Französisch): security.txt : le guide complet du signalement des vulnérabilités · SPF, DKIM, DMARC : le guide complet de la sécurité des emails · En-têtes de sécurité HTTP : le guide complet (HSTS, CSP, cookies)
Entwicklung
Monatliche Entwicklung des gesamten Registers, alle Einheiten zusammen.
Noch kein Verlauf für diese Kontrolle: die Kurve erscheint, sobald zwei vollständige Scans in verschiedenen Monaten vorliegen.
Methodik und Grenzen
Die Bewertungen beruhen auf dem Stand des Beobachtungsdatums und ausschliesslich auf öffentlich zugänglichen Informationen, die passiv und ohne Authentifizierung erhoben wurden. Sie stellen weder ein Sicherheitsaudit noch einen Penetrationstest noch eine Zertifizierung dar. Ein «solides» Ergebnis garantiert nicht die Abwesenheit von Schwachstellen; ein «zu verstärkender» Punkt bedeutet weder eine Kompromittierung noch die Verletzung einer gesetzlichen oder vertraglichen Pflicht.