La "récente" évolution des systèmes SCADA

Jusqu'au milieu des années 90, les systèmes SCADA n'ont que peu évolués. Présents dans toute l'industrie, surveillant les chaînes de montage, les centrales électriques, les systèmes de production et de distribution d'eau, gaz ou pétrole, les installations portuaires... ces systèmes spécialisés étaient bâtis à partir de mini-calculateurs dédiés (les PLC : programmable Logic Controler) chargés de récolter l'information et de l'envoyer sur des liaisons de 1200 bauds à des terminaux distant RTU (Remote Terminal Unit), eux même controlés par un MTU (Master Terminal Unit). Ces RTU ne possédaient alors aucune intelligence et n'avaient aucune interaction avec d'autres systèmes d'information.

Alors, que s'est-il passé pour que ces systèmes isolés, compartementalisés deviennent des architectures réseaux classiques qui utilisent des liaisons T-1, de l'Ethernet, du wifi et même des liaisons Internet non-protégées ?

Ma théorie est que ces systèmes ont souffert des mêmes causes qui ont permis à nos SI de la Défense de devenir vulnérables aux maux de l'Internet : la réduction des coûts et la volonté des hauts responsables d'avoir une vue temps réel du terrain (le tableau de bord avec des camemberts qui clignotent en continu) !!

L'évolution technologique majeure s'est passée au niveau des RTU. Ces équipements dédiés et monofonctions se sont peu à peu transformés en logiciels multifonctions chargés sur des systèmes d'exploitation grand public (MS Windows, Linux). Ce changement a permis de réduire considérablement l'implémentation de ces RTU qui se sont dotés des éléments logiciels suivants :
- les DPA (Data Processing Applications) permettant la reprogrammation du RTU et l'ajout d'une GUI possèdant un accès utilisateur.
- les DCA (Data Collection Applications) permettant l'intégration de données collectées sur de nouveaux contrôleurs
- une base de données...

Cette évolution a cependant eu un cout caché phénoménal : ces systèmes de contrôle industriels, hier isolés et utilisant des équipements propriétaires, sont désormais vulnérables à tous les maux qui visent nos simples PC.

Et oui, l'une des premières surprises que j'ai eu en découvrant les systèmes SCADA a été de contempler le célèbre logo "TUX" sur un boitier RTU qui surveillait les vibrations de la pompe d'un système de refroidissement ultra-sensible. De tels boitiers sont généralement disséminés sur l'ensemble d'un site et sont interconnectés via un réseau Ethernet partagé ou un réseau wifi.

Même si je suis loin d'être un adepte de la grande peur de l'après 9/11, j'ai quand même eu quelques sueurs froides lorsque j'ai commencé à étudier la dizaine de protocoles utilisés par les systèmes SCADA : ces protocoles n'ont pas du tout été pensés pour partager un réseau d'entreprise avec d'autres systèmes d'information. Je me suis alors pencher sur les RTU, et la situation m'a paru désespérée : ces systèmes, bien que bâtis sur du MS Windows classiques ou du Linux, ne sont jamais patchés et il existe même des clauses constructeurs qui interdisent toute mise à jour du système d'exploitation !

Mais, je garde le meilleur pour la fin : la "mentalité particulière" des ingénieurs de l'industrie. En tant que consultant Infosec, on trouve parfois difficile de persuader un ingénieur IT de mettre en place un système de bascule de serveurs afin de pouvoir patcher (et rebooter pour MS Windows) un système critique. Avoir la même démarche avec un ingénieur industriel est une mission impossible. En effet, la mise à jour d'un RTU signifie souvent l'arrêt d'une pompe d'une central électrique ou la fermeture d'un pipeline. Vous imaginez les centaines de millier d'euro perdus à chaque Black Tuesday !!

Bref, la sécurisation d'un système de contrôle industriel passe essentiellement par la conception du système lui-même et surtout par une énorme campagne de sensibilisation des ingénieurs industriels. Et là, nous avons du boulot pour une bonne dizaine d'années...

Voila pour une petite mise en situation de l'infosec pour systèmes SCADA. Si cela intéresse l'un de mes trois lecteurs, je vais continuer et réaliser des descriptions plus détaillées. ;-)

Changement de disciplines en vue...

Ayant changé de job au début du mois, je n'ai actuellement plus la possibilité de pratiquer le live forensique et la réponse aux incidents. D'où ce silence assez long...

J'avoue qu'il m'est même venu à l'esprit de fermer ce blog après le SSTIC (évènement qui a sonné le glas de mon anonymat... pour ceux, bien sûr, qui se donnent la peine de lire un papier jusqu'à sa 26e page !)

En fait, je ne désespère pas de trouver un jour une mission intéressante dans ces domaines et je vais d'ailleurs m'y employer dès la semaine prochaine (reste à faire une prés' sur le sujet ce weekend)

En attendant cet heureux jour, je vais m'adonner aux missions classiques des consultants Infosec : audit, pentests, stratégie de sécu, architectures, plans de progrès ou de changement... Rien de bien passionnant, encore que cela faisait des années que je n'avais pas pratiqué. Je m'efforce tant bien que mal de placer de temps à autre mes idées et ma touche personnelle, bien que pas grand chose puisse être inventé dans ces disciplines usées jusqu'à la corde.

Après quelques discussions, je crois avoir trouvé un domaine intéressant dans le domaine de l'audit et du pentest : les systèmes SCADA. Nous touchons là un territoire qui m'était complètement inconnu voila encore quelques semaines. C'est en fait à des kilomètres du serveur Oracle en back-office qui semble faire saliver les premières années Epitec (ils se reconnaitrons).

Après avoir pris quelques avis, il semble qu'il s'agisse d'un territoire quasiment vierge pour l'Infosec. Le fait est qu'un certain nombre d'expériences en la matière se sont mal déroulées. Il coure sur le sujet des légendes très croustillantes : redémarrage complet des chaînes de production d'une usine automobile après un scan nmap mal ficelé, infrastructures critiques isolées pour l'éternité de toute téléadministration et de toute mise à jour, suite à un simple connect' mal placé...

Les systèmes SCADA se révèlent être un sujet super épineux, que cela soit par la difficulté des pentests ou encore par la paranoïa outre-atlantique dont ils font l'objet (Homeland Security...). Il convient donc de les aborder avec un oeil neuf. Cela tombe bien, je me suis écarté des pentests et des audits depuis suffisamment longtemps pour essayer de tenter d'autres approches.

La pratique du forensique et la chasse aux hackers m'ont appris la furtivité, qualité qui manque trop souvent aux pentesteurs de base qui ne jurent que par les scans de vulnérabilités et la grosse artillerie... (je vais encore me faire des amis ;-))

Pour débutter en la matière, il faut que je trouve du temps pour la mise au point d'un scanner passif (sniffer+reconnaissance de motifs sur bannières et autres infos clés) qui me coute moins de 10.000$, afin de répertorier rapidement, mais grossièrement les systèmes les plus vétustes.

Le plus difficile, sans doute, sera de trouver des clients pour ce genre de manip', d'autant qu'en Europe ces systèmes ne soient pas légions. Il est vrai que les techniciens européens coutent beaucoup moins chers que leur homologues étasuniens et que, par conséquent, la téléadministration de systèmes critiques n'est pas très répandue.

Au final, cela reste tout de même un beau sujet pour un stagiaire désirant s'essayer aux micro-controleurs et aux protocoles SCADA ou encore un sujet exotique pour le prochain SSTIC ! Avis aux amateurs...

Deux pistes sérieuses pour le live forensique

Chose promise, chose due, voici enfin un article faisant la preuve de mon intérêt constant pour le live forensique.

Le RFC 3227 - Guidelines for Evidence Collection and Archiving recommandait, dès février 2002, que le premier élément de preuve à récolter dans le cadre d'une enquête forensique était la mémoire physique (la RAM) du système suspecté. Si le recueil de cette mémoire physique est peu à peu rentrée dans les procédures forensiques et de réponse aux incidents (IR), son analyse, quant à elle, reste problématique.

Lorsque j'ai quitté mon équipe IR voilà trois mois, cette analyse n'était réalisée qu'en cas de besoin impérieux de retrouver des mots de passe, adresses IP, adresses de messagerie ou URL, permettant de confondre un suspect contre lequel de fortes présomptions existaient. Pour cela, le binôme IR utilisait les outils strings et grep pour retrouver de tels éléments de preuve. L'analyse la plus "poussée" consistait alors en une exploration rapide sous bintext des mégaoctets de l'image de cette mémoire physique, afin de relever les chaînes de caractères ASCII pouvant avoir une quelconque utilité.

L'été 2005 avec son challenge forensique du DFRWS (Digital Forensic Research Workshop) a marqué une révolution pour les chercheurs INFOSEC de la planète qui se sont pris d'intérêt pour le live forensique. Sur le terrain, c'est en fait la tendance lourde des codes malveillants (virus et rootkits et autres malwares de dernière génération) à empêcher leur analyse statique via les techniques anti-forensiques qui ont amené les équipes IR et les enquêteurs forensiques à vouloir se doter d'outils puissants pour analyser efficacement cette mémoire physique, seule détentrice d'éléments non chiffrés (non-cryptés, pour utiliser un anglissisme) de ces malwares.

L'année 2006 a vu l'apparition publique des premiers outils d'analyse live fonrensique. Les uns bâtis sur l'accès à l'objet \Device\PhysicalMemory, les autres s'appuyant sur le contenu du fichier crash dump généré par les systèmes Windows après un BSoD (Blue Sreen of Death). Deux problèmes techniques sont actuellement à prendre en compte pour le choix d'une de ces familles d'outils :
- à partir de la sortie du service pack 1 de MS Windows 2003 (printemps 2005), l'objet \Device\PhysicalMemory n'est plus accessible à partir du mode utilisateur
- à l'exception de Windows 2003, les systèmes MS Windows génèrent par défaut un crash dump de taille insuffisante (il en est de même pour Windows Vista RC1)

Après avoir fait le tour de quelques outils, ma préférence va à la famille bâtie sur les crash Dump. Il est vrai qu'elle convient d'avantage à une équipe IR qui peut se permettre d'imposer de grandes images crash dump aux serveurs MS Windows sous sa responsabilité, plutôt qu'à un enquêteur forensique envoyé auprès d'un quelconque système suspect. Voir pour cela l'article de la base de connaissance Microsoft ici.

Afin d'affiner mon expérience en la matière, je pense à très court terme (dès la semaine prochaine) travailler sérieusement sur les deux pistes suivantes :
- l'outil Kernel Memory Space Analyzer de Microsoft
- une extraction à l'aide de l'outil LiveKD.exe et sa commande .dump /f fichier-dump.dmp à partir d'un système distant ou d'un système dont la fonction ou la fragilité le rendent impossible à crasher.

D'ici là, il me reste à préparer le TOEIC que je passe à la fin de cette semaine ! ;-)

Sur la perception

Ayant quitté mon équipe IR depuis plus de trois mois, je me prends à philosopher par manque de cas croustillants à me mettre sous la dent (une des raisons pour lesquelles je délaisse ce blog, sans aucun doute). La vieillesse me gagne peut-être ou serait-ce l'ennui ??

Devant rapidement trouver un nouveau job pour nourrir ma petite famille, j'ai dû réviser mes classiques INFOSEC, afin de ne pas sécher bêtement devant une question basique. En effet, après une vingtaine d'entretiens, je n'ai eu aucune question relative au live forensique ou à la réponse aux incidents ! Il faut dire que ces sujets semblent d'avantage faire partie de la recherche expérimentale que des bonnes pratiques ITIL ou autre standard à la mode... Toujours est-il qu'en révisant ces fameux classiques, j'ai eu soudain un doute vertigineux vis à vis des fondements même de l'INFOSEC tels qu'on me les a enseignés voilà plus de dix ans.

Lorsque j'étais encore étudiant en mathématiques appliquées (voila deux éternités...) j'ai subi la torture mentale infligée par un spécialiste de la logique formelle. Outre de violentes migraines, je me souviens essentiellement du théorème de Gödel, qui démontre l'assertion géniale suivante : "Au sein même d'un système, il est impossible de démontrer logiquement les points de départ."

Pour l'INFOSEC, cela peut signifier que les définitions de base (la sécurité, l'équation du risque, les menaces...) sont uniquement de simples perceptions et des valeurs arbitraires !

Or, lorsque l'on connait la part non négligeable qu'ont pris les spécialistes de l'assurance financière dans la genèse de l'actuelle doctrine INFOSEC, notamment dans la gestion des risques, il y a lieu de s'inquiéter. Pour s'en convaincre, il suffit de passer en revue les méthodologies d'analyse de risque à notre disposition. En France, EBIOS et Mehari sont des exemples flagrants de systèmes pseudo-scientifiques - si courants dans l'analyse financière - qui sont bâtis sur du vent et dont le résultat ne repose que sur l'expérience et le pragmatisme de celui qui les met en oeuvre. Ce qui requiert une compétence très poussée en programmation neuro-linguistique. ;-)

Je connais une bonne dizaine de définitions du concept de sécurité appliqué à l'INFOSEC. Cependant, celle que je préfère n'est préconisée ni par les instances de standardisation, ni par notre très haute autorité française : la DCSSI. Il s'agit tout bêtement d'une définition utilisée depuis une trentaine d'années dans le monde du renseignement qui, contrairement au monde de l'assurance financière, possède un encrage évident dans la réalité. Cette définition est la suivante :

La sécurité est le processus du maintien du risque perçu à un niveau acceptable.

Rien de bien nouveau me direz-vous, il fait simplement de l'esbroufe, sachant qu'il n'a plus grand chose à dire sur le sujet du live forensique. Peut-être, bien que je garde encore quelques cartes dans ma manche... Mais, il y a une notion qui peut paraître anodine au premier abord dans cette définition, mais qui change pourtant toute la donne. Il s'agit de la perception.

Pour un esprit français, baigné depuis sa plus tendre enfance dans la logique carthésienne, la dialectique et le raisonnement, la perception reste un élément secondaire de la réflexion. La pensée critique reste le nec plus ultra en Occident, et surtout dans notre beau pays. Il suffit pour cela d'écouter, même d'une oreille très discrète, les derniers discours de la présidentielle...

La perception est pourtant une clé, et même la clé, pour comprendre le concept de sécurité. Pour un analyste INFOSEC, la perception est la partie la plus importante de sa réflexion. En fait, toutes les erreurs que j'ai rencontrées avec mon équipe IR provenaient d'erreurs de perception, dues très souvent au stress, au manque de sommeil et surtout à une trop grande précipitation. En pratique, les erreurs de logique sont rares dans l'analyse INFOSEC. Malgré tout, nous avons appris en tant que fiers enfants de Descartes que réfléchir consiste uniquement à éviter les erreurs de logique.

Ainsi, si l'on s'attache à la perception du risque et non simplement au risque dans un système absolu, on peut alors se concentrer sur les menaces et non plus uniquement sur les vulnérabilités. Lorsque l'on observe les listes de diffusion INFOSEC que cela soit dans notre pays ou encore dans les pays anglosaxons, on voit que la majorité de notre attention est focalisée sur les vulnérabilités découvertes par les chercheurs INFOSEC.

Pour ne pas ajouter un troll à mon actif (et surtout pour ne pas blesser la susceptibilité d'un de mes uniques lecteurs), je tiens simplement à dire qu'il est vain de courir après toutes les vulnérabilités que l'on nous sert chaque semaine. Il faut en fait se concentrer sur les menaces qui nous concernent, comme le font les professionnels du renseignement depuis des années.

Mon expérience en la matière est que l'étude des groupes possédant la capacité et l'intention de nuire à une organisation est bien plus importante (et bien plus utile) que d'essayer de patcher toutes les vulnérabilités qui apparaissent. Il suffit pour s'en convaincre, de faire une pause en reconsidérant les dernières vulnérabilités zéro-days qui viennent d'être publiées à la veille de nombreuses mises à jour de produits de sécurité et des conférences INFOSEC printanières (Oups, j'ai encore trollé :-).

L'étude de tels groupes reste très confidentielle. J'ai relevé dernièrement un post assez proche de cette thématique ici. Si vous en connaissez d'autres, je suis preneur.