Recommandations pour la réponse aux incidents de sécurité

  • Article

S’applique à la recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :

SE :12 Définissez et testez des procédures efficaces de réponse aux incidents qui couvrent un éventail d’incidents, des problèmes localisés à la récupération d’urgence. Définissez clairement l’équipe ou l’individu qui exécute une procédure.

Ce guide décrit les recommandations relatives à l’implémentation d’une réponse aux incidents de sécurité pour une charge de travail. En cas de compromission de la sécurité d’un système, une approche de réponse systématique aux incidents permet de réduire le temps nécessaire à l’identification, à la gestion et à l’atténuation des incidents de sécurité. Ces incidents peuvent menacer la confidentialité, l’intégrité et la disponibilité des systèmes logiciels et des données.

La plupart des entreprises disposent d’une équipe centrale des opérations de sécurité (également appelée Security Operations Center (SOC) ou SecOps). L’équipe chargée des opérations de sécurité a pour responsabilité de détecter, de hiérarchiser et de trier rapidement les attaques potentielles. L’équipe surveille également les données de télémétrie liées à la sécurité et enquête sur les violations de sécurité.

Illustration conceptuelle qui montre une approche collaborative pour atténuer les risques potentiels et réalisés.

Toutefois, vous avez également la responsabilité de protéger votre charge de travail. Il est important que toutes les activités de communication, d’investigation et de chasse soient un effort de collaboration entre l’équipe de charge de travail et l’équipe SecOps.

Ce guide fournit des recommandations pour vous et votre équipe de charge de travail afin de vous aider à détecter, trier et examiner rapidement les attaques.

Définitions

Terme Définition
Alerte Notification qui contient des informations sur un incident.
Fidélité des alertes Précision des données qui déterminent une alerte. Les alertes de haute fidélité contiennent le contexte de sécurité nécessaire pour prendre des mesures immédiates. Les alertes de faible fidélité manquent d’informations ou contiennent du bruit.
Faux positif Alerte qui indique un incident qui ne s’est pas produit.
Incident Événement qui indique un accès non autorisé à un système.
Réponse aux incidents Processus qui détecte, répond et atténue les risques associés à un incident.
Tri Opération de réponse aux incidents qui analyse les problèmes de sécurité et hiérarchise leur atténuation.

Stratégies de conception

Vous et votre équipe effectuez des opérations de réponse aux incidents lorsqu’il existe un signal ou une alerte pour une compromission potentielle. Les alertes de haute fidélité contiennent un contexte de sécurité suffisant qui permet aux analystes de prendre facilement des décisions. Les alertes de haute fidélité entraînent un faible nombre de faux positifs. Ce guide suppose qu’un système d’alerte filtre les signaux de faible fidélité et se concentre sur les alertes de haute fidélité qui peuvent indiquer un incident réel.

Attribuer une notification d’incident

Les alertes de sécurité doivent atteindre les personnes appropriées au sein de votre équipe et dans votre organization. Établissez un point de contact désigné au sein de votre équipe de charge de travail pour recevoir des notifications d’incident. Ces notifications doivent inclure autant d’informations que possible sur la ressource compromise et le système. L’alerte doit inclure les étapes suivantes afin que votre équipe puisse accélérer les actions.

Nous vous recommandons de consigner et de gérer les notifications et actions d’incident à l’aide d’outils spécialisés qui conservent une piste d’audit. En utilisant des outils standard, vous pouvez conserver les éléments de preuve qui pourraient être requis pour des enquêtes juridiques potentielles. Recherchez les opportunités d’implémenter l’automatisation qui peut envoyer des notifications en fonction des responsabilités des parties responsables. Gardez une chaîne claire de communication et de création de rapports pendant un incident.

Tirez parti des solutions SIEM (Security Information Event Management) et des solutions SOAR (Security Orchestration Automated Response) fournies par votre organization. Vous pouvez également vous procurer des outils de gestion des incidents et encourager vos organization à les standardiser pour toutes les équipes de charge de travail.

Examiner avec une équipe de triage

Le membre de l’équipe qui reçoit une notification d’incident est responsable de la configuration d’un processus de tri qui implique les personnes appropriées en fonction des données disponibles. L’équipe de triage, souvent appelée équipe de pont, doit s’entendre sur le mode et le processus de communication. Cet incident nécessite-t-il des discussions asynchrones ou des appels de pont ? Comment l’équipe doit-elle suivre et communiquer l’avancement des enquêtes ? Où l’équipe peut-elle accéder aux ressources d’incident ?

La réponse aux incidents est une raison essentielle pour maintenir la documentation à jour, comme la disposition architecturale du système, les informations au niveau des composants, la classification de confidentialité ou de sécurité, les propriétaires et les points de contact clés. Si les informations sont inexactes ou obsolètes, l’équipe de pont perd un temps précieux à essayer de comprendre le fonctionnement du système, qui est responsable de chaque zone et quel est l’effet de l’événement.

Pour d’autres enquêtes, faites appel aux personnes appropriées. Vous pouvez inclure un gestionnaire d’incidents, un agent de sécurité ou des prospects centrés sur la charge de travail. Pour que le triage reste ciblé, excluez les personnes qui ne sont pas dans l’étendue du problème. Parfois, des équipes distinctes examinent l’incident. Il peut y avoir une équipe qui examine initialement le problème et tente d’atténuer l’incident, et une autre équipe spécialisée qui peut effectuer des analyses médico-légales pour une enquête approfondie afin de déterminer les problèmes de grande envergure. Vous pouvez mettre en quarantaine l’environnement de charge de travail pour permettre à l’équipe médico-légale d’effectuer ses investigations. Dans certains cas, la même équipe peut gérer l’ensemble de l’enquête.

Dans la phase initiale, l’équipe de triage est chargée de déterminer le vecteur potentiel et son effet sur la confidentialité, l’intégrité et la disponibilité (également appelée CIA) du système.

Dans les catégories de l’ICA, attribuez un niveau de gravité initial qui indique la profondeur des dommages et l’urgence d’une correction. Ce niveau devrait changer au fil du temps à mesure que des informations supplémentaires sont découvertes dans les niveaux de triage.

Dans la phase de découverte, il est important de déterminer un plan d’action et de communication immédiat. Y a-t-il des modifications apportées à l’état d’exécution du système ? Comment contenir l’attaque pour arrêter l’exploitation ? L’équipe doit-elle envoyer des communications internes ou externes, telles qu’une divulgation responsable ? Tenez compte de la détection et du temps de réponse. Vous pourriez être légalement obligé de signaler certains types d’infractions à une autorité réglementaire dans une période donnée, qui est souvent des heures ou des jours.

Si vous décidez d’arrêter le système, les étapes suivantes mènent au processus de récupération d’urgence de la charge de travail.

Si vous n’arrêtez pas le système, déterminez comment corriger l’incident sans affecter les fonctionnalités du système.

Récupérer à partir d’un incident

Traitez un incident de sécurité comme un sinistre. Si la correction nécessite une récupération complète, utilisez les mécanismes de récupération d’urgence appropriés du point de vue de la sécurité. Le processus de récupération doit éviter les risques de récidive. Sinon, la récupération à partir d’une sauvegarde endommagée réintroduit le problème. Le redéploiement d’un système avec la même vulnérabilité entraîne le même incident. Valider les étapes et processus de basculement et de restauration automatique.

Si le système continue de fonctionner, évaluez l’effet sur les parties en cours d’exécution du système. Continuez à surveiller le système pour vous assurer que d’autres objectifs de fiabilité et de performances sont atteints ou réajustés en implémentant des processus de dégradation appropriés. Ne compromettez pas la confidentialité en raison de l’atténuation.

Le diagnostic est un processus interactif jusqu’à ce que le vecteur, ainsi qu’un correctif et une solution de secours potentiels, soient identifiés. Après le diagnostic, l’équipe travaille sur la correction, qui identifie et applique le correctif requis dans un délai acceptable.

Les métriques de récupération mesurent le temps nécessaire pour résoudre un problème. En cas d’arrêt, il peut y avoir une urgence concernant les délais de correction. Pour stabiliser le système, il faut du temps pour appliquer des correctifs, des correctifs et des tests, et déployer des mises à jour. Déterminer les stratégies de confinement pour éviter d’autres dommages et la propagation de l’incident. Élaborer des procédures d’éradication pour éliminer complètement la menace de l’environnement.

Compromis : il existe un compromis entre les objectifs de fiabilité et les délais de correction. Lors d’un incident, il est probable que vous ne répondiez pas à d’autres exigences non fonctionnelles ou fonctionnelles. Par exemple, vous devrez peut-être désactiver certaines parties de votre système pendant que vous examinez l’incident, ou vous devrez peut-être même mettre l’ensemble du système hors connexion jusqu’à ce que vous déterminiez l’étendue de l’incident. Les décideurs métier doivent décider explicitement quelles sont les cibles acceptables pendant l’incident. Spécifiez clairement la personne responsable de cette décision.

Apprendre à partir d’un incident

Un incident révèle des lacunes ou des points vulnérables dans une conception ou une implémentation. Il s’agit d’une opportunité d’amélioration qui est pilotée par les leçons tirées des aspects de la conception technique, de l’automatisation, des processus de développement de produits qui incluent des tests et de l’efficacité du processus de réponse aux incidents. Tenir à jour des enregistrements d’incidents détaillés, y compris les actions effectuées, les chronologies et les résultats.

Nous vous recommandons vivement d’effectuer des révisions structurées après incident, telles que l’analyse de la cause racine et les rétrospectives. Suivez et hiérarchisez les résultats de ces révisions, et envisagez d’utiliser ce que vous apprenez dans les futures conceptions de charge de travail.

Les plans d’amélioration doivent inclure des mises à jour des exercices de sécurité et des tests, comme les exercices de continuité d’activité et de récupération d’urgence (BCDR). Utilisez la compromission de sécurité comme scénario pour effectuer une exploration BCDR. Les exercices peuvent valider le fonctionnement des processus documentés. Il ne doit pas y avoir plusieurs playbooks de réponse aux incidents. Utilisez une source unique que vous pouvez ajuster en fonction de la taille de l’incident et de la portée ou de la localisation de l’effet. Les exercices sont basés sur des situations hypothétiques. Effectuez des exercices dans un environnement à faible risque et incluez la phase d’apprentissage dans les exercices.

Effectuer des examens post-incidents, ou postmortems, pour identifier les faiblesses dans le processus d’intervention et les domaines à améliorer. En fonction des leçons que vous tirez de l’incident, mettez à jour le plan de réponse aux incidents (IRP) et les contrôles de sécurité.

Envoyer la communication nécessaire

Implémentez un plan de communication pour informer les utilisateurs d’une interruption et informer les parties prenantes internes de la correction et des améliorations. Les autres personnes de votre organization doivent être averties de toute modification apportée à la base de référence de sécurité de la charge de travail pour éviter de futurs incidents.

Générez des rapports d’incident à usage interne et, si nécessaire, à des fins de conformité réglementaire ou à des fins légales. Adoptez également un rapport au format standard (modèle de document avec des sections définies) que l’équipe SOC utilise pour tous les incidents. Assurez-vous qu’un rapport est associé à chaque incident avant de fermer l’enquête.

Animation Azure

Microsoft Sentinel est une solution SIEM et SOAR. Il s’agit d’une solution unique pour la détection des alertes, la visibilité des menaces, la chasse proactive et la réponse aux menaces. Pour plus d’informations, consultez Qu’est-ce que Microsoft Sentinel ?

Vérifiez que le portail d’inscription Azure inclut des informations de contact d’administrateur afin que les opérations de sécurité puissent être averties directement par le biais d’un processus interne. Pour plus d’informations, consultez Mettre à jour les paramètres de notification.

Pour en savoir plus sur l’établissement d’un point de contact désigné qui reçoit des notifications d’incident Azure de Microsoft Defender pour le cloud, consultez Configurer Notifications par e-mail pour les alertes de sécurité.

Alignement organisationnel

Cloud Adoption Framework pour Azure fournit des conseils sur la planification de la réponse aux incidents et les opérations de sécurité. Pour plus d’informations, consultez Opérations de sécurité.

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité