Petite digression un peu taquine sur l’art de rechercher la root cause

L’expression « analyse post mortem des dysfonctionnements organisationnels » étant la version « rive droite » de : c’est qui qui a merdé ?

Se planter, cela arrive à tout le monde : l’erreur est humaine. Mais se planter quand on connaissait le niveau de risque, ou pire, quand on s’était déjà planté au même endroit trois mois plus tôt, ou pire encore, quand on n’avait même pas évalué les risques, cela relève de l’incompétence.

Analyser la root cause est donc un travail indispensable qui échoit au RSSI. Si vous pouvez prendre ce moyen de transport parmi les plus sûrs du monde qu’est l’avion de ligne, c’est parce que des générations de pilotes et d’analystes ont fait en sorte que les mêmes causes ne se reproduisent jamais. Dans l’aérien, on dit que les procédures ont été écrites avec le sang des pilotes qui sont morts.

Prenons un exemple hyper courant : une règle de filtrage en any-to-any a été oubliée dans le firewall et a généré une attaque consécutive à un scan de ports. Et ne venez pas me pipauter en affirmant que cela ne vous est jamais arrivé, que vous ne l’avez jamais vu, et blablabla et blablabla.

Pendant l’incident, l’analyse, la remédiation, l’identification et la suppression de la règle, le RSSI ne sert pas à grand-chose. C’est après que la fête commence.

Les règles du FW sont un asset, un actif : elles appartiennent à quel processus, et qui est propriétaire dudit processus ? Il y a des chances que ce soit l’ingénieur réseau, mais avant de lui couper la tête, attendons un peu d’aller au bout de l’analyse.

Oui, parce que si, en première ligne, c’est l’ingé réseau, il avait peut-être parfaitement connaissance de la présence de cette règle en anomalie. Peut-être même que ses contrôles internes à son processus, je vous laisse chercher les mesures de l’annexe A, c’est dans le chapitre 8, l’avaient remontée.

Bien entendu, si contrôle il y a eu avec remontée d’anomalie, comme je suis méfiant, je demande à voir le rapport horodaté dudit contrôle. Avec, au passage, la documentation du contrôle : le document qui permet à un non-sachant de le réaliser en l’absence du sachant, du moins jusqu’à un certain stade.

Petit aparté : le processus de contrôle est un PDCA comme les autres. On documente, plan ; on réalise, do ; on vérifie que le corpus de contrôle est OK, check.

Si, évidemment, le problème est côté réseau, fin du sujet. Pour les besoins de l’exercice, on continue un cran plus loin.

Après, l’ingé réseau ne paramètre pas des règles pour le plaisir. Si la règle est là, soit elle provient d’un besoin purement interne au processus, genre bon fonctionnement de la DMZ, mais ce n’est pas le plus fréquent, soit d’un besoin issu d’un projet, technique ou AMOA.

Si l’ingé réseau a fait son boulot, la règle est documentée et on sait à quel besoin, à quel processus, elle répond. Et hop, on saute de processus comme de mouton pour arriver au demandeur initial qui a généré cette règle any-to-any.

Processus demandeur : pourquoi la règle a-t-elle été demandée ? Ça sent le test, genre la période avant recette d’un logiciel ou d’une connexion quelconque avec un partenaire externe ; genre le truc qu’on se disait qu’on supprimerait une fois passé en production ; genre on n’avait pas la matrice des flux, mais promis, promis, promis, le presta allait la donner dans la semaine, le mois, le siècle. Enfin, vous voyez le genre.

Et le genre, c’est que la règle est restée. Et que l’on s’est fait poutrer.

On passe du processus réseau au processus AMOA, dans l’exemple, et là, le RSSI se retrouve à demander des comptes à l’ingé applicatif. Et on redéroule les mêmes questions : processus, asset, référentiels, contrôles, etc.

On peut encore jouer à saute-mouton, dans l’exemple ci-dessus, c’est peu probable. On finira toujours par retomber sur le processus responsable du dysfonctionnement. Quelquefois, d’ailleurs, il y en a deux, qui ne se sont pas parlé entre eux, mais ce n’est pas le plus courant.

L’approche processus / asset / référentiel / contrôle est absolument redoutable pour deux raisons : la première est que, dans 100 % des cas, on trouve ; la seconde est qu’il est difficile de faire passer des vessies informatiques pour des lanternes cyber au RSSI.

L’intérêt, entre autres, pour le RSSI, est soit de nettoyer les processus qui dysfonctionnent, pour être poli, soit de faire comprendre fermement à ceux qui s’ignorent comme processus qu’ils doivent entrer dans une véritable démarche processus. Et de passer en mode contrôle d’abord, puis en contrôle des contrôles ensuite.

Bon, cela va sans le dire, mais mieux en le disant : un PLAN et un DO sans un CHECK, cela revient à uriner dans un violoncelle. Dit autrement, un processus sans contrôle finit toujours par se caler sur la seconde loi de la thermodynamique, qui stipule que tous les systèmes tendent inévitablement vers la chienlit.

Et il en va de même du CHECK sans ACT. Mais c’est un autre sujet, plus complexe qu’il n’y paraît.

De rien.