72 heures en cas de violation de données : où passe le temps côté logiciel

La notification d’une violation est présentée comme une procédure juridique. Mais la part de ce délai qui sera perdue dépend de la façon dont le système a été conçu, des mois avant l’incident.

Une alerte arrive sur le bureau d'une organisation un lundi matin : un accès inhabituel a été détecté sur un serveur. À partir de cet instant, le compte à rebours des soixante-douze heures commence.

Soixante-douze heures, cela paraît long. Ce qui suit est un récit heure par heure de l'endroit où ce temps part réellement, car sans voir cette répartition, il est difficile de comprendre pourquoi la préparation face à une violation doit se faire des mois à l'avance, pas pendant qu'elle se produit.

Les huit premières heures : s'agit-il vraiment d'une violation ?

La première tâche consiste à déterminer si l'alerte est réelle. Il peut s'agir d'un faux positif, d'une opération de maintenance ou d'une autorisation mal configurée.

À ce stade, l'équipe technique examine les journaux. Si les journaux ne sont pas assez bons, et dans la plupart des organisations ils ne le sont pas, cela s'éternise. Sans savoir quel compte a accédé à quelle table depuis quelle adresse, aucune étape suivante n'est possible.

Le premier point critique se situe ici. Qui ne tient pas de journaux voit l'horloge s'épuiser à cet endroit précis, et ce temps ne se rattrape jamais.

Les vingt-quatre heures suivantes : quelles données ont été touchées

Une fois établi qu'il s'agit d'une violation, une seule question se pose. Quelles données personnelles se trouvaient sur ce serveur ?

Une organisation dotée d'un inventaire à jour y répond en dix minutes. Une organisation qui n'en a pas essaie de le découvrir en examinant le schéma de la base de données, en vérifiant les noms des tables, en extrayant des enregistrements d'échantillon, en interrogeant les développeurs. Cela seul peut facilement prendre une journée entière.

La seconde moitié de la question est plus difficile. Que contiennent les sauvegardes ? Existe-t-il une copie exportée pour un rapport ? Un échantillon a-t-il été chargé dans un environnement de test ? Si les réponses ne sont écrites nulle part, on finit par se fier à des suppositions, et une notification fondée sur des suppositions doit ensuite être corrigée.

Les douze heures suivantes : combien de personnes sont concernées

Une fois le périmètre délimité, il faut produire un chiffre. Combien de personnes concernées, quelles catégories de données, quelles zones géographiques.

Une erreur fréquente ici consiste à arrondir le chiffre. Dire « environ dix mille personnes » n'entraînera pas le rejet de la notification, mais si un chiffre réel très différent apparaît par la suite, cela nuit à la crédibilité de ce que l'organisation a déclaré. S'il est impossible d'obtenir un chiffre précis, mieux vaut le dire ainsi, et en expliquer la raison, que d'en avancer un au hasard.

Le temps restant : préparer et envoyer la notification

La notification au Conseil doit couvrir quand et comment la violation s'est produite, quelles catégories de données ont été touchées, ses conséquences possibles ainsi que les mesures prises et prévues.

Rédiger cela à partir d'une page blanche consomme le temps restant. Une organisation disposant déjà d'un modèle le remplit en une demi-heure. Qui est habilité à la signer doit également être décidé à l'avance, car si cette discussion commence à ce stade, il n'y a plus de temps pour elle.

Notifier les personnes concernées est une tâche distincte. Elle se fait dès que raisonnablement possible une fois les personnes concernées identifiées ; si un contact direct n'est pas possible, un autre moyen approprié est utilisé. Le langage compte ici. Un message noyé dans le détail technique empêche la personne de comprendre ce qu'elle doit réellement faire.

Ce que le plan doit vraiment contenir

La leçon de ce parcours est la suivante. La valeur d'un plan de réponse aux incidents réside dans le fait d'avoir réfléchi à l'avance à ce qu'il faudrait réfléchir au moment de l'incident.

Il faut une répartition claire des rôles. Qui délimite l'incident, qui décide qu'il s'agit d'une violation, qui signe. Un plan qui dépend d'une seule personne s'effondre le jour où cette personne est absente.

Il faut un seuil défini. Ce qui constitue une violation doit être écrit à l'avance, sinon cette discussion se déroule dans les soixante-douze heures.

Il faut une règle de préservation des preuves. Le premier réflexe est souvent de nettoyer les systèmes touchés, ce qui rend impossible une enquête adéquate. Le plan doit indiquer explicitement que les journaux sont conservés intacts.

Il faut des modèles de communication déjà préparés, tant pour le Conseil que pour les personnes concernées.

Rien ne se termine à l'envoi de la notification

La notification n'est pas la fin de l'obligation. Le Conseil évalue si les mesures techniques et organisationnelles prises étaient suffisantes.

Une violation qui se répète dans la même organisation est interprétée comme la preuve que ces mesures n'étaient pas suffisantes. C'est pourquoi l'action corrective adoptée après une violation doit être consignée et son effet mesuré. La phrase « les mesures nécessaires ont été prises » ne constitue en soi la preuve de rien.

La seule chose qui vaille la peine d'être faite aujourd'hui

Ce qu'il y a de plus rentable à faire avant de subir une violation, c'est d'établir l'inventaire avec l'emplacement physique des données : quelle base de données, quelle table, quel champ et quelle sauvegarde contient chaque donnée.

Si ce tableau existe, environ les trente premières des soixante-douze heures sont de fait récupérées. S'il n'existe pas, aussi bien rédigé que soit le plan, le temps ne suffira pas.