Kritische Infrastrukturen in der Schweiz: Kennzahlen zur Cybersicherheit, Vergleiche und Prioritäten für Abhilfemassnahmen für Kantone, Gemeinden, den Finanzsektor und Krankenhäuser.
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).
dcod.ch
Cybersicherheit • KI • Tech
Observatorium für die Cybersicherheit der kritischen Infrastrukturen der Schweiz
Kontrolle
Stand 9 Oktober 2026 Quelle : Infrastructures et exploitants de l'approvisionnement énergétique : transport, production, négoce et distribution d'électricité (gestionnaires de réseau recensés par l'ElCom), gaz, pétrole, organismes de surveillance et de gestion de crise.
Erfasste Einheiten
493
493 gemessen · 0 nicht erreichbar
Art kritischer Infrastruktur
Energie
Aufsicht und Krisenvorsorge, Erdöllagerung und Pflichtlager, Erdölraffination, Gastransport, Gasverteilung, Stromhandel und -lieferung, Stromproduktion, Stromverteilung, Stromübertragung, Vertrieb von Erdölprodukten
Zusammensetzung des Bereichs
Art der erfassten Einrichtungen, unabhängig von ihrem Ergebnis.
- Stromverteilung 445
- Strom: Übertragung, Produktion, Handel 18
- Erdöl 12
- Aufsicht und Krisenvorsorge 9
- Gas 9
Ergebnisse
Konformitätsgrad
Über alle gemessenen Einheiten, einschliesslich jener, die nichts veröffentlichen.
- Stark 21
- Teilweise 173
- Zu verstärken 299
| Ergebnis | Einheiten | % |
|---|---|---|
| Stark | 21 | 4 % |
| Teilweise | 173 | 35 % |
| Zu verstärken | 299 | 61 % |
Vergleich der Bereiche
Alle kritischen Infrastrukturen im Vergleich, gesamtschweizerisch.
Kantone
Gemeinden
Finanzen
Spitäler
Energie
Verkehr
- Stark
- Teilweise
- Zu verstärken
Vergleich der Institutstypen
Anteil konformer Einrichtungen, pro Institutstyp – vom besten zum schwächsten.
Gas
Strom: Übertragung, Produktion, Handel
Stromverteilung
Aufsicht und Krisenvorsorge
Erdöl
- 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 Zertifikat für anderen Namen | Ein Zertifikat ausstellen, das die Domain und ihre www-Variante abdeckt (Feld « Subject Alternative Name »), oder den Hoster bitten, es für diese Domain zu aktivieren. | |
| 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. | |
| Kritisch | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS Verbindung abgebrochen | Die TLS-Konfiguration des Servers und die Firewall-Regeln auf Port 443 prüfen ; SSL Labs (ssllabs.com/ssltest) hilft, das Problem einzugrenzen. | |
| 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 | Die Zeile « Expires: » mit einem Datum in höchstens einem Jahr hinzufügen oder aktualisieren und eine Erinnerung einrichten, um sie vor Ablauf zu verlängern. | |
| 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 | Gültige Kontaktadresse (Feld Contact) STXT-CONTACT | Eine Zeile « Contact: mailto:sicherheit@beispiel.ch » hinzufügen – eine Zeile pro Kontaktweg. | |
| 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 | 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» (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=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=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 | 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 | Verschlüsselte Verbindung verfügbar (HTTPS) HEAD-HTTPS teilweise unvollständige Zertifikatskette | Auf dem Server die vollständige Kette installieren (Zertifikat + Zwischenzertifikate : Datei « fullchain.pem » bei Let's Encrypt, « Bundle » bei anderen Stellen) und danach mit SSL Labs (ssllabs.com/ssltest) prüfen : der Hinweis « Chain issues: Incomplete » muss verschwinden. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise ohne «all»-Abschluss | «-all» (oder «~all» während einer Testphase) am Ende des Eintrags hinzufügen. | |
| Erheblich | Berechtigte E-Mail-Absender (SPF) EMAIL-SPF teilweise endet mit «?all» | «?all» durch «-all» (Ablehnung) am Ende des Eintrags ersetzen, oder mindestens «~all» (Markierung) während einer Testphase: «?all» war nie mehr als ein Übergangszustand, keine beizubehaltende Richtlinie. | |
| 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». | |
| 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 | 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 | 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 | Zugriff auf Browserfunktionen eingeschränkt (Permissions-Policy) HEAD-PERMISSIONS | Eine Richtlinie hinzufügen, die Ungenutztes schliesst, zum Beispiel « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Gering | Eingeschränkte Informationen an externe Links (Referrer-Policy) HEAD-REFERRER | Den Header « Referrer-Policy: strict-origin-when-cross-origin » 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 | Dateityp nicht vom Browser neu interpretiert (nosniff) HEAD-NOSNIFF | Den Header « X-Content-Type-Options: nosniff » in der Serverkonfiguration 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 | 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 | 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 | Datei mit und ohne www erreichbar STXT-BOTH-VARIANTS | Dieselbe Datei unter beiden Varianten ausliefern oder die eine auf die andere weiterleiten. | |
| Gering | Kontaktsprachen angegeben (Feld Preferred-Languages) STXT-LANGUAGES | Eine Zeile « Preferred-Languages: de, fr, it, en » mit den für Meldungen akzeptierten Sprachen hinzufügen. | |
| 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. | |
| 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. |
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.