Le concept du « test de l’opérateur » présenté dans cet article est particulier aux environnements industriels. Il s’apparente au test du « stagiaire » dans les environnements « bureautique », où il s’agit de tests d’intrusion à partir d’un poste déjà connecté au réseau, en principe avec des droits limités.

Le « test de l’opérateur » est particulièrement pertinent dans les environnements de production où sont présents des terminaux de visualisation ou de contrôle, connectés au réseau de production.  Ces terminaux sont potentiellement des portes d’accès « sans surveillance », dont l’exploitation par une personne malveillante peut se révéler catastrophique…

L’importance du test de l’opérateur

L’une des caractéristiques des réseaux de production, outre le fait qu’ils soient souvent modérément protégés et surveillés, est que de nombreuses personnes y accèdent, via une authentification souvent faible.

En effet les opérateurs de production qui se relaient quelquefois en 3×8 ont rarement à utiliser un badge d’identification pour accéder aux terminaux de leur poste de travail : d’une part les solutions d’authentification sont coûteuses et guère évidentes à déployer dans une usine, d’autre part, la nécessité d’accéder en permanence et sans délais aux contrôles sensibles rend risqué l’usage de systèmes potentiellement bloquants.

La conséquence est que les terminaux restent souvent connectés (utilisateur « loggé » sans déconnexion automatique) pendant de longues durées (jours… semaines…). Heureusement souvent sous un compte sans privilège d’administration (quoique…).

A partir de là, il devient difficile d’assurer un minimum de sécurité, à savoir :

• mettre à jour l’OS, les applications, les signatures de virus (ce dernier point étant souvent caduc, car une majorité des systèmes fonctionne toujours sans anti-malveillant) ; car cela nécessite une interruption,
• assurer  l’authentification permettant d’établir la responsabilité d’une personne en particulier, en cas de malveillance,
• restreindre l’utilisation du terminal aux seules personnes autorisées, et non à toute personne y ayant physiquement accès, tel un opérateur non habilité.

Le test de l’opérateur en pratique

Le test de l’opérateur consiste donc à se mettre en situation devant un poste « standard », et à tester les possibilités :

• au niveau applicatif : que me permet de faire le logiciel de visualisation / contrôle, puis-je le « planter » et récupérer la main sur l’OS ?   Rappelons que l’une des failles les plus courantes sur les systèmes de production, est l’absence de vérification du format d’entrée des saisies manuelles (1)
• au niveau des périphériques : puis-je connecter une clé USB ? Voire en déconnectant la souris… Voire en déconnectant le « dongle » (la clé de licence du progiciel) …
• au niveau de l’OS : quels droits ai-je ? Quels disques réseaux ? Puis-je installer ou exécuter des jeux (avec ou sans trojan dedans !)
• au niveau du réseau : puis-je voir et naviguer sur les autres postes ? repérer le serveur ? me connecter sur des consoles http actives ?  (évidemment si j’ai pu connecter une clé USB, les différents outils que j’ai pris soin d’y copier faciliteront grandement ma tâche…)
• au niveau du site : moyennant quelques tentatives de configuration de proxy, puis-je « sortir » du réseau de production ? Voire aller sur internet ? Dans ce cas, puis-je établir un « tuyau » stable me permettant de me reconnecter sur le poste, et donc de m’introduire sur le réseau de production, après être sorti physiquement de l’entreprise ? Et tout cela sans être détecté, et éventuellement même sans trace dans le moindre log ?

Ce scénario vous semble peu plausible ? En êtes vous sûr ?

En cas de doute, une seule solution, demandez à un prestataire spécialisé de réaliser le test de l’opérateur !

Retour d’expérience

Pour avoir réalisé ce type de test récemment, j’en retiens deux choses :

• sur des installations industrielles nouvelles (récentes), et pour peu que les mots de passe par défaut des équipements aient été changés (n’oubliez pas telnet et ftp…), il y a une bonne résistance. En effet, tous les équipements récents (switchs, automates etc.) sont relativement durcis. Il suffit de bien régler les droits
• sur des installations plus anciennes, et dans un contexte ou fleurissent sur internet des scripts et méthodologies pour attaquer les SCADAs et les automates, il devient indispensable de faire un état des lieux : soit que cela fait bien longtemps que les mêmes mots de passe sont positionnés et connus de tous, soit que certains équipements ont des failles bien connues et détaillées sur internet…

(1) Publication du Department of Homeland Security: Common Cybersecurity Vulnerabilities in Industrial Control Systems, Mai 2011

Tags: Attaques, Failles, Menaces, Tests