Regonfler un pneu ou s’attaquer à la root cause : vision 27001 de la mise sous contrainte

C’est crétin, bien entendu, pour une raison simple : correction du symptôme et non pas de la cause. Quand on a mal au crâne, même si le paracétamol est un bon remède, le mal de crâne n’est certainement pas dû à un déficit de paracétamol dans l’organisme, idem.

On retrouve ce paradigme de la recherche de la cause initiale – root cause pour les intimes – dans ITIL, qui fait la distinction entre l’incident (le truc qui se passe sous nos yeux) et le problème (l’origine de l’incident), incitant bien entendu d’abord à régler l’incident, mais à s’attaquer immédiatement après au problème. Le LEAN Management va plus loin en affirmant que la résolution de l’incident doit avoir pour objectif essentiel la protection du client (au sens de client du processus) : d’abord on évite à son « client » de se retrouver dans la mouise, quitte à tirer des bouts de ficelle dans tous les sens, et après – seulement après – on s’attaque à la root cause.

Sauf que la 27001 va beaucoup plus loin[1], la 9001 aussi du reste (normal, le chapitre 10 est très semblable). On trouve en effet :

– la recherche de la root cause et la correction des conséquences immédiates, dès le début du 10.2, normal, comme ITIL et LEAN ;
– point intéressant, la recherche de la même cause à d’autres endroits du SMSI, histoire de ne pas se faire piéger une seconde fois ;
– la documentation de tout cela.

Mais ce qui est intéressant, c’est que la 27001 ne s’arrête pas au seul binôme conséquence/cause de la partie technique, mais remonte dans le système de management. Je suis justement tombé récemment sur un exemple parfait pour illustrer le propos : un malware récupéré sur un PC d’entreprise (ça, c’est la conséquence technique).

Après analyse, la root cause est double : l’utilisateur a cliqué sur un lien publicitaire rogue (ça arrive, root cause sensibilisation), mais surtout le bloqueur de pub avait été supprimé suite à la suite d’une mise à jour de la version du navigateur. La seconde root cause est donc une mauvaise maîtrise de l’asset « parc PC » et en particulier des navigateurs (maîtrise des configurations et des changements).

L’équation, à ce stade est : incident/correction des conséquences/correction root cause : on éradique le malware, on réinstalle un bloqueur de pub et l’on forme ceux qui ne l’ont pas encore été.

Si l’on s’arrêtait au volet strictement technique de l’incident, cela n’irait pas plus loin. Sauf que la correction de la root cause technique, dans ce cas, s’apparente, vu du système de management, au regonflement d’un pneu à plat.

En effet : un asset est la propriété d’un processus, qui est lui-même propriétaire des risques qui pèsent sur ces assets, donc des mesures à prendre pour réduire ces risques (ici, le bloqueur de pub et la sensibilisation utilisateur qui dans l’exemple adressent deux assets différents, donc deux processus différents), et surtout des contrôles pour vérifier que les mesures ont bien été déroulées. Dans le cas présent, la root cause côté SMSI, c’est l’absence de mesures mises en œuvre et surtout l’absence de contrôle de la bonne application de ces mesures.

L’équation devient donc : incident/correction des conséquences/correction root cause/révisions des mesures de l’asset concerné/mise en place de contrôles sur l’asset. Dit autrement, sans contrôle régulier de la présence d’un bloqueur de pub sur les PC du parc ni sensibilisation des utilisateurs, on n’a fait que regonfler le pneu.

Et si vous pensez que l’histoire est terminée, que nenni : on retrouve à deux endroits de la 27001 (§ 10.2d et § 9.1a) le couteau suisse ultime de l’auditeur, donc du RSSI, soit l’obligation de vérifier l’efficacité des mesures. Qu’est-ce qui prouve que le bloqueur de pub choisi a bien été déployé sur tous les PC mais surtout est efficace ? Qu’est-ce qui prouve que la sensibilisation des utilisateurs a balayé tout le personnel (y compris les stagiaires, les CDD, les remplacements, etc.) mais surtout est efficace ?

L’équation est donc, au final : incident/correction des conséquences/correction root cause/révision des mesures de l’asset concerné/mise en place de contrôles sur l’asset/indicateur de performance des mesures et des contrôles. Bon, pour être exact, il y a quelques subtilités additionnelles quoique sans intérêt pour cet article, mais c’est cela la différence entre « sécuriser » et « mettre sous contrainte ».

Et cet exemple permet aussi d’expliquer la différence fondamentale entre un expert cyber, qui s’attaque à la root cause technique (enfin, en principe), et un RSSI qui remonte à la root cause managériale (enfin, en principe).

PS : Si vous pensez que tout cela est lourdingue, je ferai à l’occasion un autre article pour expliquer que non en fait, et que ceux qui vous expliquent que c’est lourd sont ceux qui ne l’ont pas compris, ou ceux qui cherchent à vous fourguer des j.h (et souvent ce sont les mêmes).