Organigramme du processus de réponse aux incidents de cybersécurité (SOC)
Organigramme à couloirs du cycle de vie de réponse aux incidents techniques de cybersécurité qu'un SOC ou un CSIRT exécute, du tri des alertes à l'éradication, en passant par la récupération et le réglage des règles.
Qu'est-ce que le processus organigramme du processus de réponse aux incidents de cybersécurité (soc) ?
Un processus de réponse aux incidents de cybersécurité est le cycle de vie de travail qu'un centre d'opérations de sécurité ou CSIRT suit une fois qu'une détection se déclenche. Triez et enrichissez l'alerte, décidez si elle est vraiment positive, déclarez un incident et définissez sa gravité, attribuez-y un commandant, trouvez tous les actifs et comptes touchés par l'attaquant, confinez sans détruire les preuves, supprimez la menace, prouvez qu'elle a disparu, et ensuite seulement restaurez-la. Ce modèle trace cette séquence sur cinq voies : Détection/SOC, Intervenant en cas d'incident, Commandant de l'incident, Opérations informatiques et Gestion.
Il convient de préciser ce que ce processus n'est pas, car deux processus voisins y sont souvent fusionnés et tous deux s'en affaiblissent. Il ne s’agit pas d’une gestion des incidents informatiques, qui se mesure à la restauration d’un service perturbé et se clôture une fois que l’utilisateur travaille à nouveau ; un incident de sécurité n'est pas terminé lorsque le service est de retour, car une restauration précoce peut rendre l'accès à l'attaquant. Il ne s’agit pas non plus d’une notification de violation. Décider si des données personnelles ont été concernées, si un régulateur ou un client doit être informé et à quelle heure relève du service juridique, du délégué à la protection des données et des communications, se déroule dans les délais légaux plutôt que techniques et fait partie du processus plus large de réponse aux incidents de sécurité. Ce tableau accompagne ce travail plutôt que de l’absorber.
La forme suit la séquence des actions d'orientation les plus publiées. Le modèle en six étapes du SANS - préparation, identification, confinement, éradication, rétablissement, leçons apprises - s'y applique directement, et le NIST SP 800-61 Révision 2 regroupe le même travail que la détection et l'analyse ; confinement, éradication et rétablissement ; et l'activité post-incident. La révision 3 réorganise les orientations autour des fonctions du Cybersecurity Framework 2.0 plutôt qu'une liste de phases fixe, mais l'ordre dans lequel un intervenant travaille réellement reste inchangé. La préparation n'est pas dessinée comme une boîte car il s'agit d'un travail continu - outillage, rotations, retenues, exercices - plutôt que d'une étape réalisée lors d'un incident. Ce que le diagramme est réellement là pour protéger, c'est l'ordre : des preuves avant l'éradication, une vérification avant la restauration et une personne nommée qui peut autoriser la mise hors ligne d'un système de production.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq voies de rôle - Détection/SOC, Intervenant en cas d'incident, Commandant d'incident, Opérations informatiques et Gestion - réparties en six colonnes de phases : détection et triage, déclaration, cadrage et confinement, éradication, récupération et leçons apprises.
- Triage dans la voie SOC : « Trier et enrichir l'alerte » en alimentant un « Vrai positif ? » décision, dont aucune branche n'exécute « Fermer l'alerte et ajuster la règle » afin qu'un faux positif modifie la détection au lieu d'être simplement rejeté.
- Transfert et commandement : « Déclarer l'incident et définir la gravité » déplace le travail du SOC vers un intervenant en cas d'incident, et « Attribuer le commandant de l'incident » nomme la personne qui prend les décisions pour le reste de l'incident.
- Un « Le confinement va perturber les services ? décision appartenant au commandant de l'incident, dont la branche oui passe par « Autoriser le confinement perturbant le service » dans la voie de gestion avant que les opérations informatiques n'exécutent « Isoler les hôtes et les comptes concernés ».
- Preuves avant nettoyage : « Préserver les preuves médico-légales et les images » se situe entre le confinement et la colonne d'éradication, qui couvre la recherche de nouvelles positions d'attaquants, la suppression des logiciels malveillants et de la persistance, la réinitialisation des informations d'identification et la correction des failles exploitées.
- Une « Menace entièrement supprimée ? » décision de vérification qui revient à « Identifier les actifs et les comptes concernés » en cas d'échec, puis à reconstruire à partir de sauvegardes propres, de restauration surveillée dans la voie SOC, d'un examen post-incident et de « Mettre à jour les règles de détection et les playbooks » avant la fermeture.
Quand utiliser ce modèle
- Vous exécutez ou mettez en place un SOC ou un CSIRT et souhaitez que le cycle de vie technique se déroule sur une seule page, de la file d'attente d'alertes à la règle de détection qui se déclenchera la prochaine fois.
- Vous rédigez la moitié du runbook d'un plan de réponse à un incident et vous avez besoin de l'ordre de confinement, de preuves et d'éradication convenu avant un incident plutôt que discuté pendant celui-ci.
- Vous préparez un exercice sur table ou un test en équipe violette et souhaitez que les points de décision, les boucles et les transferts soient présentés pour tester.
- Vous avez besoin que la sécurité, les opérations informatiques et la direction conviennent à l'avance de qui peut autoriser la mise hors ligne d'un système de production et de ce qui se passe lorsque cette personne dort.
- Vous intégrez des analystes et souhaitez que le cheminement d'escalade, depuis le triage jusqu'à l'intervenant jusqu'au commandant de l'incident, soit tracé explicitement plutôt que appris par osmose.
Comment cela fonctionne
Renommez les voies selon votre véritable structure
Remplacez la détection/SOC, l'intervenant en cas d'incident, le commandant d'incident, les opérations informatiques et la gestion par ce dont vous disposez réellement : un MSSP externalisé, de niveau 1 et de niveau 2 divisés en voies séparées, une plateforme ou une équipe cloud au lieu des opérations informatiques, un fournisseur d'investigation retenu. Supprimez une voie plutôt que de la laisser sans personnel et fusionnez le commandant dans la voie des intervenants si une personne fait réellement les deux.
Mettez votre matrice de gravité sur l'étape de déclaration
Ouvrez « Déclarer l'incident et définir la gravité » et remplacez la note par vos propres critères : qu'est-ce qui rend un incident critique, qui est autorisé à le déclarer et à quoi chaque niveau vous engage en termes de temps de réponse, de personnel et d'appel en dehors des heures d'ouverture. La gravité est ce qui détermine chaque décision en aval sur ce graphique, cela vaut donc la peine d'être précis.
Définir la règle d'autorisation de confinement
Le message « Le confinement va perturber les services ? La succursale ne fonctionne que si quelqu'un peut y répondre à trois heures du matin. Notez quels systèmes peuvent être isolés sous la propre autorité de l'intervenant, lesquels nécessitent une décision commerciale, qui détient cette décision et ce qui se passe s'ils ne peuvent pas être atteints dans un délai convenu.
Fixer les règles de preuve avant le confinement
Enregistrez votre ordre de collecte sur « Préserver les preuves médico-légales et les images » : état de la mémoire et du réseau actif avant le disque, disque avant les journaux archivés, en suivant l'approche par ordre de volatilité définie dans la RFC 3227. Notez que les hôtes sont isolés au niveau de la couche réseau plutôt que mis hors tension, et indiquez où les images sont stockées et qui les signe.
Définir ce que signifie « menace entièrement supprimée »
Écrivez les critères de sortie à côté de la mention « Menace entièrement supprimée ? » décision : la fenêtre d'observation sans activité d'attaquant, chaque indicateur balayé dans le domaine, chaque identifiant compromis alterné, la vulnérabilité exploitée corrigée. Décidez également si la branche défaillante revient au cadrage, comme c'est le cas ici, ou au confinement.
Connectez-le aux processus de chaque côté et versionnez-le
Ajoutez des liens explicites vers votre chemin de notification de violation, vers la gestion des problèmes ou des modifications pour les correctifs permanents, et vers la cyber-assurance ou la notification des fournisseurs le cas échéant. Faites ensuite circuler le tableau au responsable de la sécurité, aux opérations informatiques et à la direction pour approbation et conservez la version approuvée, car le plan que vous exécutez doit être celui que vous publiez.
Questions fréquentes
Quelles sont les étapes d’un processus de réponse à un incident de cybersécurité ?
Ce tableau comporte six colonnes : détection et triage, déclaration, cadrage et confinement, éradication, rétablissement et enseignements tirés. Cela correspond au modèle en six étapes du SANS de préparation, d'identification, de confinement, d'éradication, de rétablissement et de leçons apprises, ainsi qu'au NIST SP 800-61 Révision 2, qui regroupe le travail en détection et analyse ; confinement, éradication et rétablissement ; et l'activité post-incident. La révision 3 réorganise les orientations autour des fonctions du Cybersecurity Framework 2.0 plutôt qu'une liste fixe de phases. La préparation n'est pas conçue comme une étape car il s'agit d'un travail continu - ingénierie de détection, rotations, rétentions, exercices - effectué avant toute alerte et non pendant celle-ci.
En quoi est-ce différent de la gestion des incidents informatiques et de la notification des violations ?
La gestion des incidents informatiques rétablit un service perturbé et se ferme lorsque l'utilisateur reprend son travail. Un incident de sécurité a un adversaire, donc la restauration du service n'est pas la ligne d'arrivée : c'est le point de risque maximum si la menace réside toujours, c'est pourquoi ce tableau place une décision de vérification avant la récupération. La notification de violation est l’autre voisin. Décider si des données personnelles ont été concernées, si une autorité de contrôle ou un client doit en être informé et dans quel délai légal, le travail juridique et de communication se déroule selon un calendrier légal et se déroule parallèlement à la réponse technique plutôt qu'à l'intérieur de celle-ci.
Pourquoi la préservation des preuves passe-t-elle avant l’éradication ?
Parce que les actions de confinement les plus courantes détruisent les preuves dont vous aurez besoin. La mise hors tension d'un hôte perd les logiciels malveillants résidant en mémoire, les connexions réseau actives, le matériel déchiffré et les processus injectés. La reconstruction d'un serveur avant que sa portée ne soit comprise supprime les artefacts qui montrent comment l'attaquant est entré et ce qu'il a atteint. Le principe de l'ordre de volatilité décrit dans la RFC 3227 est la règle pratique : capturez d'abord la mémoire et l'état actif, puis le disque, puis les journaux archivés. Dans ce graphique, l'étape de preuve se situe après l'isolement et avant tout travail d'éradication, et les hôtes sont isolés au niveau de la couche réseau afin qu'ils continuent de fonctionner.
Comment décidez-vous que la menace est totalement supprimée ?
Avec des critères écrits avant l’incident, non jugés sur le moment. Généralement : aucune activité d'attaquant observée dans l'ensemble du domaine pendant une fenêtre d'observation convenue ; chaque indicateur de l’enquête a balayé tous les hôtes, pas seulement ceux qui ont alerté ; chaque identifiant qui aurait pu être capturé a fait l'objet d'une rotation, y compris les comptes de service et de machine ; et la vulnérabilité ou la mauvaise configuration qui a permis la fermeture de l'accès initial. Lorsque la réponse est non, cela signifie généralement que la portée était erronée plutôt que le nettoyage était bâclé, c'est pourquoi la branche d'échec revient ici à « Identifier les actifs et les comptes concernés » plutôt qu'à l'isolement.
Qui autorise un confinement qui met hors ligne un service de production ?
Quelqu'un ayant l'autorité nécessaire pour accepter l'impact commercial, ce qui est rarement celui qui a repéré le problème. Ce graphique achemine ce cas via la voie de gestion, mais l'important n'est pas le nom de la voie : c'est que la décision, le rôle nommé et la solution de secours s'ils sont inaccessibles sont convenus à l'avance. De nombreuses équipes préautorisent l'isolement pour une liste définie de systèmes et de gravité afin que les cas courants n'attendent jamais un appel et réservent l'escalade aux services générateurs de revenus ou liés à la sécurité. Sans cela, la dispute a lieu alors que l’attaquant est encore en train de travailler.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de réponse aux incidents de phishing (e-mail signalé) et passe le relais à Organigramme du processus de remontée des incidents de sécurité (SOC à RSSI).
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
Un organigramme de classification de la gravité des incidents : un arbre de décision prenant en compte les tests de disponibilité, de portée, d'impact commercial et d'exposition jusqu'à P1, P2, P3 ou P4.
Étape 3: Organigramme du processus de réponse aux incidents de cybersécurité (SOC) Vous êtes ici
Organigramme à couloirs du cycle de vie de réponse aux incidents techniques de cybersécurité qu'un SOC ou un CSIRT exécute, du tri des alertes à l'éradication, en passant par la récupération et le réglage des règles.
É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é
Étape 6: Organigramme du processus de réponse aux violations de données (horloge RGPD…