Gestion des incidents ISO 27001 : exigences et cadre de reponse

Les incidents de securite de l’information ne sont pas une question de si, mais de quand. Une compromission d’identifiants expose les donnees clients. Un point d’acces API mal configure laisse fuiter des donnees sensibles. Une campagne de phishing cible votre equipe financiere et reussit. Lorsque ces evenements surviennent, ISO 27001 exige que votre organisation les detecte rapidement, y reponde de maniere structuree, contienne les dommages, retablisse les operations et tire les lecons de l’experience afin que la meme categorie d’incident ne se reproduise pas.

ISO 27001 adopte une approche globale de la gestion des incidents a travers ses clauses principales et un ensemble dedie de controles Annex A. La norme ne prescrit pas une pile technologique specifique de reponse aux incidents ni n’impose une structure d’equipe particuliere. Elle exige en revanche que vous etablissiez un cadre systematique de gestion des incidents — un cadre documente, communique, teste et ameliore en continu dans le cadre de votre Systeme de Management de la Securite de l’Information (ISMS).

Ce guide couvre les exigences ISO 27001 en matiere de gestion des incidents, presente les controles Annex A pertinents (A.5.24 a A.5.28), explique comment construire un cadre de reponse qui fonctionne sous pression, et aborde les defis specifiques auxquels font face les entreprises SaaS lors de la gestion des incidents de securite.

Ce qu’exige ISO 27001 pour la gestion des incidents

ISO 27001 traite la gestion des incidents a travers deux mecanismes : les clauses principales du systeme de management et les controles Annex A. Comprendre les deux est essentiel pour construire un programme conforme.

Exigences des clauses principales

Clause 6.1 — Actions pour traiter les risques et les opportunites. Votre evaluation des risques doit considerer les scenarios d’incidents comme des risques potentiels. La probabilite et l’impact de types d’incidents specifiques doivent eclairer vos decisions de traitement des risques, et les controles de gestion des incidents doivent figurer dans votre plan de traitement des risques. Si votre evaluation des risques identifie l’« acces non autorise a la base de donnees de production » comme un risque eleve, votre plan de traitement doit inclure des procedures de reponse aux incidents specifiquement concues pour ce scenario.

Clause 8.1 — Planification et controle operationnels. Vos processus de gestion des incidents doivent etre planifies, mis en oeuvre et controles. Cela signifie des procedures documentees, des responsabilites attribuees, des ressources adequates et des criteres definis pour evaluer si les processus atteignent les resultats escomptes.

Clause 9.1 — Surveillance, mesure, analyse et evaluation. Vous devez surveiller et mesurer l’efficacite de vos processus de gestion des incidents. Des indicateurs tels que le delai moyen de detection, le delai moyen de reponse, les taux de recurrence des incidents et les taux d’achevement des actions post-incident fournissent la preuve que votre programme fonctionne.

Clause 10.1 — Non-conformite et action corrective. Lorsque les incidents revelent des defaillances de controle ou des lacunes dans les processus, celles-ci doivent etre traitees comme des non-conformites. Les actions correctives doivent s’attaquer aux causes profondes, pas seulement aux symptomes. Le lien entre les incidents et votre processus d’amelioration continue est direct et obligatoire.

Controles Annex A pour la gestion des incidents

La revision 2022 d’ISO 27001 regroupe les controles de gestion des incidents dans la section A.5, au sein de la categorie des controles organisationnels. Cinq controles constituent le cadre de gestion des incidents.

A.5.24 — Planification et preparation de la gestion des incidents de securite de l’information. Ce controle exige que vous etablissiez et communiquiez des procedures de gestion des incidents. Vous devez definir ce qui constitue un evenement de securite de l’information par rapport a un incident, attribuer des roles et responsabilites, etablir des canaux de communication et preparer des procedures de reponse avant que les incidents ne surviennent. La preparation n’est pas optionnelle — c’est un controle que les auditeurs testeront.

A.5.25 — Evaluation et decision concernant les evenements de securite de l’information. Lorsqu’un evenement est detecte, vous devez disposer d’un processus pour evaluer sa nature et sa gravite et decider s’il constitue un incident de securite de l’information. Toute alerte de securite n’est pas un incident. Une seule tentative de connexion echouee est un evenement. Dix mille tentatives de connexion echouees contre plusieurs comptes depuis un botnet constituent un incident. Vos criteres de classification doivent definir ou se situe cette ligne.

A.5.26 — Reponse aux incidents de securite de l’information. Une fois qu’un evenement est classe comme incident, vous devez repondre selon des procedures documentees. Ce controle couvre l’ensemble du cycle de vie de la reponse : confinement, eradication, retablissement et communication. Les reponses doivent etre proportionnelles a la gravite de l’incident, et les procedures doivent etre suffisamment pratiques pour que votre equipe puisse les executer sous pression.

A.5.27 — Tirer les lecons des incidents de securite de l’information. Chaque incident est une opportunite d’apprentissage. Ce controle exige que vous analysiez les incidents apres resolution pour identifier les causes profondes, evaluer l’efficacite de votre reponse et determiner si les controles doivent etre renforces. Les connaissances acquises doivent alimenter votre ISMS — a travers des evaluations des risques mises a jour, des controles revises, des procedures modifiees ou une formation renforcee.

A.5.28 — Collecte de preuves. Lorsqu’un incident peut entrainer des procedures judiciaires, des actions reglementaires ou des mesures disciplinaires, vous devez collecter et preserver les preuves de maniere forensiquement valable. Ce controle traite de la chaine de custody, de l’integrite des preuves et des exigences d’admissibilite. Pour les entreprises SaaS, cela signifie souvent la preservation des journaux, la capture de l’etat du systeme et le maintien de chronologies detaillees.

Pour un guide complet de tous les controles Annex A et de leurs interrelations, consultez notre guide des controles Annex A ISO 27001.

Evenements vs. Incidents : pourquoi la distinction est importante

ISO 27001 trace une ligne deliberee entre les evenements de securite de l’information et les incidents de securite de l’information. Comprendre cette distinction est crucial car elle determine votre reponse.

Un evenement de securite de l’information est toute occurrence identifiee dans un systeme, service ou etat du reseau indiquant une possible violation de la politique de securite de l’information, une defaillance des controles, ou une situation jusque-la inconnue pouvant etre pertinente en matiere de securite. Les evenements sont des observations qui necessitent une evaluation. Les exemples incluent une tentative de connexion echouee, un pare-feu bloquant une connexion entrante, une alerte antivirus sur le poste de travail d’un employe ou un pic inhabituel de trafic reseau sortant.

Un incident de securite de l’information est un ou plusieurs evenements de securite de l’information lies qui ont une probabilite significative de compromettre les operations commerciales et de menacer la securite de l’information. Les incidents necessitent une reponse coordonnee. Les exemples incluent un acces non autorise confirme aux donnees clients, un phishing reussi ayant conduit a une compromission d’identifiants, une infection par malware s’etant propagee a plusieurs systemes, ou une attaque DDoS ayant perturbe la disponibilite du service.

Le processus d’evaluation defini par le controle A.5.25 se situe entre ces deux concepts. Chaque evenement doit etre evalue par rapport a vos criteres de classification pour determiner s’il constitue un incident. Ce processus de triage previent deux modes de defaillance egalement dommageables : traiter chaque evenement comme un incident (ce qui epuise votre equipe de reponse et la desensibilise aux menaces reelles) et ne pas reconnaitre les veritables incidents parmi le bruit des evenements de routine.

Criteres pratiques de triage. Votre processus de triage doit evaluer les evenements par rapport a ces facteurs :

Impact sur la confidentialite : Des donnees sensibles ont-elles ete consultees, exposees ou exfiltrees ?
Impact sur l’integrite : Des donnees ou la configuration du systeme ont-elles ete modifiees sans autorisation ?
Impact sur la disponibilite : Les services ont-ils ete perturbes ou degrades ?
Portee : L’impact est-il limite a un seul systeme ou utilisateur, ou affecte-t-il plusieurs systemes, clients ou jeux de donnees ?
Menace active : L’acteur de la menace est-il toujours present ou la vulnerabilite est-elle encore exploitee ?
Implications reglementaires : L’evenement declenche-t-il potentiellement des obligations de notification de violation en vertu du GDPR, d’engagements contractuels ou d’autres cadres reglementaires ?

Si l’un de ces facteurs indique un impact significatif, l’evenement doit etre escalade au statut d’incident.

Classification des incidents et niveaux de gravite

Une fois qu’un evenement est classe comme incident, vous devez attribuer un niveau de gravite qui determine la rapidite et l’ampleur de votre reponse. ISO 27001 ne prescrit pas de niveaux de gravite specifiques — vous les definissez en fonction du contexte de votre organisation, de votre appetit pour le risque et de vos exigences operationnelles.

Un modele de gravite a quatre niveaux fonctionne bien pour la plupart des organisations SaaS :

Gravite	Definition	Declenchement de la reponse	Exemples de scenarios
Critique (P1)	Violation active avec exposition confirmee de donnees, panne complete du service ou exploitation active des systemes de production	Immediat — dans les 15 minutes	Exfiltration confirmee de donnees clients, ransomware chiffrant les bases de production, plateforme completement indisponible
Eleve (P2)	Compromission significative de la securite sans exposition confirmee de donnees, panne partielle du service ou attaque active en cours	Dans l’heure	Acces administrateur non autorise detecte, service d’authentification degrade, attaque par force brute active avec quelques succes
Modere (P3)	Evenement de securite necessitant une investigation et une reponse, impact operationnel limite	Dans les 4 heures	Schemas d’acces aux donnees suspects, perturbation d’un service non critique, malware confine a un seul poste de travail
Faible (P4)	Evenement de securite mineur, quasi-incident ou violation de politique avec impact minimal	Dans les 24 heures	Tentative de phishing echouee (aucun identifiant compromis), exception mineure de politique, vulnerabilite decouverte mais non exploitee

La gravite determine l’allocation des ressources. Un incident P1 active votre equipe complete de reponse aux incidents, la communication avec la direction et potentiellement la notification aux clients. Un incident P4 peut etre gere par un seul ingenieur pendant les heures normales de bureau. Vos procedures doivent definir quelles ressources sont mobilisees a chaque niveau de gravite, qui a l’autorite d’escalader ou de desescalader, et quelle cadence de communication s’applique.

La gravite peut changer au cours d’un incident. Un evenement initialement classe P3 peut etre escalade en P1 lorsque l’investigation revele un impact plus large. Vos procedures doivent definir les declencheurs d’escalade et s’assurer que l’escalade se fait sans friction — la personne qui enquete sur un P3 doit etre habilitee a escalader en P1 sans demander l’approbation de la direction si les criteres sont remplis.

Le processus de reponse aux incidents

ISO 27001 exige des procedures de reponse documentees (A.5.26) que votre equipe peut executer sous pression. Un processus de reponse structure en cinq phases fournit le cadre.

Phase 1 : Detection et signalement

La detection est le point de depart de chaque incident. Votre capacite a detecter les incidents depend des capacites de surveillance que vous avez deployees et de la culture de signalement que vous avez etablie.

Sources de detection techniques. Pour les entreprises SaaS, la detection provient generalement de :

SIEM et gestion des journaux — Analyse centralisee des journaux avec des regles de correlation qui detectent des schemas indiquant une compromission (schemas d’acces inhabituels, escalade de privileges, indicateurs d’exfiltration de donnees)
Surveillance de la securite cloud — AWS CloudTrail, GCP Audit Logs, Azure Activity Logs avec des alertes sur les evenements pertinents en matiere de securite (modifications IAM, modifications des groupes de securite, creation inattendue de ressources)
Surveillance applicative — Outils APM qui detectent des anomalies dans le comportement de l’application (taux d’erreurs inattendus, schemas d’utilisation inhabituels de l’API, anomalies de latence)
Detection et reponse sur les terminaux (EDR) — Surveillance sur les postes de travail des employes pour les malwares, les logiciels non autorises et les activites de processus suspects
Analyse des vulnerabilites — Analyses automatisees regulieres qui identifient les vulnerabilites exploitables avant les attaquants
Renseignement sur les menaces tiers — Flux qui vous alertent sur les menaces ciblant votre secteur, votre pile technologique ou votre chaine d’approvisionnement

Signalement humain. Tous les incidents ne sont pas detectes par la technologie. Les employes qui remarquent des courriels suspects, les clients qui signalent un comportement inattendu et les partenaires qui observent des anomalies sont tous des sources de detection valides. Vos procedures de gestion des incidents doivent inclure un canal de signalement clair et accessible — une adresse courriel dediee, un canal Slack, un bouton dans vos outils internes — et les employes doivent savoir comment l’utiliser. Vos politiques ISMS doivent definir les obligations de signalement pour tout le personnel.

Exigences de signalement. Chaque evenement detecte doit etre enregistre avec :

Date et heure de detection
Source de detection (alerte systeme, signalement humain, notification externe)
Description du comportement observe
Systemes ou donnees potentiellement affectes
Evaluation initiale de la gravite
Nom et coordonnees de la personne effectuant le signalement

Phase 2 : Evaluation et triage

Une fois un evenement signale, il doit etre evalue par rapport a vos criteres de classification pour determiner s’il constitue un incident et, le cas echeant, quel niveau de gravite s’applique.

Le triage initial doit etre rapide. Pour les evenements detectes par les systemes automatises, le triage initial doit intervenir dans les minutes. L’ingenieur d’astreinte ou l’analyste securite evalue l’alerte, verifie les preuves corroborantes et prend une decision de classification initiale. Ce n’est pas le moment d’une investigation approfondie — c’est une evaluation rapide pour determiner si l’evenement justifie une reponse de niveau incident.

Liste de controle du triage. Dans les 30 premieres minutes suivant la reception d’un signalement :

L’evenement est-il confirme (vrai positif) ou peut-il etre ecarte (faux positif) ?
Quels systemes, donnees ou services sont affectes ou potentiellement affectes ?
La menace est-elle toujours active ? La vulnerabilite est-elle encore exploitee ?
Les donnees clients sont-elles potentiellement en danger ?
Quel est le rayon d’explosion — systeme unique, client unique, tous les clients, tous les systemes ?
Cela declenche-t-il des obligations de notification reglementaire (par ex., notification de violation GDPR) ?

Decision : escalader ou cloturer. En fonction du triage, l’evenement est soit classe comme incident (avec un niveau de gravite attribue) et escalade a l’equipe de reponse aux incidents, soit cloture comme non-incident avec une documentation expliquant pourquoi. Cloturer un evenement ne signifie pas l’ignorer — le journal de l’evenement doit capturer l’analyse du triage et la justification de la decision de cloture.

Phase 3 : Confinement

Le confinement empeche l’incident de s’aggraver. L’objectif est de limiter les dommages tout en preservant votre capacite a investiguer la cause profonde.

Confinement a court terme se concentre sur les actions immediates :

Isoler les systemes affectes du reseau (sans les eteindre, pour preserver l’etat forensique)
Revoquer les identifiants compromis et effectuer la rotation des cles API et jetons affectes
Bloquer les adresses IP, domaines ou agents utilisateurs malveillants au niveau du pare-feu ou du WAF
Desactiver les comptes utilisateurs compromis
Appliquer des restrictions d’acces d’urgence pour limiter l’exposition

Confinement a long terme etablit des mesures durables pendant que vous preparez l’eradication :

Deployer des correctifs temporaires ou des changements de configuration pour fermer la vulnerabilite exploitee
Mettre en place une surveillance supplementaire sur le vecteur d’attaque
Installer des controles compensatoires pour maintenir la securite pendant la reconstruction des controles principaux
Rediriger le trafic des composants compromis vers des systemes reconnus comme sains

Considerations de confinement specifiques au SaaS :

Isolation multi-tenant. Si l’incident affecte un tenant, verifiez que vos controles d’isolation des tenants ont empeche le mouvement lateral vers d’autres tenants. Si les controles d’isolation ont pu etre violes, traitez tous les tenants comme potentiellement affectes.
Rotation des cles API. Les cles API compromises peuvent etre integrees dans les applications clients. Coordonnez avec les clients affectes avant de faire la rotation des cles pour eviter des perturbations de service en cascade.
Environnements Infrastructure-as-Code. Si l’attaquant a modifie les configurations d’infrastructure, votre confinement doit inclure le retour en arriere des modifications d’infrastructure et s’assurer que l’attaquant n’a pas introduit de mecanismes d’acces persistant dans vos depots IaC.
Compromission du pipeline CI/CD. Si le pipeline de construction ou de deploiement a ete compromis, tous les artefacts produits par ce pipeline pendant la fenetre de compromission doivent etre consideres comme corrompus.

Quand mettre les services hors ligne. C’est l’une des decisions les plus difficiles lors d’un incident. Mettre un service hors ligne arrete l’attaque mais arrete aussi les operations de vos clients. Envisagez de mettre les services hors ligne lorsqu’une exfiltration active de donnees est en cours et ne peut etre arretee autrement, lorsque l’attaquant dispose d’un acces persistant qui ne peut etre confine en place, ou lorsque la poursuite des operations mettrait en danger des donnees clients supplementaires.

Phase 4 : Eradication et retablissement

Une fois l’incident confine, eliminez la cause profonde et retablissez les operations normales.

Analyse des causes profondes. Determinez exactement comment l’incident s’est produit. Les causes profondes courantes dans les incidents SaaS comprennent :

Vulnerabilites non corrigees dans le code applicatif, les frameworks ou l’infrastructure
Ressources cloud mal configurees (politiques IAM trop permissives, buckets de stockage publics, configurations reseau non securisees)
Identifiants compromis, souvent par reutilisation d’identifiants, phishing ou bourrage d’identifiants
Dependances tierces vulnerables
Validation insuffisante des entrees permettant des attaques par injection
Ingenierie sociale ayant contourne la formation a la sensibilisation securite

Actions d’eradication. En fonction de la cause profonde :

Corriger la vulnerabilite exploitee sur tous les systemes affectes
Supprimer tous les mecanismes d’acces non autorises (portes derobees, cles SSH frauduleuses, roles IAM non autorises, code malveillant)
Reconstruire les systemes compromis a partir d’images reconnues comme saines ou de deploiements propres plutot que d’essayer de nettoyer les systemes compromis sur place
Effectuer la rotation de tous les identifiants qui ont pu etre exposes, y compris les comptes de service, les cles API, les identifiants de base de donnees et les cles de chiffrement
Mettre a jour les regles de pare-feu, les configurations WAF et les parametres des groupes de securite pour prevenir le meme vecteur d’attaque

Validation du retablissement. Avant de declarer l’incident resolu et de restaurer le service complet :

Verifier que la vulnerabilite est completement corrigee sur tous les systemes et environnements affectes
Confirmer que tous les mecanismes d’acces non autorises ont ete supprimes
Valider l’integrite des donnees en les comparant avec des sauvegardes propres
Executer des analyses de securite sur les systemes restaures
Confirmer que la surveillance et les alertes sont operationnelles sur les systemes restaures
Verifier que tous les identifiants ont ete changes et que les anciens identifiants sont completement invalides

Periode de surveillance renforcee. Apres le retablissement, maintenez une surveillance renforcee pendant au moins 30 jours. Les attaquants sophistiques etablissent souvent plusieurs mecanismes de persistance, et l’eradication d’un seul ne garantit pas que les autres ont ete trouves. Surveillez les indicateurs de re-compromission : schemas d’authentification inhabituels, execution de processus inattendus, trafic reseau anormal ou modifications de configuration non autorisees.

Phase 5 : Revue post-incident

Le controle A.5.27 exige que vous tiriez les lecons des incidents. La revue post-incident est le moment ou cet apprentissage se produit, et c’est l’un des elements que les auditeurs examinent le plus attentivement car il relie la gestion des incidents a vos processus d’amelioration continue.

Calendrier. Effectuez la revue post-incident dans les 5 jours ouvrables suivant la resolution de l’incident, tant que les details sont encore frais. Pour les incidents P1, envisagez de programmer une breve revue initiale dans les 24-48 heures, suivie d’une analyse plus approfondie une fois que l’equipe a eu le temps de compiler les donnees.

Culture sans blame. La revue doit se concentrer sur les facteurs systemiques, pas sur le blame individuel. Si les gens ont peur d’etre honnetes sur ce qui s’est passe et ce qu’ils ont fait ou n’ont pas fait, la revue manquera les enseignements qui previennent les incidents futurs. Documentez les facteurs contributifs, pas la personne qui a clique sur le lien de phishing.

Ce qu’il faut documenter :

Chronologie — Une reconstitution detaillee et horodatee de l’incident, du premier indicateur a la resolution complete. Incluez quand l’evenement a ete detecte, quand il a ete classe comme incident, quand le confinement a ete atteint et quand le retablissement a ete confirme.
Cause profonde — La cause profonde technique et les facteurs contributifs qui l’ont rendue possible (lacunes dans les processus, angles morts de surveillance, deficiences de formation, faiblesses architecturales).
Evaluation de l’impact — Quantifiez l’impact : nombre d’enregistrements exposes, nombre de clients affectes, duree de la perturbation du service, cout financier (direct et indirect), implications reglementaires.
Efficacite de la reponse — Qu’est-ce qui a bien fonctionne ? Qu’est-ce qui aurait pu etre fait plus rapidement ou mieux ? Les procedures etaient-elles adequates ? L’equipe disposait-elle des outils et des informations necessaires ?
Actions a mener — Des ameliorations specifiques, attribuees et limitees dans le temps. Chaque action doit avoir un responsable et une echeance. Les actions qui ne sont jamais completees sont pires que l’absence d’actions — elles signalent aux auditeurs que votre processus d’amelioration est de facade plutot que veritable.

Reinjecter les conclusions dans l’ISMS. Les conclusions post-incident doivent alimenter plusieurs processus de l’ISMS :

Mettre a jour votre evaluation des risques si l’incident a revele des risques precedemment non identifies ou a demontre que des risques existants etaient sous-evalues
Reviser les controles et procedures en fonction des faiblesses identifiees
Mettre a jour le contenu de la formation pour combler les lacunes de competences ou de sensibilisation revelees par l’incident
Determiner si l’incident affecte votre Declaration d’Applicabilite ou la selection des controles

Procedures de signalement et d’escalade

ISO 27001 exige que vous definissiez et communiquiez des procedures d’escalade afin que les incidents atteignent les bonnes personnes au bon moment.

Escalade interne

Matrice d’escalade basee sur la gravite. Definissez qui est notifie a chaque niveau de gravite :

Gravite	Notification immediate	Dans l’heure	Dans les 4 heures
P1	Equipe de reponse aux incidents, RSSI/Responsable securite, CTO	PDG, Conseiller juridique, Responsable du succes client	Conseil d’administration (si violation de donnees confirmee)
P2	Equipe de reponse aux incidents, Responsable securite	Responsable ingenierie, Conseiller juridique	RSSI, CTO
P3	Analyste securite d’astreinte	Responsable securite	Responsable ingenierie
P4	Analyste securite d’astreinte	Responsable securite (jour ouvrable suivant)	—

Autorite d’escalade. Toute personne dans l’organisation doit pouvoir signaler un evenement de securite. Cependant, l’autorite de declarer un incident (declenchant les procedures formelles de reponse) et d’escalader la gravite doit etre definie. Typiquement, l’analyste securite ou l’ingenieur d’astreinte peut declarer les incidents P3 et P4, tandis que les declarations P1 et P2 necessitent la confirmation du responsable securite ou du commandant d’incident. De maniere cruciale, l’escalade ne doit jamais etre retardee parce que l’autorite designee n’est pas disponible — definissez des autorites de secours pour chaque role.

Signalement externe

Notification reglementaire. Si l’incident implique des donnees personnelles de residents de l’UE, l’article 33 du GDPR exige une notification a l’autorite de controle dans les 72 heures suivant la prise de connaissance de la violation. L’article 34 peut exiger une notification directe aux personnes concernees si la violation presente un risque eleve pour leurs droits et libertes. Vos procedures de reponse aux incidents doivent inclure des etapes specifiques pour evaluer les obligations de notification GDPR et executer les notifications dans les delais requis. Consultez notre guide complet de notification de violation de donnees GDPR pour les exigences detaillees.

Notification aux clients. Pour les entreprises SaaS, la notification aux clients est souvent a la fois une obligation contractuelle et un imperatif de confiance. Vos procedures doivent definir :

Les criteres pour determiner quels clients doivent etre notifies
Les delais de notification (souvent definis dans votre DPA ou accord de service — voir notre guide DPA GDPR)
Les canaux de communication (courriel, page de statut, notification dans l’application, telephone pour les comptes critiques)
Les exigences de contenu (ce qui s’est passe, quelles donnees ont ete affectees, ce que vous faites a ce sujet, ce que les clients doivent faire)
La cadence de communication de suivi

Forces de l’ordre. Certains incidents peuvent justifier l’implication des forces de l’ordre — en particulier si une activite criminelle est suspectee (ransomware, vol delibere de donnees, menace interne). Vos procedures doivent definir les criteres de notification aux forces de l’ordre et identifier qui dans votre organisation a l’autorite d’engager les forces de l’ordre.

Conservation des preuves

Le controle A.5.28 traite specifiquement de la collecte et de la conservation des preuves. Pour les entreprises SaaS, cela est particulierement important car votre infrastructure existe dans des environnements cloud ou les preuves peuvent etre ephemeres.

Principes de conservation des preuves :

Collectez tot. Commencez la collecte des preuves des qu’un incident est suspecte, pas apres sa confirmation. Les preuves qui ne sont pas collectees ne peuvent pas etre analysees ulterieurement.
Maintenez la chaine de custody. Documentez qui a collecte chaque element de preuve, quand, comment et ou il a ete stocke. Si les preuves peuvent etre utilisees dans des procedures judiciaires, la documentation de la chaine de custody doit etre rigoureuse.
Preservez l’integrite. Ne modifiez pas les preuves pendant la collecte. Utilisez des outils d’imagerie forensique qui creent des copies exactes. Calculez et enregistrez les valeurs de hachage (SHA-256) pour toutes les preuves collectees afin de prouver qu’elles n’ont pas ete alterees apres la collecte.
Stockage securise. Stockez les preuves dans un emplacement accessible uniquement au personnel autorise. Les preuves stockees dans le meme environnement qui a ete compromis ne sont pas securisees.

Types de preuves specifiques au SaaS a conserver :

Journaux d’audit cloud — CloudTrail, GCP Audit Logs, Azure Activity Logs. Ces journaux peuvent avoir des limites de retention — assurez-vous qu’ils sont conserves avant leur rotation.
Journaux applicatifs — Journaux d’acces API, journaux d’authentification, journaux d’autorisation, journaux d’erreurs. Centralisez-les avant qu’ils ne soient ecrases par la rotation normale des journaux.
Journaux d’audit de base de donnees — Journaux de requetes montrant quelles donnees ont ete consultees, par qui et quand.
Journaux de flux reseau — Journaux de flux VPC, journaux de repartiteur de charge, journaux WAF montrant les schemas de trafic.
Journaux de conteneurs et d’orchestration — Journaux d’audit Kubernetes, journaux de conteneurs Docker, enregistrements de deploiement.
Historique Infrastructure-as-Code — Historique Git pour Terraform, CloudFormation ou d’autres depots IaC montrant toute modification non autorisee.
Courriels et enregistrements de communication — Pertinents pour les incidents d’ingenierie sociale. Conservez le courriel de phishing, les en-tetes de message et toute communication que l’attaquant a eue avec les employes.
Etat du systeme — Vidages memoire, images disque, listes de processus en cours d’execution, etats des connexions reseau. Dans les environnements cloud, creez des instantanes des instances affectees avant de les terminer.

Modele de politique de gestion des incidents

Votre politique de gestion des incidents est un document requis au sein de votre ISMS. Elle doit etre examinee et approuvee par la direction, communiquee a tout le personnel concerne et revisee au moins annuellement. Voici un plan structurel aligne sur les exigences ISO 27001.

1. Objet et perimetre — Definir l’objectif de la politique (gestion systematique des incidents de securite de l’information) et son perimetre (tous les systemes, donnees et personnel dans le perimetre de l’ISMS).

2. Definitions — Definir evenement de securite de l’information, incident de securite de l’information et niveaux de gravite des incidents. Utilisez les definitions ISO 27000 comme point de depart et adaptez-les au contexte de votre organisation.

3. Roles et responsabilites — Definir les roles de l’equipe de reponse aux incidents (Commandant d’incident, Responsable technique, Responsable des communications, Scribe), identifier qui remplit chaque role et etablir des affectations de secours. Definir les responsabilites de tous les employes (obligations de signalement, conservation des preuves).

4. Classification des incidents — Documenter vos niveaux de gravite (P1-P4), les criteres pour chaque niveau, et les exigences d’escalade et de reponse associees a chacun.

5. Procedures de reponse — Referencez vos playbooks de reponse detailles pour chaque type d’incident. La politique etablit le cadre ; les playbooks fournissent les procedures etape par etape.

6. Communication et notification — Definir les voies d’escalade internes, les obligations de notification externes (reglementaire, client, forces de l’ordre), les modeles de communication et les workflows d’approbation pour les communications externes.

7. Traitement des preuves — Definir les procedures de collecte des preuves, les exigences de chaine de custody, les emplacements de stockage securise et les periodes de retention.

8. Revue post-incident — Imposer les revues post-incident pour tous les incidents P1 et P2, definir le processus de revue et etablir le lien entre les conclusions de la revue et les actions correctives.

9. Tests et exercices — Definir la frequence et les types de tests de reponse aux incidents (exercices sur table, simulations, exercices red team) et l’exigence de documenter les resultats des tests et les ameliorations.

10. Indicateurs et reporting — Definir les KPI de gestion des incidents qui sont rapportes a la direction et examines dans le cadre du processus de revue de direction.

Cette politique doit s’integrer dans votre cadre de politiques ISMS plus large et etre referencee dans votre liste de controle de certification.

Exercices sur table

Les exercices sur table sont le moyen le plus pratique de tester vos procedures de reponse aux incidents sans impacter les systemes de production. Les auditeurs ISO 27001 voient d’un bon oeil les organisations qui exercent regulierement leurs capacites de reponse.

Structure d’un exercice sur table :

Briefing du scenario — Le facilitateur presente un scenario d’incident realiste pertinent pour votre organisation. Pour les entreprises SaaS, les scenarios doivent etre inspires d’incidents reels dans votre secteur.
Injections par phases — Le facilitateur revele de nouvelles informations par etapes, simulant comment un incident se deroule en realite. Chaque injection oblige l’equipe a reevaluer, prendre des decisions et entreprendre des actions.
Discussion d’equipe — A chaque phase, l’equipe de reponse discute de ce qu’elle ferait, qui elle contacterait, quelles informations elle aurait besoin et quelles decisions elle devrait prendre. Cela revele les lacunes dans les procedures, les responsabilites floues et les capacites manquantes.
Debriefing — Apres la conclusion du scenario, l’equipe passe en revue ce qui a fonctionne, ce qui n’a pas fonctionne et ce qui doit changer. Cela produit une liste d’actions similaire a une revue post-incident.

Scenarios d’exercices sur table recommandes pour les entreprises SaaS :

Violation de donnees clients — Un attaquant exploite une vulnerabilite d’injection SQL pour exfiltrer des enregistrements clients. Teste les procedures de detection, de confinement, de notification client et de notification de violation GDPR.
Ransomware — Un ransomware chiffre les bases de donnees de production et l’attaquant exige un paiement. Teste les procedures de sauvegarde et de recuperation, la continuite d’activite, la prise de decision de la direction et la communication client.
Compromission de la chaine d’approvisionnement — Une dependance open-source largement utilisee est decouverte comme contenant du code malveillant present dans votre environnement de production depuis des semaines. Teste l’evaluation des vulnerabilites, l’analyse du rayon d’explosion et la remediation a grande echelle.
Menace interne — Un employe sur le depart est decouvert comme ayant exfiltre des donnees proprietaires pendant des mois. Teste les procedures de revue d’acces, les capacites d’investigation forensique, la coordination juridique et l’implication des ressources humaines.
Compromission de l’infrastructure cloud — Un attaquant accede a votre console de gestion cloud via un compte de service compromis. Teste les procedures de reponse specifiques au cloud, la verification de l’integrite de l’Infrastructure-as-Code et la validation de l’isolation multi-tenant.
Attaque DDoS — Une attaque DDoS soutenue submerge votre application, la rendant indisponible pour les clients. Teste les procedures d’incident de disponibilite, le basculement CDN/WAF, la communication client et l’evaluation de l’impact SLA.

Frequence et documentation. Effectuez des exercices sur table au moins deux fois par an, en alternant les differents scenarios. Documentez chaque exercice : le scenario presente, les participants, les decisions prises, les lacunes identifiees et les actions resultantes. Cette documentation sert de preuve d’audit de votre programme de test.

Scenarios d’incidents specifiques au SaaS

Les entreprises SaaS font face a des types d’incidents que les organisations traditionnelles sur site peuvent ne pas rencontrer. Votre cadre de gestion des incidents doit en tenir compte.

Exposition de donnees multi-tenant

Un defaut de code ou une mauvaise configuration fait qu’un tenant voit les donnees d’un autre tenant. C’est l’un des incidents les plus prejudiciables pour une entreprise SaaS car il sape la confiance fondamentale que les donnees clients sont isolees.