ISO 27001 : introduction au concept de classe de risques

Une organisation qui s’engage dans une démarche 27001, certifiante ou pas, va donc dérouler une appréciation des risques (AR). L’AR c’est comme les pattes d’eph : cela suit la mode. Il y a 20 piges les experts SSI ne juraient que par MEHARI. Jusqu’à il y a 5 ans leurs successeurs ne juraient que par EBIOS – même les pouvoirs publics incitaient fortement à l’adoption de cette norme, débordant de leur rôle. Et de nos jours, après avoir constaté les échecs et la lourdeur d’EBIOS, les consultants (et les pouvoirs publics leur emboitant le pas) ne jurent maintenant que par EBIOS RM, supposé être plus light qu’EBIOS. Ça laisse tout de même rêveur, pour l’avoir pratiqué il a fallu 10 jours de consulting pour me sortir une liste totalement impossible à interpréter alors que la bonne méthode dite du doigt mouillé du paysan m’a sorti un meilleur résultat en 2h à peine, et encore sans se presser. A bon entendeur. Mais bon voilà ma liste de 10 risques, qui avec la DDA, les mesures, les contrôles et le plan de traitement, constituent l’ossature de ma démarche. Mais ce n’est pas la seule classe de risques dont il faut tenir compte.

Avec la pratique, certains chapitres de la norme sont volontaire vagues – il a bien fallu écrire un truc assez générique pour couvrir tout le champs des possibles – et doivent être interpréter, ou « localisés », au contexte de l’organisation. Les chapitres A8 (gestion des actifs) et A14 (développements internes) sont particulièrement retords de ce point de vue. Trop en faire ou pas assez, se créer une charge de gestion documentaire et de contrôle, ou risquer la non-conformité, telles sont les dilemmes du RSSI et des équipes de conformité interne. Une solution consiste à utiliser l’esprit de la norme et interpréter les mesures selon les risques courus en internes. Par exemple, si aucun développement spécifiques de progiciel métier n’est réalisé mais que seuls des scripts sont écrits pour faire tourner l’exploitation et ne sont maintenus que par une poignée d’individus, rien n’empêche de restreindre les mesures de recensement et de protection du code à la plus simple expression. Mais encore faut-il avoir tracé la décision qui permet de justifier cela, et donc le risque auquel cette décision se rapporte. On est là cependant très clairement dans un risque qui est d’une autre nature que celui décrit plus haut et qui : le premier sert d’ossature à la démarche de conformité, est souvent un risque technique concret (par exemple cryptolocker) alors que le second se réfère plutôt à un fonctionnement organisationnel au sein du système de management lui-même, plutôt dans ses aspects détails.

Il existe enfin une troisième classe de risques, qui déborde largement le cadre de l’ISO : il s’agit de risques systémiques et / ou managériaux sur le pilotage de la DSI elle-même. Par exemple, le risque de non-alignement avec la stratégie d’entreprise, ou le risque de perte de légitimité face à son rôle de MOA des flux dématérialisés face aux métiers, ou encore le risque d’explosion de l’entropie du SI. J’ai listé à titre personnel environ 12 risques qui relèvent de cette troisième classe, et qui ne sont adressés par aucune méthode ou norme. (bon dans les fait, une partie sera probablement pris en compte dans la mise à jour 2022 de l’ISO 27002, et une partie est adressée par COBIT, mais on sort du cadre de l’article).

Bien entendu, certains des risques de ces 3 classes peuvent être à la marge recatégorisés, mais en tout état de cause il est impossible de faire tenir tout un système de management avec 1 seule AR. Les 3 classes ou familles susnommées sont bien entendu discutables, chaque RSSI pourra découper différemment, mais chaque RSSI va devoir à terme se poser la question de l’exhaustivité des risques qu’il adresse et de leur mode de classement. Cela est d’ailleurs cohérent avec l’existence de risques issus des EIVP (RGPD) des des autres normes en vigueur (NIS).

L'auteur 

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé. 

À lire aussi : APSSIS – AFIB : un référentiel de sécurité pour les dispositifs médicaux connectés