Et si WannaCry était encore un problème de gouvernance ?

Facebooktwitterlinkedinmailby feather

On l’a appelé WannaCry, Wcry, Wanna, WanaCrypt0r, ce ransomware apparu en fin de semaine a touché des machines dans plus de 70 pays, en exploitant une vulnérabilité dont se servait la NSA dont les outils ont été rendus publics le mois dernier par le groupe Shadow Brokers.

Pourquoi nous n’en sommes pas (encore) sortis

La première raison est simple, c’est le week-end et les admniistrateurs ne sont pas tous devant leur outil de supervision de serveurs et les postes de travail sont gentiment endormis dans les bureaux.

Ce dimanche 14 mai est toutefois jours de reprise au Moyen Orient, où le week-end tombe le vendredi et le samedi, il se pourrait donc que Wcry touche cette partie du monde aujourd’hui… avant de ressurgir dans les pays “westerns” lundi à la reprise du travail.

Vous avez dit “patch management” ?

Le patch management, ou gestion des mises à jour de sécurité en français, c’est l’industrialisation des processus d’analyse et de déploiement de ces mises à jour.

Pour éviter les effets de bord, les arrêts de production ou l’installation à grande échelle d’une mise à jour qui créerait des problèmes sur le SI de l’entreprise, on les installe d’abord dans un environnement de test.

On regarde comment cela s’installe, si les interractions entre le serveur et les machines qui y sont reliées ne sont pas affectées, si tout tourne bien pendant quelques temps, s’il n’y a pas d’évasion de données, etc.

S’il y a quelques soucis, on les prend en compte et on développe des odules que l’on ajoute à ces correctifs de sécurité afin de permettre une installation réussie sur le SI.

Sauf que si c’était aussi simple, tout roulerait.

Aujourd’hui, dans les grandes structures, les patches mettent parfois plus de six mois à arriver. Ces six derniers mois, j’ai vu des serveurs vulnérables aux attaques Poodle et heartbleed… découvertes en 2014 !

De la bonne gestion des risques

Parfois, le risque est identifié et l’entreprise choisit de le faire porter à son assureur lors de la revue de l’analyse de risques parce que la phase de test a mis en lumière que l’application du correctif entraînait trop d’effets de bord.
Parfois, les processus de patch management est (beaucoup) trop long, et cela relève d’un problème de gouvernance de la sécurité.
Parfois enfin, le risque n’a pas été évalué parce que la vulnérabilité n’est pas connue : absence d’audit, absence de veille, mauvaise implication de la direction qui ne permet pas aux DSI et RSSI de travaille dans de bonnes conditions…
Face à l’ampleur de l’attaque, Microsoft a publié dans la nuit de vendredi à samedi dernier une mise à jour de sécurité pour Windows XP, Windows 8 et Windows Server 2003, systèmes d’exploitation qui ne sont d’ailleurs plus soutenus.

On identifie donc un nouveau « trou dans la raquette » à ce niveau là : Comment à l’échelle d’une société, peut-on encore avoir des systèmes d’exploitation sur lesquels on sait pertinemment qu’il n’y aura plus aucune mise à jour de sécurité ?

(sauf encore une fois, effets de bords, risques identifiés et transférés…)

Gestion des crises

En gouvernance de la sécurité, les quatre grands axes de la protection de l’information sont la disponibilité, l’intégrité, la confidentialité et la traçabilité.

C’est ici la disponibilité qui nous intéresse : Il s’agit de la propriété de cette donnée d’être accessible et utilisable à la demande par une entité autorisée, en d’autres termes, un mélange de continuité d’activité et d’accès management.

Sur un site de production, par exemple, cette donnée est celle qui va permettre aux machines de tourner : coordonnées du point où la machine doit enfoncer tel clou qui doit avoir telle forme, taille de la surface sur laquelle la peinture doit être étendue, etc.

Assurer la continuité d’activité, c’est continuer à faire tourner la production y compris lorsque la donné transmise est fausse, y compris lorsque tel ou tel clou n’est pas le bon… et y compris quand les machines tombent en panne.

Alors on va s’appuyer sur des scénarios de crise qui vont du remplacement d’un ordinateur en moins d’une heure au basculement de la prod sur un second site en passant par la résolution de l’incident qui permettra aussi l’alimentation de la base des risques et celle des mesures de sécurité à appliquer au plus vite, par exemple sur d’autres sites de production qui pourraient être touchés un jour ou l’autre par le même problème.

Et vient le cas extrême, celui de la perte d’un datacenter, d’un site de production, pour lesquelles on réalise plusieurs fois par an des tests de basculement sur des sites de repli.

C’est aussi de la gouvernance de la sécurité.

Se dire “et si le pire arrivait ?”, ce n’est pas fabuler, c’est mesurer les risques à leur juste valeur au sein de l’entreprise.

Il y a des RSSI et des DSI qui y pensent, qui connaissent ce risque, qui env parlent, mais qui encore ue fois faute de budget, ne peuvent pas grand chose, si ce n’est avec des bouts de ficelle, pour assurer cette continuité.

Loi de programmation militaire

La loi de programmation militaire (LPM) permet à ces professionnels de la sécurité, d’enfin être écoutés sur la gestion de crise… du moins pour ceux qui travaillent dans des OIV, organismes d’importance vitale, autrement dit, les sites qui ne doivent aps tomber en cas de guerres, putch, etc.

En effet, cette loi oblige ces entités à réaliser régulièrement des excercices de crise en testant divers scénarios, permettant notamment de mettre à jour les vulnérabilités du SI ou de la gouvernance de la sécurité de l’entreprise… et bien entendu de les corriger.

Mais malheureusement, toutes les entreprises ne sont pas concernées et chaque attaque de grande ampleur, chaque vulnérabilité mise à jour n’épargne personne sur son passage.

Et demain ?

Demain, on remonte ses manches et on fait de la sécurité de manière efficiente : on détecte les attaques ou on en soutraite la détection, on potasse la très bonne documentation de l’ANSSI, y compris si on gère une PME pour appliquer les grands principes de la sécurité de l’information et on cartographie ses risques pour mieux les traiter par la suite.

twitterlinkedinby feather

Auteur : Ju

Auditrice en sécurité informatique depuis plusieurs années, j’ai réussi une reconversion après avoir travaillé 12 ans comme journaliste. Je suis certifiée Iso/CEI 27001 Lead Auditeur (PECB) – ISLA1006895-2015-09. Parfois, je donne des cours et des conférences, et j’ai eu deux livres publiés par un éditeur… il y a fort longtemps.

Laisser un commentaire

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