Nous n’exploitons pas de centre opérationnel de sécurité, et nous ne vendons pas de supervision. Ce que nous faisons, du côté de l’évaluateur et de l’ancien exploitant, c’est aider une organisation à spécifier ce qu’elle doit surveiller, qui doit réagir, et ce que disent les procédures. Voici la fois où nous l’avons fait de l’intérieur, comme RSSI de transition d’un groupe, et ce que cela nous a appris sur les trois premiers mois.
Le point de départ
Un groupe industriel de plus de vingt usines recevait ses alertes de sécurité par e-mail. L’antivirus était la seule source. Une petite équipe centrale, dans un seul pays, lisait la boîte aux heures de bureau. Une alerte levée un vendredi à dix-huit heures était lue le lundi. Trois vagues d’intrusion en six mois avaient rendu l’écart évident.
Ce qui a été spécifié, et dans quel ordre
Les sources d’abord, les outils ensuite. Deux sources qui existaient déjà et que personne ne lisait : la console antivirus et les événements de sécurité des contrôleurs de domaine, collectés par une plateforme de journaux que le groupe exploitait déjà. Plus tard, une plateforme de vulnérabilités et une détection sur les postes ont été ajoutées. Rien n’a été acheté pour la cellule elle-même.
Un seul canal, poussé, pas tiré. Les alertes des deux sources sont allées dans un canal de discussion partagé, pas dans une boîte mail. Un canal se lit ; une boîte mail se classe.
Quatre priorités et un guide pour chacune. P1 à P4, avec un guide d’une page par priorité disant qui est appelé, dans quel délai, et quelles sont les trois premières actions. Les guides ont été écrits par ceux qui allaient les dérouler, et corrigés après le premier événement réel.
Suivre le soleil avec les gens que l’on a. Le groupe avait des informaticiens sur trois continents. Le tri de premier niveau tournait entre eux par fuseau horaire, pour que le canal ait toujours quelqu’un d’éveillé qui le lise. L’équipe des Amériques s’est révélée la plus active, ce que personne n’avait prévu.
Un rapport hebdomadaire. Une page : les événements par priorité, par site, par source, et la tendance. C’est la tendance que le comité exécutif lisait.
Ce que cela a produit
À la fin de la première année, la cellule traitait une cinquantaine d’événements par mois. Quatre sur cent étaient des P1. Une vingtaine par mois nécessitaient un technicien qualifié. Presque rien ne restait sans traitement. Quand l’attaque par ransomware est arrivée, des centaines d’alertes ont frappé le canal en quelques heures, et la première réaction, la décision de couper les liens, a été prise en moins de quatre heures parce que des gens étaient éveillés et lisaient.
Ce qu’elle ne pouvait pas faire
C’était une cellule de premier niveau, et il importe de dire ce que cela veut dire. Il n’y avait pas d’astreinte de second niveau, pas de niveaux de service de second niveau, et peu de sources de données. Elle pouvait remarquer et réagir. Elle ne pouvait pas investiguer en profondeur, et elle ne pouvait pas voir ce que ses deux sources ne montraient pas. L’attaque qu’elle a remarquée était une attaque que les sources couvraient par chance. L’étape suivante, spécifiée mais pas encore construite quand l’attaque est venue, était une vraie plateforme d’événements et une détection sur les postes, avec des procédures de second niveau, avant toute décision sur une expertise externe.
Ce que l’on fait de travers
On suppose qu’une détection permanente signifie un service externalisé coûteux dès le premier jour. Les trois premiers mois consistent à répartir le tri entre les gens que l’on emploie déjà et à écrire qui fait quoi.
On suppose l’inverse : qu’une cellule de premier niveau bon marché suffit. Elle achète du temps de réaction. Elle n’achète ni l’investigation, ni la couverture de ce que l’on ne collecte pas.
On achète la plateforme avant les guides. Une plateforme dont personne n’est chargé des alertes est une boîte mail avec un tableau de bord.
Une plateforme dont personne n’est chargé des alertes est une boîte mail avec un tableau de bord.