Réponse à une crise de sécurité
Gérez une vulnérabilité activement exploitée à travers six stages — corroborez l'exploitation, contenez sur trois fronts parallèles et déposez neuf notifications réglementaires avant l'expiration de leurs délais.
Le process flow Réponse à une crise de sécurité vous mène de « nous avons un exploit confirmé dans la nature » à un dossier d'incident clos et déposé — six stages, trois fronts de confinement simultanés et neuf délais de notification réglementaires, tous visibles en même temps sur un tableau kanban. Il est conçu pour le moment où le téléphone sonne et où quelqu'un demande ce que vous êtes légalement tenu de faire dans les 24 prochaines heures.
📦 Télécharger ce pack :
security-crisis-response-1.0.0.scrydon-extension.tar.gz— importez via Paramètres → Plateforme → Extensions → Sources → Téléverser un pack (ponctuel) — le contenu d'organisation s'installe au téléversement. Voir tous les packs d'exemple.
Scénario fictif. Meridian Systems, Sint-Aldegonde Hospital Group, la National Digital Infrastructure Agency, ainsi que chaque événement, constat, déclaration réglementaire et personne décrits dans ce guide sont entièrement fictifs. Rien ici ne décrit un incident de sécurité divulgué, une entreprise réelle ou une interaction réelle avec un régulateur. Cet exemple est un point de départ pour votre propre déploiement, et non le compte rendu d'un événement réel.
Ce qu'il fournit
| Ce que le pack livre | Détail |
|---|---|
| Trois fronts de confinement parallèles (Stage 3) | Trois flux de tâches concurrents s'exécutent simultanément dès que la déclaration (Declare) est signée : confinement du produit (isoler et corriger la vulnérabilité, vérifier le correctif), verrouillage de son propre environnement (geler les releases, traiter le pipeline comme non fiable, renouveler chaque identifiant stocké en variable de pipeline, auditer la provenance des artefacts sur toute la fenêtre d'exposition) et intégrité de la chaîne de preuves (révoquer le jeton exposé de la plateforme de conformité, auditer le propre journal d'accès de la plateforme sur la fenêtre d'exposition, déclarer quels artefacts de preuve sont provisoirement non fiables et consigner les exigences de ré-attestation pour chacun). |
| Neuf délais de notification réglementaires (Stage 4) | Un tableau de notifications parallèles avec une carte par obligation — EU CRA art. 14 (×2), NIS 2 art. 23 (×2), RGPD art. 33/34 (×2), conditions de subvention, liaison client et mise à jour du signaleur — chacune portant une pastille d'échéance dueOffsetDays comptée à partir de T0. Les clients dont les propres échéances réglementaires dépendent de votre notification sont signalés ; l'objectif opérationnel de dépôt tient compte de leur délai en aval. |
| Analyse des causes racines avec trace des corrections de l'IA (Stage 6) | Une action LLM facultative rédige l'analyse des causes racines (RCA) à partir du dossier d'incident. Le brouillon de l'IA et les corrections humaines de l'IC sont tous deux conservés — ce que l'IA a déduit, ce que les preuves étayent, et ce qui a été modifié et pourquoi. Des actions correctives avec des responsables nommés et des dates d'échéance clôturent le stage. |
Quatre artefacts d'exemple sont liés dans les étapes du tutoriel ci-dessous : une note de périmètre réglementaire, un journal des notifications, une évaluation de l'intégrité de la chaîne de preuves et la RCA signée avec la trace des corrections de l'IA.
Correspondance de conformité
Cet exemple produit des artefacts mis en correspondance avec :
- NIS 2 art. 21 (mesures de sécurité pour les entités essentielles et importantes) et art. 23 (notification d'incident — alerte précoce à T0+24 h, notification à T0+72 h, rapport final à T0+30 jours).
- EU CRA art. 14 (obligation du fabricant de signaler une vulnérabilité activement exploitée à l'ENISA — alerte précoce à T0+24 h, rapport de vulnérabilité à T0+72 h).
- RGPD art. 33 (notification à l'autorité de contrôle sous 72 heures) et art. 34 (communication aux personnes concernées lorsque requis).
- ISO 27001:2022 A.5.24 (planification de la gestion des incidents), A.5.25 (appréciation et classification), A.5.26 (réponse), A.5.27 (tirer des enseignements des incidents), A.5.28 (collecte de preuves).
Posture vis-à-vis de l'IA. Une action du Stage 6 — le brouillon d'analyse des causes racines — appelle votre LLM configuré pour rédiger la RCA à partir du dossier d'incident. Cette action est facultative : si aucun LLM n'est configuré, le flow marque le brouillon comme incomplet et l'instance se clôture tout de même lorsque l'IC fournit la RCA manuellement. Toutes les autres actions sont pilotées par des humains. C'est important lorsque votre propre pipeline est suspect — le flow est conçu pour aboutir sans aucune capacité automatisée qui pourrait elle-même être non fiable.
Tutoriel de bout en bout
À la fin de ce tutoriel, vous aurez importé le Scrydon Pack Security Crisis Response, l'aurez instancié pour un incident fictif chez Meridian Systems impliquant une vulnérabilité de traversée de répertoire activement exploitée, aurez exécuté les six stages et produit un dossier d'incident signé et déposé, prêt pour votre casier à preuves et le suivi avec les régulateurs.
Lena Hartmann (RSSI, Incident Commander), Marc Dubois (responsable de l'ingénierie sécurité, Security Lead), Sofia Nkosi (ingénieure principale, Tech Lead), Pieter van den Berg (responsable d'ingénierie, Scribe), Carmen Vidal (responsable de la réussite client, Comms Lead), Rachel Stern (juriste et DPO, Legal/DPO Liaison), Dirk Vermeersch et Ana Ferreira (Customer Liaisons — un par client concerné) et James Whitfield (PDG, Exec Sponsor) le mènent ensemble. Meridian Systems, Sint-Aldegonde Hospital Group et la National Digital Infrastructure Agency sont des entités fictives. Tous les constats, déclarations et interactions réglementaires décrits sont fictifs.
Prérequis
Vous disposez d'un déploiement Scrydon avec la surface agentic activée. Définissez les variables d'environnement suivantes pour l'étape d'importation :
export SCRYDON_URL="https://<your-scrydon-url>"
export ORG_ID="<your-org-id>"
export SESSION_COOKIE="$(cat ~/.scrydon/session-cookie)"Aucune configuration de capacité ou d'intégration n'est requise pour exécuter le flow de bout en bout. Le brouillon de RCA facultatif du Stage 6 nécessite une intégration LLM si vous souhaitez l'étape d'IA ; toutes les autres actions sont pilotées par des humains.
Étape 1 — Télécharger le pack
Télécharger security-crisis-response-1.0.0.scrydon-extension.tar.gz
mkdir -p scr-tutorial && cd scr-tutorial
curl -O https://docs.scrydon.com/static/process-pack-examples/security-crisis-response-1.0.0.scrydon-extension.tar.gzLe pack fait 8 501 octets.
Étape 2 — Inspecter le pack
bunx @scrydon/sdk-authoring extension inspect security-crisis-response-1.0.0.scrydon-extension.tar.gzPack:
Package: security-crisis-response@1.0.0
Contents: ontology@1.0.0, process-flow@1.0.0
Install order: ontology → process-flow
ontology: security-crisis-response@1.0.0
process-flow: security-crisis-response (6 stages)Étape 3 — Téléverser le pack
curl -X POST "$SCRYDON_URL/api/extensions/import?organizationId=$ORG_ID" \
-H "Cookie: $SESSION_COOKIE" \
-F "file=@security-crisis-response-1.0.0.scrydon-extension.tar.gz"Une réponse 200 contient le nouveau processTemplateId.
Étape 4 — Créer une nouvelle instance d'incident
Rendez-vous sur $SCRYDON_URL/process-flows. La carte Security Crisis Response apparaît sous l'étiquette Security. Cliquez sur Nouveau à partir du modèle et nommez l'instance CVD-2026-0012 — Path-Traversal in Artifact Endpoint (Apr 2026).
L'instance s'ouvre sur la vue kanban — six colonnes de stages, avec des cartes de tâches dans chacune. C'est délibéré : trois fronts de confinement parallèles et neuf délais de notification actifs doivent tous être visibles en même temps. Un assistant pas à pas masquerait le travail concurrent derrière un panneau à étape unique. Les stages sont séquentiels dans l'ensemble (stageFlow: "sequential" avec des portes d'approbation entre eux), mais le travail à l'intérieur des Stages 3 et 4 s'exécute en parallèle au sein de chaque stage.
Étape 5 — Réception et vérification (Intake & Verify)
Lena (IC) et Marc (Security Lead) prennent ensemble en charge le premier stage. Les tâches les guident pour accuser réception auprès du signaleur, reproduire la preuve de concept dans un environnement contrôlé, figer les versions concernées (3.4.0 à 3.4.2), réserver un CVE et convenir d'un calendrier de divulgation avec le signaleur.
L'action critique ici est Corroborate the exploitation claim — lorsque Marc reproduit la preuve de concept et consigne la confirmation, le flow horodate T0 en UTC. Chaque délai réglementaire du Stage 4 court à partir de ce moment. La corroboration est aussi ce qui fait passer l'obligation de l'EU CRA art. 14 de non applicable à une exigence d'alerte précoce sous 24 heures : un signalement non confirmé ne déclenche pas l'art. 14 ; une exploitation active confirmée, si.
Les étapes de checklist présentent leurs confirmations sous forme de cases distinctes. Log the report and stamp T0 (UTC) en compte sept, de la consignation du signalement à l'enregistrement de chaque échéance de notification, et Corroborate the exploitation claim en compte quatre, la dernière étant la détermination et son responsable nommé. Mark complete reste désactivé tant que toutes les cases de l'étape ne sont pas cochées.
Marc signe la porte du Stage 1 (approverPersona: "security-lead"). Le Stage 2 se déverrouille.
Étape 6 — Déclaration et périmètre (Declare & Scope)
Lena déclare la sévérité (SEV-1) et le flow passe au triage réglementaire. L'action pivot — Determine which regulatory hats apply — est celle où Rachel Stern recense chaque obligation possible : fabricant au sens de l'EU CRA, entité NIS 2, sous-traitant et responsable de traitement au sens du RGPD, conditions de subvention. Le résultat est une note de périmètre réglementaire qui pilote le Stage 4.
Le stage construit aussi le registre des clients concernés. Comme les clients relèvent de régulateurs différents — Sint-Aldegonde Hospital Group est une entité essentielle NIS 2 en Belgique, tandis que la NDIA porte des obligations contractuelles liées aux conditions de subvention —, un Customer Liaison dédié est affecté à chaque client. Le persona customer-liaison a une cardinalité many, si bien que Dirk Vermeersch et Ana Ferreira apparaissent simultanément sur le tableau.
Lena informe l'organe de direction (James Whitfield) qu'un incident a été déclaré.
Télécharger 01-regulatory-scope-memo.md — l'évaluation des casquettes réglementaires par Rachel Stern : une ligne par obligation, avec s'applique oui/non, le délai qu'elle déclenche et son responsable. S'y ajoute le registre des clients concernés, avec l'échéance en aval propre à chaque client et l'échéance de notification de Meridian qui en découle.
Lena signe la porte du Stage 2 (approverPersona: "incident-commander"). Les Stages 3 et 4 sont désormais prêts.
Étape 7 — Confinement (Contain)
Le Stage 3 est stageType: "parallel" — trois modèles de tâches s'exécutent simultanément dès l'ouverture du stage :
contain-product — Sofia Nkosi identifie le chemin de code vulnérable (la faille de traversée de répertoire de l'endpoint de distribution d'artefacts), construit un correctif depuis une branche isolée, le déploie dans un environnement contrôlé pour vérification et prépare la release de production. Elle ne déploie pas encore en production — le gel des releases imposé par contain-own-environment est toujours en vigueur.
contain-own-environment — L'équipe gèle toutes les releases de Meridian et traite le pipeline CI/CD comme non fiable jusqu'à preuve du contraire. Chaque identifiant stocké en variable de pipeline est renouvelé — pas seulement le jeton de la plateforme de conformité. L'audit de provenance des artefacts couvre toute la fenêtre d'exposition de 27 jours : pour chaque artefact de build produit depuis la livraison de la version 3.4.0, l'équipe vérifie la provenance de la chaîne d'approvisionnement de l'artefact par rapport au commit source. C'est cette porte d'audit qui lève le gel des releases.
contain-evidence-chain — Marc Dubois révoque le jeton de compte de service exposé de la plateforme de conformité et en émet un de remplacement avec une portée réduite et des restrictions d'IP. Il audite ensuite le propre journal de la plateforme de conformité pour chaque appel d'API effectué avec le jeton exposé pendant la fenêtre de 27 jours. Il évalue si des preuves stockées ont été modifiées. Il déclare quelles preuves sont provisoirement non fiables — non parce qu'une modification a été confirmée, mais parce que le jeton disposait d'un accès en écriture et que la piste d'audit ne permet pas de l'exclure avec certitude.
Télécharger 03-evidence-chain-integrity-assessment.md — l'évaluation de Marc au Stage 3 : les portées d'autorisation du jeton, l'analyse complète du journal d'audit (111 appels expliqués, 3 anormaux), les résultats de vérification des empreintes, les trois artefacts déclarés provisoirement non fiables et les exigences de ré-attestation pour chacun.
Étape 8 — Notification (Notify)
Le Stage 4 est stageType: "parallel" — neuf tâches de notification s'exécutent simultanément, chacune avec sa propre échéance :
| Tâche | Obligation | dueOffsetDays |
|---|---|---|
notify-enisa-early-warning | EU CRA art. 14(2), alerte précoce | 1 |
notify-enisa-vuln-report | EU CRA art. 14(2), rapport de vulnérabilité | 3 |
notify-nis2-early-warning | NIS 2 art. 23(1), alerte précoce | 1 |
notify-nis2-incident | NIS 2 art. 23(4), notification d'incident | 3 |
notify-gdpr-authority | RGPD art. 33, notification à l'autorité de contrôle | 3 |
notify-data-subjects | RGPD art. 34 (le cas échéant) | — |
notify-customers | Sint-Aldegonde et NDIA (objectif opérationnel : T+18 h pour Sint-Aldegonde) | 1 |
notify-funding-body | Conditions de subvention de la NDIA, clause 14.2 | — |
notify-reporter | Mise à jour de divulgation CVD au chercheur | — |
Chaque carte de tâche du tableau kanban affiche une pastille d'échéance avec un compte à rebours depuis T0. Pieter (Scribe) tient le journal des notifications au fil du stage.
La notification des clients (notify-customers) part tôt — à T+8 h 59 min plutôt qu'à l'objectif opérationnel de T+18 h fixé au Stage 2. Le délai d'alerte précoce NIS 2 art. 23 propre à Sint-Aldegonde court à partir du moment où ce client reçoit la notification de Meridian, et non à partir de T0. Un dépôt à T+18 h laisserait à Sint-Aldegonde moins de 6 heures pour informer son responsable de la sécurité et préparer sa propre alerte précoce. Carmen Vidal envoie le dossier de notification à 19 h 22 UTC le jour où T0 est horodaté, laissant à Sint-Aldegonde une équipe de travail complète pour effectuer son dépôt avant sa propre échéance.
Télécharger 02-notification-log.md — le journal des notifications du Stage 4 tenu par Pieter : les neuf délais, leurs échéances relatives à T0, les horodatages réels de dépôt (dont le dépôt RGPD art. 33 effectué avec 6 minutes d'avance) et une note sur ce que les clients ont reçu et sur la raison de l'envoi anticipé de la notification.
Étape 9 — Remédiation et rétablissement (Remediate & Recover)
Une fois le Stage 3 terminé et les trois fronts de confinement clos, l'équipe passe au rétablissement. Sofia construit la release de production depuis un pipeline réputé sain — un runner de pipeline neuf provisionné après la fenêtre d'exposition, isolé de tout environnement ayant touché à l'abonnement cloud de préproduction de Meridian. L'artefact de build est signé de nouveau, et sa provenance est vérifiée par rapport au commit source avant la release.
Une fois le correctif livré, Carmen confirme que chaque client a appliqué la mise à jour et fournit une confirmation écrite de la mise à niveau. Marc mène la ré-attestation des trois artefacts de preuve provisoirement non fiables : chacun est reproduit à partir de son système source principal, vérifié par empreinte et téléversé de nouveau sur la plateforme de conformité avec une annotation de rupture de chaîne.
L'action d'IA facultative Emerging root-cause read donne à l'IC une première lecture structurelle des causes contributives, fondée sur le dossier d'incident à ce stade. Elle est signalée comme facultative — si aucun LLM n'est configuré, la tâche est ignorée.
Après 24 heures de surveillance de récurrence sans nouvel indicateur, Lena signe la porte du Stage 5 (approverPersona: "incident-commander"). Le Stage 6 se déverrouille.
Étape 10 — Clôture, divulgation et enseignements (Close, Disclose & Learn)
Le stage final s'exécute sous la porte de James Whitfield (approverPersona: "exec-sponsor").
L'avis CVE est publié, en créditant nommément le chercheur indépendant et en incluant un calendrier de divulgation coordonnée. Le rapport final NIS 2 est déposé à dueOffsetDays: 30 à partir de T0.
L'action d'IA facultative Root-cause analysis draft génère un brouillon de RCA à partir du dossier d'incident, des constats du journal d'audit et du journal des notifications. L'IC examine le brouillon, corrige les déductions de l'IA que le dossier n'étaye pas et signe la version corrigée. Le brouillon de l'IA n'est pas la RCA finale — c'est la version signée et corrigée par un humain qui l'est.
Les actions correctives (huit éléments dans l'exemple Meridian, numérotés CA-1 à CA-8) sont attribuées à des responsables nommés avec des dates d'échéance. James signe la validation de l'organe de direction. Le dossier d'incident est déposé.
Télécharger 04-rca-and-corrective-actions.md — la RCA signée de Lena Hartmann : la chronologie, la chaîne causale, les lacunes de détection (dont le décalage de 20 heures et 14 minutes entre la CVD et T0), les lacunes de confinement et huit actions correctives (CA-1–CA-8). Une note visible explique précisément ce que le brouillon de l'IA a mal interprété et ce que l'IC a corrigé.
Trois variantes d'erreur à connaître
| Erreur | Comment la déclencher | Ce qu'elle signifie |
|---|---|---|
STAGE_DEPENDENCY_NOT_MET | Essayez d'ouvrir le Stage 4 (Notify) avant que le Stage 2 (Declare) ne soit signé par l'IC. | Le stageFlow séquentiel est appliqué : les tâches de notification ne peuvent pas démarrer tant que le périmètre réglementaire n'est pas établi. Envoyer des notifications avant de savoir quelles obligations s'appliquent, c'est ainsi que l'on manque des échéances ou que l'on dépose des déclarations erronées. |
| Délai réglementaire dépassé | Laissez une tâche notify-* non démarrée au-delà de son dueOffsetDays. | La carte de tâche du tableau kanban affiche une pastille d'échéance rouge et un statut PAST_DUE. L'instance ne se clôture pas d'elle-même — l'obligation reste en vigueur et doit être déposée, accompagnée d'une note de dépôt tardif à l'intention du régulateur. |
| Brouillon de RCA incomplet — aucun LLM configuré | Exécutez le Stage 6 sur un tenant sans intégration LLM. | L'action Root-cause analysis draft est marquée incomplète (facultative). Le flow se clôture tout de même lorsque l'IC dépose une RCA rédigée manuellement et que James signe la porte de direction. Le statut facultatif est délibéré : votre propre pipeline peut être le suspect, et vous ne devriez pas dépendre d'une capacité automatisée à laquelle vous ne pouvez pas encore faire confiance. |
Personnaliser le pack
Votre incident réel différera du scénario Meridian sur trois points : la combinaison réglementaire (lesquelles des cinq casquettes s'appliquent réellement à vous), la liste des clients (combien de Customer Liaisons il vous faut et quelles sont les obligations propres à chaque client) et l'ensemble des délais (lesquelles des neuf tâches de notification sont des obligations en vigueur et lesquelles ne concernent pas votre juridiction ou votre type d'entité). Deux chemins de personnalisation, plus un propre à ce pack :
- Forker le pack en TypeScript. Copiez la source de
packages/sdk-authoring/src/process-flows/examples/security-crisis-response/index.tsdans votre propre projet SDK, modifiez les modèles de stages et les personas, changezpackage.idettemplate.slugen une valeur personnalisée (par exempleacme-security-crisis), incrémentezpackage.versionet reconstruisez avecbunx @scrydon/sdk-authoring extension build src/extension.ts --outDir dist. Re-téléversez via/api/extensions/import. - L'exécuter tel quel et l'adapter au moment de l'instanciation. Les modèles de tâches des stages sont renseignés par instance. Vous pouvez ignorer les tâches qui ne s'appliquent pas, ajouter des notes expliquant pourquoi et attribuer les personas aux personnes réellement disponibles. Vous n'avez pas besoin de forker pour appliquer un ensemble réglementaire différent.
- Élaguer les délais auxquels vous n'êtes pas soumis. Si vous n'êtes pas un fabricant entrant dans le champ du CRA, retirez
notify-enisa-early-warningetnotify-enisa-vuln-reportdu Stage 4 plutôt que de les laisser sur le tableau comme des tâches qui ne seront jamais déposées. Une tâche non déposée dont la pastille d'échéance a expiré ressemble à une obligation manquée pour quiconque lit le dossier de l'instance. Forkez le pack (chemin 1) et supprimez les modèles de tâchesnotify-*non applicables de la définition du Stage 4, ou marquez-les explicitement comme ignorés au moment de l'instanciation avec une justification consignée.
Si vous forkez, changez le slug et le package.id afin que la version personnalisée de votre organisation n'entre pas en conflit avec cet exemple de la documentation.
Voir aussi
Exercez votre plan de réponse aux incidents avant que le téléphone ne sonne — cinq stages, un compte rendu d'exercice daté, des critères de réussite notés et des actions de remédiation attribuées. Sans IA.
La revue annuelle ISMS + AIMS qu'alimente ce dossier d'incident — test d'intrusion, exercices sur table IRP et DR, revue de direction et preuves prêtes pour l'audit de stage 1 BELAC.
Anatomie d'un modèle — types d'actions, portes d'approbation, personas, stages parallèles, pipeline build / inspect / upload.