Modèles de réponse aux incidents
En savoir plus sur Well-Architected Trust → Security Incident Response
Des incidents de sécurité se produiront malgré les mesures préventives. Trust architecture nécessite une conception pour la détectabilité, une réponse rapide, l’enquête médico-légale et une récupération gracieuse. Cette page regroupe les modèles de réponse aux incidents de la section Réponse aux incidents du pilier Trust, qui couvre l’architecture de détection, les procédures de réponse, les capacités de criminalistique et l’apprentissage post-incident.
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Surveillance des événements | ✅ Activer la Surveillance des événements en capturant les modèles de connexion, les exportations de données en masse, les changements d’autorisation et l’activité d’API avec l’acheminement vers les plates-formes SIEM pour la rétention qui dépasse les limites de rétention natives |
| Stratégies de sécurité des transactions | ✅ Configurer des stratégies évaluant les événements en temps réel pour bloquer les actions suspectes, demander une authentification renforcée ou déclencher des notifications basées sur des niveaux de référence comportementaux |
| Journal d’audit de configuration | ✅ Surveiller les changements de configuration administrative permettant de détecter les modifications non autorisées avec une rétention de 180 jours |
| Consignation d’application personnalisée | ✅ Implémenter la consignation des événements pertinents pour la sécurité dans Apex capturant les échecs d’authentification, les refus d’autorisation et les modèles d’entrée suspects |
| Surveillance du contrôle d’intégrité | ✅ Configurer la détection automatisée des écarts de configuration par rapport aux normes de sécurité qui peuvent indiquer des modifications non autorisées |
| Intégration SIEM | ✅ Acheminer les journaux de Surveillance des événements vers les plates-formes SIEM d’entreprise pour la corrélation avec la télémétrie de sécurité d’entreprise et l’analyse comportementale |
| Règles d’alerte | ✅ Concevoir des règles d’alerte détectant les modèles suspects (accès en masse hors des heures ouvrables, connexion à partir de nouvelles zones géographiques, escalade rapide des autorisations) avec des références comportementales pour minimiser les faux positifs |
| Analyse comportementale | ✅ Établir des références comportementales permettant la détection d’anomalies pour les volumes d’accès aux données inhabituels, l’activité administrative en dehors des heures de bureau et les modèles de consommation d’API |
| Détection multicanal | ✅ Implémenter la détection via la Surveillance des événements, la Sécurité des transactions, le Journal d’audit de configuration, la consignation personnalisée et le Contrôle d’intégrité fournissant plusieurs signaux de détection indépendants |
| Stockage immuable des journaux | ✅ Acheminer les journaux vers un stockage externe immuable que les assaillants ne peuvent pas modifier, même avec un accès Salesforce administratif, garantissant l’intégrité des preuves médico-légales |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Rétention native des journaux uniquement | ⚠️ S’appuyant uniquement sur des fenêtres de rétention natives du journal d’audit Salesforce (limites natives de Surveillance des événements, 180 jours du journal d’audit de configuration) sans archivage externe, la découverte des journaux expirés lorsque l’enquête nécessite une analyse historique |
| Aucune référence comportementale | ⚠️ Ne pas avoir de référence comportementale pour la détection des anomalies, générant des alertes faussement positives excessives qui entraînent les équipes de sécurité à ignorer les notifications |
| Aucune intégration SIEM | ⚠️ Manque d’intégration SIEM d’entreprise, absence d’opportunités de corrélation avec la télémétrie de sécurité d’autres systèmes qui révéleraient des schémas de compromis plus larges |
| Examen manuel du journal | ⚠️ Selon l’examen manuel périodique du journal plutôt que l’alerte automatisée, la découverte d’incidents des semaines ou des mois après l’occurrence lorsque les dommages sont importants |
| Stratégies de sécurité sans transaction | ⚠️ N’ayant pas de politiques de Sécurité des transactions en temps réel, ne disposant pas de capacités pour bloquer les actions suspectes empêchant les dommages avant qu’ils ne surviennent |
| Couverture incomplète | ⚠️ Surveillance d’un seul sous-ensemble d’événements importants pour la sécurité (connexion, mais pas accès aux données, changements de configuration, mais pas modifications des autorisations) créant des angles morts |
| Alerte Fatigue | ⚠️ Génération d’alertes faussement positives excessives sans réglage, formation des équipes à ignorer les notifications y compris les événements de sécurité légitimes |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Limites d’isolement | ✅ Concevoir une architecture permettant d’isoler les composants compromis par la révocation d’ensembles d’autorisations, des changements de restriction IP ou la résiliation de session sans perturber les fonctions métiers critiques |
| Gestion des sessions | ✅ Implémenter des capacités de résiliation de session rapides pour les comptes compromis, y compris la déconnexion forcée et l’invalidation de session dans toutes les sessions actives |
| Révocation d’autorisation | ✅ Accordez des privilèges via des ensembles d’autorisations plutôt que des profils de référence afin de permettre une révocation rapide : le retrait de l’attribution d’ensemble d’autorisations révoque l’accès lorsqu’aucun profil ou autre attribution n’accorde indépendamment la même autorisation |
| Restrictions IP | ✅ Configurer des plages IP de connexion au niveau du profil pour les comptes privilégiés afin de refuser purement et simplement les connexions à partir d’autres adresses, ce qui permet d’isoler rapidement au niveau du réseau les emplacements administratifs connus |
| Suspension du compte utilisateur | ✅ Implémenter des procédures de gel des comptes qui empêchent l’authentification tout en préservant les données pour enquête sans supprimer le compte compromis |
| Contrôles d’accès API | ✅ Concevoir l’authentification d’API avec des capacités de révocation de jeton permettant d’isoler rapidement les comptes d’intégration compromis |
| Isolation multi-organisations | ✅ Pour des actifs de grande valeur, évaluer l’architecture multi-organisations offrant la plus forte isolation pour les composants critiques au prix d’une complexité opérationnelle accrue |
| Procédures de bris de verre d’urgence | ✅ Maintenir des procédures documentées d’accès aux bris de verre pour l’accès administratif d’urgence avec l’audit et la validation après utilisation |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Aucune limite d’isolement | ⚠️ Absence de frontières d’isolation architecturale nécessitant un arrêt complet du système pour contenir tout compromis, perturbant toutes les fonctions métiers |
| Accès trop permissif | ⚠️ Octroi de larges autorisations Modifier toutes les données empêchant la révocation de privilèges granulaires sans perturber les processus métiers multiples |
| Comptes de service partagés | ⚠️ Utilisation d’un compte « Utilisateur d’API » ou « Utilisateur d’intégration » partagé unique à travers plusieurs systèmes empêchant l’isolation d’une intégration spécifique compromise sans rompre toutes les intégrations |
| Aucune restriction IP | ⚠️ Ne pas avoir de liste d’autorisations IP pour les comptes privilégiés, ne pas avoir de capacités de confinement au niveau du réseau lorsque les comptes sont compromis |
| Aucune gestion de session | ⚠️ Absence de capacités de terminaison de session nécessitant la réinitialisation du mot de passe comme seul moyen de forcer la déconnexion, introduisant des délais pendant les fenêtres de réponse critiques |
| Aucune procédure d’urgence | ⚠️ Ne pas avoir de procédures de bris de vitre ou d’accès d’urgence documentées, improviser les décisions critiques sous pression lors d’incidents actifs |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Journaux de surveillance des événements | ✅ Capturer des journaux d’activité détaillés, notamment les actions des utilisateurs, les appels d’API, les événements d’authentification et les modèles d’accès aux données, avec suffisamment de détails pour l’analyse médico-légale |
| Journal d’audit des champs | ✅ Activer le Journal d’audit des champs en préservant l’historique des modifications des données pour les champs Restreint et Confidentiel avec des exigences réglementaires de rétention correspondantes (prend en charge la rétention illimitée ; confirme la période requise par rapport à la réglementation en vigueur) |
| Stockage immuable | ✅ Acheminer les journaux vers un stockage immuable externe que les assaillants ne peuvent pas modifier, garantissant l’intégrité des preuves médico-légales tout au long de l’enquête |
| Journal d’audit de configuration | ✅ Préserver l’historique des changements de configuration administrative permettant d’enquêter sur les modifications non autorisées du système avec une rétention de 180 jours |
| Évaluation du périmètre | ✅ Concevoir des modèles d’autorisation et des contrôles d’accès aux données permettant d’évaluer rapidement l’étendue de l’exposition aux données en fonction des privilèges de compte compromis |
| Corrélation des modifications | ✅ Maintenir la corrélation entre les changements de configuration du Journal d’audit de configuration et les modèles d’activité de Surveillance des événements, ce qui permet d’étudier les techniques des assaillants |
| Consignation de l’accès aux données | ✅ Consigner tous les accès aux données restreintes et confidentielles permettant d’enquêter sur les données exposées pendant la période de compromis |
| Journal d’audit de l’intégration | ✅ Capturer l’authentification d’API, l’autorisation et les modèles d’échange de données pour les systèmes intégrés, ce qui permet d’étudier les compromis inter-systèmes |
| Conservation des preuves | ✅ Acheminer les journaux et les pistes d’audit en permanence vers un stockage externe immuable afin de préserver les preuves médico-légales et de les rendre disponibles lors d’une enquête sur un incident |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Stockage du journal mutable | ⚠️ Stockage des journaux uniquement dans Salesforce où les assaillants qui ont un accès administratif peuvent supprimer ou modifier les preuves médico-légales |
| Détails du journal insuffisants | ⚠️ Capture d’événements de haut niveau sans suffisamment de détails pour l’investigation (connexion enregistrée mais pas adresse IP, accès aux données enregistré mais pas enregistrements spécifiques) |
| Aucune consignation d’accès aux données | ⚠️ Absence de consignation détaillée de l’accès aux données restreintes et confidentielles, impossibilité d’évaluer l’étendue de l’exposition aux données pendant la notification d’infraction |
| Journal d’audit des champs manquant | ⚠️ Ne pas activer le Journal d’audit des champs confidentiels, impossible de déterminer quelles valeurs de données ont été exposées lors d’un compromis |
| Corrélation Aucun changement | ⚠️ N’ayant aucune capacité de corrélation entre les changements de configuration du Journal d’audit de configuration et les modèles d’activité de Surveillance des événements suivants |
| Historique d’audit supprimé | ⚠️ Autoriser l’expiration de l’historique d’audit avant le minimum de rétention réglementaire les ensembles de réglementations régissant votre déploiement, créant des infractions à la conformité |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Objectifs de temps de récupération | ✅ Définir et tester l’objectif de temps de reprise (RTO) et l’objectif de point de reprise (RPO) pour des scénarios d’incident de sécurité, pas seulement des scénarios de reprise après sinistre |
| Procédures de récupération testées | ✅ Processus de récupération de documents pour les comptes compromis, l’exfiltration de données en masse, les déploiements non autorisés, l’escalade des privilèges et la compromission de package avec des tests trimestriels |
| Validation de la sauvegarde | ✅ Valider régulièrement l’intégrité des sauvegardes en veillant à ce que les capacités de restauration fonctionnent lors d’incidents de sécurité, pas seulement en cas d’échec opérationnel |
| Capacités de restauration | ✅ Concevoir des pipelines de déploiement avec des procédures de restauration testées pour les déploiements de code non autorisés ou les changements de configuration malveillants |
| Permutation des identifiants | ✅ Implémenter des procédures de rotation rapide des identifiants pour les comptes d’intégration, les utilisateurs d’API et les identifiants nommés compromis |
| Restauration des autorisations | ✅ Documenter les procédures de restauration de l’accès approprié après des actions d’isolement trop larges pendant la réponse à l’incident |
| Restauration des données | ✅ Concevoir des capacités de reprise des données traitant la corruption ou la suppression des données résultant d’incidents de sécurité, distinctes de la reprise après sinistre |
| Continuité du service | ✅ Solutions d’architecte afin que les procédures de réponse aux incidents de sécurité maintiennent la continuité des fonctions commerciales critiques pendant l’enquête et la réparation |
| Validation de la restauration | ✅ Tester les procédures de reprise trimestrielles pour vérifier que les systèmes restaurés fonctionnent correctement et que le compromis n’a pas persisté par la restauration |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Procédures non testées | ⚠️ Avoir documenté des procédures de récupération jamais testées par des exercices, découvrir lors d’incidents réels que les procédures sont incomplètes ou incorrectes |
| Pas de RTO/RPO pour la sécurité | ⚠️ Définition d’objectifs de temps de reprise uniquement pour la reprise après sinistre sans prendre en compte les scénarios d’incident de sécurité nécessitant différentes procédures de reprise |
| Aucune capacité de restauration | ⚠️ Absence de procédures de restauration du déploiement pour les déploiements de code non autorisés, nécessitant un réaménagement complet pour supprimer les modifications malveillantes |
| Sauvegardes non validées | ⚠️ Ne jamais tester la restauration de sauvegarde, découvrir lors d’incidents que les sauvegardes sont corrompues ou incomplètes |
| Aucune procédure de permutation des identifiants | ⚠️ Ne pas avoir de procédures de rotation rapide des identifiants pour les comptes d’intégration compromis, laissant les identifiants compromis actifs pendant l’enquête |
| Processus de récupération manuels | ⚠️ En fonction entièrement des procédures manuelles de reprise lors d’incidents, introduire des erreurs et des délais lorsque la vitesse est critique |
| Aucun test de restauration | ⚠️ Ne jamais valider que les systèmes restaurés fonctionnent correctement après la récupération, ce qui peut réintroduire une compromission ou une corruption des données |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Réponse du compte utilisateur compromise | ✅ Procédures de document: suspendre l’utilisateur, forcer la réinitialisation des identifiants, examiner le Journal d’audit de configuration et les journaux d’accès aux données pour la période de compromis, évaluer l’étendue de l’exposition aux données, exécuter une notification d’infraction si Données restreintes accédées |
| Réponse d’exfiltration de données en masse | ✅ Procédures de document: révoquer immédiatement la session, restreindre les autorisations, identifier les enregistrements et les niveaux de classification affectés, exécuter la notification d’infraction réglementaire dans les délais fixés par la réglementation régissant votre déploiement |
| Réponse de déploiement de code non autorisé | ✅ Procédures de document: annulez immédiatement le déploiement, auditez toutes les modifications des identifiants compromis, vérifiez la sécurité du pipeline pour le contournement des autorisations, scannez le code déployé pour détecter les portes dérobées persistantes |
| Privilégier la réponse d’escalade | ✅ Procédures de document: révoquer immédiatement les privilèges escaladés, auditer les activités exécutées avec un accès élevé, examiner comment l’escalade contourne les contrôles d’approbation, implémenter des contrôles compensatoires |
| Réponse de compromis du package AppExchange | ✅ Procédures de document: isoler les autorisations de package, évaluer les données accédées par package, évaluer les options de remplacement de package, documenter les leçons apprises pour les critères d’évaluation de package |
| Signaux de détection | ✅ Configurez la surveillance en détectant chaque scénario : anomalies de connexion pour les comptes compromis, volume d’exportation de rapports pour exfiltration, surveillance du déploiement pour code non autorisé, surveillance du changement d’autorisation pour escalade |
| Exercices sur table | ✅ Mener des exercices sur table testant les procédures de réponse pour des scénarios spécifiques à la plate-forme validant la préparation de l’équipe et l’exhaustivité des procédures |
| Automatisation des réponses | ✅ Les stratégies de sécurité des transactions en temps réel bloquent automatiquement les actions suspectes, nécessitent une authentification renforcée ou notifient les intervenants sur les signaux de détection de confiance élevée, offrant un confinement automatisé qui réduit le temps de réponse |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Plans de réponse génériques uniquement | ⚠️ N’avoir que des procédures génériques de réponse aux incidents sans guide spécifique à Salesforce, en improvisant des actions spécifiques à la plate-forme pendant les incidents actifs |
| Aucune configuration de détection | ⚠️ Ne pas avoir de surveillance configurée pour détecter des scénarios spécifiques à la plate-forme (exportation en masse, escalade des privilèges, déploiement non autorisé), découverte d’incidents via des rapports utilisateur ou des audits |
| Aucun exercice sur table | ⚠️ Ne jamais effectuer d’exercices sur table validant la familiarité de l’équipe avec les procédures d’intervention spécifiques à la plate-forme, en découvrant les lacunes Knowledge lors d’incidents réels |
| Aucune automatisation | ⚠️ Réponse entièrement manuelle pour tous les incidents sans stratégie de sécurité des transactions en temps réel pour le confinement automatisé, introduisant des délais lorsque le blocage immédiat pourrait réduire les dommages |
| Playbooks Réponse manquante | ⚠️ Absence de playbooks de réponse documentés pour des scénarios courants (compte utilisateur compromis, exfiltration de données, déploiement de code non autorisé) |
| Procédures de notification sans infraction | ⚠️ Ne pas avoir de procédures pour les exigences réglementaires en matière de notification d’infraction, se démener pour comprendre les obligations lors d’incidents réels lorsque les délais sont serrés |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Communication hors bande | ✅ Établir des canaux de communication qui ne dépendent pas de systèmes potentiellement compromis (arborescences téléphoniques, plates-formes de messagerie externes) pour coordonner la réponse |
| Procédures d’escalade | ✅ Documenter les parcours d’escalade depuis la détection initiale jusqu’à la notification exécutive avec les coordonnées et les critères d’escalade |
| Modèles de notification | ✅ Maintenir des modèles de notification pré-rédigés pour les types d’incident courants permettant une communication rapide avec les parties prenantes, les clients et les régulateurs |
| Identification des parties prenantes | ✅ Identifier les parties prenantes qui nécessitent une notification pour différents types d’incident, y compris les dirigeants, les autorités juridiques, de conformité, les utilisateurs affectés et les autorités réglementaires |
| Chronologie des notifications réglementaires | ✅ Documenter les exigences réglementaires de notification de chaque juridiction, confirmées par rapport à la réglementation en vigueur pour votre déploiement, avec des procédures garantissant la conformité en temps opportun |
| Coordination interne | ✅ Concevoir des procédures de coordination des incidents précisant les rôles et responsabilités (commandant des incidents, responsable technique, responsable de la communication, liaison juridique) |
| Coordination externe | ✅ Établir des procédures de coordination avec le Support Salesforce, les enquêteurs externes de police scientifique, les conseillers juridiques et les forces de l’ordre, selon les besoins |
| Communication du statut | ✅ Mettre en œuvre une cadence de communication de statut régulière lors d’incidents actifs en tenant les parties prenantes informées sans surcharger l’équipe d’enquête |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Aucune communication hors bande | ⚠️ En fonction entièrement de la messagerie électronique ou interne potentiellement compromise pour la coordination des incidents, perte de capacité de communication lorsque les canaux principaux sont compromis |
| Chemins d’escalade imprécis | ⚠️ Ne pas avoir de procédures d’escalade documentées, ce qui entraîne des retards et une confusion quant aux personnes qui doivent être notifiées et quand |
| Aucun modèle de notification | ⚠️ Améliorer les notifications d’incidents lors d’incidents actifs sous pression temporelle, entraînant des communications incomplètes ou incorrectes |
| Listes de parties prenantes manquantes | ⚠️ Ne pas avoir de listes d’intervenants pré-identifiées, découvrir lors d’incidents que des parties critiques (juridiques, de conformité, dirigeants) n’ont pas été notifiées |
| Aucune sensibilisation à la chronologie réglementaire | ⚠️ Ne pas connaître les délais de notification réglementaires qui s’appliquent à votre déploiement lors d’une intervention en cas d’incident, ne pas respecter les délais et créer d’autres infractions à la conformité |
| Rôles ambigus | ⚠️ Avoir des rôles et des responsabilités peu clairs en matière de réponse aux incidents, ce qui sème la confusion sur les personnes habilitées à prendre des décisions de confinement |
| Aucune procédure de coordination externe | ⚠️ N’ayant aucune relation ou procédure établie pour engager le Support Salesforce, les enquêteurs judiciaires ou les forces de l’ordre si nécessaire |
Modèles
| Où chercher | À quoi ressemble le bien |
|---|---|
| Culture irréprochable | ✅ Orienter les examens postérieurs à un incident sur les améliorations du système plutôt que sur la responsabilité individuelle, ce qui permet d’apprendre à l’organisation sans craindre de répercussions |
| Documentation sur la chronologie des incidents | ✅ Documenter la chronologie complète des incidents, y compris le compromis initial, la détection, les actions de réponse et la résolution avec des horodatages précis |
| Contrôle de l’analyse des échecs | ✅ Identifier les contrôles préventifs et détectives qui ont échoué à prévenir ou détecter l’incident, en informant les améliorations architecturales |
| Documentation sur la faiblesse architecturale | ✅ Documenter les faiblesses architecturales révélées par l’incident dans les enregistrements de décision d’architecture (ADR) en capturant les changements de sécurité |
| Priorisation de l’assainissement | ✅ Donner la priorité aux mesures correctives en fonction du potentiel de réduction des risques, en traitant les causes profondes plutôt que les symptômes |
| Partage de leçon | ✅ Partager les leçons apprises entre les équipes et les unités commerciales afin d’éviter des incidents similaires dans d’autres parties de l’organisation |
| Mises à jour des règles de détection | ✅ Mettre à jour les règles de détection et les références comportementales basées sur les techniques d’attaque observées pendant l’enquête |
| Affinage de la procédure de réponse | ✅ Mettre à jour les procédures de réponse aux incidents en fonction de ce qui a fonctionné et de ce qui n’a pas fonctionné pendant la réponse à l’incident réel |
| Suivi des métriques | ✅ Suivre le temps moyen de détection (MTTD), le temps moyen de réponse (MTTR) et l’étendue de l’impact au fil du temps en identifiant les tendances nécessitant un investissement architectural |
| Réviser la cadence | ✅ Effectuer un examen postérieur à l’incident en temps opportun pendant que les détails restent à jour et que la dynamique d’amélioration existe |
Anti-modèles
| Où chercher | À quoi ressemble mal |
|---|---|
| Ignoré les commentaires | ⚠️ Ignorer les examens postérieurs à l’incident, passer directement à l’incident suivant sans capturer les leçons apprises ou les améliorations architecturales |
| Blâmer la culture | ⚠️ Axer les examens postérieurs aux incidents sur la responsabilité individuelle plutôt que sur les améliorations du système, ce qui entraîne la dissimulation des incidents et empêche l’apprentissage organisationnel |
| Aucune documentation architecturale | ⚠️ Échec de la documentation des changements d’architecture de sécurité entraînés par les apprentissages sur les incidents dans les enregistrements de décision d’architecture (ADR) |
| Traitement des symptômes | ⚠️ Ne traiter que les symptômes d’incidents (mot de passe compromis) sans fixer les causes profondes (absence de MFA), permettant la réussite d’attaques similaires |
| Aucun partage de leçon | ⚠️ Garder les apprentissages sur les incidents au sein de l’équipe d’intervention plutôt que de partager entre les organisations, permettant des incidents similaires dans d’autres unités commerciales |
| Aucune mise à jour de détection | ⚠️ Échec de la mise à jour des règles de détection ou des références comportementales basées sur les techniques d’attaque observées, restant vulnérable à des attaques similaires |
| Aucun suivi des métriques | ⚠️ Ne pas suivre le temps moyen de détection (MTTD), le temps moyen de réponse (MTTR) ou les tendances du périmètre, les opportunités manquantes pour identifier les faiblesses systémiques |
| Examens retardés | ⚠️ Effectuer des examens postérieurs à l’incident des mois après la résolution de l’incident lorsque les détails sont oubliés et que la dynamique d’amélioration est perdue |
| Aucun suivi de l’assainissement | ⚠️ Identification des améliorations lors de l’examen postérieur à l’incident, mais échec de leur mise en œuvre, permettant ainsi la répétition d’incidents similaires |