– … Allo, ici Thierry Autret [le RSSI]. Dites-moi pourquoi ne m’avez-vous pas prévenu de l’arrêt du service de messagerie ? Je viens de le constater par hasard.

– [la DSI] Oui mais bon, c’est juste un incident de production, enfin c’est ce qu’on pense… le serveur est tombé… c’est vrai que c’est inhabituel. On regarde et on te dit.

Tout RSSI a connu dans sa carrière cette situation concernant la messagerie ou un autre service applicatif. A la décharge de la DSI et de la production, il y a chaque jour des centaines d’incidents de production (voire des milliers selon la taille de l’entreprise) et si tous ceux-ci devaient être remontés au RSSI, il n’y survivrait pas.

Au sens large de la sécurité, selon les besoins du DICP (disponibilité, intégrité, confidentialité, preuve), une perte de disponibilité est un incident de sécurité. Au niveau de l’entreprise cet incident est plus souvent perçu comme une perte commerciale. Une fraude au Président est une atteinte à la sécurité de l’entreprise, bien que le RSSI ne soit en rien concerné.

Comment donc classifier un réel incident de sécurité qui doit être remonté immédiatement au RSSI ? De deux choses l’une, soit l’incident se remarque immédiatement comme un défacement de site, ou un cryptolocker auquel cas la caractérisation ne fait aucun doute. Soit ce sont les conséquences constatées, souvent a posteriori, qui vont qualifier un incident d’incident de sécurité.

L’analyse d’un incident doit être systématisée selon des règles qui permettent rapidement de classifier l’incident de type « production », « sécurité » ou « indéterminé » donc potentiellement de sécurité. Une méthode bien connue comme le 8D pour identifier les causes et les conséquences permet d’atteindre ce but. La réponse aux questions du QQOQCCP (Qui, Quoi, Où, Quand, Comment, Combien et Pourquoi) si elles sont orientées sur l’atteinte aux services et aux données peut également y contribuer.

L’important est que la DSI/production systématise et procédure cette analyse, si possible avec l’utilisation d’un outil de gestion des incidents. Dans les grandes entreprises, une structure de CERT (computer emergency team) ou de CSIRT (Computer Security Incident Response Team) peut être la solution. Une chaine d’analystes et de décisionnaires sont nécessaires dans ce processus et en premier lieu l’utilisateur qui peut être le premier à identifier des événements pouvant être considérés comme des signaux faibles. Le service support ou helpdesk ne doit pas minimiser ces signalements qui peuvent être les précurseurs d’incidents de sécurité. A ce stade, une équipe pouvant inclure le RSSI doit décider comment répondre aux incidents de sécurité. Soit des solutions existent et peuvent être mises en œuvre, soit la situation nécessite le déclenchement d’une cellule de crise.

Beaucoup de documentation existe sur la gestion des incidents de sécurité en elle-même et nous n’y reviendrons pas ici. Nous pouvons néanmoins citer les travaux normatifs de l’ISO et en particulier la norme 27035 – 2016, qui décrit le processus de gestion des incidents de sécurité et le cycle de vie associé (détection, qualification, escalade, recueil des preuves, traitement, mise en œuvre des mesures de sécurité, etc.).

N’oublions pas que la notification des incidents de sécurité est rendue obligatoire par de nombreuses réglementations comme ePrivacy, eIDAS, NIS et bien sûr le RGPD si l’incident touche des données à caractère personne, sans compter d’autres réglementations sectorielles). Il est donc très important « par temps calme » c’est-à-dire lorsque tout va bien d’identifier le processus d’une éventuelle notification d’incident. Quels sont les acteurs de l’entreprise impliqués dans ce processus, au-delà des gens de l’IT comme le service juridique, le service communication et bien sûr la Direction Générale. Selon l’article 33 du RGPD l’entreprise ne dispose que de 72 heures au plus pour notifier l’incident à l’autorité de contrôle. L’article de la CNIL référencé ci-dessous est une bonne introduction à cette démarche.

Quelques conseils utiles pour le RSSI :

• Sensibiliser les équipes de production sur l’identification des incidents de sécurité et sur le processus à suivre ;
• Anticiper le processus et les acteurs pour une éventuelle notification à l’autorité de contrôle ;
• Capitaliser sur des outils de sécurité tels que des SOC ou des Cert, internes ou externes ;

Liens utiles :

• Qualys Magazine : Incidents de sécurité : qui sont les responders ?
• Norme ISO/CEI 27035 : Gestion des incidents de sécurité de l’information
• CNIL : Guide de la sécurité des données personnelles