#NotPetya : les enseignements tirés chez Maersk

Une sécurité périmétrique nécessaire mais insuffisante

En outre, selon lui, ces attaques sont généralement extrêmement efficaces pour faire ce pour quoi elles ont été conçues : « le directeur de la NSA [assure que] depuis sept ans qu'il occupe ce poste, il n'a jamais lancé une attaque qui n'a pas fonctionné. Mais l'hypothèse est qu'il en va de même pour les Chinois, les Russes et d'autres ; que lorsqu'un État cible une organisation, le taux de pénétration est de 100 %, de sorte que les organisations ne peuvent plus considérer la sécurité périmétrique comme un moyen de protection valide ».

Alors pour Adam Banks, si les entreprises « ont encore besoin d'un périmètre de défense pour tenir à l'écart les pirates amateurs et les cybercriminels de bas niveau, en même temps, il faut des renseignements à l'intérieur de ce périmètre pour comprendre ce qui s’y passe ». Car en définitive, « il y a des chances » que des intrus soient déjà là. En début d’année, à l’occasion du Forum international de la cybersécurité (FIC), Guillaume Poupard, directeur général de l’Anssi, ne disait pas autre chose. Et l’an dernier, à l’occasion d’Infosecurity 2018, Robert Hannigan, ancien directeur du GCHQ, assurait également que toutes les entreprises peuvent être concernées par les attaques d’Etats-nations.

Un plaidoyer pour l’automatisation

Le deuxième enseignement clé que retire Adam Banks est qu'il est peu probable que la prévention constitue une stratégie efficace : « la détection et la réponse automatisées sont la clé ». Maersk a ainsi mis en œuvre les deux : « si nous voyons quelque chose de suspect sur le réseau, nous ne nous contentons pas de le signaler, nous l'arrêtons. Et ensuite, on discute avec le propriétaire de l'appareil affecté des raisons pour lesquelles il a été déconnecté du réseau ».

Selon Adam Banks, l'efficacité de cette approche a été démontrée plus tard, lors d’une attaque impliquant Bad Rabbit, lancée via le site web de l'agence de presse russe Interfax : un ordinateur appartenant à un employé de Maersk en Russie a été touché. « Mais c’est le seul appareil de notre système d’information qui a été affecté. Et même si le scénario n'était pas identique à celui de NotPetya, il était assez proche pour que je pense que cette forme de protection automatisée soit extrêmement utile ».

Le troisième enseignement clé, pour Adam Banks, est que la sauvegarde en ligne classique ne constitue plus une approche sûre. Les organisations ont dépensé des millions ces dernières années pour passer de la sauvegarde sur bande à la sauvegarde en ligne, relève-t-il, « mais si elle est attachée à votre réseau ; vous devez aujourd'hui supposer qu'elle sera touchée ». Et qu’elle ne constitue dès lors pas une protection sûre.

Repenser la sauvegarde

Dans le monde physique, Adam Banks suggère de « déconnecter la sauvegarde en ligne sur la base d’une rotation hebdomadaire ». Las, en mode cloud, les choses n’apparaissent pas si simples : « s'il est relativement facile de se déconnecter, on a du mal à se reconnecter », affirme-t-il. Alors pour lui, « les fournisseurs de services cloud doivent prendre des mesures pour trouver un moyen de faire de la sauvegarde en ligne basée sur le cloud, une solution plus sûre ».

Et puis vient la question des correctifs. Pour Adam Banks, leur application est nécessaire, mais pas suffisante : « la première question que les gens se posent habituellement à propos de NotPetya est de savoir si nous avions appliqué les correctifs. Nous les avions appliqués de manière appropriée contre l'exploit Eternal Blue également utilisé dans WannaCry, mais cela ne nous a protégés que contre un seul vecteur de propagation de NotPetya. Celui-ci – qui a été distribué par une porte dérobée dans une mise à jour automatique du logiciel MeDoc utilisé pour soumettre les déclarations fiscales en Ukraine [qui était la véritable cible de NotPetya] – utilisait un certain nombre de méthodes différentes pour se propager, ce qui explique son efficacité ».

Ainsi, Adam Banks explique « la veille de l'arrivée de NotPetya, l'administrateur du domaine s'est connecté, a fait un inventaire complet de la machine et s'est déconnecté. Mais cela signifie que le premier identifiant volé à l'aide de la méthode pass the hash a fourni au maliciel les clés du royaume, lui permettant de se propager horizontalement et verticalement ». Et au final, « 55 000 postes clients et 7 000 serveurs ont été infectés en sept minutes ». Un laps de temps au bout duquel « il n’y avait quasiment plus rien à infecter ».

Les dommages causés à Maersk par NotPetya

Concrètement, NotPetya a gravement affecté les services DHCP et Active Directory de Maersk. Son bus de services d'entreprise (ESB) a été détruit et vCenter a été endommagé et rendu instable. Du côté de l’informatique des utilisateurs finaux, 49 000 ordinateurs portables ont été rendus inopérants, toutes les capacités d'impression ont été détruites et les fichiers partagés se sont trouvés indisponibles. Et il en est allé de même pour l’ensemble des 1 200 applications de Maersk. Un millier d’entre elles ont été détruites, de même que 3 500 des 6 200 serveurs de l’infrastructure.

Et l’on en vient au cinquième enseignement clé retiré par Adam Banks : la gestion des comptes à privilèges est extrêmement importante. Et de se souvenir : « quand je travaillais dans l'industrie des paiements, nous n'avions pas d'administrateurs. Personne dans l'entreprise n'avait de privilèges d'administrateur permanents ». Ces privilèges élevés étaient accordés temporairement sur demande : « si nous avions eu cela à Maersk au moment de l'attaque de NotPetya, je pense que nous aurions eu 400-500 machines touchées et non pas 55 000. C'est donc devenu crucial. Nous n'avons plus de privilèges élevés dans de nombreux secteurs de l'entreprise et nous travaillons à les éliminer complètement ».

Ajuster les plans de continuité

NotPetya s’est rapidement présenté comme un défi de taille pour les plans de continuité et de reprise d’activité (PCA/PRA). Et c’est là le sixième enseignement clé qu’en retire Adam Banks : les organisations doivent comprendre que, pour les industries lourdes, les plans de continuité d'activité et les plans de gestion de crise peuvent devoir être particulièrement larges.

Car selon lui, « ces plans seront probablement axés sur les actifs, comme c'était le cas pour Maersk. Mais nous avons changé cela maintenant. La première question dans le plan de gestion de crise est de savoir si l'incident en question est centré sur les actifs ou global, ce qui signifiait auparavant ‘grand’, mais qui signifie maintenant ‘mondial’. La réponse à cette question détermine si nous utilisons un modèle de type services financiers, où l’on implique l’exécutif, avec des échanges téléphoniques toutes les quatre heures, 24 heures sur 24, 7 jours sur 7, pour prendre des décisions affectant l'entreprise dans son ensemble, ou si l’on utilise un modèle centré sur les actifs, auquel cas vous le soumettez au seul cadre responsable de ces actifs. Si nous avions adopté cette approche avant NotPetya, notre réponse aurait été beaucoup plus fluide ».

Mais cela ne s’arrête pas là. Pour Adam Banks, les plans de continuité de l’activité doivent faire la distinction entre continuité de service et reprise de service : « cela oblige ceux qui se penchent sur la continuité des opérations à ne supposer aucune capacité informatique. Avant NotPetya, les deux questions ne faisaient qu’une et aucune disposition n'a été prise quant aux mesures à prendre en cas d'absence totale de ressources IT. Nous n'avions pas de plan pour la destruction globale de toutes nos capacités informatiques ».

Anticiper une indisponibilité totale de l’IT

Dissocier continuité et restauration de service permet dès lors de « commencer par dire qu'il n'y a pas d’IT disponible lorsque l’on s’attèle à la reprise de service. Cela donne une bien meilleure version du plan ».

Le dernier enseignement que retire Adam Banks de l’épisode touche à la valeur de l'ouverture et de la transparence : « la décision d'être ouvert et honnête au sujet de ce qui se passait a été extrêmement bénéfique. Malgré les difficultés, 95 % de nos conteneurs ont atteint leur destination à temps parce que nous avons pu transporter des marchandises dans les ports pendant quatre semaines sans aucun dédouanement ».

Et ce qui a permis au transporteur de profiter d’une telle souplesse exceptionnelle, outre le fait « d’être une marque de confiance », c’est que « les autorités portuaires savaient pourquoi nous ne pouvions pas [suivre les procédures] et qu'elles ont convenu que nous pourrions déclarer rétroactivement tout ce que nous avions transporté. Si nous n'avions pas été ouverts au sujet [de l’incident], nous n'aurions jamais eu ce niveau de coopération ».