mercredi 22 mai 2019    || Inscription
BanniereDossier
 
 
Droit d’accès et comptes à privilèges
Jacques Cheminat / lundi 12 mars 2018 / Catégories: Dossiers

Droit d’accès et comptes à privilèges

Equifax, Deloitte, Uber, les récentes violations de données ont souvent des techniques de piratages différentes, mais un élément commun, obtenir l’accès à des applications critiques comme les bases de données, les bases clients, les informations bancaires. En général ces programmes sont soumis à habilitation et rattachés à des comptes à privilèges. leur protection est donc une nécessité dans un monde de plus en plus ouvert et insécurisé. Dossier publié avec le concours de Kleverware.

La représentation en nuage de points du sujet des droits d’accès et des comptes à privilèges se révèle particulièrement dense. PAM (Privileged Access Management), gouvernance des accès, proxy, serveur de rebond, SSH, RDP, bastion, rotation et coffre-fort des mots de passe, discovery, collecte de logs, chiffrement de bout en bout, sont une liste non exhaustive des termes utilisés. Le sujet est porteur comme le prédit Gartner en estimant qu’en 2020, plus de 40% des PME et grands comptes vont déployer des solutions de PAM pour répondre aux problèmes de sécurité du Cloud.

Pour autant, si ce marché est complexe en se déclinant comme un sous-ensemble de la gestion des identités (IAM), il a évolué avec le temps. Dans une première phase, il se développe autour de la protection des mots de passe des comptes administrateurs et de la technique du coffre-fort, tout en ayant les yeux vers le Cloud. Puis le marché se tourne vers la gestion des accès à travers la technologie du bastion, sorte de boîte noire capable d’enregistrer les sessions, de détecter les comportements anormaux et de s’adapter aux nouvelles exigences comme l’automatisation, l’IA et l’IoT. Enfin, les comptes à privilèges ciblent maintenant les métiers en créant des datarooms, des zones de confiance, dédiées à la direction, les RH ou la finance au sein de l’entreprise.

 

L’ÈRE DU COFFRE-FORT DES MOTS DE PASSE ADMIN

Ce marché est relativement jeune et les anciens réflexes ont encore la vie dure. Selon, une étude menée par Dimensional Resarch pour One Identity, 38% des responsables français utilisent un tableur et 18% gardent les mots de passe des comptes à privilèges sur version papier. La prise de conscience de ces problématiques d’accès a été tardive, se souvient Sébastien Faivre, CTO de Brainwave, spécialiste français de la gouvernance des accès, « elles ont émergé il y a une dizaine d’années, avec les interrogations sur les mots de passe des systèmes Root, le plus haut niveau de privilèges au sein de la DSI et donc un accès à l’ensemble de l’infrastructure de l’organisation ». Ces comptes cristallisent 3 types de menaces : la malveillance interne (un administrateur système mécontent ou un utilisateur un peu trop curieux) ; la malveillance externe (attaque ciblée sur les administrateurs systèmes ou malwares visant les systèmes à privilèges) et l’accident (mauvaise configuration ou erreur de mise à jour).

En 2015, l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a publié une note de « recommandations relatives à l’administration sécurisée des systèmes d’information ». Elle donne des éléments utiles d’aide à la conception d’architectures sécurisées tout en mettant à la disposition des administrateurs les moyens techniques et organisationnels nécessaires à la réalisation de leurs missions. Les comptes à privilèges y sont abordés.

Bunkeriser les mots de passe

Face à un problème technique, la réponse a été aussi technique avec la création des coffres-forts de mots de passe. Plusieurs acteurs sont présents sur ce marché toujours très dynamique. Le principe général repose sur la centralisation en un seul point, sur site ou dans le Cloud, de la gestion des mots de passe pour les comptes à privilèges. Concrètement, la solution analyse l’ensemble de l’environnement IT pour recenser les comptes à privilèges. « En général, un agent se charge de scanner les annuaires de l’entreprise comme Active Directory sur site ou sur le Cloud Azure, mais aussi des services comme Okta ou G Suite de Google » explique Thibault Behaghel, spécialiste produit EMEA chez LastPass. « Il y a beaucoup de demandes autour des offres Cloud et notre offre permet d’appliquer 70 règles de sécurité », précise le dirigeant. L’agent analyse aussi les clés SSH publiques et privées (OpenSSH, Putty, Tectia, Windows, Linux, etc.). L’administrateur IT peut ensuite décider quels comptes associés aux clés doivent intégrer le coffre-fort. La sécurité des mots de passe s’effectue à travers des algorithmes de chiffrement AES 256 ou RSA 2048. En fonction du degré de sensibilité du compte, l’authentification peut être simple couplant identifiant et mot de passe ou bien forte en intégrant des token, de la biométrie, des serveurs Radius, Google Authenticator ou SAML (Security Assertion Markup Language).

Rotation et révocation des mots de passe

Puis, petit à petit, le coffre-fort a évolué avec des fonctionnalités de rotation et de révocation de mots de passe. Dans le premier cas, le coffre-fort est capable de générer de manière aléatoire des éléments d’authentification. Une fonctionnalité rassurante pour minimiser la menace interne, mais elle facilite également la sécurisation de projets en équipes ayant accès à des données sensibles. Dans un environnement DevOps où plusieurs métiers travaillent à la création et à la production d’applications, il est nécessaire d’accéder et de manipuler des données sensibles comme les bases de données. Affecter des éléments d’authentification pour une durée limitée est donc nécessaire. De même, cette fonctionnalité est utile pour les partenaires et les prestataires qui ont besoin d’accéder à des programmes sensibles.

La révocation des mots de passe sur les comptes à privilèges est essentielle. L’actualité est riche d’affaires mettant en cause d’anciens salariés ayant gardé leurs accès à des applications critiques. Ils peuvent ainsi voler des données, les transmettre à des concurrents ou les vendre sur le marché noir. « Il est donc important de pouvoir supprimer l’ensemble des accès quand un administrateur s’en va. Il faut donc vérifier ses identifiants, connaître les couples (mots de passe, identifiant) de ses accès et les révoquer », poursuit Valérie Husson, channel Sales Mananger France & North Africa de Thycotic, nouvel acteur du PAM, arrivé récemment en France. Une tâche automatisable pour laquelle la direction des ressources humaines peut supprimer les accès dès le départ d’un collaborateur depuis un simple bouton.

 

LE BASTION : LA VIGIE ATTENTIVE ET PRÉDICTIVE

Renforcer la gestion des identités des comptes à privilèges (PIM, pour Privileged Identity Management) sur certains éléments du SI est important, mais les responsables IT réclamaient des solutions de traçabilité des sessions des comptes à haut pouvoir.

Le surveillant en chef des sessions à privilèges

D’où l’idée du PAM et plus particulièrement du concept de bastion. « Le bastion s’apparente à la vidéosurveillance dans un appartement », résume Julien Cassignol, ingénieur avant-vente et responsable de l’activité France pour Balabit. Si la partie coffre-fort s’inquiète des identités et intègre le PAM, le bastion s’intéresse aux couches les plus basses de l’IT, « Nous analysons les flux basés sur différents protocoles : RDP (Remote Desktop Protocol), Telnet, Citrix, VNC et SSH » explique Serge Adda, CTO de Wallix, le champion français du bastion. Dans certains cas, des demandes d’analyses de protocoles spécifiques sont réclamées comme dans le cadre des systèmes industriels et les automates SCADA en particulier. « Certains protocoles sont plus complexes que d’autres, comme par exemple les demandes SQL, il y a autant de parfums que les glaces chez Berthillon », constate avec humour Julien Cassignol.

Sur le plan technique, les PAM du marché s'appuient sur des serveurs proxy et des serveurs de rebond pour scruter les flux des tâches. Concrètement, une connexion par rebond consiste à passer par une machine intermédiaire lors d’une connexion entre deux machines, PC ou serveurs, via les protocoles cités précédemment. Cette technique sécurise l’accès aux applications en déléguant l’injection des mots de passe au serveur proxy pour masquer les identifiants.

Mais ces serveurs savent aussi enregistrer les flux. Ils sont capables de rejouer une session en vidéo au format MPEG4 compressé. « 1 h de vidéo correspond à une taille de 20 Mo », assure Valérie Husson de Thycotic en mettant en avant l’offre Secret Server. Elle ajoute : « l’enregistrement se fait en direct et a un intérêt historique pour savoir ce que l’administrateur a fait ou a essayé de supprimer ».

 

Les yeux doux au DevOps et à l’IA

Forts de la traçabilité en vidéo, les bastions récoltent dans le même temps beaucoup de métadonnées. Une mine d’informations à valoriser via des solutions analytiques et de machine learning. Ces efforts aboutissent à l’émergence de solutions d’UBA (User Behavior Analytics), l’analyse comportementale des utilisateurs. « Nous allons maintenant vers l’expérience utilisateur. A travers cette vidéosurveillance, nous collectons énormément d’informations sur ce qui se passe et s’est passé », précise Serge Adda de Wallix.

Pour Balabit, le machine learning permet d’apprendre et de connaître le comportement des détenteurs d’accès aux comptes sensibles. Julien Cassignol le reconnaît, « le machine learning apprend les habitudes de comportement des administrateurs, il est ainsi capable de déterminer les moindres différences comme la façon de frapper sur un clavier, la répétition de commandes peu ou pas utilisées ». Du côté de Wallix, la partie analytique facilite la création de scénarii, « les gens ont des comportements récurrents et répétitifs sur les applicatifs, si une attitude ne correspond pas, il peut y avoir une alerte ».

Car l’objectif de cette analyse comportementale est double, à la fois pour la prévention et dans le cadre d’une enquête. Les bastions sont paramétrés pour lancer des alertes en cas de comportement anormal, voire bloquer immédiatement le compte, si le risque est important. La priorité est le Cloud et l’accompagnement du DevOps. CyberArk est clairement dans cette voie. « Aujourd’hui, les comptes à privilèges ne sont plus nécessairement le fait des humains, mais des robots comme les solutions d’orchestration ou les générateurs de scripts », explique Jean-Christophe Vitu, Pre-Sales Director West & South Europe de CyberArk. Et l’histoire pourrait bien lui donner raison, le vol de données d’Uber est à l’origine un accès à des identifiants AWS codés en dur dans un référentiel privé sur GitHub. Le spécialiste du PAM a donc sorti une offre dédiée, Conjur, pour cibler cette population et cette méthode de travail nécessitant rapidité et agilité.

 

GOUVERNANCE DES ACCÈS ET DATAROOM, AU-DELÀ DU BASTION

Si les deux éléments centraux dans le droit d’accès et la gestion des comptes à privilèges sont le coffre-fort et le bastion, il ne faut pas oublier des solutions complémentaires : la gouvernance des accès et les datarooms. La gouvernance des données s’interroge sur le cycle de vie de la donnée, alors que la notion de dataroom étend la notion de zone de confiance et d’habilitation, réservée à l’IT en général et en particulier aux sysadmins, aux dirigeants et aux responsables métiers (RH, marketing ou finances).

La gouvernance des accès, une tour de contrôle pour les PAM

« Les outils de PAM configurent le coffre-fort de mots de passe et les droits d’accès, mais ils n’englobent pas le cycle de vie des accès. Il faut croiser les logs des PAM avec d’autres bases de données comme celles des RH par exemple », confie Sébastien Faivre de Brainwave. Le concept de gouvernance des accès emprunte à la gestion des risques sur le SI et à l’audit. Il donne à un ensemble d’acteurs légitimes la possibilité de suivre l’évolution des identités et des accès des utilisateurs au sein du SI et d’en contrôler la conformité et de répondre aux questions « qui a le droit à quoi, comment et pourquoi. Le contrôle a posteriori, la réconciliation des comptes », poursuit le dirigeant.

Pour mener à bien cet audit, il est nécessaire de réaliser une cartographie. « Nous extrayons des données du SI de manière très granulaire, allant du référentiel RH, l’accès des partenaires, les bases de données, les annuaires (Active Directory, LDAP). Au final, nous dressons un inventaire des droits d’accès », explique Arnaud Fléchard, CTO de Kleverware, également spécialiste français de la gouvernance des accès. Il ajoute, « ce travail donne une vue des droits à pouvoir ou sensibles et facilite la ségrégation des tâches afin d’assurer une véritable séparation des tâches ». Les offres d’IAG (Identity and Access Governance) sont des tours de contrôle et s’imposent en complément de solutions de PAM ou d’IAM.

 

Les Dataroom blindent les données à privilèges

Les comptes à privilèges ne sont plus l’apanage des seuls administrateurs. Le Cloud, la mobilité et même les médias sociaux rebattent les cartes de la gestion d’accès. La direction d’une entreprise, les directeurs financiers, ressources humaines disposent d’accès spécifiques à des ressources sensibles. Mais la protection ne doit pas porter uniquement sur les accès, mais aussi sur le contenu. D’où la création des datarooms, des espaces sécurisés autorisant le partage de documents sensibles. Une offre qui s’adresse spécifiquement aux comités exécutifs des entreprises, manipulant des informations stratégiques (budget, fusions-acquisitions, plan de recrutement ou de licenciement, etc.). La sécurité est assurée depuis le poste de travail « avec une connexion TLS 1.2 entre les serveurs, le passage d’un antivirus sur l’objet transféré plus un chiffrement en AES 256 spécifique et un enregistrement sur disque », assure Alexis Boissinot, responsable de Brainloop France. Pas d’inquiétudes de voir la DSI disposer d’un accès privilégié aux documents, « les gens de l’IT et de la sécurité gèrent l’accès à la porte d’entrée des datarooms, mais pas aux contenus », soutient le dirigeant. Les services en mode SaaS comme Office 365 ou Salesforce sont gérés via des API, « avec un simple glisser-déposer » des objets dans la dataroom.

Les acteurs du marché des droits d’accès et comptes à privilèges

IAM (Identity Access Management) Ilex, Gemalto, GlobalSign, Okta, IBM, AWS, Google 
Coffre-fort de mots de passe Lastpass, Dashlane, Keepass
PIM (Privileged Identity Management) IBM, CyberArk, Balabit, Centrify, CA Technologies
PAM (Privileged Access Management) Wallix, CyberArk, Balabit, Thycotic, CA Technologies, Bomgar
Gouvernance des accès Brainwave, Kleverware, One Identity, Sailpoint
Dataroom Brainloop, Drooms, OOdrive, Intralinks

 

Dossier publié sur le site mag-securs.com avec le concours de Kleverware.


Infos partenaire

Kleverware, éditeur français, est un précurseur depuis 2005 dans le domaine du contrôle des identités et des accès. Avec ses innovations brevetées et la reconnaissance du marché par l’obtention de labels (France Cybersecurity, Bpifrance Excellence…), Kleverware prouve la robustesse de ses solutions, qui sont utilisées par des grands noms depuis des années pour auditer des centaines de milliers de droits tous les jours.

Les solutions de Kleverware sont flexibles et efficientes, que ce soit pour :

  • Les opérationnels de la sécurité, pour savoir rapidement quels sont les droits qui sont réellement donnés aux collaborateurs (cartographie exhaustive) au regard de leur fonction (SOD).
  • Les correspondants Métier, pour leur simplifier les revues de droits et leur offrir un gain de temps sur des taches qui ne sont pas obligatoirement bien comprises (ROI).
  • Vos auditeurs (CAC, Contrôle Interne) à qui vous démontrez que non seulement vous répondez aux préconisations, mais auxquels vous donnerez le reporting idoine.

Les solutions de Kleverware :

Kleverware IAG « Quick Start »

Cette solution ne nécessite pas d’infrastructure, un poste ou une VM suffit. Simple d’installation, elle est efficiente pour l’analyse et le contrôle, cela même pour des milliers d’identités grâce à sa technologie brevetée. Kleverware IAG « Quick Start » vous donne très rapidement des premiers indicateurs (SoD, Comptes dormants, orphelins…) pour une bonne gouvernance de vos identités et de leurs accès. Vous pouvez l’utiliser pour une cartographie exhaustive des droits, établir des tableaux de bord, vérifier que votre PSSI est respectée…

Kleverware IAG « Enterprise »

En complément de tous les avantages la version stand alone, vous bénéficiez d’une solution faite pour vos collaborateurs en charge de la revue des droits et ce au plus près des métiers. Avec ses interfaces intuitives pour les différents rôles (Managers de campagnes, approbateurs…), Kleverware IAG « Enterprise » simplifie grandement le travail qui leur est demandé. Vos collaborateurs vous remercieront d’avoir évolué vers une solution robuste, flexible et reconnue par des entreprises depuis plusieurs années.

 

Print
114346

x


Tout a-t-il été dit sur le ver Stuxnet ? Sans doute pas. On pourra sans doute en tirer un jour un fi lm à la « James Bond » ou « Mission Impossible ». Faut-il s’en tenir là ? Manifestement non, une telle attaque soulève de nombreuses questions qui doivent remettre en cause certaines certitudes...
Peut-être faut-il repenser nos paradigmes en matière de sécurité.

La faillite de la Barings Bank, en 1995, causée par le trader Nick Leeson avec 827 millions de livres sterling de pertes a été le thème du film « Trader – l’homme qui a fait sauter la banque de la Reine d’Angleterre » sorti en 2000 avec Erwan McGregor. Au début de l’année 2008, on découvre que la Société Générale passe de très peu à côté de la faillite avec l’affaire « Jérôme Kerviel » : 50 milliards d’euros d’exposition et près de 5 milliards d’euros de pertes(*). La tourmente financière de l’automne 2008 nous a donné un tout autre tempo : la crise américaine des « subprimes » met en jeu 500 milliards de dollars de valeur fictives ! Et les affaires ne sont pas terminées : Madoff avec 50 milliards de dollars, ou encore le renflouement des fi nances de l’Irlande avec 85 milliards d’Euros, etc. Stuxnet pourrait bien être à la SSI ce que Nick Leeson a été au système financier : le premier épisode d’une longue série dont les effets pourraient finir par être très dévastateurs. Le risque encouru par les systèmes industriels est connu depuis de nombreuses années et est régulièrement exposé au cours de grandes conférences comme la Black Hat, la RSA Conférence, ou le FIC. Mais force a été de constater que ce risque était considéré comme non avéré : l’attaque n’avait pas eu lieu...

Dès lors, la tentation de classer ce risque comme résiduel, c’est-à-dire acceptable sans vraiment apprécier son impact est fort... La médiatisation de l’attaque Stuxent aura au moins eu le mérite de provoquer une vaste campagne de sensibilisation sur la sécurité des systèmes industriels.

> Les éléments de l’attaque
Il convient naturellement de rester très prudent sur ce que nous savons des véritables objectifs de ce ver. Une tendance générale se dégage toutefois pour supposer que ce malware a été conçu afin de détruire les centrifugeuses de l’usine d’enrichissement d’uranium de Natanz, en Iran.

Des faits ont en effet été rapportés par l’AIEA sur un retard de ce programme et le gouvernement iranien a luimême reconnu l’existence de problèmes. Le code exécutable des commandes des centrifugeuses auraient été modifiées pour changer leur vitesse de rotation et les détruire. Il s’agirait donc d’une attaque sur les systèmes de supervision WinCC de Siemens, qui contrôlent, sur un ordinateur exploité sous Windows, les systèmes Scada (Supervisory Control and Data Acquisition).

L’affaire aurait donc eu un objectif, le blocage, ou au moins un sérieux ralentissement du programme nucléaire iranien. Elle aurait également eu l’appui d’un ou plusieurs états, les Etats-Unis et/ou Israël, des moyens intellectuels importants et sans doute également un travail traditionnel d’agents de terrain.

Ce genre d’attaque ne ressemble cependant pas aux vers que nous avons connus au début des années 2000 et qui se propageaient sur l’Internet.
Les équipements d’une centrale nucléaire ou d’une usine d’enrichissement ne sont en effet pas accessibles de l’Internet. Des réseaux spécifiques sont conçus, totalement cloisonnés. Il est même courant de mettre en oeuvre des « firewalls-diode » permettant à un équipement de mesures d’envoyer des données vers une salle de contrôle, sans qu’il ne soit possible d’envoyer des ordres à cet équipement pour le perturber, voire de changer son code exécutable.
Ces principes sont largement diffusés et sont précisés dans les documents du Nuclear Energy Institute américain, notamment le document NEI0404. L’attaque, dit-on, aurait été menée grâce à des clés USB.

La composante humaine a donc été employée... A quel niveau, de quelle manière ? Les choses ne sont pas claires : un agent sur place agissant délibérément ? Ou une contamination en amont de programmes exécutables pour que des techniciens autorisés compromettent ensuite, à leur insu, les commandes des équipements ?
Dans la mesure où plusieurs installations ont été infectées dans le monde, le second scénario nous semblerait plus plausible...

Selon la publication israélienne Debka spécialisée dans le renseignement militaire, le professeur iranien Majid Shahriari, chargé de lutter contre Stuxnet a été assassiné en novembre dernier. Le mode opératoire a été celui d’explosifs lancés depuis des motos et d’une fusillade depuis une voiture. Le pouvoir iranien a pour sa part immédiatement accusé les Etats-Unis et Israël, confirmant ainsi l’assassinat du scientifique...

L’analyse du ver Stuxnet a été réalisée par de nombreux experts et on a pu assister à un très important travail d’échanges entre les experts et les éditeurs de solutions anti-malwares. Un rapport très complet a notamment été réalisé par Symantec. Les experts ont identifié l’exploitation de quatre failles « 0 day ». L’exécution d’un payload rendue possible par l’exploitation de la faille LNK non corrigée permettait de compromettre le système en exécutant un code malicieux depuis une clé USB par un appel de lien .ink. Pour l’ensemble de la profession, la combinaison de 4 failles représente un travail exceptionnel et jamais vu à ce jour. Symantec explique que le système de contrôle des fréquences des moteurs entre 807 Hz et 1210 Hz étaient visées. Les experts relèvent également que l’attaque exploite l’utilisation d’un mot de passe par défaut. WinCC / PCS7 s’appuie en effet sur une base de données MS SQL qui demande un mot de passe pour établir une communication interne. La vérification ne concerne donc pas l’utilisateur du système et Siemens recommande à ses clients de ne pas changer le mot de passe pour éviter des dysfonctionnements...

L’étude du ver fait encore apparaître que deux certificats ont été volés à JMicron et Realtek. Le système vérifie en effet l’authenticité des codes exécutables auprès d’une autorité de certification : Verisign. Mais le code exécutable modifié disposait des certificats originaux et l’autorité de certification les reconnaissait comme valides ! Comment les certificats ont-ils été volés ? Infiltration, commandos, espionnage, achat de personnes... L’histoire ne le dit pas encore, mais il existe de nombreux films qui montrent cela...

Les experts estiment que ce ver a demandé un travail de 6 mois à un an à une équipe de 6 à 10 personnes. L’analyse du code montre par ailleurs des éléments plus curieux. Il comporterait un fichier nommé « Myrthus », ce qui signifie « l’arbre de Myrthe » en français. Or, on trouve dans la Bible le Myrthe comme étant un symbole de justice : « au lieu du buisson croîtra le sapin et au lieu de l’épine croîtra le Myrthe : et cela rendra glorieux le nom de l’éternel et sera un signe perpétuel, qui ne sera jamais retranché ». D’autres experts y ont vu une allusion au Livre d’Esther, et donc à la Torah : « elle s’appelait Hadassah parce qu’elle était juste et que l’on compare au Myrthe ceux qui aiment la justice ». Hadassah est l’un des noms de la reine Esther qui signifie Myrthe. Le Livre d’Esther explique comment la reine Hadassah déjoua les attaques perses destinées à anéantir le peuple juif.

Autre détail issu de l’analyse du code, le ver s’arrêtera de fonctionner le 23 juin 2012. Des experts ont relevé que c’est très exactement 100 ans, jour pour jour, après la naissance d’Alan Turing, connu pour ses travaux sur les ordinateurs, mais aussi pour avoir dirigé une équipe de cryptanalyse durant la seconde guerre mondiale dans le centre de Bletchley Park qui décodait les communications allemandes et a joué un rôle considérable dans la victoire alliée contre le régime nazi...

L’unanimité n’est cependant pas de mise entre tous les experts SSI de la planète. En Israël, on trouve des spécialistes qui dénoncent une campagne de communication hostile à leur pays et qui minimisent les capacités de Stuxnet. En France, Daniel Ventre, ingénieur au CNRS et directeur de la collection « Cyberconflits et Cybercriminalité » aux éditions Hermès-Lavoisier, se montre très circonspect vis-à-vis de nombreuses conclusions qui sembleraient avérées pour le plus grand nombre. « L’attaque n’était pas ciblée, souligne-t-il, elle a touchée l’Inde, l’Indonésie, la Russie, les Etats-Unis et la Chine ! Son origine étatique n’est pas démontrée : un travail de 10 ingénieurs pendant 10 mois est à la portée d’une entreprise, ou d’un groupe d’étudiants ! » Dans son rapport sur Stuxnet, Symantec met toutefois en évidence que le plus grand nombre d’attaques se trouve bien manifestement en Iran, très loin devant les autres pays...

> Un risque sur les centrales françaises ?
Le risque a été pris au sérieux par les autorités françaises de possibles effets sur nos centrales nucléaires, en France. L’IRSN a publié le 30 septembre une note d’analyse sur Stuxnet.(*) On y lit que seul le réacteur nucléaire EPR en construction à Flamanville utilise un système de contrôle-commande Siemens. Son éventuelle sensibilité à des logiciels tels que Stuxnet doit donc être prise en compte dans l’analyse de sûreté. La propagation du ver Stuxnet nécessite que les ordinateurs de supervision exploitent Windows et que les logiciels de supervision soient ceux de la gamme PCS 7/WinCC de Siemens.

L’IRSN poursuit en expliquant le besoin d’une démarche globale d’analyse critique de sûreté, avec une analyse technique systématique et détaillée des systèmes, dont les dysfonctionnements peuvent influencer la sûreté d’une installation nucléaire. Pour le réacteur EPR, explique encore l’IRSN, EDF a retenu la gamme « SPPA-T2000 » de Siemens, basée sur sa technologie « S5 » plus ancienne et radicalement différente de sa technologie « WinCC / S7 » visée par Stuxnet. Les ordinateurs de supervision du réacteur EPR de Flamanville ne sont pas basés sur le système d’exploitation Windows et n’utilisent pas les logiciels WinCC et PCS 7 ; le ver Stuxnet est donc sans influence sur eux.

Et l’IRSN poursuit en précisant que l’analyse de sûreté de la plateforme SPPA-T2000 de Siemens a permis de vérifier d’avance qu’elle présentait les propriétés qui garantissent, entre autres, son immunité aux logiciels malveillants, et en particulier au ver Stuxnet. Le Système de Protection de l’EPR, le plus important des systèmes de sûreté, est développé à partir d’une autre technologie nommée Teleperm XS. Cette technologie d’Areva ne comporte pas les logiciels ciblés par Stuxnet et ses automates de sûreté n’ont aucune interface qui permettrait à un logiciel malveillant de l’infecter. Voici qui est rassurant… ou très inquiétant, car rien ne dit qu’un autre malware ne pourrait, lui, aboutir à mener une attaque contre des sites français... Il faut continuer à réaliser des études de sécurité très strictes.

> Approfondir les principes des analyses de risques et les paradigmes de la sécurité
Stuxnet nous enseigne surtout qu’il est nécessaire d’approfondir nos principes d’analyse de risque. Nous sommes en effet habitués à nous interroger sur l’origine des menaces auxquelles nous devons faire face et à en écarter de nombreuses pour conserver des systèmes simples. Or, si nous retenons le scénario que Stuxnet visant les centrifugeuses iranienne, nous devons aussi reconnaître que pour réaliser sa contamination et atteindre son objectif, il a dû se répandre dans la nature et peut encore causer des dégâts sur des équipements d’autres industries. Le code utilisé par Siemens n’est-il pas aussi utilisé dans d’autres équipements industriels comme il est souvent l’usage ? Dès lors le fait de ne pas avoir identifié d’ennemis directs ne veut pas dire qu’il n’existe pas une exposition à une attaque extrêmement sophistiquée...

La notion de dégâts ou de pertes collatérales bien connues dans les opérations militaires peuvent aussi exister dans nos entreprises. Nous devons de même intégrer le fait que des attaques étatiques, même si elles ne sont pas totalement avérées, doivent être aujourd’hui considérées comme plausibles. Beaucoup d’analyses de risque se concentrent sur la disponibilité des systèmes. Il faut que l’entreprise produise, vende et se fasse payer. Des moyens importants sont mis dans les sauvegardes, la lutte anti-incendie, les plans de reprise d’activité. Dans de nombreuses grosses PME, l’analyse de risque se limite d’ailleurs souvent à ce stade. La confidentialité des informations est souvent prise en compte en raison d’enjeux commerciaux, de contraintes réglementaires, par exemple pour les données de santé, ou encore de questions de souveraineté nationale. Là aussi, les moyens sont en général mis en oeuvre sont parfois importants : chiffrement, traçage des logs, infrastructure de gestion de clés, etc. Le contrôle de l’intégrité des programmes et codes exécutables ne suscite pour sa part qu’un niveau de préoccupation assez bas.

Certes, toutes les entreprises admettent qu’il faut mettre des antivirus... encore que sur le Macintosh et les serveurs Unix / Linux la pratique soit encore exceptionnelle ! La défense en profondeur est parfois prise en compte, avec un logiciel anti-malware sur le poste de travail et un second sur la passerelle de l’entreprise, voire un troisième sur le serveur de messagerie si celui-ci est hébergé. Il est aussi souvent d’usage de contrôler l’accès à certains équipements en interdisant et en bloquant de nombreux accès : par exemple en supprimant les ports USB. Ensuite, il existe les solutions de signatures des codes par différents procédés : RSA, courbes elliptiques, etc. Le système suppose la mise en place d’une infrastructure de gestion de clé IGC, ou PKI. On trouve malheureusement parfois des contrôles d’intégrité qui ne sont basés que sur un simple hash du code. Le code est envoyé avec son empreinte MD5, ou SHA1 : à la réception le système vérifie que le code et l’empreinte sont cohérentes. Cela n’empêche pas un éventuel attaquant de modifier le code et d’envoyer une nouvelle empreinte... Ce n’est pas sérieux ! Le cas de l’attaque Stuxnet nous révèle un autre scénario : celui du vol de certificats. L’autorité de certification ne sert plus à rien et l’IGC est détruite...

Les premières traces d’une attaque ressemblant à ce qu’est devenu Stuxnet remontent, selon le rapport de Symantec, à fin 2008. La vulnérabilité permettant l’exécution de code distant dans le spooler d’imprimantes partagées date d’avril 2009. Une pré-version de Stuxnet est découverte en juin 2009. Le 25 janvier 2010, le driver Stuxnet est signé avec un certificat paraissant « valide » appartenant à RealTek Semiconductor Corp. Le 16 juillet 2010, Verisign révoque le certificat de Realtek Semiconductor Corp. Le 17 juillet 2010, ESET identifie à nouveau Stuxnet signé avec un certificat provenant de JMicron Technology Inc. Verisign ne révoquera ce certificat que le 22 juillet...

Bref, l’ICG fournie avec Verisign est restée perméable durant de longs mois... Mais ces scénarios sont-ils intégrés aujourd’hui dans nos analyses de risques ? Ne faut-il pas changer de paradigmes ? Trouver une autre façon de s’assurer de l’intégrité d’un code exécutable ? L’interdiction de toute connexion sur une machine ne tient pas toujours face aux exigences de l’exploitation. On a déjà vu des systèmes avec des ports USB noyés dans la résine, mais il reste toujours un moment où on doit mettre à jour les logiciels, et alors... Prétendre qu’un certificat ne sera jamais volé n’est pas non plus très sérieux. Ne faut-il pas aller plus loin avec d’autres mesures de sécurité et une défense en profondeur accrue ?

Le bilan Stuxnet pour les éditeurs d’antivirus

Pages: 1 de 4 Page suivante