Organigramme du processus de réponse aux incidents de sécurité
Un organigramme du processus de réponse aux incidents de sécurité, depuis la détection et le tri jusqu'au confinement, l'éradication, la notification et l'examen des violations.
Qu'est-ce que le processus organigramme du processus de réponse aux incidents de sécurité ?
Un processus de réponse aux incidents de sécurité est la séquence qu'une organisation suit depuis le moment où quelque chose de suspect est repéré jusqu'au moment où l'enregistrement de l'incident est fermé. Ce n’est délibérément pas la même chose qu’un processus d’incident de service informatique. L’objectif n’est pas seulement de rétablir le service, mais aussi de déterminer ce qu’un attaquant a fait, de l’empêcher d’en faire davantage, de conserver les preuves intactes et de décider si l’incident doit être signalé à un régulateur.
La plupart des processus publiés partagent le même squelette. Le NIST SP 800-61r2 le divise en préparation, détection et analyse, confinement, éradication et récupération, et activité post-incident. ISO/IEC 27035 utilise la planification et la préparation, la détection et le reporting, l'évaluation et la décision, les réponses et les leçons apprises. Ce graphique suit cette forme et présente les deux décisions qui suscitent le plus de controverses lors d'un incident réel : s'agit-il réellement d'un incident de sécurité et la violation doit-elle être notifiée.
Les choses que les équipes se trompent sous la pression sont généralement les règles d'ordre. Le confinement d'un hôte en le mettant hors tension détruit les preuves de mémoire volatile. Reconstruire un serveur avant que la portée ne soit analysée signifie que vous ne pouvez plus prouver ce qui a été pris. Le rétablissement du service avant que les systèmes ne soient vérifiés propres réinfecte le domaine. Se mettre d'accord sur la séquence à l'avance, avec une voie par rôle, est la façon dont ces règles survivent à un appel à trois heures du matin.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq voies de rôle (rapporteur et détection, équipe de sécurité, commandant de l'incident, opérations informatiques, juridique et communications) réparties en cinq colonnes de phases : détection et signalement, triage et classification, confinement, éradication et récupération, et notification et examen.
- Détection et reporting : activité suspecte générée via un canal d'incident unique, puis enregistrée par l'équipe de sécurité avec le démarrage de la chronologie de l'incident.
- Un « Incident de sécurité confirmé ? » décision après triage, envoi des faux positifs dans un dossier fermé et des incidents confirmés vers la classification de la gravité et de l'impact.
- Un « Incident de haute gravité ? » décision qui désigne un commandant d'incident nommé pour les cas de haute gravité et achemine tout le reste directement vers le confinement.
- Le confinement est divisé en court terme (isoler les systèmes affectés) et long terme, avec préservation des preuves et imagerie du système entre les deux, suivi d'une analyse de la portée, de l'éradication et d'un « Systèmes vérifiés propres ? » vérifiez que cela revient à l'isolement en cas d'échec.
- Un message « Violation à notifier ? » décision appartenant aux services juridiques et aux communications, acheminement vers le régulateur et notification à la personne concernée dans la fenêtre statutaire, puis examen post-incident et clôture avec enregistrements des leçons.
Quand utiliser ce modèle
- Vous rédigez ou actualisez un plan de réponse aux incidents et avez besoin d’une seule page indiquant qui fait quoi et dans quel ordre.
- Vous vous préparez à un audit ISO 27001 ou à un examen de sécurité client et il vous a été demandé de montrer un processus de réponse documenté (le diagramme démontre le processus, il ne démontre pas à lui seul la conformité).
- Vous effectuez un exercice sur table et souhaitez que les points de décision, les transferts et l'horloge de notification soient présentés pour être testés.
- Vous intégrez de nouveaux analystes ou une rotation d'astreinte qui comprend des personnes extérieures à l'équipe de sécurité.
- Vous souhaitez que les services de sécurité, les opérations informatiques et les services juridiques conviennent de leurs transferts avant un incident plutôt que pendant celui-ci.
Comment cela fonctionne
Renommez les voies selon vos rôles réels
Remplacez les cinq voies par les rôles que vous avez réellement : SOC ou MSSP, centre de services, responsable de la sécurité, équipe de plateforme, DPO, légiste externe ou conseiller en matière de violation. Si un rôle n’existe pas, supprimez la voie plutôt que de la laisser sans personnel.
Définissez vos critères de gravité
Ouvrez la case « Classifier la gravité et l'impact » et remplacez la note par votre propre matrice : qu'est-ce qui rend un incident de haute gravité, qui est autorisé à le déclarer et quel temps de réponse vous engage à chaque niveau.
Réparer la fenêtre de notification et le régulateur
Modifiez le champ « Violation à notifier ? » décision, elle nomme donc les régimes qui s'appliquent à vous : RGPD britannique ou européen (72 heures pour l'autorité de contrôle), NIS2, HIPAA, règles sectorielles et éventuels délais de préavis contractuels aux clients, qui sont souvent plus courts que les délais légaux.
Ajoutez les points de contact dont les gens ont besoin à 3 heures du matin
Mettez le canal de l'incident, le numéro d'astreinte, la rotation du commandant de l'incident et l'emplacement de stockage des preuves dans la case commentaires, afin que le diagramme soit utilisable lors d'un incident et pas seulement lors d'un examen.
Ajustez les boucles et ajoutez les étapes manquantes
Décidez si le message « Systèmes vérifiés propres ? » Le retour à l'isolement correspond à votre façon de travailler et ajoutez tout ce qui est spécifique à votre patrimoine, comme l'engagement d'un fournisseur de médecine légale retenu, une notification de cyber-assurance ou une étape d'approbation des communications client.
Faire circuler pour approbation et conserver la version
Partagez le tableau avec le responsable de la sécurité, les opérations informatiques et le service juridique pour approbation, puis conservez la version approuvée. Un plan de réponse aux incidents est un document contrôlé et la version que vous exercez doit être celle que vous publiez.
Questions fréquentes
Quelles sont les étapes du processus de réponse aux incidents ?
Ce tableau en utilise cinq : détection et signalement, triage et classification, confinement, éradication et rétablissement, et notification et examen. Cela correspond étroitement au NIST SP 800-61r2, qui utilise la détection et l'analyse ; confinement, éradication et rétablissement ; et l'activité post-incident. Le NIST comporte également une phase de préparation, mais la préparation est un travail continu (outillage, rotations, exercices, rétentions) plutôt qu'une étape que vous effectuez lors d'un incident, elle n'est donc pas tirée sur le flux.
En quoi la réponse aux incidents de sécurité est-elle différente de la gestion des incidents informatiques ?
Un incident de service informatique est terminé lorsque le service est rétabli. Il n’y a pas d’incident de sécurité, car il y a un adversaire. Une restauration trop précoce peut rétablir l'accès de l'attaquant, et il existe des obligations qu'un processus d'incident ITIL ne comporte pas : conserver les preuves avant la reconstruction, déterminer quelles données ont été affectées et informer les régulateurs et les individus si nécessaire. C'est pourquoi ce tableau place la préservation et l'imagerie des preuves avant l'éradication, et ajoute une branche de notification après la récupération.
Qui devrait être le commandant de l’intervention, et quand est-il nommé ?
Le commandant de l'incident doit être celui qui a le pouvoir de prendre des décisions (mettre un système de production hors ligne, faire appel à un conseil externe, contacter les clients), et pas nécessairement la personne la plus technique disponible. Ils coordonnent plutôt qu’enquêtent. Dans ce tableau, le commandant est affecté uniquement lorsque la question « Incident de haute gravité ? » la décision renvoie oui ; les incidents de moindre gravité restent avec l’équipe de sécurité. Lors d'un incident de longue durée, le rôle est transféré explicitement à chaque changement d'équipe.
Quand commence le délai de notification de 72 heures en cas de violation ?
En vertu du RGPD du Royaume-Uni et de l'UE, le délai de 72 heures court à partir du moment où l'organisation prend conscience qu'une violation de données personnelles a eu lieu, et non à partir du début de l'attaque ou de la conclusion de l'enquête, et vous pouvez notifier par étapes si l'image complète n'est pas encore disponible. La notification des personnes concernées constitue un test distinct : elle est requise sans retard injustifié lorsque la violation est susceptible d'entraîner un risque élevé pour elles. D'autres régimes utilisent des horloges différentes, alors réglez celle qui s'applique à vous sur la boîte de décision.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus d'assistance informatique (incidents et demandes) et passe le relais à Organigramme du processus de réponse aux violations de données (horloge RGPD….
C'est une étape de Réponse aux incidents de sécurité.
Étape 1: Organigramme du processus de réponse aux incidents de phishing (e-mail signalé)
Étape 2: Organigramme de classification de la gravité des incidents
Étape 3: Organigramme du processus de réponse aux incidents de cybersécurité (SOC)
Étape 4: Organigramme du processus de remontée des incidents de sécurité (SOC à RSSI)
Modèle d'organigramme du processus d'escalade des incidents de sécurité : triage SOC, porte de gravité S1/S2, gestion des incidents et propriété du RSSI, équipe de crise, vérification des données personnelles et notification externe.
Étape 5: Organigramme du processus de réponse aux incidents de sécurité Vous êtes ici
Un organigramme du processus de réponse aux incidents de sécurité, depuis la détection et le tri jusqu'au confinement, l'éradication, la notification et l'examen des violations.
Étape 6: Organigramme du processus de réponse aux violations de données (horloge RGPD…
Un organigramme pour la réponse aux violations de données personnelles : le confinement, le test de risque pour les individus, la notification du régulateur dans les 72 heures et le registre des violations.