Partager via

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

  • Article

S’applique à cette recommandation de liste de contrôle Sécurité Power Platform Well-Architected :

SE:11 Définissez et testez des procédures efficaces de réponse aux incidents qui couvrent un spectre d’incidents, depuis les problèmes localisés jusqu’à la récupération d’urgence. Définissez clairement quelle équipe ou personne exécute une procédure.

Ce guide décrit les recommandations pour la mise en œuvre 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 systématique de réponse aux incidents permet de réduire le temps nécessaire pour identifier, gérer et atténuer les 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 d’opérations de sécurité (également connue sous le nom de centre des opérations de sécurité [SOC] ou SecOps). La responsabilité de l’équipe des opérations de sécurité est de détecter, hiérarchiser et trier rapidement les attaques potentielles. L’équipe surveille également les données télémétriques liées à la sécurité et enquête sur les failles de sécurité.

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

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

Ce guide fournit des recommandations pour vous et votre équipe chargée de la charge de travail afin de vous aider à détecter, trier et enquêter rapidement sur les attaques.

Définitions

Terme Définition
Alert Une notification qui contient des informations sur un incident.
Fidélité des alertes L’exactitude des données qui déterminent une alerte. Les alertes haute fidélité contiennent le contexte de sécurité nécessaire pour prendre des mesures immédiates. Les alertes basse fidélité manquent d’informations ou contiennent du bruit.
Faux positif Une alerte qui indique un incident qui ne s’est pas produit.
Incident Un é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.
Triage Une opération de réponse aux incidents qui analyse les problèmes de sécurité et priorise leur atténuation.

Stratégies de conception clés

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

Attribuer notification l’incident

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

Nous vous recommandons d’enregistrer et de gérer les notifications d’incidents et les actions à l’aide d’outils spécialisés qui conservent une piste d’audit. En utilisant des outils standards, vous pouvez conserver les preuves qui pourraient être nécessaires à d’éventuelles enquêtes judiciaires. Recherchez des opportunités de mise en œuvre d’une automatisation capable d’envoyer des notifications en fonction des responsabilités des parties responsables. Gardez une chaîne de communication et de reporting claire lors d’un incident.

Profitez des solutions d’informations de sécurité gestion d’événement (SIEM) et des solutions de réponse automatisée d’orchestration de sécurité (SOAR) fournies par votre organisation. Vous pouvez également vous procurer des outils de gestion des incidents et encourager votre organisation à les standardiser pour toutes les équipes chargées de la charge de travail.

Enquêter avec une équipe de triage

Le membre de l’équipe qui reçoit une notification d’incident est chargé de mettre en place un processus de tri impliquant les personnes appropriées en fonction des données disponibles. L’équipe de triage, souvent appelée équipe de pont, doivent se mettre d’accord sur le mode et le processus de communication. Cet incident nécessite-t-il des discussions asynchrones ou des ponts téléphoniques ? Comment l’équipe doit-elle suivre et communiquer les progrès des enquêtes ? Où l’équipe peut-elle accéder aux ressources liées à l’incident ?

La réponse aux incidents est une raison cruciale 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 principaux points de contact. Si les informations sont inexactes ou obsolètes, l’équipe à la passerelle perd un temps précieux à essayer de comprendre comment fonctionne le système, qui est responsable de chaque zone et quel pourrait être l’effet de l’événement.

Pour des investigations plus approfondies, impliquez les personnes appropriées. Vous pouvez inclure un gestionnaire d’incidents, un responsable de la sécurité ou des responsables centrés sur la charge de travail. Pour que le tri reste concentré, excluez les personnes qui ne relèvent pas de la portée du problème. Parfois, des équipes distinctes enquêtent sur l’incident. Il peut y avoir une équipe qui enquête initialement sur 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 des problèmes plus vastes. Vous pouvez mettre l’environnement de charge de travail en quarantaine pour permettre à l’équipe d’investigation de mener ses enquêtes. Dans certains cas, la même équipe peut gérer l’intégralité 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 la CIA, attribuez un niveau de gravité initial qui indique la profondeur des dommages et l’urgence de la réparation. Ce niveau devrait changer au fil du temps à mesure que davantage d’informations seront découvertes dans les niveaux de triage.

Dans la phase de découverte, il est important de déterminer un plan d’action immédiat et des plans de communication. Y a-t-il des changements dans l’état de fonctionnement du système ? Comment l’attaque peut-elle être contenue pour mettre un terme à toute exploitation ultérieure ? L’équipe doit-elle envoyer des communications internes ou externes, comme une divulgation responsable ? Tenez compte du temps de détection et de réponse. Vous pourriez être légalement obligé de signaler certains types de violations à une autorité de régulation dans un délai précis, qui est souvent de plusieurs heures ou jours.

Si vous décidez d’arrêter le système, les étapes suivantes mènent au processus de reprise après sinistre (DR) de la charge de travail.

Si vous n’arrêtez pas le système, déterminez comment remédier à l’incident sans affecter la fonctionnalité du système.

Se remettre d’un incident

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

Si le système continue de fonctionner, évaluez l’effet sur les pièces en fonctionnement du système. Continuez à surveiller le système pour vous assurer que les autres objectifs de fiabilité et de performance sont atteints ou réajustés en mettant en œuvre 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’une solution et une solution de repli potentielles, soient identifiés. Après le diagnostic, l’équipe travaille sur la remédiation, qui identifie et applique le correctif requis dans un délai acceptable.

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

Compromis : Compromis entre fiabilité cibles et temps remédiation. 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 enquêtez sur l’incident, ou vous devrez peut-être même mettre l’ensemble du système hors ligne jusqu’à ce que vous ayez déterminé l’étendue de l’incident. Les décideurs commerciaux doivent décider explicitement quelles sont les cibles acceptables lors de l’incident. Précisez clairement la personne responsable de cette décision.

Apprenez d’un incident

Un incident révèle des lacunes ou des points vulnérables dans une conception ou une mise en œuvre. Il s’agit d’une opportunité d’amélioration qui s’appuie sur des leçons sur les aspects de conception technique, l’automatisation, les processus de développement de produits qui incluent les tests et l’efficacité du processus de réponse aux incidents. Tenir des registres détaillés des incidents, y compris les mesures prises, les délais et les conclusions.

Nous vous recommandons fortement d’effectuer des examens structurés après incident, tels qu’une analyse des causes profondes et des rétrospectives. Suivez et hiérarchisez les résultats de ces examens, et envisagez d’utiliser ce que vous avez appris dans les futures conceptions de charges de travail.

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

Effectuer des examens post-incident, ou post-mortem, pour identifier les faiblesses du processus de réponse et les domaines à améliorer. Sur la base 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

Mettre en œuvre un plan de communication pour informer les utilisateurs d’une perturbation et informer les parties prenantes internes des mesures correctives et des améliorations. Les autres personnes de votre organisation doivent être informées de toute modification apportée à la base de sécurité de la charge de travail afin d’éviter de futurs incidents.

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

Facilitation de Power Platform

Les sections suivantes décrivent les mécanismes que vous pouvez utiliser dans le cadre de vos procédures de réponse aux incidents de sécurité.

Microsoft Sentinel

Solution Microsoft Sentinel pour Microsoft Power Platform permet aux clients de détecter diverses activités suspectes, comme :

  • Power Apps exécution à partir de zones géographiques non autorisées
  • Destruction de données suspectes par Power Apps
  • Suppression massive de Power Apps
  • Attaques de phishing effectuées via Power Apps
  • Power Automate flux d’activité des salariés qui partent
  • Microsoft Power Platform Connecteurs ajoutés dans l’environnement
  • Mettre à jour ou supprimer les stratégies de protection contre la perte de données Microsoft Power Platform

Pour plus d’informations, consultez la solution Microsoft Sentinel pour Microsoft Power Platform présentation.

Journalisation des activités Microsoft Purview

La journalisation des activités, Power Apps, Power Automate, des connecteurs et de prévention contre la perte de données et administrative Power Platform est suivie et affichée à partir du portail de conformité Microsoft Purview.

Pour en savoir plus, consultez :

Customer Lockbox

La majeure partie des opérations, de l’assistance et du dépannage effectués par le personnel Microsoft (y compris les sous-traitants) ne nécessite pas d’accéder aux données client. Avec Power Platform Customer Lockbox, Microsoft offrons aux clients une interface pour qu’ils puissent examiner et approuver (ou rejeter) les demandes d’accès aux données dans les rares occasions où l’accès aux données des clients est nécessaire. Elle est utilisée dans les cas où un ingénieur Microsoft a besoin d’accéder aux données client, que ce soit en réponse à un ticket de support initié par le client ou à un problème identifié par Microsoft. Pour plus d’informations, voir Accéder en toute sécurité aux données client via Customer Lockbox dans Power Platform et Dynamics 365.

Mises à jour de sécurité

Les équipes de service effectuent régulièrement les opérations suivantes pour garantir la sécurité du système :

  • Analyses du service pour identifier les vulnérabilités de sécurité possibles.
  • Évaluations du service pour garantir que les contrôles de sécurité clés fonctionnent efficacement.
  • Évaluations du service pour déterminer l’exposition aux vulnérabilités signalée par le Centre de réponse aux problèmes de sécurité Microsoft (MSRC), qui surveille régulièrement les sites externes de sensibilisation à la vulnérabilité.

Ces équipes identifient et suivent les problèmes identifiés, et prennent rapidement des mesure pour limiter les risques si nécessaire.

Comment obtenir des informations sur les mises à jour de sécurité ?

Comme les équipes de service s’efforcent d’appliquer des atténuations des risques sans besoin d’un temps d’arrêt de service, les administrateurs Customer Engagement ne voient généralement pas les notifications du Centre de messages pour les mises à jour de sécurité. Si une mise à jour de sécurité nécessite l’impact de service, elle est considéré comme une maintenance planifiée, et sera publiée avec la durée estimée d’impact, et le créneau lorsque le travail aura lieu.

Pour plus d’informations sur la sécurité, voir Centre de gestion de la confidentialité Microsoft.

Gérer votre fenêtre de maintenance

Microsoft assure la maintenance et la mise à jour régulière pour garantir la sécurité, des performances et la disponibilité, et fournir de nouvelles fonctions et fonctionnalités. Ce processus de mise à jour offre des améliorations de sécurité et de service mineures sur une base hebdomadaire, chaque mise à jour étant déployée région par région selon un calendrier de déploiement sécurisé, organisé en Stations. Pour plus d’informations sur votre fenêtre de maintenance par défaut pour les environnements, consultez Stratégies et communications pour les incidents de service. Voir aussi Gérez votre fenêtre de maintenance.

Assurez-vous que le portail d’inscription Azure inclut les informations de contact Administrateur afin que les opérations de sécurité puissent être notifiées directement via un processus interne. Pour plus d’informations, voir mettre à jour Paramètres notification.

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ération sécurité.

Voir aussi

Liste de contrôle de sécurité

Référez-vous à l’ensemble complet des recommandations.

Liste de contrôle de sécurité