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.
Qu'est-ce que le processus organigramme du processus de remontée des incidents de sécurité (soc à rssi) ?
Un processus de remontée d'incidents de sécurité est la réponse à une question répétée à chaque niveau de gravité : qui a besoin d'être informé maintenant et qui est autorisé à décider de la suite des événements. Cela commence là où commence le travail d'un analyste SOC, avec une alerte qui doit être triée et confirmée comme un événement réel plutôt que comme du bruit. À partir de là, le graphique ci-dessous suit un seul événement dans l'échelle, via une porte de gravité qui décide s'il reste avec le SOC ou s'il est transféré au gestionnaire d'incidents, une deuxième porte qui décide si le gestionnaire d'incidents peut le gérer seul ou si le RSSI et une équipe de crise sont impliqués, une vérification des données personnelles qui est transmise à un processus de violation dédié là où cela s'applique, une décision quant à savoir si une personne extérieure à l'organisation doit être informée et une cadence de mises à jour de la direction qui s'exécute jusqu'à ce que l'incident soit confirmé comme contenu et que l'échelle redescende.
Ce tableau n'est délibérément pas la réponse technique elle-même : il ne contient pas d'ingénierie de détection, de traitement des preuves, de mécanismes de confinement ou d'étapes d'éradication, qui appartiennent à un processus dédié de réponse aux incidents de cybersécurité exécuté en dessous. Il ne s’agit pas non plus du test de gravité qu’un centre de services informatique générique utilise pour évaluer une panne ordinaire, ni du flux de travail réglementaire détaillé pour une violation de données personnelles confirmée, qui a ses propres décisions et sa propre horloge statutaire dans un processus distinct. Ce que contient ce tableau est plus restreint et, dans un incident réel, tout aussi important : le chemin d'escalade lui-même, qui est indiqué à chaque seuil, et le point à partir duquel l'incident peut être interrompu en toute sécurité. Considérez-le comme un point de départ pour vous adapter à votre propre plan de réponse aux incidents, à vos obligations réglementaires et au jugement de celui qui occupe le poste de RSSI ou un rôle équivalent dans votre organisation, et non comme un substitut à l'un ou l'autre.
Deux décisions portent le poids de l’échelle. « Répond au seuil S1/S2 ? » se trouve aux côtés de l'analyste SOC, car c'est la première personne à voir les preuves qui peut passer cet appel, et une erreur dans un sens ou dans l'autre enterre un événement grave dans la file d'attente du SOC ou réveille le RSSI pour un rapport de phishing. « L'incident est-il contenu ? siège avec la direction et l'équipe de crise pour la raison opposée : le confinement est un jugement technique porté ailleurs sur l'organigramme, mais la décision de retirer l'équipe de crise et d'arrêter la cadence de mise à jour appartient aux personnes qui l'ont convoquée. Entre ces deux-là, la question « Données personnelles impliquées ? » et « Notification externe requise ? » les décisions se situent volontairement dans la voie juridique/vie privée, car l'existence d'une obligation est une question juridique même lorsque le déclencheur est technique.
Ce que couvre cet organigramme
Dans ce modèle
- Cinq couloirs (analyste SOC, gestionnaire d'incidents, RSSI/gestion de la sécurité, juridique/confidentialité et direction/équipe de crise) répartis en sept phases : détecter et trier, classer la gravité, hiérarchiser la réponse, contenir et évaluer, juridique et notification, surveillance exécutive, et désamorcer et clôturer.
- Un « Vrai positif ? porte juste après le triage, de sorte qu'un faux positif confirmé est renvoyé vers le réglage de la règle de détection plutôt que simplement fermé, et seul un événement réel continue de gravir les échelons
- La première porte d'escalade, « Atteint le seuil S1/S2 ? », qui divise l'échelle en deux : les événements S3 et S4 restent avec le SOC, reçoivent un ticket et sont résolus sans jamais atteindre le gestionnaire d'incidents.
- Une deuxième porte à l'intérieur de la branche remontée, « La gravité est S1 ? », qui décide si le gestionnaire d'incidents et le propriétaire du système gèrent seuls un événement S2 ou si le RSSI est amené et une équipe de crise est activée pour S1.
- Le message « Données personnelles impliquées ? » décision dans la voie juridique/confidentialité, dont la branche oui confie l'incident à un processus dédié aux violations de données plutôt que de dupliquer cette évaluation sur ce tableau
- Un message « Notification externe requise ? » la décision alimente la notification du régulateur, des forces de l'ordre, des clients et de l'assureur, le cas échéant, puis une cadence de mise à jour exécutive commandée par « L'incident est-il contenu ? » ça tourne en boucle jusqu'à ce que l'équipe de crise puisse se retirer
Quand utiliser ce modèle
- Vous rédigez ou mettez à jour un plan de réponse à un incident et le chemin d'escalade est décrit en prose que personne ne peut suivre à deux heures du matin.
- Votre SOC et vos dirigeants ne sont pas d'accord sur le moment où le RSSI doit être réveillé, et vous avez besoin d'un seuil écrit plutôt que d'être argumenté au cas par cas.
- Vous créez un runbook de communication sur les incidents majeurs ou les crises et vous avez besoin que le point où les notifications légales et externes entrent en jeu soit rendu explicite.
- Un auditeur, un assureur ou un comité du conseil d'administration a demandé comment votre organisation signale et signale un incident de sécurité, indépendamment de la façon dont il est techniquement contenu.
- Vous intégrez un nouveau gestionnaire d'incidents ou RSSI et souhaitez que les niveaux, les transferts et la décision de retrait soient sur une seule page plutôt que d'apprendre du dernier incident.
Comment cela fonctionne
Renommez les voies selon votre véritable chaîne d'escalade
Remplacez l'analyste SOC, le gestionnaire d'incidents, le RSSI/gestion de la sécurité, l'équipe juridique/confidentialité et l'équipe de direction/crise par les rôles qui détiennent réellement chaque décision dans votre organisation. Une organisation plus petite fusionne souvent le gestionnaire des incidents dans la voie du RSSI, ou fait appel aux services juridiques par l'intermédiaire d'un conseiller externe ; supprimez ou fusionnez une voie plutôt que de la laisser sans propriétaire.
Écrivez vos critères de gravité sur la première porte
Ouvrez « Répond au seuil S1/S2 ? » et remplacez l'espace réservé par vos propres définitions : systèmes ou données concernés, nombre d'utilisateurs ou de clients, si la production est dégradée, s'il y a un impact sur la sécurité. Les étiquettes S1 à S4 sur ce graphique sont illustratives et ne constituent pas une norme. Définissez donc les critères suffisamment spécifiques pour que deux analystes travaillant sur des équipes différentes parviennent au même appel.
Nom qui est autorisé à déclarer chaque niveau
Indiquer sur la carte, ou dans le plan lié, qui peut confirmer un S2 sans réveiller personne d'autre, et qui peut déclarer un S1 et déclencher l'activation de l'équipe de crise. Ajoutez un adjoint pour les deux rôles et une règle sur ce qui se passe si aucun des deux ne peut être atteint dans un délai convenu, car les critères d'escalade qu'une seule personne peut approuver échouent exactement au moment où ils sont le plus nécessaires.
Confirmez vos données personnelles et les déclencheurs de notification
Travaillez avec le service juridique ou votre responsable de la protection des données pour rédiger le véritable test derrière « Données personnelles impliquées ? » et « Notification externe requise ? » : qu'est-ce qui compte comme données personnelles pour vous, quels régulateurs, clients, organismes chargés de l'application de la loi et assureurs pourraient avoir besoin d'être informés, et quels sont les délais légaux ou contractuels dans votre juridiction. Dirigez la branche des données personnelles vers votre procédure de violation réelle plutôt que de la laisser comme étiquette.
Définir la cadence de mise à jour des dirigeants
Décidez à quelle fréquence l'équipe de crise envoie une mise à jour de l'état pendant la question « L'incident est-il contenu ? » ne cesse de répondre non, qui le reçoit et ce qu'il doit contenir : l'impact actuel, les actions entreprises et le prochain point de décision. Notez la cadence avant qu'un incident ne se produise ; décider qu'il est en direct est la façon dont les mises à jour cessent de sortir ou prennent le relais de la réponse.
Définir ce que signifient contenu et fermé
Acceptez les preuves nécessaires pour répondre « L'incident est-il contenu ? » avec oui, et séparément ce qui doit être vrai avant que l'équipe de crise ne se retire et que l'incident ne soit clos. Les deux ne sont pas le même moment : un incident peut être techniquement maîtrisé bien avant que les communications, les services juridiques et les propriétaires d'entreprise concernés ne soient prêts à cesser de le traiter comme étant réel.
Marchez contre un incident passé
Prenez un incident que vous avez réellement déclenché, idéalement un incident qui a atteint le RSSI ou au-delà, et tracez-le dans le graphique. Notez chaque point où la véritable escalade s'est produite plus rapidement, plus lentement ou par un itinéraire différent de celui indiqué dans le graphique, et utilisez ces lacunes comme agenda pour mettre à jour le plan avant le prochain incident, et non pendant celui-ci.
Questions fréquentes
Quelles sont les étapes d’un processus de remontée d’incident de sécurité ?
Un analyste SOC effectue un tri de niveau 1 sur alerte et confirme qu'il s'agit d'un véritable positif ; un faux positif est fermé et réinjecté dans la règle de détection. L'événement confirmé est vérifié par rapport au seuil S1/S2 : S3 et S4 restent avec le SOC, reçoivent un ticket et y sont résolus. Un événement S1 ou S2 est transmis au gestionnaire d'incidents, qui vérifie s'il s'agit spécifiquement de S1. Un S2 est géré par le gestionnaire d'incidents et le propriétaire du système. Un S1 est remonté au RSSI, qui dirige le confinement pendant que l'équipe de crise est activée. Le service juridique vérifie ensuite si des données personnelles sont impliquées, les transmet à un processus de violation là où elles se trouvent, et décide si le régulateur, les forces de l'ordre, les clients ou l'assureur doivent en être informés. L'équipe de crise envoie des mises à jour selon une cadence définie jusqu'à ce que l'incident soit maîtrisé, puis se retire et clôt l'opération avec un rapport post-incident.
En quoi est-ce différent d’un processus de réponse aux incidents de cybersécurité ?
Ils répondent à différentes questions sur le même événement. Un processus de réponse aux incidents de cybersécurité correspond au cycle de vie technique : trier l'alerte, la définir, la contenir sans détruire les preuves, éradiquer la menace, vérifier qu'elle a disparu et récupérer, généralement exécuté entièrement au sein du SOC et des opérations informatiques. Ce processus d'escalade concerne les personnes et l'autorité plutôt que la technique : à quel moment un événement cesse-t-il d'être la décision du seul SOC, à qui est-il informé au fur et à mesure de l'ascension et qui doit approuver le retrait. Dans un S1 en direct, les deux courent côte à côte, l'équipe technique travaillant sur les étapes de confinement et d'éradication tandis que cette échelle décide qui d'autre est dans la pièce et ce qui est communiqué vers l'extérieur.
Pourquoi les « Données personnelles sont-elles impliquées ? » passer à un autre processus ?
Parce que l’évaluation derrière cette décision comporte ses propres tests et sa propre horloge réglementaire qui méritent un tableau à part entière plutôt que d’être compressés dans une seule case ici. La question de savoir si une violation doit être notifiée à une autorité de contrôle et séparément si les personnes concernées elles-mêmes doivent en être informées sont des questions avec différents seuils et différents propriétaires, généralement le responsable de la protection des données et le responsable juridique. Garder cette évaluation dans un processus dédié aux violations de données signifie qu'elle peut être détaillée et tenue à jour avec les règles de votre juridiction sans que chaque changement doive également être revérifié par rapport à l'échelle d'escalade. Ce graphique doit uniquement savoir que le transfert a eu lieu et que le dossier est suivi.
Quelle est la différence entre le niveau de gravité et le niveau d’escalade ?
La gravité décrit l'impact de l'incident lui-même : dans quelle mesure il est affecté, dans quelle mesure et pour combien de personnes. Le niveau d'escalade décrit qui en est actuellement responsable et qui en a été informé. Les deux sont liés mais pas identiques, c’est pourquoi ce tableau les traite comme des décisions distinctes plutôt que comme une seule. Un incident peut être confirmé comme étant de gravité S1 dès qu'il est compris, mais l'escalade n'atteint le RSSI et l'équipe de crise qu'une fois que cette gravité a effectivement été déclarée et ignorée ; à l'inverse, un incident qui semblait mineur au premier tri peut gravir la même échelle plus tard si des preuves de type « Impact modifié lors de la prochaine mise à jour » arrivent, sans que son étiquette de gravité d'origine ne soit jamais revisitée.
Qui décide quand retirer l’équipe de crise ?
Celui qui l’a convoqué, s’est appuyé sur des preuves plutôt que sur la pression pour passer à autre chose. Ce graphique indique « L'incident est-il contenu ? » dans le couloir de la direction/de l'équipe de crise délibérément : le confinement au sens technique est confirmé par les équipes de sécurité et informatiques travaillant sur l'incident, mais réduire la structure de crise, arrêter la cadence de mise à jour et informer l'organisation dans son ensemble que l'événement est terminé est un appel distinct qui appartient à celui qui possède la réponse à la crise. Notez à l'avance les critères de sortie, par exemple une période d'observation définie sans récurrence et chaque système concerné vérifié, afin que la décision ne soit pas prise uniquement en fonction du degré de fatigue de la pièce.
Où ce processus s'inscrit
Dans la plupart des opérations, ce processus suit Organigramme du processus de réponse aux incidents de cybersécurité (SOC) 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)
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) Vous êtes ici
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é
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…