Présentation de la fiche

A qui s'adresse-t-elle ?

• Responsables de la sécurité des systèmes d'information (RSSI)
• Administrateurs du système d'information
• Equipe sécurité

Quand l'utiliser ?

Utiliser cette fiche lorsqu'une compromission est suspectée ou confirmée sur une machine Windows ou Linux du système d'information.

A quoi sert-elle ?

L'objectif de cette fiche est de proposer une aide à la qualification d'un signalement de compromission système. Les différentes actions proposées aideront à :

• Confirmer qu'un incident de sécurité est bien en cours, et qu'un ou plusieurs systèmes sont compromis,
• Évaluer la gravité de l'incident en évaluant le périmètre affecté, l'impact potentiel sur le fonctionnement de l'organisation et l'urgence à le résoudre.

Comment l'utiliser ?

Deux parties principales composent cette fiche :

• La partie Conclusions attendues de la qualification correspond aux questions auxquelles la qualification devra répondre.
• La partie Méthode d'évaluation pas à pas correspond à la méthodologie pour aider à y répondre.

Cette fiche doit être exécutée en temps court. Pour cela, fixer un temps contraint (selon l'urgence pressentie) et ne pas rechercher l’exhaustivité des réponses : des réponses approximatives et des réponses "je ne sais pas répondre" sont acceptées dans un premier temps. Par la suite, une qualification plus approfondie se fera sûrement, avec plus de recul ou l'appui d'une équipe spécialisée en réponse à incident.

Sommaire

• Prérequis
• Conclusions attendues de la qualification
• Méthode d'évaluation pas à pas
  • Évaluer l'incident
    • Mesure 1 - Identifier le système concerné
    • Mesure 2 - Confirmer l'incident de type compromission système
    • Mesure 3 - Évaluer le périmètre de l'incident
    • Mesure 4 - Évaluer l'impact de l'incident
    • Mesure 5 - Évaluer l'urgence à résoudre l'incident
  • Qualifier l'incident
• Suite des actions
• Annexes

Prérequis

Avoir les personnes nécessaires

Avoir les personnes nécessaires

S'assurer que les personnes qui effectueront la qualification de l'incident aient les accès nécessaires au système d'information :

• Les accès à l'administration et au monitoring du système d'information
• Les accès aux équipements de sécurité du système d'information
• La connaissance des priorités métier de l'organisation
• L'annuaire de contacts d'urgence

Ces personnes peuvent être internes ou externes à l'organisation. Si le système d'information est infogéré, s'assurer de la capacité à mobiliser l'infogérant dans l'urgence.

Ouvrir une main courante

Dès le début de l'incident, ouvrir une main courante pour tracer toutes les actions et événements survenus sur le système d'information dans un ordre chronologique.

Chaque ligne de ce document doit représenter une action avec au minimum trois informations :

1. La date et l'heure de l’action ou de l'évènement (si estimé nécessaire, ajouter le fuseau horaire UTC)
2. Le nom de la personne ayant réalisé cette action ou ayant informé sur l'évènement
3. La description de l’action ou de l'évènement et les machines concernées

Ce document sera utile pour :

• Réaliser un historique du traitement de l'incident et partager les retours d'expérience
• Piloter la coordination des actions et suivre leur état d'avancement
• Évaluer l'efficacité des actions et leurs potentiels impacts non prévus

Cette main courante doit être éditable et consultable par tous les intervenants. Il est déconseillé de la stocker sur le système d'information compromis, où elle serait accessible par l'attaquant. En revanche, cette main courante peut être accessible sur un partage de fichiers en ligne (cloud) ou intégrée dans le logiciel de gestion d'incident ou le SIEM si l'organisation en possède un, voire être au format papier.

Avoir pris connaissance des actions déjà entreprises

Avoir pris note des personnes ayant déjà agi en réponse à l'incident en cours et des actions qu'elles ont déjà entreprises sur le système d'information. Commencer à reporter ces notes d'intervention dans la main courante.

Prendre en considération la présence active d'un attaquant

Important: Dans les actions d'endiguement, il est important d'éviter d'ouvrir une session interactive avec la machine suspectée compromise : connexion locale, RDP et SSH sont à minimiser, à fortiori avec un compte privilégié.

Si les actions à distance sont impossibles, autant que faire se peut :

1. Préférer les actions au travers d'un EDR ou un logiciel de gestion à distance n'ouvrant pas de système (type RMM).
2. Sinon, préférer une connexion locale - console physique, hors bande (Out-of-Band) ou d'hyperviseur - avec un compte administrateur uniquement local au système concerné.
3. En dernier recours, utiliser une connexion par le réseau qui ne met pas en danger le mot de passe des administrateurs : Powershell Remoting ou Windows Remote Shell (WinRS) qui permettent d'ouvrir l'équivalent d'un terminal, ou RDP en mode Restricted Admin qui n'autorise que Kerberos et n'autorise pas la mise en cache du TGT.

Tracer impérativement ces actions de connexion sur une machine compromise dans la main courante.

Conclusions attendues de la qualification

Cette partie résume les conclusions auxquelles doivent mener les évaluations, qui aboutiront à la qualification de l'incident.

La partie suivante présentera des actions détaillées pour guider pas à pas ces évaluations.

Évaluer l'incident

Mesure 1 - Identifier le système concerné

• La nature des informations transmises permet-elle d'identifier avec sureté le système compromis ?

Mesure 2 - Confirmer l'incident de type compromission système

• L'incident de type compromission système est-il confirmé, est-il un faux positif ou nécessite-t-il des investigations complémentaires ?

Mesure 3 - Évaluer le périmètre de l'incident

• L'incident est-il circonscrit à une partie du système d'information identifiable ?
• Les ressources d'administration ont-elles été compromises (comptes, postes, serveurs) ?
• Les autres systèmes d'information interconnectés avec celui de l'entreprise sont-ils en risque ?

Mesure 4 - Évaluer l'impact de l'incident

• Quelles activités métiers essentielles sont-elles ou peuvent-elles être perturbées ?
• Quelles chaînes d'activité sont impactées et dont la défaillance peut causer des perturbations graves ?

Mesure 5 - Évaluer l'urgence à résoudre l'incident

• Quelles sont les activités essentielles potentiellement perturbées, pour lesquelles des mesures préventives de maintien d'activité doivent être envisagées ?
• L'activité détectée est elle récente et donc sujette à évolution ou ancienne et stable ?
• L'incident est-il à risque de généralisation imminente (forte connectivité, atteinte à une fonction de sécurité) ?

Qualifier l'incident

Conclure quant à la gravité de l'incident

• La compromission d'une machine appartenant au système d'information est-elle confirmée ?

  • Si elle ne l'est pas, y a-t-il un risque de machine réellement compromise mais non identifiée ?

• L'incident est-il circonscrit sur mon système d'information, ou est-il étendu ?

• L'incident présente-il un impact fort pour mon activité métier et le fonctionnement de mon système d'information ?

• L'incident est-il urgent à résoudre, ou les activités vitales ont-elles réussi à être maintenues ?

• Au final, quelle gravité représente cet incident de sécurité ?

  • Anomalie courante
  • Incident mineur
  • Incident majeur
  • Crise cyber

Méthode d'évaluation pas à pas

Cette partie détaillera des actions qui aideront à conduire les évaluations et à aboutir à la qualification de l'incident.

Vous avez reçu une notification vous signifiant que vous étiez compromis.

Que celle-ci soit une détection interne, ou un signalement de tiers, il va falloir en évaluer la pertinence et la gravité.

Les informations signalant une compromission système sont généralement de 3 natures différentes:

1. Adresse réseau : adresse IP, nom d’hôte qualifié (FQDN), l'adresse peut être celle d'un équipement relais plutôt que directement la machine compromise (pare-feu, proxy, serveur DNS).
2. Nom de machine : nom Windows ou Unix d'une machine sans le domaine DNS ou Active Directory
3. Alerte de sécurité : alerte remontée par un capteur système comme un EDR, ou un événement système supervisé dans un SIEM

Évaluer l'incident

Mesure 1 - Identifier le système concerné

• Action 1.a : Identifier le système concerné

  • A partir d'une adresse réseau :
    • L'adresse IP est elle connue comme attribuée (DHCP, inventaire...)?
    • Le sous-réseau IP concerné fait-il partie des adresses (internes ou externes) utilisées sur le SI ?
    • Si l'adresse IP fait partie d'un pool DHCP, peut-on retrouver la machine portant l'adresse au moment de l'activité signalée ?
    • Si l'adresse est publique sur Internet, la machine peut-elle être associée à l'organisation (bannières, certificats TLS, services hébergés, etc.)
    • Le signalement pointe-t-il vers une machine susceptible d'en masquer plusieurs (Routeur, Proxy, Serveur DNS, Pare-feu, NAT) ?
      • Les informations du signalement permettent-elles d'identifier la machine derrière ce relais ?
      • Les journaux de l'équipement permettent-ils d'identifier les systèmes masqués ?
  • Sur la base d'un nom de machine :
    • La machine existe-elle dans un annuaire centralisé (Active Directory, orchestrateur) ?
    • La machine pourrait-elle être hors gestion centralisée (Workgroup, poste associé à une application métier, machine virtuelle hors domaine, instances de développement, etc.) ?
  • Confirmer la source précise d'une alerte venant d'un outil détection :
    • Les informations fournies par l'outil de détection permettent-elles d'identifier la machine compromise de façon sure ?

• Action 1.b : Recueillir les informations élémentaires de configuration système

  • Le système visé par le signalement peut-il être identifié ? Si oui :
    • Quel est le système d'exploitation opérant le système signalé ?
    • Quel est le niveau de version et d'installation de correctif déployé sur ce système ?
    • Est-ce que le système reliés à un système de synchronisation horaires (NTP) ?
    • Quelles applications métier sont installées sur ce système ?
    • Présence d'un logiciel dans un niveau de version susceptible d'être vulnérable à une faille activement exploité ? CISA KEV

• Action 1.c : Confirmer la validité du signalement Les erreurs de signalement étant fréquentes et source de perte de temps considérables, il est nécessaire de le confirmer :

  • L'architecture et la configuration du système concerné permet-elle de valider l'évènement à la date signalée ? (date trop ancienne ou réforme du système d'information entre temps)
  • L'horodatage est-il cohérent avec le reste du signalement
  • Le fuseau horaire de l'horodatage du signalement est-il compréhensible ?
  • Le système était-il en production aux dates et heures d'activité signalées ?
  • Les informations techniques signalées correspondent-elles au système (versions de système d'exploitation, ou type de compromission pouvant être incohérents) ?

L'objectif des actions précédentes est finalement de vous aider à répondre au besoin d'évaluation suivant :

• Action 1.d : (Conclure) Confirmer l'identification du système
  • La nature des informations transmises permet-elle d'identifier avec sûreté le système compromis ?

Mesure 2 - Confirmer l'incident de type compromission système

Confronter les informations du signalement aux informations observables du système d'information doit permettre de confirmer l'incident de type compromission système :

• Action 2.a : Si le signalement est un flux réseau

  • Le flux peut-il être observé dans les journaux d'un pare-feu ou du proxy ?
  • Le flux peut-est-il détecté par une sonde réseau (IDS) ?
  • Le flux montre-t-il une volumétrie inhabituelle ?

• Action 2.b : Si le signalement est une détection de code malveillant

  • Un EDR permet-il de vérifier la présence du code sur la machine ?
  • Une alerte antivirale est-elle visible (console, journaux et événements système)

• Action 2.c : Des flux inhabituels sont-ils visibles depuis cette machine ?

  • Connexion de nature ou de destination Internet inhabituelle (hébergement de VPS, flux TOR, Ports inhabituels)
  • Initiation de connexions internes, réussies ou non, vers des services inhabituels ou rares (tentatives de montage réseau, scan, tentative de connexions RDP ou SSH, résolution DNS...) ?
  • Des alertes de blocages de flux sont-elles associées à la machine ?

L'objectif des actions précédentes est finalement de vous aider à répondre au besoin d'évaluation suivant :

• Action 2.d : (Conclure) Confirmer l'incident de type compromission système
  • L'incident de type compromission système est-il confirmé, est-il un faux positif ou nécessite-t-il des investigations complémentaires ?

Mesure 3 - Évaluer le périmètre de l'incident

• Action 3.a : Identifier la fonction de la machine suspectée

  • Postes de travail ?
  • Serveurs applicatif ?
  • Serveurs de stockage ?
  • Hyperviseurs ?
  • Machines virtuelles ?
    • Sur quel hyperviseur ?
  • Machines physiques ?
  • Appliance en boite noire (équipements réseau et de stockage sans console système interactive) ?
  • La machine est-elle exempte de certaines mesures de sécurité (Machine de développement, En zone industrielle, Legacy) ?

• Action 3.b : Identifier la connectivité de la machine

  • Internet :
    • La machine expose-t-elle des services sur Internet ?
    • La machine peut-elle initier des connexions vers Internet ?
  • Interconnexions :
    • La machine peut-elle monter des connexions vers des systèmes de partenaires ou clients ?
    • La machine reçoit-elle des connexions de partenaires, clients ou utilisateurs distants ?
    • La machine peut-elle servir de pont entre le réseau local et des réseaux plus sensibles ?

• Action 3.c : Identifier la volumétrie potentielle

  • Le signalement pointe-t-il vers plusieurs machines ?
  • Si le système compromis était derrière un relais (routeur, proxy, pare-feu...)
    • Les anomalies détectées sur la machine compromise existent-elles sur d'autres machines ?

L'objectif des actions précédentes est finalement de vous aider à répondre au besoin d'évaluation suivant :

• Action 3.e : (Conclure) Évaluer le périmètre de l'incident
  • L'incident est-il circonscrit à une partie du système d'information identifiable ?
  • Les ressources d'administration ont-elles été compromises (comptes, postes, serveurs) ?
  • Les autres systèmes d'information interconnectés avec celui de l'entreprise sont-ils en risque ?

Mesure 4 - Évaluer l'impact de l'incident

• Action 4.a : Évaluer niveau de compromission pouvant résulter de la prise de contrôle de la machine

  • Des comptes d'administration globaux (administrateur du domaine ou administrateur équivalent à pouvoir agir sur la totalité du SI) se sont-ils récemment connectés sur la machine et surtout depuis le dernier reboot ?
  • La machine porte-t-elle une fonction de sécurité: ?
    • Gestion des identités
    • Gestion des mises à jour
    • Gestion de configuration et déploiement (SCCM, Orchestrateur...)
    • Console de contrôle d'une fonction vitale (EDR, sauvegarde, hyperviseur)
    • Hyperviseur
    • La machine donne-t-elle accès à des services critiques ?
      • Poste d'administration
      • Serveur de rebond d'administration (bastion)
    • La machine porte-t-elle ou contribue-t-elle significativement à une activité vitale ?

• Action 4.b : Évaluer les impacts potentiels sur l'activité métier

  • Quelles activités métiers sont concernées par la machine suspectée, à usage interne ou externe ?
  • Quelles activités potentiellement perturbées sont vitales pour l'organisation ?
    • Si votre organisation possède un BIA (Business Impact Analysis), ces activités y ont-elles été analysées ?
  • Parmi les activités potentiellement perturbées, certaines provoquent-elles une importante perte financière ?

• Action 4.c : Évaluer les impacts réglementaires

  • Le système d'information affecté est-il soumis à une réglementation particulière (OSE, OIV, NIS2, etc.) ?
  • Peut-on savoir si le système d'information affecté stocke des données sensibles ?
    • données classifiées
    • données personnelles
    • données à statut protégé : de santé, financières
    • données soumises à engagement contractuel ou réglementaire autre.

L'objectif des actions précédentes est finalement de vous aider à répondre au besoin d'évaluation suivant :

• Action 4.e : (Conclure) Évaluer l'impact potentiel de l'incident
  • Quelles activités métiers essentielles sont-elles ou peuvent-elles être perturbées ?
  • Quelles chaînes d'activité sont impactées et dont la défaillance peut causer des perturbations graves ?

Mesure 5 - Évaluer l'urgence à résoudre l'incident

• Action 5.a : Évaluer l'urgence métier à résoudre l'incident Pour chacune des activités vitales impactées identifiées précédemment :

  • Existe-il une procédure de continuité d'activité en mode nominal ?
  • Existe-il une procédure de maintien d'activité en mode dégradé ?

• Action 5.b : Évaluer la récence de l'information

  • Le signalement est-il a propos d'une détection récente ?
  • Si oui, l'activité détectée est-elle récente ou peut-elle être détectée dans le passé ?

L'objectif des actions précédentes est finalement de vous aider à répondre au besoin d'évaluation suivant :

• Action 5.c : (Conclure) Évaluer l'urgence à résoudre l'incident
  • Quelles sont les activités essentielles potentiellement perturbées pour lesquelles des mesures préventives doivent être envisagées ?
  • L'activité détectée est-elle récente et donc sujette à évolution, ou ancienne et stable ?
  • L'incident est-il à risque de généralisation imminente (forte connectivité, atteinte à une fonction de sécurité) ?

Qualifier l'incident

Conclure quant à la gravité que représente l'incident de sécurité pour mon organisation, en prenant en compte le périmètre affecté, l'impact potentiel sur le fonctionnement de l'organisation et l'urgence à le résoudre :

• La compromission d'une machine appartenant au système d'information est-elle confirmée ?

  • Si elle ne l'est pas, y a-t-il un risque de machine réellement compromise mais non identifiée ?

• L'incident est-il circonscrit sur mon système d'information, ou est-il étendu ?

• L'incident présente-il un impact fort pour mon activité métier et le fonctionnement de mon système d'information ?

• L'incident est-il urgent à résoudre, ou les activités vitales ont-elles réussi à être maintenues ?

• Au final, quelle gravité représente cet incident de sécurité ?

  • Anomalie courante
  • Incident mineur
  • Incident majeur
  • Crise cyber

Suite des actions

Si l'incident de compromission système est confirmé alors, en cohérence avec le périmètre de compromission évalué :

• Mettre en œuvre des mesures d'endiguement pour contenir l'attaque.
  • Fiche suivante conseillée : Fiche réflexe - Compromission système - Endiguement

Parallèlement, piloter la suite du traitement de cet incident et demander de l'aide pour résoudre l'incident, en cohérence avec les impacts identifiés :

• Mettre en œuvre une gestion d'incident cyber pour piloter la résolution de l'incident.
  • Voir les annexes Contacts et Déclarations.

De plus, si l'incident a un périmètre étendu sur le système d'information, qu'il a un impact fort et qu'il nécessite une résolution urgente :

• Activer le dispositif de gestion de crise cyber de l'organisation pour piloter la résolution de l'incident et la continuité d'activité.
  • Guide conseillé : Crise cyber, les clés d'une gestion opérationnelle et stratégique

Annexes

Définitions

Compromission système

Une compromission système est l'activité d'un code ou d'un acteur malveillant sur une machine du système d'information, résultant en sa prise de contrôle.

Faute de pouvoir qualifier précisément la prise de contrôle, dans de nombreux cas, toute activité adverse sur le système pouvant avoir donné lieu à une escalade de privilège est considérée comme une compromission. Une compromission entraîne généralement une forme de communication entre la machine compromise et un attaquant y exécutant des actions.

Qualifier un incident

Qualifier un incident signifie :

• Confirmer qu'un incident de sécurité est bien en cours et si oui, déterminer précisément sa nature.
• Évaluer la gravité/priorité de l'incident en évaluant le périmètre affecté, l'impact potentiel sur le fonctionnement de l'organisation et l'urgence à le résoudre.

La qualification permettra de prendre des décisions éclairées sur la réponse à l'incident et d'allouer les ressources appropriées pour le résoudre.

Endiguer un incident

L'endiguement désigne l’ensemble des actions prises au début d’un incident de sécurité informatique destinées à en contenir l’ampleur. Elles n’ont généralement pas vocation à être prolongées durablement.

Axes d'évaluation

• Périmètre : Le périmètre d'un incident désigne son étendue sur le système d'information et dans son administration.
• Impact : L'impact d'un incident désigne le niveau de perturbation et de dommage potentiel qu'il engendre pour l'organisation.
• Urgence : L'urgence d'un incident désigne la rapidité avec laquelle il faut réagir pour rétablir les activités essentielles impactées.

Degrés de gravité

• Anomalie courante (gravité faible) : Une anomalie courante est un incident de sécurité ne représentant pour l'instant pas de menace sérieuse pour la sécurité du système d'information et n'entraînant pas d'impact significatif sur l'activité métier. Elle nécessite tout de même d'être correctement qualifiée pour confirmer son faible degré de gravité.
• Incident mineur (gravité modérée) : Un incident mineur est un incident de sécurité représentant une menace limitée pour le système d'information et entraînant - ou risquant d'entraîner - un impact modéré sur l'activité métier.
• Incident majeur (gravité élevée) : Un incident majeur est un incident de sécurité représentant une menace sérieuse pour le système d'information et entraînant - ou risquant d'entraîner - un impact fort sur l'activité métier.
• Crise cyber (gravité critique) : Une crise cyber représente un incident de sécurité ayant un périmètre étendu sur le système d'information, un impact fort sur l'activité métier et nécessitant une résolution urgente.

Contacter le CERT-FR

Important

Quand vous effectuez un signalement auprès du CERT-FR, un numéro de référence vous est attribué. Pensez à rappeler ce numéro quand vous nous recontactez, ou dans l'entête de vos messages afin de simplifier le suivi du cas.

Par Téléphone

Le CERT-FR est joignable 7J/7, 24H/24:

• depuis la France métropolitaine au 3218 (service gratuit + prix d’un appel) ou 09 70 83 32 18
• depuis certaines collectivités territoriales situées en Outre-mer ou depuis l’étranger au +33 9 70 83 32 18

Par Internet

• mèl: cert-fr@ssi.gouv.fr
• site: https://cert.ssi.gouv.fr/contact/

Clé PGP du CERT-FR

Pour vérifier l’intégrité des informations fournies ci-dessous, veuillez contacter le CERT-FR.

Identifiant de la clé : 0x1B45CF2A

Empreinte de la clé : 7F4C 8FA6 A356 D1CC 2E5C AB09 5416 33B8 1B45 CF2A

Télécharger la clé publique: https://cert.ssi.gouv.fr/uploads/public_key_2024.asc

Contacts

La gestion d’un incident cyber implique de faire appel à des équipes spécialisées au sein de CERT/CSIRT, qui appuieront les équipes internes dans la réalisation de leurs actions de défense.

Qui ?	Comment ?	Pour qui ?
CERT/CSIRT interne de l'organisation
CERT/CSIRT externe en prestation de réponse à incident	https://www.cybermalveillance.gouv.fr/diagnostic/accueil https://cyber.gouv.fr/produits-services-qualifies	Pour les petites organisations : consulter le registre des prestataires spécialisés sur Cybermalveillance Pour les organisations opérant un système d’information complexe : faire appel à un Prestataire qualifié de Réponse à Incidents de Sécurité (PRIS)
CSIRT régional	https://www.cert.ssi.gouv.fr/csirt/csirt-regionaux	Pour les organisations de taille intermédiaire : collectivités territoriales, PME, ETI ou associations
CERT sectoriel	https://www.cert-aviation.fr https://www.m-cert.fr https://esante.gouv.fr/produits-services/cert-sante	Pour les organisations du secteur de l'aviation, maritime ou santé
CERT-FR	https://www.cert.ssi.gouv.fr/contact	Pour les administrations et les opérateurs d’importance vitale et de services essentiels

De plus, pour les incidents complexes, une aide externe est également recommandée pour :

• Gérer la crise
• Gérer la communication interne et externe
• Augmenter les ressources humaines et capacitaires de reconstruction de votre direction informatique

Pour faciliter la mobilisation de tous ces acteurs, il est conseillé de s’appuyer sur des annuaires tenus à jour en amont et accessibles même en cas d'indisponibilité du système d'information.

Déclarations

Conjointement à la résolution de l'incident, des déclarations doivent être effectuées :

Qui ?	Comment ?	Pourquoi ?
Assureurs		Notifier son assurance cyber permet de démarrer la prise en compte de la couverture et d'identifier des prestataires que l’assureur pourra recommander ou mandater.
ANSSI	https://www.cert.ssi.gouv.fr/contact/ https://cyber.gouv.fr/notifications-reglementaires	L’administration, les opérateurs d’importance vitale et de services essentiels, et toute organisation impliquant des informations classifiées, doivent déclarer leurs incidents à l'ANSSI.
Dépôt de plainte	https://www.francenum.gouv.fr/guides-et-conseils/protection-contre-les-risques/cybersecurite/comment-porter-plainte-en-cas-de	Déposer plainte permet de déclencher une enquête et de dégager votre responsabilité en cas de propagation de l’attaque à d’autres victimes.
CNIL	https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles	Les incidents affectant des données personnelles doivent faire l’objet de déclaration à la CNIL dans un délai de 72 heures. En cas de doute, il faut faire une pré-déclaration précisant avoir subi une potentielle compromission même si aucune exfiltration de données n'a été confirmée.
Autres autorités		Une organisation d'un domaine réglementé (finance, santé, etc.) est astreinte à des obligations de déclaration spécifiques. Dans le doute, consulter le service juridique.

Préparation

En prévention d'un incident, une fiche réflexe sera d'autant plus efficace si elle a pu être contextualisée et traduite en une procédure interne et actionnable immédiatement à son système d'information. Dans une situation d’urgence, elle augmentera la rapidité de la réponse, minimisera les erreurs de manipulation et permettra à une personne d'astreinte moins expérimentée de mener ces actions.

Liens utiles

Lors d'une lecture préparatoire de cette fiche ou pour aller plus loin dans la compréhension et la mise en œuvre des notions évoquées, certains documents annexes peuvent être utiles :

• Fiche réflexe - Compromission système - Endiguement
• Crise d’origine cyber, les clés d’une gestion opérationnelle et stratégique
• Cyberattaques et remédiation

Licence

Ce document est dérivé des les travaux du GT Fiches Réflexes de remédiation de l'InterCERT FRANCE

Les documents originaux peuvent être consultés sur le site de l'InterCERT-France (https://www.intercert-france.fr/).

Le présent document est publié sous licence CC BY-NC-SA 4.0.