Fiche pratique & réponse à incident
Réponse à incident : qualifier, contenir, comprendre et reprendre
Un incident de sécurité commence rarement avec une vision claire de la situation. Une alerte, un comportement inhabituel, un compte compromis, un serveur inaccessible ou une activité réseau anormale peuvent être les premiers signes d’un événement beaucoup plus important.
La réponse à incident consiste à reprendre progressivement la maîtrise de la situation : qualifier les faits, limiter les conséquences, comprendre ce qui s’est produit, éliminer la cause, restaurer les services et tirer les enseignements nécessaires. Cette fiche propose une méthode simple et opérationnelle pour structurer cette réponse.
Avant de commencer
Répondre à un incident, ce n’est pas appliquer mécaniquement une procédure
Une procédure de réponse à incident donne un cadre. Elle définit des rôles, des principes, des actions possibles et des points de contrôle.
Mais un incident réel ne respecte jamais parfaitement le scénario prévu.
Les premières informations sont souvent partielles. Certaines peuvent être contradictoires. Le périmètre évolue à mesure que l’investigation progresse et les décisions doivent parfois être prises avant de disposer de toutes les réponses.
Le bon objectif
L’objectif n’est pas de suivre parfaitement une procédure. Il est de prendre les bonnes décisions avec les informations disponibles, de limiter l’impact et de conserver la maîtrise de la situation.
La réponse à incident doit donc rester adaptable.
Qualification, confinement, investigation et remédiation peuvent se chevaucher. Une découverte réalisée pendant l’investigation peut obliger à renforcer le confinement. Une tentative de remise en service peut révéler qu’une remédiation est incomplète.
Établir ce que l’on sait réellement et identifier ce qui reste incertain.
Choisir les mesures proportionnées à la situation et aux impacts.
Mettre en œuvre les actions techniques et organisationnelles nécessaires.
Conserver les faits, décisions, actions, preuves et résultats.
Étape 1
Qualifier : que se passe-t-il réellement ?
La première difficulté consiste à déterminer la nature de l’événement.
Une alerte de sécurité n’est pas nécessairement un incident. À l’inverse, un événement initialement considéré comme mineur peut être le premier symptôme d’une compromission beaucoup plus large.
La qualification doit permettre d’établir rapidement une première vision de la situation sans attendre de tout comprendre.
Quel événement a déclenché l’alerte ?
Quels utilisateurs, postes, serveurs, applications ou équipements semblent concernés ?
Quels symptômes ont réellement été observés ?
Depuis quand le comportement anormal est-il visible ?
L’incident semble-t-il toujours en cours ?
Existe-t-il un impact sur la disponibilité, l’intégrité ou la confidentialité des données ?
Des activités métiers sont-elles déjà perturbées ?
À ce stade, il faut également attribuer un niveau de criticité provisoire. Celui-ci pourra évoluer lorsque de nouvelles informations seront disponibles.
Ne pas attendre la certitude
Chercher à obtenir une vision parfaite avant d’agir peut faire perdre un temps précieux. Une qualification est une photographie de la situation à un instant donné, pas une conclusion définitive.
Ce qu’il faut déjà tracer
La chronologie commence dès maintenant.
Date et heure de détection.
Personne ou outil ayant détecté l’événement.
Premiers symptômes observés.
Périmètre initialement identifié.
Niveau de criticité retenu et éléments ayant conduit à cette évaluation.
À la fin de cette étape
L’organisation doit être capable de dire ce qu’elle sait, ce qu’elle soupçonne, ce qu’elle ignore encore et pourquoi la situation nécessite — ou non — une réponse à incident structurée.
Étape 2
Confiner : empêcher la situation de s’aggraver
Une fois l’incident suffisamment caractérisé, la priorité consiste à limiter sa propagation et ses conséquences.
Le confinement peut concerner un compte utilisateur, une machine, un segment réseau, une application, un accès distant, un service exposé sur Internet ou une partie plus importante du système d’information.
Il n’existe pas une action de confinement valable pour tous les incidents.
Déterminer ce qui doit réellement être isolé.
Mesurer l’impact de l’action de confinement.
Limiter la capacité de l’incident à se propager.
Vérifier que la mesure produit bien l’effet attendu.
Isoler n’est pas nécessairement éteindre
Couper brutalement un système peut faire disparaître des informations utiles à l’investigation, interrompre des traitements ou rendre la compréhension de l’incident plus difficile. Une machine peut par exemple être isolée du réseau tout en restant sous tension lorsque la situation le permet.
La bonne décision dépend du niveau de menace, de la capacité de propagation, de la criticité du système, de l’impact métier et des besoins d’investigation.
L’incident peut-il encore se propager ?
Quels systèmes peuvent être isolés sans créer un risque plus important ?
Des comptes ou accès doivent-ils être désactivés immédiatement ?
Faut-il bloquer certains flux ou accès externes ?
Quelles conséquences métiers entraînera le confinement ?
Une décision technique peut devenir une décision métier
Isoler un serveur bureautique et isoler l’ERP, une chaîne de production ou une plateforme de vente n’ont pas les mêmes conséquences. Selon le périmètre, la décision doit être partagée avec les responsables disposant de l’autorité nécessaire.
Ce qu’il faut tracer
Chaque action de confinement importante devrait comporter une heure, un responsable, une justification et un résultat.
Cette information sera essentielle quelques heures plus tard lorsque plusieurs intervenants chercheront à reconstruire ce qui a été fait, dans quel ordre et pour quelle raison.
Étape 3
Investiguer : comprendre avant de reconstruire
Une fois les premières mesures conservatoires prises, l’investigation doit permettre de comprendre l’incident avec suffisamment de précision pour préparer une remédiation fiable.
Il ne s’agit pas nécessairement de reconstituer immédiatement chaque seconde de l’attaque.
Il faut d’abord répondre aux questions qui conditionnent la maîtrise de la situation.
Les journaux système, événements d’authentification, traces réseau, équipements de sécurité, consoles d’administration, historiques des applications et informations fournies par les prestataires peuvent être nécessaires à cette analyse.
Il faut également chercher au-delà du premier système identifié.
Le premier système découvert n’est pas forcément le premier système compromis
Un serveur sur lequel une activité malveillante est détectée peut n’être qu’une étape du scénario. L’investigation doit chercher les mouvements précédents, les comptes utilisés et les autres systèmes susceptibles d’avoir été touchés.
Préserver les éléments utiles
Les éléments collectés doivent être conservés de manière organisée. Certains pourront être nécessaires pour une analyse technique approfondie, une expertise externe, une déclaration ou une action ultérieure.
Conserver les journaux disponibles.
Identifier l’origine et l’heure de collecte.
Éviter les manipulations inutiles sur les systèmes concernés.
Conserver les fichiers, messages ou indicateurs significatifs.
Documenter les constats et les hypothèses sans les confondre.
Un fait n’est pas une hypothèse
« Le compte X s’est authentifié à 03 h 14 » est un fait observable. « Le compte X est le point d’entrée de l’attaque » est une hypothèse tant que les éléments disponibles ne permettent pas de l’établir. Cette distinction est essentielle pendant une investigation.
Étape 4
Remédier : éliminer la cause et les mécanismes de persistance
La remédiation ne consiste pas simplement à remettre en marche ce qui ne fonctionne plus.
Elle vise à supprimer les éléments ayant permis l’incident et à empêcher autant que possible que le même mécanisme puisse être immédiatement réutilisé.
Supprimer les logiciels malveillants, accès ou mécanismes de persistance identifiés.
Traiter les vulnérabilités, mauvaises configurations ou faiblesses exploitées.
Réinitialiser les secrets, comptes ou accès qui doivent l’être.
S’assurer que le périmètre identifié a été traité dans son ensemble.
Corriger uniquement le premier système compromis ne suffit pas
Si d’autres machines, comptes ou services ont été touchés, une remédiation partielle peut laisser à l’attaquant un accès permettant de recommencer immédiatement.
Selon l’incident, les actions pourront inclure le retrait d’un logiciel, le blocage d’un compte, la rotation de mots de passe ou de secrets, l’application d’un correctif, la modification d’une règle réseau, la fermeture d’un accès exposé ou la reconstruction complète d’un système.
Réparer ou reconstruire ?
Lorsqu’un système a été fortement compromis, le remettre en état directement n’est pas toujours la meilleure option.
Une reconstruction à partir d’une base connue comme saine peut parfois offrir un niveau de confiance supérieur à une succession de corrections appliquées sur un système dont l’intégrité n’est plus certaine.
La question à poser avant la reprise
Avons-nous suffisamment confiance dans l’état de ce système pour l’autoriser à rejoindre de nouveau le système d’information ?
Étape 5
Retour à la normale : restaurer progressivement et sous contrôle
La disparition des symptômes ne signifie pas que l’incident est terminé.
La reprise constitue elle-même une phase de la réponse à incident.
Les systèmes doivent être restaurés ou reconstruits, contrôlés puis remis progressivement à disposition selon des priorités cohérentes avec les besoins de l’organisation.
Remettre à disposition un environnement considéré comme sain.
Vérifier fonctionnement, configuration et sécurité.
Réintégrer progressivement le système dans son environnement.
Rechercher toute réapparition d’un comportement anormal.
La priorité de remise en service ne correspond pas nécessairement à l’ordre dans lequel les systèmes sont techniquement les plus faciles à restaurer.
Elle doit tenir compte des dépendances et des besoins métiers.
Ne pas confondre vitesse et précipitation
La pression pour rétablir rapidement le service peut être très forte. Une remise en production prématurée peut pourtant réintroduire l’incident ou reconnecter un système encore compromis.
Définir des critères de retour en production
Le système restauré est considéré comme sain.
Les vulnérabilités ou faiblesses identifiées ont été corrigées.
Les accès et secrets compromis ont été traités.
Les dépendances nécessaires au fonctionnement sont disponibles.
Les contrôles fonctionnels ont été réalisés.
Une surveillance renforcée est prévue après la remise en service.
Qui autorise réellement le retour en production ?
Cette responsabilité devrait être définie avant l’incident. Selon le système concerné, la validation peut nécessiter un accord technique, sécurité et métier.
Étape 6
Retour d’expérience : transformer l’incident en amélioration
Une fois l’activité stabilisée, l’organisation pourrait être tentée de refermer rapidement l’incident.
C’est précisément à ce moment que commence pourtant l’une des étapes les plus utiles.
Le retour d’expérience permet de transformer ce qui vient d’être vécu en connaissance et en actions concrètes.
Comment l’incident a-t-il réellement commencé ?
Pourquoi a-t-il été possible ?
Qu’est-ce qui a permis de le détecter ?
Qu’aurions-nous pu détecter plus tôt ?
Quelles décisions ont été difficiles à prendre ?
Quelles informations nous ont manqué ?
Qu’est-ce qui a bien fonctionné pendant la réponse ?
Quelles actions devons-nous maintenant engager ?
Le REX ne doit pas rechercher un responsable à blâmer.
Il doit permettre de comprendre les faiblesses techniques, organisationnelles ou documentaires révélées par l’incident.
Établir une chronologie fiable de l’incident et de la réponse.
Identifier les causes, difficultés et points forts.
Transformer les constats en actions d’amélioration.
Vérifier que les actions décidées sont réellement réalisées.
Le REX doit revenir vers la gestion des risques
Si l’incident révèle une menace mal évaluée, une dépendance inconnue ou une mesure de sécurité insuffisante, ces éléments doivent alimenter l’analyse de risques et le plan d’amélioration de l’organisation.
Pendant toute la réponse
Documentation et traçabilité : le fil rouge de l’incident
La documentation n’est pas une dernière étape à réaliser une fois l’incident terminé.
Elle commence dès le premier signal et accompagne toute la réponse.
Plus l’incident dure, plus le nombre d’acteurs, de systèmes et de décisions augmente. Sans une chronologie commune, il devient rapidement difficile de distinguer ce qui a été observé, décidé, exécuté ou simplement envisagé.
La mémoire humaine n’est pas un journal d’incident
Après plusieurs heures de mobilisation, personne ne se souvient précisément de l’ordre des événements, de l’heure exacte d’une décision ou de la raison pour laquelle une action particulière a été réalisée.
La traçabilité permet également aux équipes qui rejoignent la réponse en cours d’incident de comprendre rapidement la situation sans recommencer l’analyse depuis le début.
Horodater les événements significatifs.
Identifier les personnes responsables des décisions et actions.
Distinguer les faits établis des hypothèses de travail.
Conserver les éléments de preuve utiles.
Tracer les actions ayant échoué autant que celles ayant réussi.
Conserver les décisions importantes et leur contexte.
Le principe à retenir
Si une information a influencé une décision importante, elle mérite probablement d’être tracée.
Une bonne chronologie ne sert pas uniquement au retour d’expérience. Elle permet de piloter l’incident pendant qu’il se déroule.
Pilotage de l’incident
En quoi ORKA peut aider ?
ORKA n’est ni un EDR, ni un SIEM, ni un outil d’investigation forensique.
Son rôle est différent.
Pendant un incident, de nombreux outils techniques peuvent produire des informations. La difficulté consiste ensuite à conserver une vision cohérente de la situation, des actions engagées, des responsables, des décisions prises et des éléments nécessaires au retour d’expérience.
Centraliser les premières informations et caractériser l’incident.
Suivre les actions, responsables et évolutions de la situation.
Associer les éléments utiles et conserver une chronologie exploitable.
Transformer le retour d’expérience en actions et en amélioration des risques.
L’intérêt est particulièrement visible lorsque plusieurs personnes ou équipes interviennent simultanément.
Une action technique peut être confiée à un administrateur. Une autre doit être réalisée par un prestataire. Une décision peut nécessiter l’accord du RSSI, du DSI ou d’un responsable métier.
Toutes ces informations participent à une même histoire : celle de l’incident.
À une condition essentielle
Un outil utilisé pour piloter un incident doit lui-même rester disponible. Son hébergement, son authentification, ses dépendances réseau et son accès doivent donc être intégrés à la stratégie de continuité de l’organisation.
La philosophie ORKA
Savoir ce qui s’est passé, ce qui a été décidé, ce qui a été fait et ce qu’il reste à améliorer.
Un incident se traite avec des outils techniques. Il se pilote avec de l’information, des responsabilités clairement identifiées et une chronologie fiable.
À retenir
La réponse à incident en six étapes
Comprendre ce qui se passe et évaluer le périmètre initial.
Limiter la propagation et éviter l’aggravation de la situation.
Comprendre l’origine, le périmètre et le scénario de l’incident.
Éliminer les causes, accès et mécanismes de persistance.
Restaurer progressivement les services et renforcer leur surveillance.
Analyser l’incident et transformer les constats en améliorations.
Et pendant les six étapes : documenter
Les faits, décisions, actions, responsables, preuves et résultats doivent constituer une chronologie continue de l’incident.
Cette méthode ne garantit pas qu’un incident sera simple à gérer. Aucun cadre ne peut supprimer l’incertitude, la pression ou les imprévus.
Elle permet en revanche de conserver une démarche structurée lorsque la situation devient complexe.
Le principe à retenir
Un incident bien géré est un incident dont on conserve progressivement la maîtrise
Les premières minutes d’un incident sont rarement confortables. Les informations manquent, les hypothèses se multiplient et la pression augmente rapidement lorsque les services métiers commencent à être touchés.
La méthode permet alors de garder un cap.
Comprendre suffisamment pour agir. Limiter les conséquences. Continuer à investiguer. Corriger ce qui doit l’être. Reprendre progressivement. Puis revenir sur l’événement pour éviter de reproduire les mêmes faiblesses.
Et pendant toute cette période, conserver une trace fiable de ce qui s’est réellement passé.
Une question simple
Si un incident majeur commençait maintenant, sauriez-vous où consigner la première information ?
Si la réponse n’est pas immédiate, c’est probablement un excellent premier point à travailler avant le prochain incident.