SCADA sous les balles

SCADA
SCADA

On a encore récemment parlé de SCADA à l’occasion de la propagation du ver Stuxnet qui visait des systèmes SCADA Siemens. Sa cible et ses auteurs présumés, comme son fonctionnement, ont été largement commentés et ceci est du à la nature des équipements sur lesquels les systèmes SCADA opèrent. L’une des 4 vulnérabilités inconnue jusqu’à Stuxnet, et qui affectait Windows, a tout juste été fixée. Stuxnet par son aspect ultra élaboré est soupçonné d’être l’oeuvre d’une agence gouvernementale dans le but de mettre à mal une centrale nucléaire iranienne. Nous n’aurons probablement jamais le fin mot de l’affaire mais ceci a peut être été l’occasion pour certains d’aller jeter un oeil sur la sécurité de ces systèmes dédiés au monitoring et à l’acquisition de données d’équipements industriels ou de génie civil, divers et variés.

Daté d’hier, un exploit révèle un buffer overflow dans les systèmes SCADA Realflex de DATAC Realwin.

Ce qui se passe aujourd’hui, en dehors du mystère Stuxnet, résulte de dizaines d’années de mauvaises pratiques sécuritaires chez quelques éditeurs et dans le secteur de l’informatique industrielle. La situation est toutefois assez inquiétante et tous les pays concernés devraient méditer un audit sans concession de ces infrastructures, ne serait-ce, que pour évaluer le risque, souvent amoindri au prétexte que ces équipements sont rarement interconnectés.

Si certains systèmes ne présentent que peu de risques, des systèmes dédiés à des sites bien identifiés comme à risque (ponts, tunnels, lignes de transport ferroviaire, installations nucléaires…) devraient faire l’objet d’attentions nouvelles.

Sans céder à la paranoia, il serait bienvenu, même au niveau français et c’est pas Ossama qui me contredira, de prendre la mesure exacte des risques de scénarios noirs sur ces systèmes et essayer de comprendre si nous y sommes préparés.

16 réponses sur “SCADA sous les balles”

  1. Bonjour,

    J’ose espérer que nos autorités ont anticipées ce genre de problématiques et ce avant la venue de « Stuxnet ».

    « Die-Hard-4 » date de 2006…

    PS : Bravo le blog au fait 🙂

    1. hmm, il est quasiment certain que dans des labos et autres, des gens apte technologiquement ont envisagé ce genre de problèmes…

      Par contre, à savoir si leurs recommandations ont pu percer l’administration qui les encadre au point d’avoir un effet quelconque, c’est moins certains 🙁

      1. Bonjour,

        Je me questionne d’ailleurs sur un registre quasi similaire. En parlant de gens aptes technologiquement et dont le métier est la sécurité informatique, combien connaissaient l’acronyme « SCADA » avant la déferlante audiovisuelle récente ?
        De ce que j’ai pu noter, pas beaucoup mais bon, je suis peut-être dans un microcosme.

  2. Les SII (Systèmes Informatiques Industriels) sont généralement assez bien isolé d’Internet mais une fois à l’intérieur, il n’y a quasiment aucune sécurité.
    Les vecteurs d’entrée sont les clefs usb (le nombre de clef infectés est impresionnant) et les modems (en cours de suppression et bien surveiller).
    Mais de toute façon, vu la pseudo sécurité physique des installations, c’est bien plus simple de trafiquer tranquillement le process que d’utiliser le SII.

    1. En fait, oui mais non.
      Historiquement c’est vrai car les systèmes indus dialoguaient en protocoles … industriels (modbus, etc).
      Depuis l’immiscion de TCP/IP (cela part toujours d’une volonté de réduire les coûts via la suppression de licences ou par l’élargissement de la couverture) c’est déjà moins vrai … en interne seulement.
      Mais depuis l’utilisation de réseaux ouverts TCP/IP pour l’interconnexion (toujours pour réduire les coûts par rapport aux lignes spécialisées) c’est la boîte de Pandore.
      db

    2. Oui … mais non.
      Jadis ces systèmes étaient bien isolés : matériels et protocoles spécifiques.
      Puis la baisse des coûts (par la suppression des licences) est passée par là ainsi que les velléités d’ouverture à d’autres mondes (la bureautique, le web).
      Ainsi TCP/IP et Ethernet ont remplacé les MODBUS sur RS/485 (pas partout) créant des points d’accès au réseau industriel depuis l’intérieur de l’entreprise.
      Puis, toujours dans une perspective de réduction des coûts, d’interconnexion et de personnel cette fois, les réseaux ouverts (Internet) sont venus reliés les différents installations à la place des lignes spécialisées.
      D’installations protégées par défaut de par leur singularité on est passé à de bêtes réseaux bureautiques interconnectés.
      Ben, sauf que le serveur là c’est une centrale nucléaire ou 1/4 de la grille d’alimentation électrique des US.

      A cette situation s’ajoute donc l’intérêt d’une attaque potentielle qui n’est PAS du même ordre de grandeur : c’est tout de même bien plus rigolo de tenter de mettre par terre une centrale hydroélectrique ou nucléaire plutôt qu’un bête serveur de données.

      Enfin, alors que pour un serveur on vise avant tout la compromission (vol ou perte de données) et que l’indisponibilité a, en général, peu d’intérêt pour les SCADA c’est l’indisponibilité qui prévaut alors que la compromission c’est bof.
      Et l’indisponibilité est très souvent bien plus facilement atteignable que la compromission.

      Bref, z’ont tous les défauts ces SCADAs.
      Mais, c’est comme d’hab, il faut des morts pour que les autorités daignent se bouger le fion dans le cas d’une route dangereuse. Là il a fallu Stuxnet pour que les esprits s’émeuvent.
      Car, il ne faut pas croire, les experts en sécurité signalent cet état de fait depuis des années.
      Cause toujours …
      Heureusement que nous n’en sommes pas arrivé au comportement d’un Thomas Gabriel. Quoique …

      db

      1. Sur les SII où j’ai fait de l’audit sécurité, même s’il y a des tunnels IPSEC qui passe à travers Internet, les SSI sont isolés par des FW ayant des règles saines (rien dans le sens SIE/Internet->SII, uniquement du flux spécifique (généralement PI) dans l’autre sens).
        Effectivement, la convergence vers une plateforme Microsoft Windows est en cours avec des logiciels qui donnent l’impression d’avoir fait un saut de 20 ans dans le passé:
        Buffer overflown, mot de passe en clair, script de debug accessible sans auth, etc …

        Donc, il ne faut pas exagéré: les responsables de ces réseaux connaissent les risques et font leur possible pour les limiter.
        Un scénario à la Die Hard n’est pas réaliste …

    3. Bonjour,

      Exact, un exemple pour illustrer ce genre de choses est de regarder la protection intrinsèque d’ouvrages défensifs :
      le camp romain type vs le « Krak des chevaliers »

      Une fois passé le premier mur…

  3. Sans compter que bon nombre de systèmes ne sont pas forcément patchables facilement étant donné l’OS sous-jacent : vieille version de QNX, etc.
    Dans ces cas-là il faut confiner.
    Db

  4. « Ce qui se passe aujourd’hui, en dehors du mystère Stuxnet, résulte de dizaines d’années de mauvaises pratiques sécuritaires chez quelques éditeurs et dans le secteur de l’informatique industrielle »

    => je vous trouve un peu dur ! La problématique, 10 ou 20 ans en arrière, de ces systèmes étaient d’assurer la redondance et le fail-over ! Objectifs sur lesquels la plupart des experts s’accordent à reconnaître la réussite.

    Après tout, en France tout du moins, il y a peu d’incidents industriels majeurs à déplorer !

    Rappelons que la problématique des attaques informatiques est encore relativement récente par rapport aux aspects traités par ces systèmes.

    Enfin, je rappelle aussi que les cycles de vie de ces composant sont très différents.

    Je concluerai en disant que la faute revient plutôt aux entreprises et organisations qui décident :

    1/ d’interconnecter ces systèmes alors que le bon sens laissait apparaitre la dangerosité.

    2/ d’utiliser des produits « sur-étagères » de type windows et autres pour asseoir de tels systèmes…

    Ces produits ne sont plus adaptés certes ! Les changer est complexe en raison des contraintes de disponibilité mais vous ne pouvez pas dire que la conception a été honteusement baclée…

      1. La conjonction des 2 (ouverture des systèmes mais conservation des mauvaises pratiques d’antan) fait que le résultat est explosif.
        db

    1. Bonjour,

      Je ne pense pas en effet qu’il faille parler de critiques sur la conception des systèmes sus-nommés.
      Ce qu’il faut plutôt regarder, ce sont les notions afférentes à la prise en compte de risques potentiels.

  5. Vous avez été servi le 11 mars 2011 par le virus Stunex, injecté à distance par une société du nom de MAGNA en charge de la maintenance, dans les serveurs de la centrale de Fukushima qui a interdit ainsi le contrôle par les opérateurs sur place, et qui n’ont donc pas pu éviter la catastrophe Nucléaire

Répondre à Gaduc Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.