Propriétaire de rien, responsable de tout (enfin, presque)

Allons vérifier plutôt que de croire la parole de qui que ce soit, moi y compris : le paragraphe 6.1.2.c dit très exactement « identifie les risques de sécurité de l'information »… et c'est tout. L'EBIOS n'est jamais mentionnée dans les exigences. La 27005 n'apparaît que dans la liste des normes et en bibliographie. Les scénarios de menaces et de vulnérabilités, jamais un mot. Ce que vend une bonne partie de l'écosystème conseil comme un passage obligé n'est, sur le plan strictement normatif, qu'une option parmi d'autres.

En revanche, la norme exige beaucoup sur la mécanique : que la méthode produise, répétition après répétition, des résultats cohérents, valides et comparables (6.1.2.b) ; qu'elle s'appuie sur des échelles de vraisemblance et d'impact et des critères d'acceptation ; qu'elle reste elle-même minimaliste et révisée régulièrement ; que les risques résiduels remontent en revue de direction et soient formellement acceptés par ceux qui en portent la charge. Dit autrement, l'appréciation des risques, c'est à peu près 1 % de contenu sur l'évaluation proprement dite, et 99 % de dispositif de management : le PLAN influe sur le DO, le DO est contrôlé par le CHECK, le CHECK remonte les anomalies à l'ACT, qui reboucle sur le PLAN. Un établissement qui aligne trente jours d'ateliers avec un tableur à trente-six onglets mais oublie de relier ce travail à un plan de traitement suivi en revue de direction n'a rien produit d'utile, juste vidé sa ligne budgétaire pendant que le consultant se prélasse en réutilisant jusqu'à l'indigestion les mêmes modèles d'un client à l'autre.

La même maladie frappe la mesure A.8.12 de l'annexe A, consacrée à la prévention de la fuite de données, introduite dans la version 2022 de la norme et qui génère depuis lors le plus gros contingent de non-conformités mineures en audit de certification. Le biais est toujours le même : du technosolutionnisme pur jus. On part chercher un outil de DLP avant même de s'être demandé si la méthode existait. Ce que demande réellement la mesure tient pourtant en trois lignes : chaque propriétaire de processus identifie si ses actifs informationnels doivent y répondre ; il apporte une réponse, même minimaliste ; cette réponse est vérifiée dans le processus de surveillance du § 9.1. Les trous dans la raquette deviennent des risques résiduels tracés dans un DSA, les impossibilités de traitement remontent en revue de direction. Aucun outil dans cette liste : une méthode, oui ; un outil, éventuellement, en aval, si le contexte le justifie. Et, très sincèrement, dans 99 % des cas, un simple tableur open source fait le boulot.

Il y a pire, ou plus subtil selon l'humeur : le paragraphe 6.1.1 sur les risques et opportunités du SMSI lui-même, qu'on confond allègrement avec l'appréciation des risques des actifs. Ce ne sont pourtant pas les mêmes objets. Et ce sont, très exactement, les seuls risques dont le RSSI soit vraiment propriétaire. Pas les serveurs, pas les applications métier, pas les données du DPI : cela relève des propriétaires de processus, la DSI, le métier, chacun chez soi. Le RSSI n'est propriétaire que d'une chose : le SMSI en tant que tel. C'est son seul actif propre, celui qu'aucun processus ne réclamera jamais à sa place, et qu'il est seul à devoir faire vivre sur le même cycle PDCA que tous les autres.

Voilà qui remet les choses à leur juste place. On passe des années à batailler pour faire reconnaître au comité de direction que le RSSI n'est propriétaire de rien, qu'il ne fait que conseiller et alerter, que la responsabilité reste entièrement du côté des propriétaires de traitement. Tout cela est exact, et il faut continuer à le marteler. Mais il ne faudrait pas oublier, à force de répéter qu'on n'est propriétaire de rien, qu'on l'est bel et bien de quelque chose : de ce machin bureaucratique et ingrat qu'est le SMSI. Traitez-le comme n'importe quel autre risque du système : listez, justifiez, mettez des actions en face de chaque ligne (une opportunité sans action n'existe pas davantage qu'un risque sans action), faites valider en revue de direction. Et si vous ne voyez toujours pas le rapport entre ces quatre points, il n'est peut-être pas trop tard pour vous reconvertir dans la plomberie.

Quant au consultant et à ses trente jours d'EBIOS, il repassera. J'ai un tableur à trente-six onglets à finir de vider.