Cybersécurité et risque technologique du secteur public

Pourquoi cela compte pour la valeur publique

Quand les systèmes d'un hôpital sont chiffrés par un attaquant, les cliniciens ne peuvent pas voir les historiques de médication, les ambulances sont détournées, et les opérations sont annulées. Quand les systèmes de contrôle d'une régie des eaux sont compromis, la valeur publique en jeu n'est pas une panne de serveur mais la sécurité de l'eau potable. Quand la base de données d'un organisme de prestations est violée, les gens les plus exposés sont souvent les gens les moins capables d'en absorber les conséquences : un paiement retardé, une identité volée, une famille qui ne peut pas prouver qui elle est à l'État qui lui doit du soutien. La sécurité informatique, communément appelée cybersécurité, est la pratique consistant à protéger les systèmes informatiques, réseaux, et données contre l'accès non autorisé, la perturbation, ou le dommage. Dans les institutions publiques, cette pratique se situe directement sur le chemin entre l'État et le citoyen qu'il sert.

C'est pourquoi ce thème cadre le risque cybernétique comme une question de valeur publique, non seulement technique. La légitimité et le soutien dépendent des citoyens croyant que les institutions détenant leurs données et faisant fonctionner leurs services essentiels peuvent être fiées pour garder les deux en sécurité (voir thème 1.2 — Le triangle stratégique : légitimité, valeur et capacité). Une seule brèche bien publicisée peut faire un dommage durable à cette confiance, de la même façon qu'une urgence mal gérée le fait, parce que les citoyens jugent les institutions sur comment elles se comportent sous attaque autant que sur comment elles performent au quotidien (voir thème 3.12 — Crise, urgence et gestion de la résilience, qui traite les incidents cybernétiques comme une catégorie à l'intérieur de la discipline plus large de la résilience). La cybersécurité est aussi inséparable de la gouvernance des données : une institution ne peut pas protéger ce qu'elle ne sait pas détenir, et l'interopérabilité et l'ouverture qui créent de la valeur publique à partir des données élargissent aussi la surface qu'un attaquant peut exploiter (voir thème 5.4 — Données, interopérabilité et données ouvertes du secteur public).

Le problème de dotation en ressources est aigu et spécifique aux secteurs public et social. Les grands organismes nationaux ont de plus en plus des équipes de sécurité dédiées et des budgets d'entreprise ; le conseil des eaux desservant une petite ville, le fonds de fiducie d'hôpital régional, et l'organisme à but non lucratif local faisant fonctionner un refuge pour violence domestique n'en ont typiquement pas, malgré détenir des données dont la sensibilité rivalise ou dépasse celle de toute banque. Les attaquants le savent. Les organismes publics sous-dotés en ressources ne sont pas un cas limite dans ce thème ; ils en sont proches du centre, parce que l'institution publique médiane faisant face à ce risque aujourd'hui n'est pas un ministère national mais une petite collectivité locale, une régie régionale, ou un organisme de bienfaisance avec une poignée de personnel de technologie de l'information et aucun spécialiste de sécurité du tout.

Enfin, c'est un problème vivant et qui empire, non hypothétique. Les campagnes de rançongiciel ciblent de plus en plus les collectivités locales, hôpitaux, écoles, et organisations du secteur social précisément parce qu'ils combinent des données sensibles, des services essentiels, une faible tolérance aux temps d'arrêt, et des défenses comparativement faibles — une combinaison qui les rend plus susceptibles de payer et moins susceptibles d'avoir prévenu l'attaque en premier lieu. Traiter la cybersécurité comme un ajout spécialisé plutôt qu'un engagement de valeur publique au niveau de la gouvernance est, pour cette classe d'organisation, proche d'une invitation.

Concepts fondamentaux

L'infrastructure critique est l'ensemble des systèmes et actifs — énergie, eau, transport, santé, finance, communications — si essentiels que leur incapacité ou destruction aurait un effet débilitant sur la sécurité, l'économie, ou la confiance publique. La protection de l'infrastructure critique est la discipline consistant à sécuriser ces systèmes contre les menaces physiques et numériques à la fois ; elle compte ici parce que nombre des incidents cybernétiques du secteur public les plus conséquents ne sont pas des attaques sur des données abstraites mais des attaques sur la technologie opérationnelle qui garde l'infrastructure physique fonctionnant, distincte de la technologie de l'information qui garde les dossiers et traite les transactions.

Un acteur de menace est tout individu, groupe, ou État qui peut tenter de compromettre un système ; dans le secteur public, ceux-ci vont des groupes criminels motivés financièrement aux acteurs parrainés par un État poursuivant l'espionnage ou la perturbation, et la même institution peut faire face aux deux simultanément avec des objectifs très différents. Le rançongiciel est un logiciel malveillant qui chiffre les données ou systèmes d'une organisation et exige un paiement pour leur libération ; il est devenu la menace dominante pour les organismes publics précisément parce que les services essentiels ne peuvent pas tolérer un temps d'arrêt prolongé, ce qui augmente la pression de payer. L'hameçonnage est une forme d'ingénierie sociale dans laquelle les attaquants trompent le personnel pour révéler des identifiants ou installer un logiciel malveillant, typiquement à travers un courriel trompeur, et demeure la façon la plus courante par laquelle un attaquant obtient d'abord un point d'ancrage, parce qu'il cible les gens plutôt que la technologie.

Une violation de données est l'accès non autorisé, la divulgation, ou la perte d'information, que ce soit à travers une attaque externe, un initié, ou une simple erreur humaine telle qu'une base de données mal configurée laissée ouverte à internet. Une attaque de chaîne d'approvisionnement compromet une organisation indirectement, en ciblant un fournisseur, éditeur de logiciel, ou prestataire de service géré moins sécurisé auquel l'organisation cible fait confiance ; celles-ci sont particulièrement dangereuses pour le secteur public parce que tant d'organismes publics partagent la même poignée de fournisseurs de logiciel, ce qui signifie qu'un seul compromis de fournisseur peut se propager en cascade vers des centaines d'institutions simultanément.

L'hygiène cybernétique est l'ensemble des pratiques routinières — corriger les logiciels rapidement, appliquer une authentification forte, limiter qui peut accéder à quoi, sauvegarder les données et tester la restauration de ces sauvegardes — qui préviennent la grande majorité des attaques réussies sans exiger d'outils exotiques. La plupart des violations exploitent des vulnérabilités connues et non corrigées ou des identifiants faibles plutôt que des techniques nouvelles, donc l'écart entre l'hygiène cybernétique réelle d'une organisation et sa politique déclarée est habituellement un meilleur prédicteur de son risque que la sophistication des menaces qu'elle nomme dans son registre des risques.

L'architecture de confiance zéro est un principe de conception de sécurité soutenant qu'aucun utilisateur ou appareil ne devrait être fié par défaut, même à l'intérieur du propre réseau d'une organisation, et que chaque demande d'accès doit être vérifiée indépendamment d'où elle provient. Elle est devenue influente dans l'orientation du secteur public parce qu'elle correspond à comment le travail gouvernemental moderne se produit réellement — personnel, contractants, et citoyens accédant aux services depuis de nombreux appareils et lieux — mieux qu'un modèle plus ancien qui faisait confiance à tout ce qui était déjà à l'intérieur du périmètre.

La gestion des incidents de sécurité informatique, habituellement appelée réponse aux incidents, est le processus organisé consistant à détecter, contenir, éradiquer, et se rétablir d'un incident de sécurité, suivi d'une révision de ce qui a permis qu'il se produise. Une obligation de divulgation est un devoir légal ou réglementaire de notifier les individus affectés, les régulateurs, ou le public quand des données personnelles ou des services critiques ont été compromis, dans un temps spécifié et à une norme spécifiée, sur la logique que les citoyens et organes de supervision ont un droit de savoir quand leurs données ou leurs services essentiels ont été mis en risque, et que la divulgation opportune permet aux gens de se protéger.

Pratiques exemplaires

1. Traitez la cybersécurité comme une responsabilité de l'organe de gouvernance, non une fonction technique déléguée. Les conseils, assemblées, et équipes exécutives devraient recevoir des briefings réguliers et en langage clair sur le risque cybernétique et approuver le budget pour cela directement, plutôt que de le laisser être négocié à l'intérieur d'une ligne budgétaire de technologie de l'information plus large où c'est la chose la plus facile à couper.
2. Inventoriez ce que vous détenez et ce qui en dépend avant de décider comment le protéger. Une organisation ne peut pas sécuriser des données ou systèmes qu'elle n'a pas cartographiés ; un inventaire d'actifs et de données actuel, recoupé contre le travail d'interopérabilité et de gouvernance des données couvert ailleurs (voir thème 5.4 — Données, interopérabilité et données ouvertes du secteur public), est la précondition pour chaque autre pratique de cette liste.
3. Appliquez les fondamentaux partout avant de dépenser sur quoi que ce soit d'avancé. La gestion des correctifs, l'authentification multifacteur, les sauvegardes testées, et le contrôle d'accès au moindre privilège arrêtent l'écrasante majorité des attaques du monde réel ; un organisme public sans ces éléments en place ne devrait pas prioriser les abonnements de renseignement sur les menaces ou les outils de surveillance sur mesure.
4. Adoptez un cadre reconnu plutôt que d'en inventer un sur mesure. Des cadres tels que le Cybersecurity Framework du National Institute of Standards and Technology donnent un vocabulaire partagé et une structure — identifier, protéger, détecter, répondre, se rétablir — qu'une petite organisation peut adopter sous forme simplifiée et une grande peut adopter en entier, sans réinventer la taxonomie de base.
5. Mettez en commun les ressources à travers les petites organisations plutôt que chacune achetant seule. Un service partagé de surveillance de sécurité, un bassin régional de réponse aux incidents cybernétiques, ou un cadre d'approvisionnement sectoriel peuvent donner à un groupe de petites collectivités locales ou d'organismes à but non lucratif une protection qu'aucun d'eux ne pourrait se permettre individuellement — la réponse unique la plus directe au problème de sous-dotation en ressources sur lequel ce thème se centre.
6. Écrivez le plan de réponse aux incidents avant l'incident, et répétez-le. Un plan rédigé pour la première fois pendant une attaque en direct est un plan mal rédigé, sous panique, par des gens qui n'ont jamais testé s'il fonctionne réellement ; un plan exercé au moins annuellement transforme une première heure chaotique en une séquence répétée d'étapes connues (voir thème 3.12 — Crise, urgence et gestion de la résilience pour la discipline plus large sur laquelle cela s'appuie).
7. Décidez la politique de divulgation et de paiement à l'avance, non pendant l'incident. Si l'organisation considérera payer une rançon, qui a l'autorité de faire ce choix, et comment et quand les gens affectés seront informés devraient être une politique approuvée par le conseil, non une décision improvisée prise sous la pression d'une demande d'extorsion en direct.
8. Segmentez les réseaux afin qu'un seul compromis ne puisse pas devenir tous les compromis. Garder la technologie opérationnelle qui contrôle l'infrastructure physique séparée de la technologie de l'information de bureau générale, et séparer les systèmes de haute sensibilité des systèmes de moindre sensibilité, limite combien loin un intrus qui entre par un point faible peut voyager.
9. Gérez le risque tiers et de chaîne d'approvisionnement aussi rigoureusement que le risque interne. Exigez des assurances de sécurité, des clauses de droit d'audit, et des obligations de notification d'incident dans les contrats avec les fournisseurs de logiciel et prestataires de service gérés, puisqu'une part croissante des incidents majeurs du secteur public a pour origine un fournisseur de confiance plutôt qu'une attaque directe.
10. Investissez dans les gens, non seulement les outils. Une formation régulière et réaliste — y compris des exercices d'hameçonnage simulés — réduit mesurablement les attaques d'ingénierie sociale réussies, et retenir même un ou deux membres de personnel de sécurité qualifiés dans une petite organisation vaut habituellement plus qu'une dépense équivalente en licences logicielles supplémentaires.
11. Rapportez les incidents honnêtement et utilisez les quasi-accidents comme des leçons gratuites. Une culture qui discipline le personnel pour avoir signalé une violation suspectée garantit que la suivante sera signalée tard ou pas du tout ; les organisations qui s'améliorent le plus vite sont celles qui traitent chaque quasi-accident comme une preuve dont apprendre plutôt qu'une raison d'assigner le blâme.
12. Intégrez la résilience cybernétique dans l'approvisionnement et les conditions de subvention, non seulement la politique interne. Les bailleurs de fonds et organismes de commande peuvent exiger un niveau de référence de pratique de sécurité des organisations qu'ils financent ou avec lesquelles ils contractent, étendant la portée de la bonne pratique aux partenaires de livraison plus petits qui n'auraient autrement aucune pression externe pour y investir (voir thème 3.7 — Achats publics et commande de services).

Questions à discuter avec votre équipe

Savons-nous quelles données et systèmes nous détenons réellement, et lesquels blesseraient quelqu'un s'ils étaient compromis ? De nombreuses organisations découvrent l'étendue réelle de leurs avoirs de données seulement pendant une enquête de violation, ce qui est le pire moment possible pour l'apprendre. Parcourez vos services majeurs et demandez, pour chacun, quelles données personnelles ou opérationnellement sensibles il touche et ce qui arriverait à une véritable personne si ces données étaient volées, altérées, ou rendues indisponibles. Si la réponse honnête est « nous ne sommes pas sûrs », cette incertitude est elle-même le constat, et la fermer est le premier point à votre ordre du jour. Cette question compte le plus pour les organisations qui ont grandi par acquisition, fusion, ou systèmes hérités accumulés, où la mémoire institutionnelle de ce qui existe s'est amincie.

Si nous étions frappés par un rançongiciel demain, pourrions-nous restaurer depuis une sauvegarde sans payer ? La valeur d'une sauvegarde n'est pas qu'elle existe mais qu'elle a été testée pour réellement restaurer, assez rapidement, depuis une version assez récente pour compter. Demandez quand les sauvegardes ont été testées pour la dernière fois avec un véritable exercice de restauration, non seulement un journal d'achèvement, et combien de temps une restauration complète prendrait contre combien de temps votre organisation peut tolérer une panne. Si ces chiffres ne correspondent pas, vous avez une décision de dotation en ressources à prendre maintenant, non pendant un incident. C'est aussi le moment de discuter si les sauvegardes elles-mêmes sont isolées du réseau qu'un attaquant qui atteint vos systèmes principaux pourrait aussi atteindre.

Qui a l'autorité de décider si nous payons une rançon, et en avons-nous déjà discuté avant qu'on ne nous le demande ? C'est l'une des décisions à plus haut enjeu qu'une équipe exécutive puisse affronter, souvent requise en quelques heures et avec une information incomplète sur ce que l'attaquant a réellement. Décider le processus, les individus autorisants, et les principes à l'avance — même si le choix final dépend encore des spécificités de l'incident — prévient une décision improvisée prise sous pression d'extorsion. Discutez de ce que la loi de votre juridiction et les conditions de vos bailleurs de fonds disent sur le paiement de rançon, et qui vous auriez besoin de notifier.

Nos plus petits partenaires et fournisseurs sont-ils un plus grand risque pour nous que nous ne le sommes pour nous-mêmes ? Une organisation centrale bien sécurisée peut encore être compromise à travers un fournisseur, contractant, ou partenaire de livraison mal sécurisé avec un accès légitime à ses systèmes ou données. Cartographiez les tiers qui peuvent atteindre vos systèmes ou détenir vos données, et soyez honnête sur combien d'assurance vous avez réellement sur leurs pratiques de sécurité par rapport à combien d'assurance vous supposez avoir. Décidez quelle norme minimale vous exigerez d'eux à l'avenir, et comment vous la vérifierez plutôt que de simplement demander une assurance écrite.

Saurions-nous que nous avons été violés, et à quelle vitesse ? Certains des incidents les plus dommageables ne sont pas ceux qui se produisent vite mais ceux qui passent inaperçus pendant des mois, pendant lesquels un attaquant a discrètement exploré, escaladé des privilèges, et exfiltré des données. Discutez de comment vous détecteriez réellement une activité inhabituelle aujourd'hui, qui la surveille, et si cette surveillance fonctionne en dehors des heures de bureau, puisque de nombreuses attaques sont lancées délibérément la nuit ou pendant un week-end férié quand la réponse est la plus lente. Si la détection dépend entièrement d'un citoyen ou d'une organisation partenaire vous disant que quelque chose ne va pas, c'est une lacune critique.

Notre conseil ou organe de gouvernance comprend-il ce risque assez bien pour le gouverner, ou avons-nous discrètement externalisé ce jugement à l'équipe de technologie de l'information ? Les décisions de risque cybernétique impliquent de véritables arbitrages entre coût, continuité de service, et protection citoyenne qui relèvent proprement des affaires de l'organe de gouvernance, non une matière technique déléguée à approuver d'un signe de tête. Discutez de comment le risque cybernétique est actuellement rapporté à votre conseil ou assemblée, si c'est dans un langage sur lequel un non-spécialiste peut réellement agir, et si le budget pour cela est décidé avec la même rigueur que tout autre risque majeur. Si votre organe de gouvernance ne pouvait pas actuellement expliquer les trois principaux risques cybernétiques de votre organisation dans ses propres mots, c'est la lacune à fermer en premier.

En pratique : un exemple de valeur publique

Une autorité de transport en commun régionale de taille moyenne — fictive, illustrative d'un schéma plutôt qu'un compte rendu d'une organisation réelle — faisait fonctionner des systèmes d'horaire et de paiement vieillissants qui avaient été corrigés au coup par coup pendant une décennie plutôt que modernisés. Son équipe de technologie de l'information était de trois personnes, responsables de tout depuis les tickets d'assistance jusqu'à la sécurité réseau, et la cybersécurité n'avait jamais eu sa propre ligne dans le budget ; elle vivait à l'intérieur d'une allocation générale de « maintenance des systèmes » qui n'avait pas crû en termes réels depuis des années.

Un attaquant a obtenu l'accès à travers un courriel d'hameçonnage envoyé à un agent des finances, utilisant une facture usurpée d'un fournisseur que l'autorité utilisait authentiquement. Une fois à l'intérieur, l'attaquant a passé six semaines à se déplacer discrètement à travers le réseau avant de déployer un rançongiciel qui a chiffré le système d'horaire, la plateforme de paiement de tarifs, et les sauvegardes de l'autorité, qui n'avaient jamais été isolées du réseau principal. Les bus ont continué de fonctionner sur la mémoire des conducteurs de leurs itinéraires le premier jour, mais les tarifs ne pouvaient pas être collectés électroniquement, les écrans d'information en temps réel se sont éteints, et les systèmes financiers de l'autorité étaient inutilisables pour la paie.

L'équipe exécutive a affronté la décision de rançon sans politique préconvenue : personne n'avait décidé à l'avance qui avait l'autorité d'approuver un paiement, quelle était la position légale, ou ce qu'ils diraient aux usagers. La restauration depuis une sauvegarde n'était pas une option, parce que les sauvegardes étaient chiffrées avec tout le reste. Après neuf jours de perturbation, une restauration partielle du service, et un paiement que le conseil de l'autorité a décrit plus tard comme la moins mauvaise option disponible à l'époque, l'autorité a commandé une révision indépendante.

Les constats de la révision étaient peu glorieux et entièrement cohérents avec le schéma que ce thème décrit : aucune authentification multifacteur sur les systèmes financiers, aucune segmentation réseau entre les systèmes de bureau et l'infrastructure de paiement, aucune restauration de sauvegarde testée en plus de deux ans, et aucune visibilité au niveau du conseil sur le risque cybernétique du tout avant l'incident. La réponse de l'autorité a été également peu glorieuse — un plan échelonné pour corriger les fondamentaux, un arrangement de surveillance de sécurité partagé avec deux autorités de transport voisines pour diviser le coût d'une couverture spécialisée qu'aucune d'elles ne pouvait se permettre seule, et un point permanent à l'ordre du jour du conseil sur le risque cybernétique. Rien de tout cela n'était coûteux selon les normes d'un programme majeur de technologie de l'information ; tout cela avait été sauté pendant des années parce que ce n'avait jamais été le travail clairement assigné de personne d'insister dessus.

Quatre angles sectoriels

Collectivités locales

Les collectivités locales se situent à une intersection inconfortable : elles détiennent des données hautement sensibles — dossiers de soins sociaux, information de logement et de prestations, registres électoraux — et font fonctionner des services dont les citoyens ne peuvent pas facilement se passer, mais elles ont typiquement les plus petits budgets de sécurité et le moins de personnel spécialisé de tout niveau de gouvernement. Un grand ministère national peut bâtir un centre d'opérations de sécurité interne ; un petit conseil de district ne le peut habituellement pas, ce qui rend les services partagés, la mise en commun régionale, et les programmes de soutien nationaux la voie pratique vers une protection adéquate plutôt qu'un extra optionnel. Les élus locaux sont aussi souvent les moins équipés, de tout palier de gouvernement, pour interroger un briefing de risque technique, ce qui rend le rapport en langage clair aux membres élus un défi de gouvernance distinct à ce niveau.

Gouvernement national

Les gouvernements nationaux ont généralement les ressources pour bâtir des agences de cybersécurité dédiées et des cadres nationaux — des organismes tels que le National Cyber Security Centre du Royaume-Uni ou la Cybersecurity and Infrastructure Security Agency des États-Unis existent pour fixer des normes, coordonner la réponse, et soutenir les organismes publics moins dotés en ressources à l'intérieur de leur juridiction. Le défi distinctif au niveau national concerne moins l'hygiène de base et davantage les acteurs de menace parrainés par un État et hautement capables, l'interdépendance de l'infrastructure nationale critique à travers les secteurs et opérateurs privés, et les dimensions diplomatiques et légales de l'attribution et de la réponse, qui apparaissent rarement au niveau local ou organisationnel.

Secteur social et organismes à but non lucratif

Les organismes à but non lucratif et les ONG détiennent souvent parmi les données les plus sensibles de tout secteur — dossiers de santé, dossiers de survivants de violence ou de persécution, travail de cas de réfugiés et d'asile — tout en opérant sur les budgets de sécurité les plus minces de tout type d'organisation dans ce livre, parce que les bailleurs de fonds réservent rarement de l'argent pour la sécurité et les conditions de subvention l'exigent rarement. De nombreuses organisations du secteur social dépendent aussi de bénévoles et d'un roulement de personnel élevé, ce qui rend la formation de sécurité cohérente et le contrôle d'accès plus difficiles à soutenir que dans une organisation stable et dotée en personnel professionnel ; un incident de sécurité peut être existentiel pour un petit organisme de bienfaisance d'une façon qu'il l'est rarement pour un département gouvernemental, parce que le dommage réputationnel et la perte de confiance des donateurs peuvent mettre fin à l'organisation carrément (voir thème 3.8 — Secteur social et gestion des organismes à but non lucratif).

Organismes multilatéraux et internationaux

Les organismes multilatéraux et internationaux opèrent à travers des juridictions avec différentes lois de divulgation, différentes définitions de l'infrastructure critique, et différents niveaux de capacité cybernétique nationale, ce qui rend la coordination elle-même un problème distinct : les propres systèmes d'un organisme international peuvent être bien protégés tandis que ses organismes membres nationaux varient énormément, et un organisme tel que l'Organisation de coopération et de développement économiques ou l'Agence de l'Union européenne pour la cybersécurité joue autant un rôle de normalisation et de renforcement de capacité qu'un rôle opérationnel. Le prisme multilatéral est aussi où la réponse aux incidents transfrontalière et les arrangements de partage d'information comptent le plus, puisqu'une attaque qui commence dans l'infrastructure d'un pays peut se propager en cascade vers celle d'un autre en quelques heures, plus vite que la plupart des mécanismes de coordination internationale ne sont bâtis pour bouger.

Modes de défaillance courants

Le théâtre de sécurité sans substance opérationnelle. Une organisation adopte un document de politique d'apparence impressionnante, un certificat de conformité, ou un seul outil coûteux, et traite la case comme cochée, tandis que l'hygiène de base — correctifs, authentification multifacteur, sauvegardes testées — demeure incohérente. Cela coûte de l'argent réel pour l'apparence de la sécurité plutôt que la sécurité elle-même, et ce n'est souvent découvert avoir été du théâtre qu'après qu'un incident n'expose l'écart entre politique et pratique.

Le risque non possédé. La cybersécurité est supposée être le travail de quelqu'un d'autre — l'équipe de technologie de l'information, un fournisseur, un régulateur — et aucun propriétaire redevable unique n'existe au niveau de l'organe de gouvernance. Cela produit un risque discuté partout et décidé nulle part, et c'est précisément le schéma qui laisse les organisations incapables de répondre à des questions basiques sur leur propre exposition quand on le leur demande.

Le sous-investissement justifié par l'absence d'un incident antérieur. Parce qu'un programme de sécurité bien géré ne produit aucun événement visible quand il réussit, il est facile de le définancer dans un cycle budgétaire serré en faveur de quelque chose avec un résultat visible, et l'absence d'une violation jusqu'ici est confondue avec la preuve d'une protection adéquate plutôt que la preuve qui n'a pas encore été testée. Cela reflète la même logique budgétaire qui mine l'investissement en résilience plus largement (voir thème 3.12 — Crise, urgence et gestion de la résilience).

Les systèmes hérités gardés fonctionnant au-delà de leur vie soutenable. Les organismes publics font fréquemment fonctionner des logiciels ou du matériel bien après qu'un fournisseur ait cessé d'émettre des correctifs de sécurité pour eux, parce que le remplacement est coûteux, perturbateur, ou politiquement impopulaire, et le système « fonctionne encore ». Un système non corrigé et non supporté n'est pas un inconvénient hérité ; c'est une porte ouverte qui ne coûte rien à un attaquant pour la traverser.

La culture d'incident axée sur le blâme d'abord. Quand le personnel qui signale une violation suspectée ou une erreur est discipliné plutôt que soutenu, les futurs incidents sont signalés tard, minimisés, ou pas du tout signalés, et l'organisation perd le signal d'alerte précoce que le signalement opportun fournit. Ce mode de défaillance compose chaque autre de cette liste, parce qu'aucun des correctifs ci-dessus ne fonctionne si l'organisation ne peut pas voir ses propres problèmes honnêtement.

Modèle de maturité

Liste de vérification

• Un individu ou comité nommé au niveau de l'organe de gouvernance possède le risque cybernétique et en rapporte régulièrement, en langage clair.
• Un inventaire actuel existe de quelles données et systèmes l'organisation détient, et lesquels sont les plus sensibles ou les plus critiques pour un service.
• L'authentification multifacteur est appliquée sur tous les systèmes qui détiennent des données sensibles ou contrôlent des services critiques.
• Les sauvegardes sont prises régulièrement, stockées isolées du réseau principal, et la restauration a été testée au cours des douze derniers mois.
• Les logiciels et systèmes sont corrigés selon un calendrier défini, et tout système qui ne peut plus être corrigé a un plan documenté pour le remplacer ou l'isoler.
• Un plan de réponse aux incidents écrit existe, nomme qui a l'autorité de prendre les décisions clés, et a été répété à travers un exercice réaliste au cours de la dernière année.
• Une politique approuvée par le conseil existe sur le paiement de rançon et sur comment et quand les gens affectés, régulateurs, et le public seront notifiés.
• Les contrats avec les fournisseurs de logiciel et prestataires de service gérés incluent des assurances de sécurité et des obligations de notification d'incident.
• Le personnel reçoit une formation de sécurité régulière et réaliste, y compris des exercices d'hameçonnage simulés.
• Signaler un incident suspecté ou un quasi-accident est traité comme une information valorisée, non un motif de blâme.
• Des arrangements de sécurité partagés ou mis en commun ont été explorés avec des organisations pairs de taille et de budget similaires.
• Le risque cybernétique figure explicitement dans la planification de crise et de résilience plus large de l'organisation, non comme un plan séparé et déconnecté.

Sources principales

Ce thème s'appuie sur le Cybersecurity Framework du National Institute of Standards and Technology comme le cadre structuré de premier plan pour organiser la pratique de cybersécurité ; la mission et l'orientation publiées de l'Agence de l'Union européenne pour la cybersécurité sur l'atteinte d'un niveau commun de cybersécurité à travers l'Union européenne ; le travail de politique de sécurité numérique de l'Organisation de coopération et de développement économiques, qui cadre la sécurité numérique comme un enjeu de gestion de risque économique et social plutôt que purement technique ; et l'orientation opérationnelle publiée par les agences de cybersécurité nationales telles que le National Cyber Security Centre du Royaume-Uni et la Cybersecurity and Infrastructure Security Agency des États-Unis, toutes deux fournissant une orientation gratuite spécifiquement destinée aux organismes publics sous-dotés en ressources.

Références

1. Computer security — Wikipedia — https://en.wikipedia.org/wiki/Computer_security
2. Critical infrastructure — Wikipedia — https://en.wikipedia.org/wiki/Critical_infrastructure
3. Ransomware — Wikipedia — https://en.wikipedia.org/wiki/Ransomware
4. Phishing — Wikipedia — https://en.wikipedia.org/wiki/Phishing
5. Data breach — Wikipedia — https://en.wikipedia.org/wiki/Data_breach
6. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
7. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
8. Computer security incident management — Wikipedia — https://en.wikipedia.org/wiki/Computer_security_incident_management
9. National Cyber Security Centre (United Kingdom) — Wikipedia — https://en.wikipedia.org/wiki/National_Cyber_Security_Centre_(United_Kingdom)
10. Cybersecurity and Infrastructure Security Agency — Wikipedia — https://en.wikipedia.org/wiki/Cybersecurity_and_Infrastructure_Security_Agency
11. Cybersecurity Framework — National Institute of Standards and Technology — https://www.nist.gov/cyberframework
12. Who we are — European Union Agency for Cybersecurity (ENISA) — https://www.enisa.europa.eu/about-enisa/who-we-are
13. Digital security — Organisation for Economic Co-operation and Development (OECD) — https://www.oecd.org/en/topics/digital-security.html
14. What we do at the NCSC — National Cyber Security Centre (United Kingdom) — https://www.ncsc.gov.uk/section/about-ncsc/what-we-do
15. About CISA — Cybersecurity and Infrastructure Security Agency (United States) — https://www.cisa.gov/about