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 1 Oktober 2026 Quelle : Établissements hospitaliers publics et subventionnés (listes hospitalières cantonales, art. 39 LAMal).
Erfasste Einheiten
46
46 gemessen · 0 nicht erreichbar
Art kritischer Infrastruktur
Gesundheitswesen
Medizinische Versorgung und Spitäler
Zusammensetzung des Bereichs
Art der erfassten Einrichtungen, unabhängig von ihrem Ergebnis.
- Akutspital 41
- Universitätsspital 5
Ergebnisse
Konformitätsgrad
Über alle gemessenen Einheiten, einschliesslich jener, die nichts veröffentlichen.
- Stark 2
- Teilweise 11
- Zu verstärken 33
| Ergebnis | Einheiten | % |
|---|---|---|
| Stark | 2 | 4 % |
| Teilweise | 11 | 24 % |
| Zu verstärken | 33 | 72 % |
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. | |
| 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=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» | 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 | 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 «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. | |
| 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 | Eingeschränkte Informationen an externe Links (Referrer-Policy) HEAD-REFERRER | Den Header « Referrer-Policy: strict-origin-when-cross-origin » hinzufügen. | |
| 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 | 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 | 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 | Dateityp nicht vom Browser neu interpretiert (nosniff) HEAD-NOSNIFF | Den Header « X-Content-Type-Options: nosniff » in der Serverkonfiguration 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 | 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.
| Monat | Stark | Teilweise | Zu verstärken | Bewertete Einheiten |
|---|---|---|---|---|
| 2026-08 | 11 % | 68 % | 21 % | 47 |
| 2026-09 | 4 % | 24 % | 72 % | 47 |
| 2026-10 | 4 % | 24 % | 72 % | 47 |
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.