« De la précision dans les termes, de la précision » disait mon professeur à l’école de journalisme. Et il avait parfaitement raison : on ne peut comprendre, et encore moins transmettre, une idée si celle-ci est désignée par une multitude de termes différents utilisés sans logique apparente.

C’est pourtant ce que l’on observe régulièrement dans le petit monde de la sécurité dès que l’on entend parler d’événement, d’incident ou encore de problème. Tous ces termes désignent-ils la même réalité ? La question n’est pas sans importance : selon ce qui est désigné, la réponse ou l’équipe concernée seront probablement très différentes.

C’est là qu’un membre de SecuritVibes, intervenant dans une discussion au sujet d’ITIL, nous offre un scénario particulièrement clair :

• Evénement : on remonte une alerte de l’antivirus
• Incident : c’est un fichier infecté sur le poste de travail. Mais celui-ci est géré par les équipes bureautique : pourquoi faudrait-il alors l’estampiller ‘incident de sécurité‘ ?
• Problème : c’est arrivé parce que l’utilisateur a utilisé une clé usb personnelle sur son poste de travail. Ce n’est pas un problème purement IT mais plutôt un problème à gérer au niveau du SMSI : c’est donc un problème de sécurité

On le voit, faire clairement la distinction entre ces termes est une première étape essentielle à la bonne organisation des processus de correction. Cela permet notamment de déterminer la ou les entités responsables des opérations correctives.

Dans l’exemple ci-dessus on constate que l’événement est collecté par une entité sans apriori sur sa qualité ou sa destination. Il doit ensuite être routé : l’information corrective (incident) concerne alors une équipe d’exploitation tandis que la cause (problème) est plutôt du ressort d’une équipe sécurité organisationnelle.

Ce n’est bien entendu pas un hasard si cet exemple survient dans le cadre d’une discussion consacrée au positionnement de la sécurité vis-à-vis d’ITIL : la tentation est grande (ou l’obligation réglementaire est forte…) d’intégrer les incidents de sécurité à un processus ITIL, forcément plus transverse. Mais  la sécurité est têtue et ses spécificités viennent semble-t-il parfois gêner aux entournures (l’on pense par exemple au besoin de collecte des preuves post-incident).

Au fil de la même discussion un autre membre confie avoir préféré le standard ISO 27035 consacré au cycle de vie de l’incident de sécurité.  Mais cela restreint alors la sécurité à son silo habituel tandis qu’ITIL offre une solution plus rationnelle.

Une approche hybride est-elle alors possible ? Voire même souhaitable ? C’est en tout cas l’avis d’un participant à notre discussion, pour qui une notification aux RSI et RSSI et l’implication éventuelle de la cellule de gestion de crise (en case d’impact majeur sur la confidentialité ou la disponibilité de l’information) est essentielle, bien que hors du cadre ITIL.

Et vous, comment appréhendez-vous les incidents, problèmes et événements de sécurité ? Comment assignez-vous les mesures correctives ? Etes-vous plutôt ITIL ou ISO 27035 ? Venez partager votre expertise avec la communauté !