Ressources · 21

Qualifier un incident cyber et préserver les premières preuves

Transformer un signal confus en chronologie, hypothèses, décisions et escalade proportionnée.

Mis à jour le 28 octobre 2026 · 11 min

Ce que ce guide permet

Recevoir un signal utile
Préserver le contexte
Qualifier l’impact
Organiser les décisions

Contrôle express

Qui a observé quoi, où et quand ?
Quelles sources ou traces risquent de disparaître ?
Quels services, comptes et données pourraient être touchés ?
Qui décide des mesures immédiates ?
Quand la qualification sera-t-elle réévaluée ?

Méthode pas à pas

01
Ouvrir un dossier unique
Enregistrer le signal initial, l’heure, l’observateur, les systèmes concernés et le canal de remontée. Définir un responsable de suivi et une suppléance.
Livrable : fiche d’incident horodatée.
02
Séparer fait et hypothèse
Lister les observations vérifiables, leur source et leur degré de confiance. Formuler les scénarios possibles sans présumer de l’origine ou de l’étendue.
Livrable : chronologie factuelle et hypothèses à tester.
03
Préserver les éléments volatils
Identifier journaux, alertes, messages et états de systèmes utiles ; conserver des copies selon les procédures internes et noter qui a eu accès. Éviter toute manipulation qui détruit les traces.
Livrable : inventaire et chaîne de conservation initiale.
04
Évaluer portée et impact
Relier les actifs, comptes, données et parcours métier potentiellement touchés. Noter ce qui est confirmé, exclu ou encore inconnu et les conséquences d’une attente.
Livrable : carte de périmètre et niveau d’impact provisoire.
05
Décider et escalader
Choisir les mesures de protection proportionnées, les spécialistes à mobiliser et les interlocuteurs à informer selon les obligations applicables. Enregistrer le décideur et la justification.
Livrable : journal de décisions et plan de communication.
06
Réévaluer et apprendre
Fixer un prochain point de situation, intégrer les nouvelles preuves, puis relier les causes et écarts aux actions correctives une fois l’incident clos.
Livrable : mises à jour datées et retour d’expérience.

Comprendre · essayer · décider

Faux positifs : compter les cas avant de juger une alerte

Exemple fictif : 100 cas positifs sur 10 000 observations. Les étiquettes de référence sont connues ; chaque observation produit ici une seule décision : alerte ou absence d’alerte.

Le jeu contient 90 vrais positifs, 99 faux positifs, 10 faux négatifs et 9 801 vrais négatifs. Le rappel porte sur les cas positifs ; la précision porte sur les alertes. Ces résultats ne constituent pas une probabilité établie pour une alerte réelle.

Un jeu, plusieurs dénominateurs

Mesure	Calcul	Interprétation
Cas positifs de référence	100 / 10 000 · 1 %	Fréquence imposée dans ce jeu.
Cas positifs détectés	90 / 100 · 90 %	Rappel : dénominateur positif.
Alertes sur cas négatifs	99 / 9 900 · 1 %	Taux de faux positifs : dénominateur négatif.
Cas positifs parmi les alertes	90 / 189 · 47,62 %	Précision : dénominateur des alertes.
Cas négatifs sans alerte	9 801 / 9 900 · 99 %	Spécificité : dénominateur négatif.

Faire varier l’hypothèse

Ce qui change la conclusion

Changez une seule condition, puis indiquez quelle conclusion reste possible.

Définir le périmètre
Fixer unité, période, étiquettes et version de règle.
Compter les quatre issues
Conserver alertes et absences d’alerte dans le jeu de référence.
Qualifier les signaux
Rechercher des preuves sur le cas réel et documenter la décision.

Exercice fictif : aucune alerte réelle n’est traitée.

Et si les cas positifs passent à 10 % ?

Nouvel élément: Le second jeu contient 1 000 positifs sur 10 000, avec le même rappel et le même taux de faux positifs par hypothèse.
Conséquence pour la décision: Sur 990 alertes, 900 sont positives : la précision atteint 90,91 %. La population change le résultat ; ces taux constants sont une hypothèse pédagogique.

Et si seules les alertes ont été vérifiées ?

Nouvel élément: Les cas sans alerte ne disposent pas d’étiquette de référence.
Conséquence pour la décision: On ne connaît pas les faux négatifs : ne pas annoncer un rappel mesuré. Documenter la couverture des étiquettes et vérifier un périmètre adapté.

Et si un réglage réduit le nombre d’alertes ?

Nouvel élément: La nouvelle règle émet moins de notifications.
Conséquence pour la décision: Cela ne suffit pas à montrer une amélioration. Rejouer les mêmes cas étiquetés et comparer aussi les positifs manqués, les délais et la charge de qualification.

Indicateurs de pilotage

Indicateur	Ce qu’il mesure	Première action
Délai de qualification	Temps entre signal et premier périmètre documenté	Clarifier l’escalade
Traçabilité	Décisions avec heure, responsable et raison	Compléter le journal
Couverture des preuves	Sources critiques identifiées et préservées	Corriger la collecte
Réévaluation	Hypothèses reprises aux points prévus	Mettre à jour le périmètre

Erreurs fréquentes

Effacer les traces en intervenant trop tôt
Publier une cause avant validation
Laisser plusieurs chronologies contradictoires
Oublier de dater une décision ou de revoir une hypothèse

Questions fréquentes

Toute alerte est-elle un incident ?

Non. La qualification détermine si les observations justifient une réponse formelle et peut évoluer avec les preuves.

Faut-il attendre de tout comprendre pour protéger ?

Non. Des mesures proportionnées peuvent limiter l’impact pendant l’enquête, à condition de documenter leur effet sur les preuves et le service.

Que communiquer au départ ?

Les faits confirmés, les effets connus, les actions en cours et le prochain point. La cause et l’étendue restent provisoires tant qu’elles ne sont pas établies.

Incident, vulnérabilité ou fuite : choisir le bon interlocuteur

Un CSIRT accompagne un périmètre défini, appelé constituency : une organisation, un secteur ou un public. Son pays et son adhésion à FIRST ne suffisent pas à établir votre éligibilité, sa disponibilité ou les services proposés. Vérifiez ces trois points sur son site officiel.

Qualifier les faits
Vérifier le périmètre
Confirmer le canal officiel

Incident sur votre système

Contactez l’équipe interne ou le prestataire désigné dans votre plan de réponse. Cherchez un CSIRT couvrant votre organisation si une coordination externe est nécessaire.

Vérifiez le public accompagné, les modalités de signalement et les horaires ; un formulaire public ne garantit pas une réponse immédiate.

Chercher un CSIRT

Faille dans un produit tiers

Consultez la politique de divulgation de l’éditeur ou son équipe de sécurité produit (PSIRT). Le fichier /.well-known/security.txt peut indiquer le contact, la politique et le chiffrement.

Contrôlez le domaine, le champ Expires et le périmètre de la politique. security.txt n’autorise aucun test ; convenez du canal avant de transmettre une preuve sensible.

Comprendre la divulgation

Données personnelles concernées

Associez le responsable du traitement et le délégué à la protection des données, s’il existe, à l’équipe de réponse technique.

L’assistance technique et une éventuelle notification réglementaire sont des démarches distinctes. Faites déterminer l’autorité compétente, les conditions et les délais applicables à votre situation.

Consulter le dossier données

Préparer un premier contact utileChronologie avec fuseau horaire, service concerné et faits observés, séparés des hypothèses.Périmètre et impact connus, mesures déjà prises et personne habilitée à échanger.Résumé expurgé et canal de partage validé ; aucun mot de passe, jeton ou journal complet dans un formulaire public.

Cette liste prépare l’échange ; elle ne mesure ni la gravité ni la résolution de l’incident. Les choix restent dans cette page et ne sont pas envoyés.

Repères : FIRST, RFC 9116 et CNIL (cadre français). FIRST · CSIRT Services Framework 2.1 RFC 9116 · security.txt CNIL · Violations de données personnelles

Références : données, usages et limites

Documentation consultée le 2026-10-22.

Références : données, usages et limites
Source et objet	Donnée ou repère vérifié	Comment l’utiliser	Limite à conserver
NIST · SP 800-61 Rev. 3 Préparer la réponse à incident dans la gestion du risque cyber.	La révision 3 a été publiée en avril 2025 et remplace la révision 2. Elle se présente comme un profil communautaire du CSF 2.0.	Exercez décision de confinement, conservation des traces, communication et reprise. Comparez ce qui était prévu aux preuves produites pendant l’exercice. Approfondir la méthode →	Lire le guide ne valide pas un plan local. Les contacts, accès de secours et dépendances doivent être testés dans votre environnement.

Incident cyber : décisions et preuves de reprise

De l’alerte à la reprise : rendre les décisions vérifiables

Qualifier un signal, protéger les éléments d’enquête et restaurer un service ne répondent pas à la même question. Le CSF 2.0 distingue notamment la décision de démarrer la reprise, l’intégrité des moyens de restauration, la validation des actifs restaurés et la fin de la reprise. Ce sont des résultats à documenter, pas une certification ni une procédure unique.

Les douze repères ci-dessous sont une sélection du CSF 2.0, reformulée pour la lecture. Les colonnes de preuves, la chronologie et les injects sont des propositions pédagogiques originales. Ils ne remplacent pas le plan local ; aucun délai, niveau de gravité ou autorisation universels n’en sont déduits. La référence SP 800-61 Rev. 3 est finale depuis avril 2025 et remplace la Rev. 2.

Laboratoire de reprise fictif sans personne, baie isolée et mallettes de stockage sous une lumière ambre. — Illustration conceptuelle générée : laboratoire isolé de validation de reprise, sans personne. Aucun système réel, sauvegarde authentique ou résultat de sécurité n’est représenté.

Quatre décisions à distinguer pendant la reprise

RS.MA-05 : appliquer les critères de démarrage. RC.RP-03 : vérifier les moyens de restauration avant usage. RC.RP-05 : contrôler les actifs restaurés et le service. RC.RP-06 : déclarer la fin selon des critères et terminer la documentation. Ces repères ne constituent pas une chronologie obligatoire ; enquête et surveillance peuvent continuer.

Douze résultats NIST et les preuves qui les rendent exploitables

Douze résultats NIST et les preuves qui les rendent exploitables
Repère et sens reformulé	Pièce utile dans le dossier local	Conclusion à éviter
`RS.MA-02` Trier et valider les signalements.	Signal reçu, source vérifiée, horodatage et raison de la qualification provisoire.	Une alerte n’est pas automatiquement un incident confirmé.
`RS.MA-03` Catégoriser les incidents et les prioriser.	Type supposé ou confirmé, service concerné, impact, urgence et date de révision.	Le nombre d’alertes ne suffit pas à établir la gravité métier.
`RS.MA-04` Escalader ou porter la décision à un niveau supérieur si nécessaire.	Besoin de ressources, personne saisie, autorité attendue et prochaine réévaluation.	Ajouter des intervenants n’équivaut pas à obtenir une décision.
`RS.MA-05` Appliquer les critères de démarrage de la reprise.	Critères locaux, faits et hypothèses connus, risques de l’action, décideur et périmètre autorisé.	La restauration ne commence pas sur le seul constat qu’une copie existe.
`RS.AN-06` Consigner les actions d’enquête et préserver l’intégrité et la provenance du journal.	Action, auteur, heure, justification, effet observé et accès au journal protégé.	Un compte rendu réécrit sans historique ne prouve pas l’ordre des décisions.
`RS.AN-07` Collecter données et métadonnées d’incident en préservant leur intégrité et leur provenance.	Origine, collecte, horodatage, détenteur et règles de conservation ; accès réservé aux personnes habilitées.	Une empreinte seule ne prouve ni l’origine complète ni toutes les conditions de collecte.
`RC.RP-01` Exécuter la partie reprise du plan lorsqu’elle est déclenchée par le processus de réponse.	Plan et version utilisés, autorisations, personnes mobilisées et début des opérations.	La reprise peut se dérouler pendant ou après la réponse ; ce n’est pas toujours une phase totalement séparée.
`RC.RP-02` Choisir, délimiter, prioriser et effectuer les actions de reprise.	Services et dépendances visés, ordre, ressources, hypothèses et changements de périmètre.	Restaurer tous les actifs dans le même ordre ne reflète pas nécessairement les priorités.
`RC.RP-03` Vérifier l’intégrité des sauvegardes et autres moyens de restauration avant leur utilisation.	Contrôles prévus sur corruption, signes de compromission, cohérence et origine du candidat retenu.	Un travail de sauvegarde terminé avec succès ne valide pas à lui seul la copie.
`RC.RP-04` Tenir compte des fonctions critiques et du risque cyber pour définir le fonctionnement après incident.	Mode normal ou dégradé accepté, limites, propriétaire métier et surveillance adaptée.	Un mode dégradé ne doit pas être présenté comme un retour complet sans réserve.
`RC.RP-05` Vérifier les actifs restaurés, rétablir les services et confirmer leur fonctionnement.	Contrôles d’intégrité, causes traitées dans le périmètre, parcours métier testé et validation du propriétaire.	Des fichiers recopiés ou un écran accessible ne prouvent pas la reprise du parcours.
`RC.RP-06` Déclarer la fin de la reprise selon des critères et compléter la documentation de l’incident.	Décision de clôture, critères atteints, risques résiduels, bilan et actions attribuées.	Le retour du service ne ferme pas automatiquement toutes les investigations ou actions correctives.

Une chronologie fictive qui conserve ses incertitudes

Cas pédagogique : une application de traitement de demandes présente une activité inhabituelle sur un compte de service. T+0 correspond à 08:00 UTC dans cet exercice ; les durées ci-dessous ne constituent pas des objectifs NIST. Aucun nombre de dossiers touchés ni aucune fuite de données ne sont supposés sans preuve.

Une chronologie fictive qui conserve ses incertitudes
Temps de l’exercice	Observation ou décision	Preuve et limite
T+0 · 08:00 UTC	Une alerte signale un export inhabituel.	Conserver l’événement et sa source ; l’alerte seule ne prouve pas une exfiltration.
T+7 · 08:07 UTC	La source de l’alerte est validée ; la copie de nuit est marquée « terminée ».	Deux faits différents : le statut du travail n’établit pas l’intégrité de la copie.
T+12 · 08:12 UTC	Le responsable déclare l’incident dans le cadre du plan et fait suspendre un parcours sensible.	Consigner l’autorité, le périmètre connu et les effets métier ; l’étendue reste provisoire.
T+25 · 08:25 UTC	Des restrictions d’accès ciblées sont autorisées et consignées.	Tracer ce qui a effectivement changé. Cela ne prouve pas l’absence d’autres accès ou mécanismes de persistance.
T+40 · 08:40 UTC	Le contrôle d’un candidat de restauration révèle une corruption.	Ne pas utiliser ce candidat ; documenter le rejet et évaluer un autre point de restauration.
T+60 · 09:00 UTC	Un autre candidat satisfait les contrôles définis ; une restauration isolée est autorisée.	Conserver les résultats et le périmètre des contrôles. Leur succès n’équivaut pas à une garantie d’absence de compromission.
T+90 · 09:30 UTC	Les fichiers sont restaurés, mais une dépendance fait échouer le parcours métier.	La validation du service n’est pas acquise ; le dossier reste ouvert.
T+120 · 10:00 UTC	Le parcours critique est testé dans un mode dégradé accepté par le métier.	Tracer les limites et la surveillance. La clôture attend encore les critères et la décision prévus.

Six informations dans chaque décision importante

Fait observé: Source, heure d’événement, heure de collecte et fuseau.
Hypothèse: Ce qui est supposé, pourquoi et comment le vérifier.
Action décidée: Périmètre exact, auteur de la décision et personne chargée de l’exécution.
Effet constaté: Résultat effectivement observé, écart et éléments encore inconnus.
Preuve conservée: Référence protégée, provenance, intégrité et personnes habilitées.
Prochain point: Condition ou date de réexamen, responsable et dépendance bloquante.

Utiliser les six cartes d’exercice →

Références primaires et limites

Les identifiants et le sens des résultats proviennent du CSF 2.0 ; les recommandations de réponse et de reprise sont précisées dans SP 800-61r3. Les tableaux de preuves, horaires et scénarios sont pédagogiques, sans résultat client, certification ou notification réelle.

NIST · SP 800-61 Rev. 3 · Final · 2025-04-03
Community Profile CSF 2.0 ; remplace / supersedes Rev. 2
NIST · SP 800-61r3 — recommandations détaillées / detailed recommendations · April 2025
Pages imprimées / printed pages 27–29, 34–35 : RS.MA, RS.AN, RC.RP, RC.CO
NIST · Cybersecurity Framework 2.0 · 2024-02-26 · NIST CSWP 29
Appendix A, printed pages 22–23 : official outcome identifiers
NIST · SP 800-184 — Guide for Cybersecurity Event Recovery · Final · 2016-12-22
Recovery planning, playbooks, testing and improvement

Références relues le 2026-10-22

Indicateurs STIX et partage TLP

Relier l’indicateur aux observations et au retrait

Une correspondance avec un indicateur ouvre une piste d’analyse. Pour décider de sa portée, conserver les événements observés, le contexte technique, la couverture des capteurs et les hypothèses alternatives.

Distinguer Indicator, Observed Data et Sighting ; une assertion de renseignement ne remplace pas les données observées.
Ne pas assimiler une résolution DNS à une exécution ou un Sighting count=0 à une absence globale de menace.
Prévoir le responsable et le mécanisme de retrait des règles dérivées lors d’une expiration ou d’une révocation.

Consulter la fiche STIX, observations et partage TLP →

Sources vérifiées le 2026-10-22 · OASIS · STIX 2.1

OSINT : preuves et conservation

Préserver le contexte avant de confondre copie et preuve

Une réponse à incident doit relier les traces conservées à leur source, à leur périmètre et aux manipulations effectuées. Une empreinte protège une comparaison de contenu ; elle ne reconstitue pas une possession non documentée.

Attribuer des identifiants distincts à la référence conservée et aux copies de travail.
Consigner les remises, réceptions et incertitudes d’horloge.
Préserver un écart observé et sa référence avant d’en rechercher la cause.

Voir la filiation des copies et les huit cas de conservation →

Sources vérifiées le 2026-10-22 · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard

Codes syslog et preuves de collecte

Un code syslog ne qualifie pas seul un incident

Lors d’un triage, conservez la valeur brute, la source et la règle de normalisation. Une severity Informational peut documenter une authentification ou une action utile à l’enquête ; une valeur Emergency reste une déclaration de l’émetteur.

Rattacher le message à un actif connu et à son contexte d’exposition.
Comparer l’événement brut à la valeur visible dans le SIEM.
Relier l’alerte à une décision, avec les lacunes de collecte explicites.

Lire les codes syslog et tester le calcul PRI →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Références officielles

Date de consultation des références : 23/10/2026. La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.