Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

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

Être certifié ISO27001 ne veut pas dire être sécurisé
2012-06-052013-04-10sécurité organisationnelle et humainefr
Beaucoup de personnes pensent qu'un service certifié ISO27001 est sécurisé. Selon moi, ils sont dans le faux. Ceci dit, il ne faut 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...
Publié le 5 Juin 2012 par Jean-François Audenard dans sécurité organisationnelle et humaine
ê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

11 Commentaires

  • 23 Décembre 2014
    2014-12-23
    par
    Johnc500

    Fantastic website. A lot of useful information here. I'm sending it to a few pals ans also sharing in delicious. And naturally, thank you in your sweat! gegdkdcdageg

  • 23 Décembre 2014
    2014-12-23
    par
    Johnd783

    Good writeup, I am normal visitor of ones blog, maintain up the excellent operate, and It's going to be a regular visitor for a lengthy time. ekecbfegfkdg

  • 8 Août 2014
    2014-12-23
    par
    Thierry MOTSCH
    Bonjour Jean - François,
    Vous avez bien raison de préciser la différence entre la certification ISO 27001 et la sécurisation. En ce qui me concerne, je préconise d'adjoindre aux exigences de certification, une solide méthode de management des risques de sécurité comme EBIOS, MEHARI voir OCTAVE. Je recommanderais EBIOS - Expression des Besoins et Identification des Objectifs de Sécurité - en particulier parce que la CNIL la recommande dans son guide de sécurité. En effet, la sécurité est défini par ISO 27001 comme "l’absence de risque non négligeable". Le guide 73: 2009 définit le risque comme "l'effet de l'incertitude sur l'atteinte des objectifs". En conséquence, le couple EBIOS, ISO 27001 fait bon ménage pour un management dynamique de la sécurité de l'information selon un système en amélioration continue permanente muni d'une robuste gestion de son portefeuille de risques résiduels.
    Cordialement,
    Thierry MOTSCH - consultant
  • 23 Septembre 2012
    2014-12-23
    par
    Samsam
    Bonjour,

    Merci pour ce site qui est très enrichissant, j'ai une question a vous poser si vous permettez. Si on veut être certifié iso 27001 on doit bien sur suivre la norme, dans la nome on précise qu'il faut rédiger des procédures, est ce que la norme iso 27001 a un modèle à suivre pour rédiger une procédure ?
    Merci à vous.
  • 7 Juillet 2012
    2014-12-23
    par
    Totalement en phase. Cet article est évident pour les personnes qui savent de quoi il s'agit lorsque l'on parle de certifications comme l'ISO27001.
    Par contre, certaines personnes le croient dur comme fer. La différence entre ceux qui savent de quoi elles parlent et les autres qui croient comprendre. Au premiers d'expliquer ce qui coïnce.
    Jeff.

Pages

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage