C&ESAR 2013 - Jour 2

La sécurité des systèmes de contrôles industriel n’a pointé son nez qu’après Stuxnet. Si l’on regarde dans Google Trend, avant 2010, aucune recherche n’était effectuée sur les ICS. Et depuis Stuxnet, on voit du Cyber partout. Les journalistes adorent afficher des cyber-trucs dans leurs colonnes. D’un coup la SSI prend une forme plus concrète, physique, qui parle plus aux profanes.

La disponibilité des interfaces SCADA en ligne n’arrange pas les choses. à l’aide de shodan ou de moteurs de recherche spécialisés, il est possible de découvrir un très grand nombre d’interfaces SCADA en ligne. La mise en place d’un honeypot SCADA construit à l’aide de Raspberry Pi, d’Arduino, et de Beef pour l’identification des attaquants. Après analyse de l’ensemble des probes et des identifications, il s’avère que la Russie est à l’origine d’un grand nombre de probes, mais que les attaques elles sont majoritairement chinoises et notamment à destination d’honeypot chinois ! Il semblerait donc que tout le monde attaque tout le monde sans distinctions.

Autre exemple d’attaque, basé sur du social engineering avec un .doc piégé. Le document piégé drop deux malwares qui scannent immédiatement le réseau à la recherche de device, et notamment de device SCADA ou d’automates. En recherchant l’origine du malware, ils ont découvert une chaîne de caractères spécifique au malware, qu’ils ont retrouvé dans des malwares cités dans le rapport APT-1 de mandiant.

Les réseaux industriels couvrent de nombreux domaines, du bus embarqué aux réseaux de collecte de mesures en passant par des réseaux informatiques classiques installés dans des usines, on place de tout dans le terme « réseau industriel ». La profusion des protocoles pour les réseaux industriels liés aux types de matériels employés, aux constructeurs, etc, sont plus ou moins bien normalisés, et plus ou moins vieux. Ces protocoles ont fait l’objet de migration vers Ethernet ou d’adaptation. Migration plus ou moins bien réussi au niveau sécurité.

Les devices devant synchroniser des valeurs issues de capteurs très rapidement, les protocoles industriels fonctionnent avec des trames courtes diffusés à tout les devices connectés au bus. L’accès au bus de donné est partagé entre tout les devices, le bus de communication n’est pas switché, mais il faut le voir comme un ensemble de PC connectés par un hub. Et l’accès au média de transmission est contrôlé par un Maître.

Ethernet n’était pas populaire dans le monde industriel, car le mode CSMACD ne garantissait pas l’accès au média et la transmission de l’information à temps. En mode commuté, il est possible de gérer une notion de priorité permettant de répondre aux contraintes industrielles. Est issu de cette migration des protocoles comme EtherNet/IP qui n’est pas de l’IP over Ethernet mais du DeviceNet et du ControlNet sur Ethernet d’ou le N majuscule. Et la transmission d’information, pour qu’elle soit simultanée pour tous les devices, se fait en mode multicast.

Pour la migration, 3 solutions sont choisies, soit placer la portion applicative de l’ancien protocole dans la payload d’un paquet UDP envoyé en multicast, soit la placer directement dans la payload Ethernet avec un EtherType dédié. Soit on bidouille Ethernet, et c’est plus vraiment de l’Ethernet comme avec EtherCAT, AFDX, BACnet/IP. Avec des assemblages de couches plus ou moins heureux. D’autres stratégies de migration font appel à des passerelles permettant de basculer d’un protocole à un autre.

Les passerelles sont des composants intéressantes, car elles sont multi-protocoles et elles stockent les données dans des bases, et elles pourraient être transformés en composant de sécurité puisqu’elles sont en coupure d’un réseau par rapport à l’autre.

Les pare-feux doivent s’adapter aux protocoles industriels et à leur spécificités, notamment leur aspect déterministe qui peut être utilisé pour mettre en œuvre un filtrage statefull spécifique, et une validation comportementale forte.

Détection d’intrusion sur les systèmes industriels

le focus ici est porté sur les systèmes de contrôle-commande, et comment les stratégies de détection d’intrusion peuvent être adaptés à ce contexte. On retrouve alors deux approches classique, l’approche comportementale ou l’on cherche à modéliser le fonctionnement normal et ou l’on signale les déviations par rapport au modèle. L’autre approche par signature consiste à lister les attaques connues, et à signaler leur présence. Pour alimenter ces approches, il faut avant tout collecter de l’information sur ces bus de communication sans impacter leur performance car l’aspect temps-réel est primordial sur ces réseaux.

Une fois les flux collectés, il faut pouvoir les décoder, et là, autant il y a profusion de protocoles, autant le nombre de décodeurs disponibles sont très limités.

La construction des signatures pose problème, car on a un recul très faible sur les attaques sur ces protocoles, à peine 4 ans contre des dizaines d’années pour les attaques classiques.

L’approche par modélisation du fonctionnement normal est plus intéressante puisque les Automates sont des machines à état simples, les protocoles peu complexes, et donc il est possible de mettre en place une méthode comportementale adaptée aux réseaux industriels.

Pour l’approche par modélisation, il est possible d’employer des approches génériques par apprentissage qui vont se baser sur un échantillon de trafic légitime, mais là se pose la question de la représentativité du trafic enregistré par rapport au fonctionnement normal du système industriel. L’approche par invariants notamment (ip, taille des paquets, etc…) ou bien encore l’analyse spectrale des paquets, ou l’analyse n-gram des paquets sont des solutions agnostiques au système. Mais sans trafic légitime et représentatif, ces approches ne fonctionnent pas.

Pour l’approche par signature, des travaux ont été fait pour modéliser les comportements dangereux ou potentiellement nuisibles au bon fonctionnement du système. Ou tout simplement la modélisation du bon fonctionnement du système industriel, mais encore faut il avoir les outils pour modéliser correctement ce système, et cette modélisation doit être faite par des automaticiens en partenariat avec les spécialistes de la détection d’intrusion.

Détection et surveillance des systèmes de contrôles industriels.

Les objectifs de cette surveillance sont de contrôler que les paramètres critiques du système comme l’horodatage ou diverses constantes ne soient pas modifiés. Et de détecter d’éventuelles attaques. Ici le contrôle est effectué au niveau des Automates et de leur protocole de communication avec le SCADA.

La surveillance des postes SCADA peut reposer sur des systèmes plus classiques issue de la SSI traditionnelle.

La surveillance des Automates se met en place en partenariat avec les automaticiens pour faciliter la transition des techniques de détection et établir les scénarios d’attaques pouvant mettre à mal le système industriel sous-jacent.

Exemple avec la commande STOP d’un automate qui met en arrêt la partie métier de l’Automate tout en laissant l’OS sous-jacent fonctionnel, ce qui peut avoir pour conséquence des dysfonctionnement du système industriel avec des risques humains et matériel avérés. Cette commande STOP arrête l’automate, qui n’exécute pas de séquence d’arrêt propre du système. En utilisant SNORT et un plugin modbus, il est possible de détecter l’appel à la commande STOP et de lever une alerte. Il faut donc mettre en place des signatures sur l’ensemble des commandes sensibles.

L’adaptation des SIEMs existants aux systèmes industriel ne se fait pas en branchant directement les sondes du SIEM sur les Automates, mais en interfaçant le SIEM à des interface de remontée d’information présent sur le SCADA plus simples à interroger, ce qui permet de détecter les changements effectués sur les différents systèmes SCADA et les Automates qui en dépendent.

Coté attaque, il est simple d’insérer un device malicieux dans un bus de communication industriel, car lorsqu’une question est posée à un Automate, c’est la première trame de réponse qui est prise lorsqu’il y en a plusieurs. On peut donc injecter des réponses éronées dans le bus de communication et perturber le bon fonctionnement du SCADA et des autres Automates par ce biais, voir manipuler la perception qu’a le SCADA de ses Automates.

Les centrales nucléaires ont été conçues de façon très cloisonnée avec des réseaux dédiés par groupe de fonctions. Le problème c’est que le cloisonnement est remis en question par les besoins de remontée d’informations issues du réseau Contrôle Commande vers des réseaux d’exploitation. Il faut donc pouvoir garantir la défense en profondeur du SI tout en effectuant une transition sans rupture de fonctionnement pour répondre aux nouveaux besoins. Le SI est donc architecturé en 5 zones cloisonnement sous le contrôle de plusieurs cellules, chacune intervenant sur une à plusieurs de ces Zones en fonction de leur cœur de compétence. En plus de ces cellules métier orientées sécu, deux autres cellules d’audit technique réalisent pentests et scan de vulnérabilités sur ces différentes zones.

Investigating requirements models completeness in a unified process for safety and security.

… X_x

Étude du Clusif sur la sécurité des SI Industriels.

Au lieu de produire un nième document sur la sécurité des réseaux industriels, le groupe de travail du CLUSIF à préféré faire un panorama des documentations et ressources disponibles sur le domaine.

La littérature sur le sujet est abondante, variée aussi bien technique qu’organisationnel, et les sources de publication aussi. Les domaines d’application ou de focus des documents sont principalement sur le domaine de l’énergie ou du nucléaire, les documents sur le domaine du transport ou de la santé étudiés étaient soit très vieux, soit très succincts. Ceci dit, les documents sélectionnés par le CLUSIF sont adaptables à d’autres domaines que ceux ciblés à l’origine.

Stratégie et livre blanc

La vision de l’ANSSI est que la sécurité soit intégrée aux référentiels métiers. Et la vision des différents acteurs va vers la labellisation des architectures mises en œuvre. Que le produit soit sécurisé ou pas n’est pas forcément le cœur du problème, mais plutôt que l’architecture choisie ou en place soit sûre ou sécurisée.

De ce fait, l’ANSSI à mis Intégrateurs, Equipementiers et Industriels autour de la table dans un Groupe de travail en déléguant à certains partenaires certains travaux d’étude comme c’est le cas avec le CLUSIF avec son étude des référentiels documentaires existants.

Le focus du groupe de travail à été mis sur le pragmatisme et l’efficacité opérationnelle des conseils issus de ce groupe. De plus les travaux du groupe se sont concentré sur les systèmes industriels critiques, afin de remplir l’objectif de l’ANSSI qui est de labelliser tous les nouveaux systèmes industriels critiques déployés d’ici deux ans.

Les systèmes ont donc été classés en fonction de leur niveau d’importance, afin de fournir des niveaux d’analyse adaptés en fonction de la criticité du système, et les actions de sécurisation adaptés à mettre en œuvre. Afin de rendre l’implémentation de ces action efficace, l’ANSSI à préconisé que les actions soient mises en œuvre par un duo Informaticien-Automaticien.

Afin de faire simple, les systèmes industriels ont été découpés en 3 niveaux de criticité:
– mineure, ne faisant l’objet que de recommandations
– moyenne, faisant l’objet d’une auto-homologation, et en cas d’incident, cet effort de sécurisation fera l’objet d’un contrôle et de sanctions
– majeur, dont l’incident peut avoir des conséquences majeures au niveau humain, environnemental, etc… et les directives de sécurisation seront forte et feront l’objet d’une homologation.

La démarche d’analyse et d’évaluation accorde peu d’importance à la confidentialité, mais une très grande importance à la disponibilité. Il n’est pas très gênant que des informations fuitent d’un tel système tant que ça n’impacte pas son bon fonctionnement. De même la vraisemblance des attaques sont prise en compte dans la classification comme l’exposition, le nombre d’intervenants, la connectivité du site ou bien encore les profils des attaquants. Une fois tout ces paramètres pris en compte, on peut déterminer très simplement le niveau de criticité du système.

Les mesures quand à elle vont aller de la définition d’une chaîne de responsabilité à une bonne cartographie du système en passant par des audits et la mise en œuvre d’un processus de veille associé. Bien entendu l’aspect humain n’est pas laissé de coté avec une habilitation des personnes et les contrôles d’accès associés. Les modes d’urgence et la gestion de crise doivent être intégré dès le début dans l’analyse de risques et dans la conception du système pour éviter l’introduction de trous de sécurités liés à ces modes d’urgences tout en permettant la réponse sur incident la plus efficace possible. Coté mesures technique, l’isolation des réseaux et la limitation voir l’interdiction de l’accès à internet forment une base saine. Pour la télémaintenance et la télégestion, ces opérations sont fortement déconseillées pour les infrastructures les  plus critiques.

Toutes ces recommandations sont actuellement en cours d’évaluation par des acteurs extérieurs au groupe de travail afin de les raffiner et de s’assurer qu’elles sont réalistes. Les documents seront ensuite adaptés à chaque secteur.