Votre prestataire vous dit « le problème est réglé » : comment en être certain ?
Une alerte apparaît. Le prestataire intervient. Quelques heures plus tard, il annonce que tout est réglé. Mais qu'a-t-il réellement vérifié ? Voici comment une entreprise peut suivre ses incidents sans devenir experte en cybersécurité.
Un lundi matin, un collaborateur signale un comportement inhabituel sur son ordinateur.
Le prestataire informatique intervient à distance.
Il effectue quelques vérifications, corrige un paramètre et redémarre un service.
Dans l'après-midi, le dirigeant reçoit un email :
« Le problème a été traité. Tout est rentré dans l'ordre. »
Bonne nouvelle.
Mais une question reste sans réponse.
Qu'est-ce qui était réellement en cause, et comment sait-on que le risque a disparu ?
Cette question n'est pas une remise en cause du prestataire.
C'est une question normale de gestion d'entreprise.
Un service rétabli n'est pas nécessairement un incident de sécurité résolu
Il faut distinguer deux choses.
La première est le retour au fonctionnement normal.
La messagerie fonctionne à nouveau, les fichiers sont accessibles et les collaborateurs peuvent reprendre leur activité.
La deuxième est la résolution du problème de sécurité.
L'accès suspect a-t-il été identifié ? Les droits ont-ils été vérifiés ? Les journaux ont-ils été conservés ? Existe-t-il encore un mécanisme permettant à l'attaquant de revenir ?
Ces deux situations peuvent être très différentes.
Un compte compromis peut recommencer à fonctionner après une réinitialisation de mot de passe, sans que toute l'activité antérieure ait été examinée.
Un service exposé peut redevenir disponible après une correction, sans que l'on ait déterminé s'il avait déjà été exploité.
Le fonctionnement normal prouve que l'activité a repris. Il ne démontre pas à lui seul que l'incident est entièrement compris.
Le dirigeant n'a pas besoin de cinquante pages de journaux
C'est l'autre extrême.
Pour rassurer son client, un prestataire pourrait envoyer une longue exportation technique : événements Windows, logs réseau, résultats de scans, tableaux de vulnérabilités.
Mais le dirigeant n'a pas nécessairement les compétences ni le temps pour interpréter ces informations.
Ce dont il a besoin est plus simple.
Quel était le problème ?
Quelles activités étaient exposées ?
Qu'avons-nous fait ?
Qu'est-ce qui a été vérifié ?
Reste-t-il quelque chose à faire ?
Une bonne communication de sécurité doit répondre à ces questions sans masquer les incertitudes.
Un incident dont l'origine reste inconnue doit être présenté comme tel.
Exemple : une connexion inhabituelle à une messagerie
Imaginons qu'une entreprise reçoive une alerte concernant une connexion suspecte.
Le prestataire change le mot de passe du collaborateur.
Il serait tentant de fermer le ticket immédiatement.
Mais il manque encore plusieurs éléments.
L'authentification suspecte a-t-elle réellement abouti ?
L'utilisateur reconnaît-il l'appareil ou la localisation ?
Des sessions doivent-elles être révoquées ?
Une méthode MFA inconnue a-t-elle été ajoutée ?
Des règles de messagerie ont-elles été modifiées ?
Des emails frauduleux ont-ils été envoyés ?
Ces vérifications permettent de distinguer une mesure de précaution d'une réponse à une compromission confirmée.
Cybermalveillance.gouv.fr recommande notamment de vérifier les coordonnées de récupération, les règles de transfert et les sessions actives après un piratage de compte.
Source : Cybermalveillance.gouv.fr — Piratage de compte
Le vrai problème : les actions qui restent ouvertes après l'intervention
Dans la pratique, il arrive qu'une correction immédiate soit réalisée alors que des actions complémentaires restent nécessaires.
Un équipement doit être mis à jour lors de la prochaine maintenance.
Un compte technique doit être remplacé.
Un accès doit être limité après validation du responsable métier.
Une sauvegarde doit faire l'objet d'un test de restauration.
Aucun de ces sujets n'est nécessairement une urgence absolue.
Mais ils ne doivent pas disparaître simplement parce que l'incident initial est clos.
Chaque action devrait avoir un responsable, une échéance et un état compréhensible.
Sans cela, les mêmes problèmes peuvent revenir.
Quand la sécurité devient un sujet de coordination
Un incident implique rarement une seule personne.
Le prestataire doit parfois demander une autorisation.
L'administrateur doit intervenir.
Le responsable métier doit accepter une interruption.
Le dirigeant doit arbitrer une dépense ou un risque résiduel.
Et parfois, le client doit simplement confirmer qu'un service fonctionne correctement après la correction.
Ces échanges peuvent rapidement se disperser dans des emails, des appels téléphoniques et des tickets.
Une personne pense attendre le prestataire.
Le prestataire pense attendre le client.
Et l'action reste ouverte.
L'ANSSI insiste dans ses ressources sur la nécessité de coordonner les équipes techniques et les responsables métiers, notamment pendant la gestion d'une crise cyber.
Source : ANSSI — Anticiper et gérer une crise cyber
Donner au client une visibilité compréhensible
Pour une entreprise qui utilise plusieurs services de sécurité managés, la question devient particulièrement importante.
Il faut savoir quels services sont couverts, quelles informations ont été publiées, quels incidents demandent une attention et quelles décisions restent en attente.
C'est l'un des principes retenus pour Cyberhack Platform.
L'espace client regroupe les synthèses de services managés, les rapports publiés et les mises à jour d'incidents. Lorsqu'une action ou une réponse du client est nécessaire, les éléments de suivi peuvent être consultés dans cet espace.
L'idée n'est pas de remplacer les échanges humains.
Au contraire, c'est de mieux les préparer.
Une information claire permet au dirigeant de poser la bonne question, au responsable informatique d'agir sur un point précis et au prestataire de conserver une continuité dans le suivi.
Et si des données personnelles sont concernées ?
Un incident peut également avoir des conséquences réglementaires.
Une compromission de messagerie, par exemple, peut exposer des données personnelles.
Il faut alors qualifier la violation, évaluer les risques pour les personnes et documenter les faits.
La CNIL rappelle que les violations de données personnelles doivent être documentées en interne et que celles présentant un risque pour les droits et libertés doivent lui être notifiées dans les meilleurs délais, si possible dans les 72 heures après leur constatation. En cas de risque élevé, les personnes concernées doivent aussi être informées, sous réserve des exceptions prévues.
Ce délai ne concerne pas indistinctement tous les incidents informatiques : l'obligation dépend de la qualification de la violation et du risque.
Source : CNIL — Notifier une violation de données personnelles
Cette dimension montre pourquoi un simple message « problème résolu » peut être insuffisant dans certains cas.
Les cinq questions à poser après un incident
Une PME peut demander à son prestataire un compte rendu court qui répond à cinq questions :
- Quelle est la cause identifiée, ou quelles hypothèses restent à confirmer ?
- Quels comptes, équipements ou services étaient concernés ?
- Quelles actions ont été réalisées ?
- Quels contrôles permettent de considérer le risque comme maîtrisé ?
- Quelles actions restent ouvertes, avec quel responsable et quelle échéance ?
Ces cinq réponses ne remplacent pas un rapport d'investigation lorsqu'il est nécessaire.
Mais elles fournissent une base compréhensible pour suivre la situation.
La confiance se construit aussi après l'incident
Une entreprise n'attend pas de son prestataire qu'il promette une absence totale d'incidents.
Ce serait irréaliste.
Elle attend surtout qu'il sache expliquer ce qui se passe, prendre les bonnes mesures et indiquer honnêtement ce qui reste incertain.
La qualité d'un service de cybersécurité se mesure donc aussi après l'intervention.
Dans la clarté du compte rendu.
Dans la capacité à justifier une correction.
Dans le suivi des mesures non terminées.
Et dans la façon dont le client reste informé.
Conclusion
« Le problème est réglé » est une bonne nouvelle.
Mais ce n'est pas toujours une réponse suffisante.
Pour une entreprise, l'essentiel n'est pas de comprendre chaque commande exécutée ou chaque journal technique.
C'est de savoir ce qui a été découvert, corrigé, vérifié et éventuellement reporté.
Un incident bien géré n'est pas seulement un incident après lequel tout fonctionne.
C'est un incident dont les conséquences sont évaluées, les actions documentées et les risques résiduels clairement identifiés.
Et c'est précisément cette transparence qui permet de construire une relation durable entre l'entreprise et ceux qui assurent sa sécurité.
