Faut-il patcher les systèmes industriels ?

Les composants des systèmes d’information industriels étant mal armés pour résister à des cyber-attaques, que faut-il faire :

  1. les rendre plus résistants en réduisant leur vulnérabilité ? (les « patcher »)
  2. ou les mettre hors de portée des attaquants via des barrières logiques et physiques ?

Les deux solutions sont difficiles à mettre en œuvre. L’option 2) est l’approche souvent appelée « défense en profondeur ». L’option 1)  consiste essentiellement à « patcher » les systèmes industriels pour en supprimer les failles logicielles. Comme l’actualité (blogs, normes…) traite du sujet, c’est l’occasion de faire le point.

Patcher les systèmes industriels : est-ce possible ?

L’une des croyances persistantes en cyber-sécurité industrielle est qu’on ne peut pas les « patcher » (mettre à jour) pour supprimer des bugs et a fortiori des failles de sécurité. Et c’est un fait, les responsables de maintenance industrielle restent peu familier avec le concept. Certains constructeurs, sous la pression notamment du CERT US (à défaut de la pression des clients…), on commencé à s’y mettre.

Aujourd’hui de nombreuses vulnérabilités sont publiées, et des « exploits » faciles d’utilisation même par des hackers amateurs sont largement diffusés. Ne pas mettre à jour les systèmes industriels est une position de plus en plus risquée.

Voici l’analyse de quelques publications récentes pour alimenter le débat.

Le rapport trimestriel Solutionary Q4 2012

Ce rapport d’une société de sécurité américaine apporte plusieurs éclairages importants pour la cybersécurité industrielle.

Pas la peine d’utiliser les derniers outils en date

La majorité des attaques informatiques (exploits) fournies dans les « kits d’exploits » payants date de plus de deux ans : ces « boîtes à outils » intègrent des ensembles d’attaques informatiques permettant à des hackers de mener des attaques interactivement, ou de packager les attaques dans des logiciels malveillant.

Si on connait l’architecture et les composants utilisés dans un site industriel donné, il est relativement facile de concevoir une attaque sur mesure. Et si la « cible » applique rarement les mises à jour de sécurité des logiciels, c’est presque un jeu d’enfant de concevoir une attaque, surtout si les PCs ont encore l’auto-run activé (ports USB, CD-ROMs), ou si des postes qui permettent de consulter les emails sont connectés à l’infrastructure industrielle…

Preuve en est l’attaque Shamoon sur Aramco, qui a effacé en un instant l’ensemble des 30,000 postes de travail de la société : Shamoon n’utilisait aucun « exploit 0-day », mais uniquement des attaques publiquement connues. Seulement… Aramco n’était pas à jour de sécurité (sur les postes Windows…)

Les anti-virus sont inefficaces

Ce n’est pas une nouveauté mais un rappel utile : selon ce rapport, les anti-virus arrêtent à peine un tiers des attaques. L’emploi d’anti-virus n’est donc pas suffisant, que ce soit sur les postes qui ont accès à internet et ouvrent les emails, ou (on peut rêver) ceux qui tournent sur les systèmes industriels. Cela ne veut pas dire que ce n’est pas utile, pour éviter le vieux virus lambda arrivant accidentellement sur le réseau.

Stuxnet était l’œuvre d’un état avec beaucoup de moyens, de talents, et une forte motivation. Le logiciel malveillant embarquait 4 exploits « 0-day » (inconnus et « exclusifs »), ce qui en faisait une attaque presque impossible à empêcher : il est « normal » qu’il n’ait pu être stoppé. Il aurait cependant été possible de le détecter du fait de son activité sur le réseau : on parle là de solutions « IDS » (Intrusion Detection Systems) pour lesquelles on a encore peu de retour d’expérience malheureusement, en environnement industriel.

Le faible coût de conception d’une attaque

Le rapport montre que pour $1000 (le coût typique d’un « pack d’exploit ») la plupart des hackers amateurs pourraient concevoir une attaque efficace contre une installation dont les systèmes ne sont pas régulièrement mis à jour. Les mises à jour doivent concerner non seulement les systèmes d’exploitation (Microsoft et Linux), mais aussi les logiciels applicatifs, qui sont la cible de la plupart des exploits, toujours selon ce même rapport.

Solutionary est une société étasunienne de services en sécurité de l’information, et opère notamment des SOC « security operation centers » pour le compte de clients dans le monde entier.

Rappel sur la vulnérabilité liée aux clé USB

Pour rajouter mes 2 centimes aux messages de ce rapport… Une incroyable faille USB a été rendue publique lors de sa correction par Microsoft, et permet potentiellement rien de moins que d’infecter un poste simplement en y insérer une clé USB (trafiquée), sans autre action, et même si les drivers USBs sont désactivés !

Exactement ce qu’on voit dans la plupart des films et séries américaines… mais qu’on pensait peu crédible.

Cette information est postérieure au document Solutionary, mais c’est l’occasion de rappeler que les clés USB restent un vecteur d’attaque largement sous estimé. Évidemment, le risque reste faible (car faible probabilité a priori), et les moyens de contrôle de l’utilisation de clés USB sont souvent complexes et peu pratiques. Il reste utile de sensibiliser les gens, pour qu’au moins ils mesurent le risque.

Mettre des « bouchons USB » en place sur les ports inutilisés n’est pas si idiot… d’ailleurs cela se fait dans plusieurs usines à ma connaissance.

Un point sur les vulnérabilités par Eric Byres

Eric Byres, patron de Tofino, contributeur clé à la norme ISA 99, a rédigé un article intéressant sur le sujet de la course sans fin qui consisterait à patcher les équipements industriels.

Un éléphant dans un couloir

Dans son article, Eric indique que les systèmes industriels sont, pour les pirates, des « sitting ducks », ce qui est à peu près équivalent à des « éléphants dans un couloir ». Son point est que vu le nombre de vulnérabilités déjà trouvées, et surtout étant donné qu’on va continuer d’en trouver encore régulièrement, c’est en fait une course sans fin que de vouloir les adresser toutes : en réalité un attaquant ne peut guère rater son tir s’il vise un système industriel.

Pour démontrer son point de vue sur l’extrême vulnérabilité, il cite un exemple réel d’une étude réalisée dans une raffinerie, comportant une centaine de PCs/serveurs industriels (environ 300 applications), et autant d’automates. Un scan de vulnérabilité a identifié 5455 vulnérabilité publiquement connues, un nombre qui a pu être divisé par deux suite à un effort de patching Windows des systèmes concernés. Mais l’autre moitié, liée aux applications et aux automates, demanderait des efforts manuels et au cas par cas, donc considérables, pour les réduire.

Un nombre de failles ingérables

Eric Byrs utilise ensuite une comparaison entre le nombre de failles trouvées sur Windows XP et les applications industrielles, avec pour base la fourchette de 0,03 (Windows XP) à 0,5 failles par « KLOC » (kilo ligne de code), pour faire une estimation de ce qu’il faut s’attendre à voir arriver pour les logiciels, firmware et applications industrielles. Comme référence : pour XP plus de 1000 vulnérabilités de criticité moyenne ou haute sont connues…

Sa conclusion est que les failles qui ont été à ce jour rendues publiques sur les systèmes industriels représentent la partie émergée de l’iceberg, et que le rythme de leur découverte dépend uniquement de l’attention des chercheurs. Pour s’occuper sérieusement des failles industrielles, il faudrait patcher les installations toutes les semaines pour suivre le rythme, ce qui est impossible du fait des arrêts de production nécessaires.

Par ailleurs, rappelons aussi que les constructeurs ne produisent des patches que pour leurs produits les plus récents : la base installée de produits plus anciens, qui constitue l’essentiel des infrastructures industrielles, ne pourra jamais être « patchée ». Cela était évoqué dans un précédent article, intitulé les « failles forever-day ».

Un effort inutile contre les attaques ciblées

Je rajouterai aux messages d’Eric Byres qu’outre les chercheurs « white hat » qui visent à rendre publiques les failles trouvées, d’autres hackers et non des moindres (équipes travaillant pour le gouvernement américain notamment) cherchent et trouvent également des failles, pour se constituer un arsenal. Et celles-ci ne sont pas publiées…

Cela signifie que même si un effort (considérable) était fait pour patcher les systèmes récents et remplacer les plus anciens, on n’adresserait pas les menaces les plus sérieuses, à savoir les attaques par des hackers à but d’extorsion, voire de sabotage, car ceux-ci ont accès à des failles non publiques…

Concernant les points de vue d’Eric Byres, il est important que rappeler qu’en tant que patron de Tofino, il a des avis pertinents mais potentiellement biaisés car Tofino vend des solutions de filtrage adaptés aux réseaux industriels. En particulier, Eric conclut qu’il faut mettre des solutions de défense en profondeur et de filtrage, car il n’est pas possible de patcher efficacement.

Que disent les normes ?

Il y a deux normes traitant le sujet :

  • l’ISO 17790 « asset management & patchs »
  • l’ISA/IEC 62443-2-3 (publication probable en 2014)

La norme ISO, qui vise les systèmes d’information classiques, est peu adaptée aux systèmes industriels pour toutes les raisons déjà évoquées.

La norme ISA vient (juin 2013) de passer une étape importante (draft for comments : dernière étape avant de proposer un texte pour vote). Il faudra cependant encore quelques mois pour qu’elle soit publiée.

Si on voulait concevoir aujourd’hui une nouvelle installation, en choisissant des équipements conçus avec des objectifs de sécurités (les nouveaux automates sécurisés commencent à arriver sur le marché), on pourrait s’en inspirer pour le « maintient en condition de sécurité », un concept encore très nouveau pour les installations industrielles.

Points clés de la future norme ISA

On trouve d’abord le besoin classique de constituer un état des lieux précis, une base de données des configuration détaillée, extension de la GMAO avec les versions précises des OS mais aussi des firmwares, applicatifs, installés en production – avec une mise à jour régulière.

NDLR à noter que même si on ne prévoit pas de politique de mises à jour, un tel état des lieux, qui souvent est manquant, sera bien utile dès lors qu’on voudra faire un peu de veille, ou qu’on voudrait gérer un incident de sécurité…

Ensuite, pour ajuster les efforts aux besoins (partant du principe qu’on ne peut pas « tout patcher »), l’ISA recommande une méthode pour affecter une « criticité » aux différentes zones de production (en principe déjà fait si on applique les approches ISA 99.03.03). Cela permet ensuite d’appliquer une politique de patch suivant la criticité de la zone et l’importance de la vulnérabilité. Par exemple pour une vulnérabilité élevée touchant un zone critique, on envisagera éventuellement un arrêt de production ad-hoc. Dans d’autres cas, on attendra l’arrêt de production annuel.

NDLR on a ainsi une approche un peu plus réaliste que viser à maintenir tous les systèmes à jour en permanence.

Concernant les fournisseurs, la recommandation est d’exiger de leur par de diffuser les informations concernant les vulnérabilités et les patches le plus vite possible, de manière sécurisée, et l’ISA va même jusqu’à proposer des formats XML à cet effet. Référence est fait au projet ISA 99.02.04 qui vise à évaluer la maturité des fournisseurs sur différents axes, notamment sur leur capacité à informer les clients des vulnérabilités et à proposer des patchs.

NDLR là on est à l’évidence dans une cible un peu lointaine, mais on peut rêver et imaginer que cela soit en place dans un dizaine d’années ?

Bref le document est donc très complet et bien construit (comme tous les nouveaux documents ISA de la série 99 ou à présent intitulée 62443), très intéressant en termes de « check-list ». Il est très ambitieux et décrit un environnement client / fournisseur très éloigné de la réalité d’aujourd’hui, mais qui peut être considéré comme un cible à viser et dont il faut essayer de se rapprocher.

Il donne surtout aux fournisseurs (équipements, GMAO…) et aux industriels des objectifs précis qu’ils peuvent s’approprier : on est curieux de voir quel fournisseur va le premier annoncer qu’il respecte ISA 99.02.03 !

Conclusion

On voit bien qu’aujourd’hui il est illusoire :

  • de mettre à jour les systèmes industriels au rythme de la sortie de patchs de sécurité,
  • et de toutes manières, d’atteindre un niveau de sécurité satisfaisant, puisque les patchs sont loins d’être disponibles pour toutes les vulnérabilités.

Cela devrait évoluer positivement dans les prochaines années, mais pour l’instant il s’agit avant tout de s’occuper des vulnérabilités les plus connues, et de mettre en place des politiques de mise à jour a minima des systèmes d’exploitation.

On ne se protégera pas ainsi des attaques ciblées, ce qui est un objectif difficile à atteindre aujourd’hui, mais au moins on évitera au moins d’avoir des incidents de production à cause d’un bête virus « standard », ce qui arrive encore trop souvent.

Enfin, si certains sites (les PIVs – Points d’Intérêt Vitaux) ont l’obligation de mettre en place des moyens pour la prévention des attaques , la majorité des sites industriels vont devoir plutôt privilégier la détection. Cette approche pragmatique, privilégier la détection à la prévention, est suggérée par de nombreux spécialistes, par exemple dans cette présentation disponible sur www.cyber-securite.fr.

Tags: , , , , ,

1 commentaire sur “Faut-il patcher les systèmes industriels ?”

  1. Laurent RAILLIER dit :

    Merci pour cet article intéressant (comme d’habitude).
    Deux points non évoqués concernant les patchs des API et les mises à jour:

    1) Il existe parfois un risque (faible mais non nul) qu’un patch de l’OS d’un API ait un impact sur ses performances: allongement du temps de cycle, temps de traitement des communications…
    Pour certaines applications où la performance est une donnée sensible, il conviendra de tester le fonctionnement avant et après l’application du patch; ces tests peuvent être longs et nuire à la production.

    2) Dans certains secteurs critiques (nucléaire, militaire…) il est souvent exigé de figer les versions de hardware et d’OS sur une durée très longue, ce qui ne va pas dans le sens des mises à jours.

Répondre à Laurent RAILLIER

Note: Vous êtes responsable de vos commentaires, veillez à rester courtois et factuel. En postant votre commentaire, vous accordez de fait un droit de diffusion à Secur'id.