Politique de sécurité : Elle est classée comme une infrastructure vitale, indispensable pour l'avenir.

Dans les secteurs bancaire et des services publics, les autorités de réglementation définissent certains systèmes comme critiques. Un système critique est un système dont la défaillance pourrait causer un préjudice intolérable aux clients, aux marchés ou à la sécurité publique. Par exemple, une plateforme de paiement dans une banque de compensation ou un réseau SCADA chez un distributeur d'électricité sont soumis aux obligations de gouvernance les plus strictes, notamment une surveillance continue, une gestion des changements documentée et une résilience démontrable.

L’environnement de politiques — un ensemble de règles accumulées au niveau des pare-feu, des contrôles cloud et de la microsegmentation — détermine quels systèmes peuvent interagir, quelles communications sont bloquées et quelles exceptions sont maintenues. Ces règles constituent collectivement la couche de contrôle des politiques de sécurité : la couche de gouvernance qui traduit les objectifs métier en décisions d’accès sur les différents points d’exécution distribués.

Une règle de hachage mal configurée lors d'une migration vers le cloud peut déconnecter un service de paiement de sa plateforme de règlement ; de même, une règle temporaire accordant un large accès d'un sous-réseau de développement à l'environnement de production peut rester en vigueur pendant des mois après son fonctionnement effectif en raison de l'absence de personne chargée de la supprimer.

Les règles de pare-feu, les politiques de segmentation et les décisions d'accès ont toutes une incidence directe sur les risques opérationnels, et lorsque l'environnement de politiques échoue, les services essentiels qui le régissent échouent également.

Cela fait de l'environnement politique une infrastructure vitale en soi.

Elles sont toujours gérées comme des tâches de routine.

Malgré cela, de nombreuses organisations réglementées continuent de gérer leurs environnements de politiques comme de simples tâches opérationnelles. Les règles sont ajoutées par le biais de demandes de modification, et l'effet cumulatif est rarement examiné au regard de l'objectif initial. La responsabilité se fragmente au gré des changements de rôles des dirigeants, et la raison d'être d'une règle particulière ne se trouve souvent que dans une demande de modification, lorsqu'elle existe.

Un responsable de la sécurité des systèmes d'information (RSSI), qui n'autoriserait jamais le fonctionnement d'une plateforme de paiement sans surveillance continue ni documentation des dépendances, pourrait accepter l'absence de ces deux éléments dans le cadre réglementaire qui détermine l'accessibilité de la plateforme. On peut qualifier cette situation de problématique majeure pour l'infrastructure, malgré une gouvernance de niveau opérationnel.

Dans le secteur bancaire, une défaillance de système perturbant la communication entre les systèmes de règlement entraînerait une interruption des services essentiels. La Financial Conduct Authority (FCA) serait particulièrement vigilante face à de telles défaillances, car l'interruption d'un tel service pourrait avoir des conséquences graves.

Dans les secteurs de la santé et de l'énergie, les conséquences diffèrent, mais le mécanisme reste le même : une erreur de configuration permettant l'accès, depuis un réseau d'entreprise, aux systèmes cliniques d'un établissement du NHS ou à la technologie opérationnelle d'un distributeur d'énergie, crée des vulnérabilités dans la fourniture des services essentiels. Il ne s'agit pas de risques hypothétiques, mais de conséquences opérationnelles bien réelles liées à la négligence de la gouvernance des infrastructures critiques. Pour mieux comprendre l'importance d'une planification proactive, consultez notre article « Avant de commencer : Questions essentielles sur les infrastructures ».

Les prévisions des organismes de réglementation confirment cette même tendance.

Au Royaume-Uni, les exigences réglementaires se renforcent, confirmant une même conclusion : les politiques de sécurité régissant l’accès aux services critiques doivent être gérées avec une rigueur à la hauteur de l’infrastructure. Le dispositif de résilience opérationnelle de la Financial Conduct Authority (FCA) impose aux entreprises réglementées d’identifier leurs services critiques et de démontrer en permanence que l’infrastructure sous-jacente reste dans les limites de tolérance établies en matière d’impact.

L’autorité de régulation du marché du gaz et de l’électricité (Ofgem) évalue les fournisseurs de services essentiels au regard du cadre d’évaluation de la cybersécurité du Centre national de cybersécurité (NCSC), s’interrogeant sur l’atteinte continue d’objectifs de sécurité spécifiques. Le projet de loi sur la cybersécurité et la résilience, qui devrait être adopté plus tard cette année, étendra des obligations similaires aux centres de données , aux fournisseurs de services gérés et aux fournisseurs critiques.

Ces cadres de référence ne sont ni prescriptifs ni détaillés ; aucun ne définit les règles de pare-feu qu’une organisation doit mettre en place ni la configuration de ses politiques de vente au détail. Ils exigent en revanche une preuve : que l’environnement de politiques autorise ce qui était prévu et que l’organisation peut le démontrer de manière systématique, sans avoir à reconstituer les éléments de preuve à chaque évaluation.

Pourquoi le système actuel ne peut-il pas répondre à cette norme ?

La plupart des environnements de politiques publiques n'ont jamais été conçus pour répondre à cette norme. En réalité, la plupart n'ont même pas été créés consciemment ou intentionnellement. Les politiques ont plutôt tendance à s'accumuler comme un effet secondaire des processus de mise en œuvre. Chaque projet et chaque migration ajoute de nouvelles règles, et très peu sont supprimées.

Au fil du temps, la « surface de politique » – l’ensemble des règles et des décisions d’accès à travers les différentes couches de mise en œuvre – devient plus vaste que ce que le groupe de personnes qui la comprennent peut gérer, et le système atteint un point où il peut être exploité mais pas expliqué.

Dans les secteurs réglementés comme la banque, l'énergie et la santé, cette approche était viable avec les anciens cadres réglementaires : évaluations périodiques, audits basés sur les contrôles et cadres de conformité qui s'interrogeaient sur l'existence des contrôles plutôt que sur leur efficacité. Mais cela ne suffit plus. La nouvelle norme exige des preuves continues que l'accès est intentionnel.

Les conclusions de la Financial Conduct Authority (FCA), à l'issue d'une année d'auto-évaluation de la résilience opérationnelle, illustrent ce phénomène en pratique. Lorsque les entreprises réglementées ont signalé peu ou pas de failles de sécurité dans l'infrastructure supportant leurs services critiques, la FCA a souvent jugé les éléments de preuve insuffisants pour déterminer si les failles n'existaient pas ou si elles n'avaient tout simplement pas été découvertes.

Cette leçon s'applique directement à la gouvernance des politiques de sécurité : aucune organisation ne peut affirmer avec certitude que les vulnérabilités d'accès sont maîtrisées sans fournir de preuves de ce que ses politiques autorisent, de la manière dont elles ont été testées et de la manière dont les vulnérabilités ont été corrigées.

exigences de gouvernance au niveau de l'infrastructure

Souvent, la réaction consiste à réclamer plus de transparence et de documentation. Mais la documentation ne reflète qu'un instant précis ; elle ne peut fournir l'assurance continue attendue par les organismes de réglementation.

Dans une entreprise soumise à une réglementation, un RSSI a besoin de bien plus qu'un simple enregistrement des autorisations prévues par l'environnement de sécurité. Configuration et accès effectif sont deux choses différentes. Les équipes de sécurité doivent comprendre comment les règles, les chemins d'accès, les objets et les couches d'implémentation interagissent pour déterminer les éléments pouvant communiquer.

Le respect de cette norme implique de concilier deux choses : démontrer que l’environnement autorise réellement ce qu’il était censé autoriser, et être en mesure de le prouver sans avertissement préalable.

Nous distinguons la définition des politiques de leur application. Les politiques sont gérées de manière centralisée, tandis que leur application reste distribuée entre les pare-feu, les contrôles cloud et la microsegmentation dans les environnements hybrides, multicloud et multifournisseurs.

Cette intention est vérifiée en continu plutôt qu'à des moments précis : les modifications proposées sont testées par rapport à la politique en vigueur avant leur mise en production, et l'accès effectif est évalué en permanence afin de détecter toute exposition inutile, les incohérences entre les niveaux d'implémentation et les écarts par rapport à l'objectif métier. Les éléments autorisés et modifiés sont conservés comme preuves.

Le même responsable de la sécurité de l'information qui n'accepterait jamais une plateforme de paiement fonctionnant sans surveillance continue, sans contrôle des changements vérifié et sans dépendances documentées, devrait appliquer cette norme à l'environnement politique qui détermine si une plateforme est accessible ou non.

L’Autorité de conduite financière (FCA), le cadre d’évaluation de la cybersécurité du Centre national de cybersécurité (NCSC) et le projet de loi sur la cybersécurité et la résilience pointent tous vers la même question fondamentale : cette organisation peut-elle démontrer de manière constante que l’infrastructure qui soutient ses services critiques est gérée conformément aux normes requises par ces services ?

Répondre à cette question implique de savoir (une connaissance réelle, et non une supposition ou une reconstruction après examen) ce que permet le contexte politique à un moment donné, et si ce qu'il permet correspond aux intentions initiales. Ces questions fondamentales d'infrastructure constituent un point de départ crucial dans ce contexte.