I. Introduction

« As descri­bed above, having regard to the impact of the Covid-19 pande­mic (On Marriott and more gene­rally), and consis­tently with the Commissioner’s publi­shed guidance, [T]he final penalty payable will there­fore be redu­ced to £18.4 million ». Tels sont les termes dont le conseil d’administration du groupe Mariott a pris connais­sance le 30 octobre dernier en tour­nant sans doute avec anxiété les pages de la déci­sion rendue par l’ICO, après avoir subi un inci­dent en matière de sécu­rité ayant exposé envi­ron 339 millions de fichiers de clients. Célian Hirsch s’en faisait récem­ment l’écho ici même.

Ce cas est loin d’être isolé, preuve en est le rapport publié en fin d’année dernière par Risk Based Security faisant état de 2’935 inci­dents ayant mené à la divul­ga­tion de 36 milliards de fichiers durant les seuls neuf premiers mois de l’année 2020.

Aujourd’hui, la ques­tion n’est donc pas tant de savoir « si », mais « quand » un tel inci­dent va se produire et avec quelle ampleur. Si les risques sont nombreux, tout aussi nombreux sont les orga­nismes s’efforçant de les iden­ti­fier pour s’en prému­nir. Parmi ces initia­tives, mention­nons celles, deve­nues un stan­dard et récem­ment utili­sées comme réfé­ren­tiel sur le plan contrac­tuel, de la Fondation OWASP, qui réfé­rence de manière pério­dique les dix préoc­cu­pa­tions majeures en termes de sécurité.

En toute hypo­thèse, nonobs­tant les efforts déployés, éviter ces risques ad eter­nam appa­raît peu probable. Fort de ce constat, les détec­ter et y remé­dier aussi rapi­de­ment que possible appa­raît comme une condi­tion sine qua non pour éviter d’avoir à passer sous les fourches caudines des autorités.

Ces fourches peuvent s’avérer parti­cu­liè­re­ment piquantes. En 2020, les sanc­tions pronon­cées sur le fonde­ment de l’art. 32 RGPD se sont montées à plus de 83 millions d’euros ; entre 2018 et 2020, les amendes infli­gées par les auto­ri­tés de protec­tion des données dans les États de l’Union euro­péenne sur le fonde­ment d’un défaut de sécu­rité auraient ainsi été multi­pliées par 162 si l’on en croit un article paru dans le Journal du Net.

Conjugué à l’obligation faite à l’art. 33 RGPD aux respon­sables de trai­te­ment de noti­fier la viola­tion des données à carac­tère person­nel aux auto­ri­tés lorsqu’il en résulte un risque pour les indi­vi­dus concer­nés, une obli­ga­tion qui exis­tera égale­ment en Suisse après l’entrée en vigueur de l’art. 24 nLPD¹, le risque décou­lant d’un tel inci­dent fait de l’adoption d’un plan de réponse une étape primor­diale dans la mise en œuvre d’un plan de gestion digne de ce nom en matière de données.

Cette brève contri­bu­tion a pour objec­tif de décrire de manière sommaire les étapes liées à l’établissement et la mise en œuvre d’un tel plan.

II. Établissement d’un plan de réponse en cas de faille de sécurité

Il existe deux grands modèles pour établir un plan de réponse en cas d’incident : celui du National Institute of Standards and Technology (NIST) d’une part et celui du Sysadmin, Audit, Network, and Security (SANS) d’autre part. Ces modèles comprennent les phases suivantes, que nous allons reprendre l’une après l’autre :

• prépa­ra­tion [a] ;
• détec­tion et analyse [b] ;
• confi­ne­ment, suppres­sion et récu­pé­ra­tion [c]² ;
• ensei­gne­ments [d].

a) Préparation

Cette première étape consiste en un premier temps à déter­mi­ner l’équipe en charge de gérer l’incident puis, en un second, d’apprécier les ressources dont dispose l’entreprise pour gérer l’incident.

La struc­ture donnée à l’équipe en charge de répondre à l’incident sera propre à la struc­ture de l’entreprise. Centralisée au travers d’une seule équipe pour les PME, elle sera le plus souvent décen­tra­li­sée lorsque l’entreprise est présente sur diffé­rents marchés ou subdi­vi­sées en de nombreuses unités, hypo­thèse dans laquelle la coor­di­na­tion jouera un rôle impor­tant quant à l’efficacité de la réponse donnée à l’incident.

En toute hypo­thèse, répondre à un inci­dent requiert une coor­di­na­tion entre de nombreux acteurs aux rôles diffé­rents au sein d’une entre­prise, parmi lesquels : la direc­tion  (respon­sable à la fin de la gestion de l’incident et donc à tenir infor­mée en premier lieu), le support IT (à même de prendre les mesures adéquates rapi­de­ment concer­nant les systèmes concer­nés), le service juri­dique (à même d’apprécier les obli­ga­tions légales résul­tant de l’incident, notam­ment quant au devoir de noti­fi­ca­tion), les ressources humaines (si l’incident concerne les employés) ou encore la commu­ni­ca­tion (suscep­tible d’entrer en jeu lorsqu’il s’agit d’informer les médias de la surve­nance de l’incident eu égard à sa nature) pour prendre les plus courants. Ces diffé­rents acteurs et le rôle qu’ils seront respec­ti­ve­ment amenés à jouer dans le cadre de la gestion de l’incident doivent être clai­re­ment identifiés.

La deuxième étape consiste à faire un inven­taire des ressources à dispo­si­tion pour être à même de gérer un inci­dent. Ces ressources sont géné­ra­le­ment de trois ordres : (i) orga­ni­sa­tion­nel tout d’abord, en s’assurant que tous les membres de l’équipe sont à même de joindre les autres membres (télé­phones portables notam­ment) et la chaîne de repor­ting ; (ii) maté­riel ensuite, en s’interrogeant sur les appa­reils et logi­ciels à dispo­si­tion pour trai­ter l’incident (analyse foren­sique, ordi­na­teurs de réserve, impri­mantes portables, disques externes, etc.) ; (iii) en termes d’outils d’analyse dispo­nibles pour mieux appré­hen­der l’incident enfin (listes des ports, docu­men­ta­tion, diagrammes des réseaux et liste des biens critiques, etc.).

À l’issue de la prépa­ra­tion, l’équipe mise en place devrait être en mesure de répondre posi­ti­ve­ment aux ques­tions suivantes :

• chacun connaît-il les poli­tiques en matière de sécu­rité de la société ?
• chacun sait-il à qui il doit rappor­ter et avec qui il doit prendre contact en cas d’incident ?
• les personnes en charge de trai­ter l’incident ont-elles accès aux jour­naux et outils permet­tant de mettre en œuvre le proces­sus de réponse mis sur pied ?
• chacun a‑t-il pris part à des exer­cices de mise en œuvre du plan de réponse (work­table exer­cise) ?

Enfin, à partir du moment où la docu­men­ta­tion revêt un aspect crucial dans la gestion d’un inci­dent, il est utile de savoir où aller cher­cher des modèles de docu­ments auxquels il convien­dra de recou­rir ; on en trou­vera d’utiles en libre accès mis à dispo­si­tion par le SANS.

b) Détection et analyse

Pour être en mesure de détec­ter un inci­dent, il convient de surveiller les diffé­rents systèmes en place. Pour ce faire, plusieurs types d’outils sont dispo­nibles, parmi lesquels :

• IDS-IPS : ces deux systèmes sont liés à l’infrastructure réseau. Alors que le système de détec­tion d’intrusion (intru­sion detec­tion system) ne fait que collec­ter des infor­ma­tions³, le système de préven­tion (intru­sion preven­tion system) permet d’opérer un tri dans les paquets et de filtrer ceux qui ne sont pas conformes à la poli­tique en matière de sécu­rité de l’entreprise⁴. Le premier ne fait ainsi que surveiller, tandis que le second est à même d’exécuter des actions préven­tives visant à éviter l’incident.
• DLP : les outils de préven­tion de pertes de données (data loss preven­tion) visent comme le nom l’indique à éviter que des données ne soient perdues ou compro­mises par un accès indu de quelque manière que ce soit⁵.
• SIEM : le système de gestion de l’information et des événe­ments en matière de sécu­rité (secu­rity infor­ma­tion and event mana­ge­ment) analyse en temps réel le fichier des logs et des événe­ments pour iden­ti­fier tout compor­te­ment inha­bi­tuel⁶.

Quels que soient les outils utili­sés, il est impor­tant de docu­men­ter toutes les infor­ma­tions ayant trait à la décou­verte et à l’analyse de l’incident, parmi lesquels : (i) le statut de l’incident ; (ii) le résumé ; (iii) les indi­ca­teurs ; (iv) les inci­dents corol­laires ; (v) les actions prises par les diffé­rents membres de l’équipe ; (vi) l’analyse de l’impact lié à l’incident ; (vii) les coor­don­nées des diffé­rentes parties impli­quées ; (viii) la liste des preuves réunies durant l’analyse de l’incident et (ix) les prochaines étapes.

L’analyse de l’incident doit permettre de déter­mi­ner quel est l’impact fonc­tion­nel sur la conti­nuité des affaires et les efforts néces­saires pour réta­blir la situation.

Si l’on suit la métho­do­lo­gie rete­nue par le NIST⁷, la clas­si­fi­ca­tion en ce qui a trait à l’impact opéra­tion­nel est la suivante :

Quant aux efforts de remise en état, ce même NIST retient la clas­si­fi­ca­tion suivante :

À l’issue de cette analyse, il convien­dra d’apprécier quelles sont les personnes devant être infor­mées de l’incident, parmi lesquelles : (i) le CIO ; (ii) le CISO (ces deux l’étant en prin­cipe d’ores et déjà) ; (iii) d’autres équipes de réponse en matière d’incident (approche décen­tra­li­sée) ; (iv) le respon­sable du système ; (v) les ressources humaines ; (vi) les rela­tions publiques et commu­ni­ca­tion ; (viii) le service juridique.

d) Confinement, éradi­ca­tion et récupération

Une fois détecté et analysé, l’incident doit être traité.

Contenir l’incident est une phase essen­tielle pour mini­mi­ser son impact. Les stra­té­gies en la matière varient. Ainsi sera-t-elle diffé­rente suivant que l’on a affaire à une attaque au travers d’un cour­riel vérolé ou d’une attaque par déni de service distri­bué (DDoS) qui touche au réseau. La déci­sion à prendre dépend alors de la réponse appor­tée à plusieurs ques­tions : (i) les systèmes touchés peuvent-ils être isolés des systèmes qui n’ont pas été affec­tés par l’incident (par exemple suppres­sion du malware, décon­nexion des comptes utili­sa­teurs ayant fait l’objet d’un accès indu, etc.) ? ; (ii) une image du système touché a‑t-elle pu être créée avant que quiconque n’y touche et sommes-nous assu­rés d’avoir un suivi docu­menté de toute personne suscep­tible d’intervenir et des démarches effectuées ?

Une fois l’incident maîtrisé, la ques­tion se pose de la restau­ra­tion des systèmes affec­tés : (i) le système peut-il être restauré et nettoyé par diverses mesures pour éviter toute attaque future (par exemple au travers du recours à des back-ups propres, rempla­ce­ment de fichiers véro­lés par des fichiers propres, instal­la­tion de patches, chan­ge­ment de mots de passe, recon­fi­gu­ra­tion des fire­walls et routeurs, etc.) ? ; (ii) la solu­tion appor­tée est-elle durable ou faudra-t-il prendre de plus amples mesures à plus long terme ?

Les systèmes restau­rés devront être régu­liè­re­ment testés et surveillés pour s’assurer qu’ils ne risquent plus d’être affec­tés par un inci­dent simi­laire à l’avenir. La ques­tion se pose alors de savoir quels outils la société a à sa dispo­si­tion pour assu­rer un tel suivi.

e) Enseignements

Une fois l’incident clôturé, faire une séance de retour d’analyse fait partie des bonnes pratiques à mettre en place pour tirer les leçons du passé et éviter qu’il ne se repro­duise, en répon­dant en parti­cu­lier aux ques­tions suivantes :

• que s’est-il passé exac­te­ment, et à combien de reprises ?
• la gestion de l’incident s’est-elle passée comme prévu ? Le plan a‑t-il bien fonc­tionné et était-il adéquat ?
• quelle infor­ma­tion aurait-il été utile d’avoir plus tôt ?
• les infor­ma­tions ont-elles bien circulé ?
• y a‑t-il eu des démarches prises qui ont retardé le trai­te­ment de l’incident ?
• que ferait l’équipe diffé­rem­ment si un inci­dent simi­laire devait se produire à l’avenir ?
• quelles mesures préven­tives sont suscep­tibles d’éviter qu’un inci­dent compa­rable se produise à l’avenir ?
• à quels indi­ca­teurs faudrait-il en parti­cu­lier prêter attention ?

III. Conclusion

La ques­tion de savoir quel doit être le degré de sophis­ti­ca­tion d’un plan de réponse et, corol­lai­re­ment, quelles ressources il convient de mettre en œuvre repose sur une analyse coûts-bénéfice.

En ce qui a trait aux enti­tés soumises au RGPD, l’importance des sanc­tions admi­nis­tra­tives pronon­cées par les auto­ri­tés en appli­ca­tion de l’art. 83 RGPD plaident en faveur de l’octroi par les conseils d’administration d’un budget adéquat.

S’agissant des socié­tés suisses qui ne sont soumises qu’à la Loi fédé­rale sur la protec­tion des données, on peut se deman­der si cette analyse conduira au même résul­tat. Force est en effet d’admettre que la révi­sion n’a pas permis de confé­rer au Préposé fédé­ral des pouvoirs compa­rables à ceux accor­dés par le RGPD à ses pairs euro­péens. Ainsi, seule une plainte pénale permet­tra à une auto­rité pénale de pronon­cer une amende pour le non-respect des mesures de sécu­rité préco­ni­sées par le Conseil fédé­ral dans une ordon­nance à venir. Outre le fait que cette amende ne pourra pas dépas­ser le montant de CHF 250’000.–, elle sera de surcroît limi­tée aux seules infrac­tions inten­tion­nelles (art. 61 let. c nLPD). Difficile dès lors de faire moins dissua­sif. Au final, l’incitation vien­dra donc certai­ne­ment davan­tage de la prise de conscience du public et de la média­ti­sa­tion de ces inci­dents par les médias, autant d’éléments suscep­tibles de créer un dommage répu­ta­tion­nel bien plus inci­ta­tif à prendre des mesures qu’une éven­tuelle amende bien théo­rique et éloi­gnée. Sera-ce suffi­sant ? L’avenir le dira.

1. À ce sujet : Métille/​Meyer, Annonce des viola­tions de la sécu­rité des données, RSDA 2021, p. 23 ss.
2. Dans le modèle SANS, ces trois phases sont distinctes, de sorte que le modèle SANS est subdi­visé en 6 phases, le modèle NIST – que je suis ici – n’en compor­tant que quatre. Pour une analyse de ces diffé­rences, voir : https://​www​.isacy​ber​se​cu​rity​.com/​c​o​m​p​a​r​i​n​g​-​n​i​s​t​-​s​a​n​s​-​i​n​c​i​d​e​n​t​-​f​r​a​m​e​w​o​r​ks/.
3. Pour des exemples de systèmes de détec­tion d’intrusion (i) réseaux, par exemple : Snort, Bro, Suricata ou Enterasys ; (ii) hôtes, par exemple : AIDE, Chkrootkit, DarkSpy ou IceSword.
4. Pour des exemples de systèmes de préven­tion d’intrusion : CISCO IOS Intrusion Prevention System, Varonis.
5. Pour des exemples : Digital Guardian, Forcepoint, McAfee, Symantec, RSA, Endpoint Protector ou encore Protection des données CA (l’offre DLP de Broadcom).
6. Pour des exemples : LogRhythm, RSA, Splunk ou encore QRadar.
7. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800–61r2.pdf.