être certifié ISO27001 ne veut pas dire être sécurisé

Beaucoup de personnes pensent qu'un service certifié ISO27001 est sécurisé. Selon moi, ils sont dans le faux. Ceci dit, il ne faut pas leur jeter la pierre car comprendre l'esprit de cette certification n'est pas aussi immédiat que cela.

Explications et décryptage avec quelques exemples histoire de comprendre ce qu'être certifié veut dire et ce qu'il convient d'éviter de croire.

un système de management de la sécurité

La norme ISO27001 a pour objectif de mettre en place un SMSI (Système de Management de la Sécurité du Système d'information). Ce qu'il faut retenir c'est que cela consiste à mettre en place une organisation (des personnes et des processus) pour gérer la sécurité d'un système informatique.

Cette "organisation sécurité" a pour mission de maintenir les contrôles de sécurité (qu'ils soient techniques ou organisationnels) et de faire en sorte de les améliorer dans le temps.

dire ce que l'on fait et faire ce que l'on dit

Un point important avec l'ISO27001 est qu'il est nécessaire de définir de quelle façon la sécurité du système d'information va être gérée. Cela implique donc un travail de rédaction non négligeable qui est très souvent "zappé" pour des raisons de coûts et de priorités.

Le point fondamental c'est qu'une procédure (ou un processus) doit être suivie. On fait ce que l'on dit et on dit ce que l'on fait. Si le processus est inadapté ou incorrect, il peut (doit) être mis à jour et le nouveau processus devra ensuite être suivi. On retrouve ici la belle roue de Deming (PDCA - Plan, Do, Check et Act) qui guide tous le modèle sous-jacent de la certification ISO27001.

La norme ISO27001 ne vérifie donc pas l'efficacité des contrôles eux-mêmes mais si leur mise en oeuvre est effectivement conforme à ce qui a été préalablement défini.

pas de processus, pas de vérification

Là où ça coince, c'est que si il n'y a pas de processus de défini pour une action donnée, et bien cela passera surement inaperçu pour l'auditeur car celui-ci vérifie si les processus sont bien suivis.

Exemple : si un processus existe pour que les impacts sécurité de tous les changements (RFC - Request For Change) soumis en CAB (Change Advisory Board) soient analysés, alors un changement effectué sans RFC officielle passera sous le radar... (pour les RFC et CAB, voir processus ITIL)

Et oui, tout ce qu'il faut c'est que ce changement "non officiel selon les processus" ne soit pas à l'origine d'un incident de sécurité (qui lui est géré par un processus déclaré et suivi). Si lors de l'analyse post-mortem de l'incident ce change "à la sauvage" est identifié alors une action corrective devra être lancée. C'est le bon coté du modèle PDCA.

les incidents de sécurité sont les bienvenus

Si vous m'avez bien suivi, le processus c'est le processus et il doit être suivi. Il n'y a donc aucun problème pour que des incidents de sécurité surviennent : l'important réside dans le fait qu'ils soient gérés selon les processus.

Certains penseront "ah bon...?". Oui. Après, je vous rassure c'est bien mieux que dans certaines sociétés ou organisation ou il n'y a pas de processus de gestion des incidents (tout est fait selon le processus "la rache"). :-)

le "trou-noir" entre les audits annuels

Pour être certifié ISO27001 il faut passer un audit initial. Une fois le précieux sésame obtenu, les audits de contrôle annuels vont permettre à l'auditeur de vérifier que le système fonctionne correctement.

De façon assez classique c'est le "rush" 6 mois avant la date pour mettre les choses à peu près propres pour montrer à l'auditeur que le système fonctionne (c'est-à-dire que les processus sont suivis et que l'on a lancé/avancé sur son plan d'actions d'amélioration).

Entre deux audits, il peut donc se passer plein de choses plus ou moins reluisantes. Tout va dépendre de l'implication, de l'expertise et du professionalisme des équipes en charge du SMSI.

ISO27001 est-elle bonne à jeter ?

Non. Clairement ISO27001 est une bonne norme. Avoir un système d'information certifié selon cette norme donne un niveau d'assurance que la sécurité est gérée de façon structurée et organisée dans une approche long terme.

Un système certifié successivement de façon continue sur plusieurs années (genre 4 ou 5 ans) sera clairement plus mature qu'un système venant juste d'obtenir sa certification.

Dans tous les cas, il est important de bien comprendre le périmètre (c'est-à-dire la "portée") qui a été certifié afin de ne pas se faire "avoir" par des personnes un peu trop marketing.

quoi d'autre dans le pipe pour "dépasser les limites" ?

Coté Cloud Computing, l'approche "certification continue" est un sujet particulièrement actif. Pour en savoir plus, je vous suggère d'aller regarder les initiatives CloudAudit et CloudTrust Protocol (CTP) proposées par la Cloud Security Alliance.

Pour ce qui concerne les briques techniques, c'est du coté du NIST qu'il faut aller voir avec leur protocole SCAP (Security Content Automation Protocol). SCAP est un "dialecte" XML conçu avec l'objectif de rendre automatisable la collecte d'informations sur des contrôles de sécurité.

Jean-François

crédit photo : © S.John - Fotolia.com