Malware Triton : décryptage d’une cybermenace inquiétante pour l’avenir de l’industrie

Face aux attaques du malware, il devient impératif que les systèmes de cyberdéfense portent bien au-delà du cœur du réseau des systèmes de contrôle industriel.

Le malware Triton s’est attaqué il y a peu à une entreprise d’infrastructure critique en essayant de modifier et de manipuler des systèmes de sécurité industrielle afin de causer des dommages physiques qui auraient pu être désastreux. Or, comme les systèmes de contrôle industriel (ICS) créent une interface entre les environnements physiques et digitaux, les conséquences d’une panne non traitée peuvent leur être fatales.

La campagne Triton s’articule autour de deux phases conceptuelles. Dans un premier temps, les hackers ont réussi à accéder à distance à un poste de travail technique rattaché au SIS (Safety Instrumented System), après quoi ils ont déployé un programme conçu pour se faire passer pour une application autorisée produite par un prestataire de services de contrôle critique et de sécurité système. Le cadre technique créé pour imiter cette application n’étant pas à la portée du premier venu, tout porte à croire que Triton est l’œuvre d’acteurs disposant de financements solides, d’une expertise extrêmement pointue, qui visaient probablement plus qu’un gain monétaire mineur.

Les attaquants sont parvenus à saboter les défenses classiques du réseau. Une fois dans la place, ils ont entrepris de plonger au plus profond du réseau et d’y effectuer une mission de reconnaissance détaillée – la seconde phase de l’attaque. Par chance pour l’entreprise visée, ils ont provoqué par mégarde une panne partielle du système que l’équipe interne de sécurité a examinée et résolue.

Ayant échoué à atteindre leur objectif final, les assaillants vont selon toute vraisemblance évaluer les failles de leur modus operandi pour éviter de se trahir si près du but la prochaine fois. Ils pourraient aussi songer à supprimer l’étape de reconnaissance, attendu qu’ils étaient à l’évidence capables de saboter sérieusement les défenses du réseau depuis leur poste, sans pour autant accentuer le risque de se faire prendre. Et quand on voit l’efficacité avec laquelle leurs méthodes et outils actuels leur ont permis de pénétrer les couches les plus profondes du réseau tout en restant incognito, il est presque certain qu’ils vont les réutiliser contre d’autres organisations.

À l’évidence, Triton constitue un précédent majeur pour la sécurité des systèmes de contrôle industriel. L’enseignement que l’on doit tirer de cet incident est que les zones démilitarisées classiques, la séparation stricte des réseaux et la présence de plusieurs firewalls ne suffisent pas du tout à protéger les machines presque sans défense qui composent les réseaux ICS. Dès lors, comment les fournisseurs d’infrastructures doivent-ils adapter leurs mesures de sécurité compte tenu de l’attaque Triton ?

Concernant la seconde phase, un mécanisme de détection des anomalies semble tout indiqué pour déceler une activité suspecte au sein du système de contrôle, en ce qu’il porte à l’attention de l’équipe de sécurité toute opération non planifiée de reprogrammation ou de reconnaissance. Les échanges tout à fait prévisibles entre les appareils ICS comme les interactions personne-machine et les contrôleurs logiques programmables constituent le terrain idéal pour ce type de démarche, ce qui n’a pas échappé aux régulateurs. C’est par exemple le cas du Royaume-Uni, où la future Directive NIS (sécurité des réseaux et de l’information) obligera les fournisseurs d’infrastructures critiques à doter celles-ci de systèmes de détection des anomalies pour les réseaux qui en dépendent.

Cela étant, les équipes de sécurité aspirent légitimement à détecter leurs assaillants avant que ces derniers aient pris les rênes de leur système de contrôle et commencent à se servir de leurs protocoles d’automatisation et à exploiter des appareils intrinsèquement vulnérables. Ils veulent être alertés en amont de la chaîne du cybercrime, dès que les hackers ont infiltré leurs réseaux, afin de contrer leur attaque à ce stade. Pour ce faire, la seule solution est d’étendre le mécanisme de détection des anomalies et cybermenaces au-delà du système de contrôle, de sorte qu’il couvre les autres réseaux (zones démilitarisées, réseau d’entreprise) capables de créer des zones tampons autour de l’ICS.

C’est la raison pour laquelle il est essentiel d’utiliser des outils conçus pour superviser tous ces réseaux en même temps et couvrir tous les types d’appareils, des contrôleurs logiques programmables aux systèmes informatiques quasi standardisés des salles de contrôle des technologies opérationnelles, en passant par les zones situées en périphérie du champ de vision de l’entreprise – et même sur le cloud si nécessaire. Car les responsables de la protection des systèmes de contrôle ne peuvent se contenter de superviser les protocoles d’automatisation ou les réseaux sur lesquels ceux-ci s’exécutent.