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 : Sites officiels des 26 cantons suisses (curation DCOD).
Erfasste Einheiten
26
26 gemessen · 0 nicht erreichbar
Art kritischer Infrastruktur
Behörden
Parlament, Regierung, Justiz, Verwaltung
Ergebnisse
Konformitätsgrad
Über alle gemessenen Einheiten, einschliesslich jener, die nichts veröffentlichen.
- Stark 6
- Teilweise 15
- Zu verstärken 5
| Ergebnis | Einheiten | % |
|---|---|---|
| Stark | 6 | 23 % |
| Teilweise | 15 | 58 % |
| Zu verstärken | 5 | 19 % |
Vergleich der Bereiche
Alle kritischen Infrastrukturen im Vergleich, gesamtschweizerisch.
- Stark
- Teilweise
- Zu verstärken
Vergleich der Gemeinden nach Kanton
Anteil konformer Gemeinden, pro Kanton. Diese Ansicht fasst alle Gemeinden jedes Kantons zusammen: Sie gibt nicht das Ergebnis der kantonalen Website selbst wieder, deren Punktwert den zuständigen Sicherheitsverantwortlichen vorbehalten bleibt.
- 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 | 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ü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 | 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» | 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 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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. |
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.
| Monat | Stark | Teilweise | Zu verstärken | Bewertete Einheiten |
|---|---|---|---|---|
| 2026-08 | 23 % | 73 % | 4 % | 26 |
| 2026-09 | 23 % | 58 % | 19 % | 26 |
| 2026-10 | 23 % | 58 % | 19 % | 26 |
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.