Infrastructures critiques suisses : chiffres clés de cybersécurité, comparaisons et priorités de correction pour cantons, communes, finance et hôpitaux.
Cette analyse consolide les résultats des scans de cybersécurité menés sur les infrastructures critiques suisses. Trois axes mesurés : security.txt (point de contact pour signaler une faille), en-têtes de sécurité, et sécurité e-mail (SPF, DMARC, DNSSEC).
dcod.ch
Cybersécurité • IA • Tech
Observatoire de la cybersécurité des infrastructures critiques suisses
Périmètre
Cantons suissesCommunes suissesÉtablissements financiers suissesHôpitaux suissesApprovisionnement énergétique suisse
Contrôle
État au 9 octobre 2026 Source : 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.
Entités recensées
493
493 mesurées · 0 inatteignables
Type d'infrastructure critique
Énergie
Distribution d'électricité, Distribution de gaz, Distribution de produits pétroliers, Négoce et fourniture d'électricité, Production d'électricité, Raffinage pétrolier, Stockage et réserves pétrolières, Surveillance et gestion de crise, Transport d'électricité, Transport de gaz
Composition du périmètre
Type des établissements recensés, indépendamment de leur résultat.
- Distribution d'électricité 445
- Électricité : transport, production, négoce 18
- Pétrole 12
- Surveillance et gestion de crise 9
- Gaz 9
Résultats
Niveau de conformité
Sur l'ensemble des entités mesurées, y compris celles qui ne publient rien.
- Solide 21
- Partiel 173
- À renforcer 299
| Résultat | Entités | % |
|---|---|---|
| Solide | 21 | 4 % |
| Partiel | 173 | 35 % |
| À renforcer | 299 | 61 % |
Comparaison entre domaines
Tous les domaines d'infrastructure critique comparés entre eux, au niveau suisse.
Cantons suisses
Communes suisses
Établissements financiers suisses
Hôpitaux suisses
Approvisionnement énergétique suisse
- Solide
- Partiel
- À renforcer
Comparaison entre types d'établissement
Part des établissements en conformité, par type d'établissement – du meilleur au moins bon.
Gaz
Électricité : transport, production, négoce
Distribution d'électricité
Surveillance et gestion de crise
Pétrole
- Solide
- Partiel
- À renforcer
Problèmes à corriger
Types d'erreurs rencontrés, classés par gravité et non par fréquence. La part indique combien d'entités mesurées sont touchées.
| Gravité | Contrôle | Entités | Correction recommandée |
|---|---|---|---|
| Critique | Fichier security.txt publié STXT-PRESENT | Publier un fichier texte à l'adresse /.well-known/security.txt du site, portant une adresse de signalement – de préférence une boîte générique relevée par plusieurs personnes, jamais celle d'une seule. | |
| Critique | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC | Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT sur _dmarc.<domaine>, en commençant par « v=DMARC1; p=none; rua=mailto:… » puis en durcissant vers p=reject. | |
| Critique | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF | Publier, dans la zone DNS du domaine (chez l'hébergeur qui la gère), un enregistrement TXT « v=spf1 … -all » listant les serveurs autorisés, terminé par -all. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS certificat pour un autre nom | Émettre un certificat qui couvre le domaine et sa variante www (champ « Subject Alternative Name »), ou demander à l'hébergeur de l'activer pour ce domaine. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS | Installer un certificat (Let's Encrypt est gratuit et automatisable) et servir le site en HTTPS. | |
| Critique | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS connexion interrompue | Contrôler la configuration TLS du serveur et les règles du pare-feu sur le port 443 ; SSL Labs (ssllabs.com/ssltest) aide à situer le problème. | |
| Majeur | Chiffrement SMTP forcé en transit (MTA-STS) EMAIL-MTA-STS | Publier un enregistrement TXT sur _mta-sts.<domaine> (« v=STSv1; id=… »), puis publier le fichier de politique sur https://mta-sts.<domaine>/.well-known/mta-sts.txt avec « mode: enforce » une fois vérifié. | |
| Majeur | Réponses DNS signées et vérifiables (DNSSEC) EMAIL-DNSSEC | Activer DNSSEC chez l'hébergeur de la zone DNS (souvent une simple case à cocher), puis publier l'enregistrement DS chez le registraire. | |
| Majeur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS | Ajouter l'en-tête « Strict-Transport-Security: max-age=31536000 » (1 an ; 6 mois minimum acceptés). | |
| Majeur | Redirection automatique vers HTTPS HEAD-REDIRECT | Configurer le serveur pour rediriger de manière permanente (301 ou 308) toute requête HTTP vers l'adresse HTTPS équivalente, dès le premier saut – éviter 302 (temporaire), qui incite le navigateur à retenter en clair lors d'une prochaine visite. | |
| Majeur | Redirection automatique vers HTTPS HEAD-REDIRECT redirection vers une adresse non HTTPS | Rediriger directement vers https://<même domaine>/ dès le premier saut, sans étape intermédiaire en HTTP. | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES | Ajouter « Expires: » avec une date ISO 8601 future (par exemple dans un an) et penser à la renouveler. | |
| Majeur | Date de validité renseignée (champ Expires) STXT-EXPIRES date de validité dépassée | Renouveler la date du champ « Expires: » (ISO 8601, par exemple dans un an) et prévoir un rappel avant la prochaine échéance. | |
| Majeur | Adresse de contact valide (champ Contact) STXT-CONTACT | Ajouter une ligne « Contact: mailto:security@exemple.ch » (répéter la ligne pour plusieurs contacts, ne pas la renommer). | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=quarantine » | Passer de « p=quarantine » à « p=reject » (rejet) une fois les rapports rua= vérifiés et les faux positifs écartés. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré se termine par « ~all » | Remplacer « ~all » par « -all » en fin d'enregistrement, une fois les expéditeurs légitimes bien listés (le marquage « ~all » n'est censé être qu'une étape de test). | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » (surveillance seule) | Passer de « p=none » à « p=quarantine » (mise en quarantaine), puis à terme « p=reject » (rejet) une fois les rapports rua= vérifiés. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=none » sans « rua= » | Ajouter « rua=mailto:… » à l'enregistrement pour recevoir les rapports d'agrégation : sans eux, impossible de savoir quand durcir vers « p=quarantine » ou « p=reject » sans risquer de bloquer des courriels légitimes. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=quarantine » sans « rua= » | Ajouter « rua=mailto:… » pour recevoir des rapports, puis passer de « p=quarantine » à « p=reject » (rejet) une fois ces rapports vérifiés et les faux positifs écartés. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré « p=reject » sans « rua= » | Ajouter « rua=mailto:… » à l'enregistrement : la politique de rejet reste inchangée, mais le domaine reçoit enfin des rapports sur les tentatives d'usurpation et peut vérifier que sa configuration continue de fonctionner comme prévu. | |
| Majeur | Connexion chiffrée disponible (HTTPS) HEAD-HTTPS partiellement configuré chaîne de certificats incomplète | Installer sur le serveur la chaîne complète (certificat + intermédiaires : fichier « fullchain.pem » chez Let's Encrypt, « bundle » chez les autres autorités), puis vérifier avec SSL Labs (ssllabs.com/ssltest) : la mention « Chain issues: Incomplete » doit disparaître. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré sans terminaison « all » | Ajouter « -all » (ou « ~all » en phase de test) en fin d'enregistrement. | |
| Majeur | Expéditeurs de courrier autorisés (SPF) EMAIL-SPF partiellement configuré se termine par « ?all » | Remplacer « ?all » par « -all » (rejet) en fin d'enregistrement, ou au minimum « ~all » (marquage) le temps d'une phase de test : « ?all » n'a jamais été qu'un état transitoire, pas une politique à conserver. | |
| Majeur | Politique appliquée aux courriels frauduleux (DMARC) EMAIL-DMARC partiellement configuré sous-domaines moins protégés | Ajouter ou durcir « sp=reject » pour aligner la politique des sous-domaines sur celle du domaine principal – ou « sp=quarantine » a minima. | |
| Mineur | Rapports d'échec de chiffrement SMTP (TLS-RPT) EMAIL-TLSRPT | Publier un enregistrement TXT sur _smtp._tls.<domaine> (« v=TLSRPTv1; rua=mailto:… »). | |
| Mineur | Autorités de certification restreintes (CAA) EMAIL-CAA | Publier, dans la zone DNS du domaine, un enregistrement CAA listant la ou les autorités autorisées (ex. « 0 issue "letsencrypt.org" »). | |
| Mineur | Liste des scripts et ressources autorisés (CSP) HEAD-CSP | Définir une politique, en commençant en mode rapport (Content-Security-Policy-Report-Only) pour vérifier qu'elle ne casse rien. | |
| Mineur | Accès aux fonctions du navigateur limité (Permissions-Policy) HEAD-PERMISSIONS | Ajouter une politique fermant ce qui n'est pas utilisé, par exemple « Permissions-Policy: camera=(), microphone=(), geolocation=() ». | |
| Mineur | Informations limitées vers les liens sortants (Referrer-Policy) HEAD-REFERRER | Ajouter « Referrer-Policy: strict-origin-when-cross-origin ». | |
| Mineur | Protection contre l'affichage dans un cadre invisible (anti-clickjacking) HEAD-FRAME | Ajouter « X-Frame-Options: SAMEORIGIN », ou la directive frame-ancestors dans la politique CSP. | |
| Mineur | Type de fichier non réinterprété par le navigateur (nosniff) HEAD-NOSNIFF | Ajouter l'en-tête « X-Content-Type-Options: nosniff ». | |
| Mineur | Clé de chiffrement publiée (champ Encryption) STXT-ENCRYPTION | Ajouter une ligne « Encryption: https://exemple.ch/cle-pgp.asc » pointant vers la clé publique de l'équipe de sécurité. | |
| Mineur | Numéro de version du logiciel non divulgué HEAD-VERSION | Configurer le serveur pour masquer le numéro de version dans les en-têtes Server et X-Powered-By (souvent ServerTokens Prod et ServerSignature Off sous Apache, expose_php = Off sous PHP). | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. | |
| Mineur | Fichier accessible avec et sans www STXT-BOTH-VARIANTS | Servir le même fichier sur les deux variantes, ou rediriger l'une vers l'autre. | |
| Mineur | Langues de contact indiquées (champ Preferred-Languages) STXT-LANGUAGES | Ajouter une ligne « Preferred-Languages: fr, de, it, en » listant les langues acceptées pour le signalement. | |
| Mineur | Navigateur forcé à rester en HTTPS (HSTS) HEAD-HSTS partiellement configuré durée (max-age) trop courte | Augmenter max-age à au moins 15552000 (6 mois) – idéalement 31536000 (1 an) avec includeSubDomains. | |
| Mineur | Cookies protégés (Secure, HttpOnly, SameSite) HEAD-COOKIES partiellement configuré | Ajouter les attributs Secure, HttpOnly et SameSite (Lax au minimum) à chaque cookie posé par le site. | |
| Mineur | Liste des scripts et ressources autorisés (CSP) HEAD-CSP partiellement configuré mode rapport seul | Une fois les rapports vérifiés sans faux positif, publier la même politique sous l'en-tête « Content-Security-Policy » (sans « -Report-Only ») pour qu'elle s'applique réellement. |
Pour corriger pas à pas, les guides complets : 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)
Évolution
Tendance mensuelle de l'ensemble du registre, toutes entités confondues.
Pas encore d'historique pour ce contrôle : la courbe apparaît dès que deux scans complets ont eu lieu sur des mois différents.
Méthodologie et limites
Les évaluations sont établies à la date d'observation, sur la seule base d'informations publiquement accessibles, collectées de manière passive et sans authentification. Elles ne constituent ni un audit de sécurité, ni un test d'intrusion, ni une certification. Un résultat « solide » ne garantit pas l'absence de vulnérabilité ; un point « à renforcer » n'implique ni compromission, ni manquement à une obligation légale ou contractuelle.