Groupe de réflexion sur la sécurité : Une protection adéquate de la CNI exige de la spécificité

Lorsque nous pensons aux infrastructures nationales essentielles (INN), nous avons tendance à penser à des industries comme l’électricité, l’eau et les transports, et bien que la CNI inclut également les communications et les finances, ce sont les industries plus lourdes et critiques pour la sécurité que nous pensons en premier.

En règle générale, il s’agit de grands systèmes de contrôle industriel (SCI) qui fonctionnent 24 heures sur 24, 7 jours sur 7, 365 jours par année, dont nous dépendons tous dans notre vie quotidienne.

Des attaques réussies contre ces systèmes pourraient causer des blessures graves ou la mort, comme l’illustre l’attaque récente contre une usine de purification de l’eau en Floride. Les menaces qui pèsent sur ces systèmes peuvent provenir d’acteurs ayant des motivations similaires à celles des systèmes informatiques, mais les risques et la manière d’y faire face peuvent être très différents.

La première chose à comprendre est que si les systèmes informatiques sont tous à peu près les mêmes, en utilisant des composants et des architectures similaires, les solutions ICS sont toutes très différentes les unes des autres. Les systèmes industriels ne sont pas physiquement sécurisés dans une belle pièce climatisé, mais sont souvent répartis sur plusieurs kilomètres carrés, voire plusieurs kilomètres le long d’un pipeline, ce qui les rend extrêmement vulnérables à la falsification.

En outre, ils ne peuvent très souvent pas être arrêtés rapidement pour l’entretien et ont des exigences de disponibilité très élevées. Les risques et leurs atténuations doivent donc être spécifiques à chaque système et sous-jacents à cela, il devrait y avoir une très bonne compréhension du système et des processus qu’il prend en charge.

Les premières étapes pour sécuriser un système ICS doivent donc être de créer un plan précis du système et de ses interconnexions (telles qu’elles existent, et non comment il a été conçu) et de documenter les processus qu’il prend en charge. Cela permettra d’évaluer les risques afin d’identifier, d’analyser et d’évaluer les risques avant d’identifier les mesures à prendre pour les atténuer.

Si les systèmes informatiques et de technologie opérationnelle (OT) d’une organisation sont connectés, alors cet exercice doit être appliqué à la fois à l’informatique et à l’OT en tant que système global unique et, de manière critique, cela doit impliquer les personnes sur le plancher de l’atelier qui exécutent le système et de comprendre comment il fonctionne réellement. Au fur et à mesure que les choses changeront avec le temps, le système et l’évaluation des risques doivent être examinés et mis à jour régulièrement.

Cela fait près de 10 ans qu’Eric Byres a présenté son article Licornes et trous d’air : existent-ils vraiment ?. Le trou d’air mythique existe aujourd’hui, mais seulement dans des systèmes de contrôle très critiques comme ceux d’un réacteur nucléaire. Un système véritablement cartographié à l’air ne peut accepter les données de l’extérieur que par l’intermédiaire d’un appareil physique (comme un clavier) et les données de sortie par l’intermédiaire d’un autre (une imprimante, par exemple).

Dès que vous commencez à déplacer des données sur des supports physiques tels que des clés USB, une connexion logique est créée qui peut être exploitée, comme on l’a vu avec Stuxnet.

Cela ne veut pas dire qu’un trou d’air n’est pas une mesure de sécurité valide, mais le risque est de croire qu’il y a un trou d’air quand il n’y en a pas. Si l’on doit être utilisé, tout transfert à travers l’écart – ou le pont vers un autre système – doit être connu, bien contrôlé et documenté.

Trop souvent, les lacunes en matière d’air sont comblées à l’aide de solutions ad hoc sans papiers avec un câble supplémentaire comblant le trou d’air, ou même en utilisant la connexion Internet 4G pour fournir un accès externe aux fournisseurs pour la maintenance, illustrant la nécessité de connaître le système tel qu’il est, et non comment il a été construit.

Les risques pour ics ont tendance à être beaucoup plus sur la disponibilité et l’intégrité que la confidentialité – et presque toujours inclure la sécurité. Les aspects opérationnels doivent également être pris en compte.

Problèmes de correction

Par exemple, le patching peut être un problème lorsque le système ne peut être arrêté qu’un jour par an pour maintenance. Les correctifs doivent être testés de façon à ce qu’ils fonctionnent sans conséquences imprévues. En outre, certains systèmes auront été en place pendant de nombreuses années et il est probable qu’il y ait des vulnérabilités qui ne peuvent pas être corrigés, ou où aucun patch n’est disponible. Ici, des mesures d’atténuation sont nécessaires pour réduire les chances qu’un attaquant exploite les vulnérabilités.

En outre, lorsque la sécurité et la disponibilité sont primordiales, une politique de contrôle d’accès qui pourrait verrouiller un utilisateur en cas d’urgence et empêcher l’arrêt d’un processus hors de contrôle n’est pas acceptable. En raison des besoins d’ICS, vous ne pouvez pas simplement prendre une liste de contrôle de sécurité informatique et l’appliquer à un système ICS. Au lieu de cela, vous devez compter sur le contrôle de l’accès au système, l’application du zonage pour créer des points de surveillance et de contrôle qu’un attaquant doit passer à travers, et le verrouillage de l’accès à distance.

L’utilisation d’un pare-feu/passerelle ICS entre les systèmes informatiques et OT et les pare-feu ICS entre les zones fournira une surveillance pour détecter les activités potentiellement malveillantes pendant qu’un attaquant tente de se déplacer à travers le système. Que permettra également le blocage de la signalisation de contrôle qui serait nécessaire pour exploiter les vulnérabilités connues qui ne peuvent pas être corrigés.

Les attaques de la chaîne d’approvisionnement lancées par un attaquant compromettant un sous-traitant ou un fournisseur, puis utilisant leurs droits d’accès pour violer les systèmes de leurs clients sont de plus en plus fréquentes. Par conséquent, un tel accès à distance doit être étroitement contrôlé à l’aide du contrôle d’accès multifactoriel, géré par le propriétaire du système.

Les utilisateurs distants ne devraient avoir qu’un accès limité aux machines à laquelle ils ont besoin et leurs actions doivent être surveillées et enregistrées en détail. Il peut également être nécessaire d’accepter les délais maintenus et d’accorder l’accès seulement au moment convenu, avec une surveillance en direct par un opérateur du système de ce qui est fait exactement.

Nous continuons de voir des cyberattaques contre des cibles d’infrastructures essentielles, mais au cours des cinq dernières années, de nouvelles réglementations ont également été publiées pour la CNI, en particulier la directive de l’UE sur le réseau et la sécurité de l’information (NIS), et la sécurité des systèmes CNI a été améliorée.

Cela s’explique en partie par la réglementation qui a mené à des évaluations plus détaillées des risques et, en partie, par l’introduction de nouvelles technologies, de nombreux systèmes du CNI ayant été mis à jour pour éliminer les anciennes technologies vulnérables.

En outre, la nécessité d’un accès à distance et l’utilisation de solutions cloud ont souligné le mythe du trou d’air comme mesure défensive dans la plupart des cas.

L’attaque contre l’usine de traitement de l’eau en Floride, qui semble avoir été montée à travers un logon distant et contrecarrée lorsqu’un ingénieur sur place a remarqué que les choses n’étaient pas comme elles devraient l’être, souligne toutefois la nécessité de contrôler l’accès à distance, ainsi que le fait que les opérateurs qui comprennent les systèmes doivent faire partie de l’évaluation des risques et de la gestion de leurs systèmes.