Certification Microsoft 365 - Exemple de guide de preuve

Vue d’ensemble

Ce guide a été créé pour fournir aux éditeurs de logiciels indépendants des exemples du type de preuve et du niveau de détails requis pour chacun des contrôles de certification Microsoft 365. Les exemples partagés dans ce document ne représentent pas la seule preuve pouvant être utilisée pour démontrer que les contrôles sont respectés, mais agissent uniquement comme une ligne directrice pour le type de preuve requis.

Remarque : les interfaces, captures d’écran et documentation réelles utilisées pour répondre aux exigences varient en fonction de l’utilisation du produit, de la configuration du système et des processus internes. En outre, notez que lorsque la documentation de stratégie ou de procédure est requise, l’éditeur de logiciels indépendant doit envoyer les documents RÉELs et non les captures d’écran, comme peut-être illustré dans certains exemples.

Il existe deux sections de la certification qui nécessitent des soumissions :

1. Envoi de document initial : petit ensemble de documents de haut niveau requis pour définir l’étendue de votre évaluation.
2. Envoi de preuves : ensemble complet de preuves requis pour chaque contrôle dans l’étendue de votre évaluation de certification.

Conseil

Essayez l’outil d’automatisation de la conformité des applications pour Microsoft 365 (ACAT) afin d’accélérer la procédure d’obtention de la certification Microsoft 365 en automatisant la collecte des preuves et la validation du contrôle. En savoir plus sur le contrôle entièrement automatisé par ACAT.

Structure

Ce document correspond directement aux contrôles que vous allez présenter lors de votre certification dans l’Espace partenaires. Les conseils fournis dans ce document sont détaillés comme suit :

• Domaine de sécurité : les trois domaines de sécurité que tous les contrôles sont regroupés : Sécurité des applications, Sécurité opérationnelle et Sécurité et Confidentialité des données.
• Contrôle(s) : = Description de l’activité d’évaluation : ces contrôles et le nombre associé (No.) sont directement extraits de la liste de contrôle de certification Microsoft 365.
• Intention : = l’intention de la raison pour laquelle le contrôle de sécurité est inclus dans le programme et le risque spécifique qu’il est destiné à atténuer. L’espoir est que cette information fournira aux éditeurs de logiciels indépendants le raisonnement derrière le contrôle pour mieux comprendre les types de preuves qui doivent être collectés et ce que les éditeurs de logiciels indépendants doivent prêter attention et avoir conscience de la production de leurs preuves.
• Exemples de recommandations en matière de preuves : = Donné pour aider à guider les tâches de collecte de preuves dans la feuille de calcul Liste de vérification de certification Microsoft 365, cela permet aux éditeurs de logiciels indépendants de voir clairement des exemples du type de preuve qui peuvent être utilisés par l’analyste de certification qui les utilisera pour déterminer avec certitude qu’un contrôle est en place et maintenu, ce qui n’est pas exhaustif par nature.
• Exemple de preuve : = Cette section donne des exemples de captures d’écran et d’images de preuves potentielles capturées sur chacun des contrôles dans la feuille de calcul De la liste de contrôle de certification Microsoft 365, en particulier pour les domaines de sécurité opérationnelle et de sécurité des données et de confidentialité (onglets dans la feuille de calcul). Notez que les informations avec des flèches rouges et des zones dans les exemples sont pour vous aider à mieux comprendre les exigences nécessaires pour répondre à n’importe quel contrôle.

Domaine de sécurité : Sécurité des applications

Contrôle 1 - Contrôle 16 :

Les contrôles de domaine Sécurité des applications peuvent être satisfaits d’un rapport de test d’intrusion émis au cours des 12 derniers mois montrant que votre application ne présente aucune vulnérabilité en suspens. La seule soumission requise est un rapport propre par une entreprise indépendante réputée.

Domaine de sécurité : Sécurité opérationnelle / Développement sécurisé

Le domaine de sécurité « Sécurité opérationnelle / Développement sécurisé » est conçu pour garantir que les éditeurs de logiciels indépendants implémentent un ensemble solide de techniques d’atténuation de la sécurité contre une myriade de menaces auxquelles sont confrontés les groupes d’activités. Il est conçu pour protéger l’environnement d’exploitation et les processus de développement logiciel afin de créer des environnements sécurisés.

Protection contre les programmes malveillants - Antivirus

Contrôle n°1 : fournissez une documentation de stratégie qui régit les pratiques et procédures antivirus.

• Intention : L’objectif de ce contrôle est d’évaluer la compréhension par un éditeur de logiciels indépendant des problèmes auxquels il est confronté lorsqu’il considère la menace des virus informatiques. En établissant et en utilisant les meilleures pratiques du secteur dans l’élaboration d’une stratégie et de processus antivirus, un isv fournit une ressource adaptée à la capacité de ses organization à atténuer les risques auxquels sont confrontés les programmes malveillants, en listant les meilleures pratiques en matière de détection et d’élimination des virus, et fournit des preuves que la stratégie documentée fournit des conseils de sécurité suggérés pour le organization et ses employés. En documentant une stratégie et une procédure sur la façon dont l’éditeur de logiciels indépendants déploie des déconsenements anti-programmes malveillants, cela garantit le déploiement et la maintenance cohérents de cette technologie afin de réduire le risque de programmes malveillants pour l’environnement.
• Exemples de recommandations en matière de preuves : fournissez une copie de votre stratégie antivirus/anti-programme malveillant détaillant les processus et procédures implémentés au sein de votre infrastructure pour promouvoir les meilleures pratiques en matière d’antivirus/programmes malveillants. Exemple de preuve
• Exemple de preuve :

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle n° 2 : fournir des preuves démontrables que le logiciel antivirus s’exécute sur tous les composants système échantillonné.

• Intention : Il est important d’avoir des protections antivirus (AV) (ou anti-programmes malveillants) exécutées dans votre environnement pour vous protéger contre les risques de cybersécurité que vous pouvez ou non connaître, car les attaques potentiellement dangereuses augmentent, à la fois en sophistication et en nombre. Le déploiement de l’antivirus sur tous les composants système qui prennent en charge son utilisation permet d’atténuer certains des risques d’introduction de logiciels anti-programme malveillant dans l’environnement. Il suffit qu’un seul point de terminaison ne soit pas protégé pour fournir potentiellement un vecteur d’attaque pour qu’un groupe d’activités prenne pied dans l’environnement. L’AV doit donc être utilisé comme l’une des nombreuses couches de défense pour se protéger contre ce type de menace.
• Exemples de recommandations en matière de preuves : pour prouver qu’une instance active d’AV est en cours d’exécution dans l’environnement évalué. Fournissez une capture d’écran pour chaque appareil de l’exemple qui prend en charge l’utilisation de l’antivirus, qui montre le processus antivirus en cours d’exécution, le logiciel antivirus est actif ou, si vous avez un console de gestion centralisé pour l’antivirus, vous pouvez être en mesure de le démontrer à partir de ce console de gestion. Si vous utilisez le console de gestion, veillez à démontrer dans une capture d’écran que les appareils échantillonné sont connectés et fonctionnent.
• Exemple de preuve 1 : la capture d’écran ci-dessous a été extraite de Azure Security Center ; elle montre qu’une extension anti-programme malveillant a été déployée sur la machine virtuelle nommée « MSPGPRODAZUR01 ».

• Exemple de preuve 2

La capture d’écran ci-dessous a été prise à partir d’un Windows 10 appareils, montrant que « Protection en temps réel » est activée pour le nom d’hôte « CLARANET-SBU-WM ».

Contrôle n°3 : Fournir des preuves démontrables que les signatures antivirus sont à jour dans tous les environnements (dans un délai d’un jour).

• Intention : Des centaines de milliers de nouveaux programmes malveillants et d’applications potentiellement indésirables (PUA) sont identifiés chaque jour. Pour fournir une protection adéquate contre les programmes malveillants récemment publiés, les signatures AV doivent être mises à jour régulièrement pour prendre en compte les programmes malveillants récemment publiés.
• Ce contrôle existe pour s’assurer que l’éditeur de logiciels indépendant a pris en compte la sécurité de l’environnement et l’effet que l’antivirus obsolète peut avoir sur la sécurité.
• Exemple de recommandations en matière de preuves : fournissez des fichiers journaux antivirus de chaque appareil échantillonné, montrant que les mises à jour sont appliquées quotidiennement.
• Exemple de preuve : la capture d’écran suivante montre Microsoft Defender mise à jour au moins quotidienne en montrant « Event 2000, Windows Defender », qui est la mise à jour. Le nom d’hôte est affiché, montrant qu’il a été extrait du système dans l’étendue « CLARANET-SBU-WM ».

Note: La preuve fournie devrait inclure une exportation des journaux pour afficher les mises à jour quotidiennes sur une période plus longue. Certains produits antivirus génèrent des fichiers journaux de mise à jour afin que ces fichiers soient fournis ou exportés à partir de observateur d'événements.

Contrôle n°4 : fournir des preuves démontrables que l’antivirus est configuré pour effectuer une analyse à l’accès ou une analyse périodique sur tous les composants système échantillonnées.

Note: Si l’analyse à l’accès n’est pas activée, un minimum d’analyse quotidienne et de alerting_ DOIVENT _be activés.

• Intention : l’objectif de ce contrôle est de s’assurer que les programmes malveillants sont rapidement identifiés afin de minimiser l’effet que cela peut avoir sur l’environnement. Lorsque l’analyse de l’accès est effectuée et couplée à un blocage automatique des programmes malveillants, cela permet d’arrêter les infections de logiciels malveillants connus par le logiciel antivirus. Lorsque l’analyse à l’accès n’est pas souhaitable en raison des risques de faux positifs entraînant des pannes de service, des mécanismes d’analyse et d’alerte quotidiens appropriés (ou plus) doivent être implémentés pour garantir une réponse rapide aux infections de programmes malveillants afin de minimiser les dommages.
• Exemple de recommandations de preuve : fournissez une capture d’écran pour chaque appareil de l’exemple qui prend en charge l’antivirus, montrant que l’antivirus s’exécute sur l’appareil et est configuré pour l’analyse à l’accès (analyse en temps réel), OU fournissez une capture d’écran montrant que l’analyse périodique est activée pour l’analyse quotidienne, que les alertes sont configurées et que la date de la dernière analyse pour chaque appareil de l’exemple.
• Exemple de preuve : la capture d’écran suivante montre que la protection en temps réel est activée pour l’hôte, « CLARANET-SBU-WM ».

Contrôle n° 5 : fournir des preuves démontrables que l’antivirus est configuré pour bloquer automatiquement les programmes malveillants ou la mise en quarantaine et alerter sur tous les composants système échantillonné.

• Intention : La sophistication des programmes malveillants évolue tout le temps avec les différents degrés de dévastation qu’ils peuvent apporter. L’objectif de ce contrôle est soit d’empêcher les programmes malveillants de s’exécuter, et donc de les empêcher d’exécuter leur charge utile potentiellement dévastatrice, soit si le blocage automatique n’est pas une option, en limitant la durée pendant laquelle les logiciels malveillants peuvent causer des ravages en alertant et en répondant immédiatement à l’infection potentielle du programme malveillant.

• Exemple de recommandations en matière de preuves : fournissez une capture d’écran pour chaque appareil de l’exemple qui prend en charge l’antivirus, montrant que l’antivirus s’exécute sur l’ordinateur et est configuré pour bloquer automatiquement les programmes malveillants, les alertes ou la mise en quarantaine et l’alerte.

• Exemple de preuve 1 : la capture d’écran suivante montre que l’hôte « CLARANET-SBU-WM » est configuré avec la protection en temps réel activée pour Microsoft Defender Antivirus. Comme l’indique le paramètre, cela permet de localiser et d’arrêter les programmes malveillants de s’installer ou de s’exécuter sur l’appareil.

Contrôle n° 6 : fournir des preuves démontrables que les applications sont approuvées avant d’être déployées.

• Intention : avec le contrôle d’application, le organization approuvera chaque application/processus autorisé à s’exécuter sur le système d’exploitation. L’objectif de ce contrôle est de s’assurer qu’un processus d’approbation est en place pour autoriser les applications/processus qui peuvent s’exécuter.

• Exemple de recommandations en matière de preuves : vous pouvez fournir des preuves indiquant que le processus d’approbation est suivi. Il peut être fourni avec des documents signés, un suivi au sein des systèmes de contrôle des modifications ou à l’aide d’Azure DevOps ou de JIRA pour suivre ces demandes et autorisations.

• Exemple de preuve : la capture d’écran suivante montre une approbation par la direction que chaque application autorisée à exécuter dans l’environnement suit un processus d’approbation. Il s’agit d’un processus sur papier chez Contoso, mais d’autres mécanismes peuvent être utilisés.

Contrôle n° 7 : Fournir des preuves démontrables qu’une liste complète des applications approuvées avec justification métier existe et est conservée.

• Intention : Il est important que les organisations tiennent à jour une liste de toutes les applications approuvées, ainsi que des informations sur la raison pour laquelle la demande/le processus a été approuvé. Cela permet de garantir que la configuration reste à jour et peut être examinée par rapport à une base de référence pour garantir que les applications/processus non autorisés ne sont pas configurés.

• Exemple de recommandations en matière de preuves : fournissez la liste documentée des applications/processus approuvés, ainsi que la justification métier.

• Exemple de preuve : la capture d’écran suivante répertorie les applications approuvées avec justification métier.

Note: Cette capture d’écran montre un document. L’objectif est que les éditeurs de logiciels indépendants partagent le document de prise en charge réel et ne fournissent pas de capture d’écran.

Contrôle n° 8 : fournissez une documentation de support indiquant en détail que le logiciel de contrôle d’application est configuré pour répondre à des mécanismes de contrôle d’application spécifiques.

• Intention : la configuration de la technologie de contrôle d’application doit être documentée avec un processus de maintenance de la technologie, c’est-à-dire l’ajout et la suppression d’applications/processus. Dans le cadre de cette documentation, le type de mécanisme utilisé doit être détaillé pour chaque application/processus. Cela alimente le contrôle suivant pour garantir que la technologie est configurée comme documentée.

• Exemple d’instructions de preuve : fournissez une documentation de soutien détaillant la façon dont le contrôle d’application a été configuré et comment chaque application/processus a été configuré dans la technologie.

• Exemple de preuve : la capture d’écran suivante répertorie le mécanisme de contrôle utilisé pour implémenter le contrôle d’application. Vous pouvez voir ci-dessous que 1 application utilise des contrôles de certificat et que les autres utilisent le chemin d’accès au fichier.

Note: Cette capture d’écran montre un document. L’objectif est que les éditeurs de logiciels indépendants partagent le document de prise en charge réel et ne fournissent pas de capture d’écran.

Contrôle n° 9 : fournir une preuve démontrable que le contrôle d’application est configuré comme documenté à partir de tous les composants système échantillonnés.

• Intention : l’objectif est de vérifier que le contrôle d’application est configuré dans l’exemple conformément à la documentation.

• Exemple d’instructions de preuve : fournissez une capture d’écran pour chaque appareil de l’exemple afin de montrer qu’il a des contrôles d’application configurés et activés. Cela doit afficher les noms des machines, les groupes auxquels elles appartiennent et les stratégies de contrôle d’application appliquées à ces groupes et ordinateurs.

• Exemple de preuve : la capture d’écran suivante montre un objet stratégie de groupe avec des stratégies de restriction logicielle activées.

Cette capture d’écran suivante montre la configuration en ligne avec le contrôle ci-dessus.

Cette capture d’écran suivante montre l’environnement Microsoft 365 et les ordinateurs inclus dans l’étendue appliqués à cet objet de stratégie de groupe « Paramètres de l’ordinateur du domaine ».

Cette capture d’écran finale montre le serveur dans l’étendue « DBServer1 » se trouvant dans l’unité d’organisation dans la capture d’écran ci-dessus.

Gestion des correctifs – Classement des risques

L’identification et la correction rapides des vulnérabilités de sécurité permettent de réduire les risques d’un groupe d’activités qui compromettent l’environnement ou l’application. La gestion des correctifs est divisée en deux sections : classement des risques et mise à jour corrective. Ces trois contrôles couvrent l’identification des vulnérabilités de sécurité et leur classement en fonction du risque qu’elles posent.

Ce groupe de contrôle de sécurité s’étend aux environnements d’hébergement PaaS (Platform-as-a-Service), car les bibliothèques de logiciels tiers d’application/complément et la base de code doivent être corrigées en fonction du classement des risques.

Contrôle n° 10 : Fournissez une documentation de stratégie qui régit la façon dont les nouvelles vulnérabilités de sécurité sont identifiées et affectées à un score de risque.

• Intention : l’objectif de ce contrôle est de disposer d’une documentation de soutien pour garantir que les vulnérabilités de sécurité sont identifiées rapidement afin de réduire la fenêtre d’opportunité que les groupes d’activités ont pour exploiter ces vulnérabilités. Un mécanisme robuste doit être en place pour identifier les vulnérabilités couvrant tous les composants système utilisés par les organisations ; par exemple, les systèmes d’exploitation (Windows Server, Ubuntu, etc.), les applications (Tomcat, MS Exchange, SolarWinds, etc.), les dépendances de code (AngularJS, jQuery, etc.). Les organisations doivent non seulement garantir l’identification en temps voulu des vulnérabilités au sein du patrimoine, mais également classer les vulnérabilités en conséquence pour s’assurer que la correction est effectuée dans un délai approprié en fonction du risque que présente la vulnérabilité.

Note Même si vous exécutez dans un environnement de plateforme en tant que service, vous avez toujours la responsabilité d’identifier les vulnérabilités au sein de votre base de code, c’est-à-dire les bibliothèques tierces.

• Exemples de recommandations en matière de preuves : fournissez la documentation de support (et non des captures d’écran)

• Exemple de preuve : cette capture d’écran montre un extrait de code d’une stratégie de classement des risques.

Note: Cette capture d’écran montre un document de stratégie/processus. Les éditeurs de logiciels indépendants s’attendent à partager la documentation réelle sur la stratégie/procédure de prise en charge et à ne pas fournir de screenshot._

Contrôle n° 11 : fournir des preuves de la façon dont les nouvelles vulnérabilités de sécurité sont identifiées.

• Intention : l’objectif de ce contrôle est de s’assurer que le processus est suivi et qu’il est suffisamment robuste pour identifier les nouvelles vulnérabilités de sécurité dans l’environnement. Il ne s’agit peut-être pas seulement des systèmes d’exploitation ; il peut inclure des applications s’exécutant dans l’environnement et des dépendances de code.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies en affichant les abonnements aux listes de diffusion, en examinant manuellement les sources de sécurité pour détecter les vulnérabilités nouvellement publiées (il faudrait effectuer un suivi adéquat avec des horodatages des activités, c’est-à-dire avec JIRA ou Azure DevOps), des outils qui détectent des logiciels obsolètes (par exemple, il peut s’agir de Snyk lors de la recherche de bibliothèques de logiciels obsolètes, ou peut être Nessus à l’aide d’analyses authentifiées qui identifient les logiciels obsolètes.).

Note Si vous utilisez Nessus, cette opération doit être exécutée régulièrement pour identifier rapidement les vulnérabilités. Nous vous recommandons au moins une fois par semaine.

• Exemple de preuve : cette capture d’écran montre qu’un groupe de publipostage est utilisé pour être averti des vulnérabilités de sécurité.

Contrôle n° 12 : fournir des preuves montrant que toutes les vulnérabilités se voient attribuer un classement des risques une fois identifiées.

• Intention : la mise à jour corrective doit être basée sur le risque, plus la vulnérabilité est risquée, plus elle doit être corrigée rapidement. Le classement des risques des vulnérabilités identifiées fait partie intégrante de ce processus. L’objectif de ce contrôle est de s’assurer qu’il existe un processus de classement des risques documenté qui est suivi pour s’assurer que toutes les vulnérabilités identifiées sont correctement classées en fonction du risque. Les organisations utilisent généralement la classification CVSS (Common Vulnerability Scoring System) fournie par les fournisseurs ou les chercheurs en sécurité. Si organization s’appuient sur cvss, il est recommandé d’inclure un mécanisme de re-classement dans le processus pour permettre aux organization de modifier le classement en fonction d’une évaluation interne des risques. Parfois, la vulnérabilité peut ne pas être l’application en raison de la façon dont l’application a été déployée dans l’environnement. Par exemple, une vulnérabilité Java peut être libérée, ce qui a un impact sur une bibliothèque spécifique utilisée par le organization.

• Exemples de recommandations en matière de preuves : fournissez des preuves par le biais d’une capture d’écran ou d’autres moyens, par exemple DevOps/Jira, qui montre que les vulnérabilités passent par le processus de classement des risques et se voient attribuer un classement des risques approprié par le organization.

• Exemple de preuve : cette capture d’écran montre le classement des risques dans la colonne D et le reclassement dans les colonnes F et G, si le organization effectuer une évaluation des risques et déterminer que le risque peut être rétrogradé. Il faudrait fournir des preuves de re-classement des évaluations des risques comme preuve à l’appui

Gestion des correctifs – Mise à jour corrective

Les contrôles ci-dessous concernent l’élément de mise à jour corrective pour La gestion des correctifs. Pour maintenir un environnement d’exploitation sécurisé, les applications/modules complémentaires et les systèmes de prise en charge doivent être correctement corrigés. Un délai approprié entre l’identification (ou la mise en production publique) et la mise à jour corrective doit être géré pour réduire la fenêtre d’opportunité pour qu’une vulnérabilité soit exploitée par un « groupe d’activités ». La certification Microsoft 365 ne stipule pas de « fenêtre de mise à jour corrective », mais les analystes de certification rejettent les délais qui ne sont pas raisonnables.

Ce groupe de contrôle de sécurité s’étend aux environnements d’hébergement PaaS (Platform-as-a-Service), car les bibliothèques de logiciels tiers d’application/complément et la base de code doivent être corrigées en fonction du classement des risques.

Contrôle n° 13 : Fournir une documentation de stratégie pour la mise à jour corrective des composants système dans l’étendue, qui inclut une période de mise à jour corrective minimale appropriée pour les vulnérabilités à risque critique, élevé et moyen ; et la désaffectation de tous les systèmes d’exploitation et logiciels non pris en charge.

• Intention : la gestion des correctifs est requise par de nombreuses infrastructures de conformité de la sécurité, c’est-à-dire PCI-DSS, ISO 27001, NIST (SP) 800-53. L’importance d’une bonne gestion des correctifs ne peut pas être trop soulignée, car elle peut corriger les problèmes de sécurité et de fonctionnalité dans les logiciels, les microprogrammes et atténuer les vulnérabilités, ce qui contribue à réduire les opportunités d’exploitation. L’objectif de ce contrôle est de réduire la fenêtre d’opportunité d’un groupe d’activités pour exploiter les vulnérabilités qui peuvent exister dans l’environnement dans l’étendue.

• Exemples de recommandations en matière de preuves : fournissez une copie de toutes les stratégies et procédures détaillant le processus de gestion des correctifs. Cela doit inclure une section sur une fenêtre de mise à jour corrective minimale, et que les systèmes d’exploitation et logiciels non pris en charge ne doivent pas être utilisés dans l’environnement.

• Exemple de preuve : voici un exemple de document de stratégie.

Note: Cette capture d’écran montre un document de stratégie/processus, dont l’attente est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement un screenshot._

Contrôle n° 14 : fournir des preuves démontrables que tous les composants système échantillonnés sont corrigés.

Note: Incluez toutes les bibliothèques logicielles/tierces.

• Intention : la mise à jour corrective des vulnérabilités garantit que les différents modules qui font partie de l’infrastructure des technologies de l’information (matériel, logiciels et services) sont tenus à jour et exempts de vulnérabilités connues. La mise à jour corrective doit être effectuée dès que possible pour réduire le risque d’incident de sécurité entre la publication des détails de la vulnérabilité et la mise à jour corrective. Cela est encore plus critique lorsque l’exploitation de vulnérabilités connues pour être dans la nature.

• Exemple de recommandations en matière de preuves : fournissez une capture d’écran pour chaque appareil de l’exemple et les composants logiciels de prise en charge montrant que les correctifs sont installés conformément au processus de mise à jour corrective documenté.

• Exemple de preuve : la capture d’écran suivante montre que le composant système dans l’étendue « CLARANET-SBU-WM » effectue des mises à jour Windows conformément à la stratégie de mise à jour corrective.

Note: La mise à jour corrective de tous les composants système dans l’étendue doit être une preuve. Cela inclut des éléments tels que : Mises à jour du système d’exploitation, Mises à jour d’application/composant (i.e__., Apache Tomcat, OpenSSL, etc.), dépendances logicielles (par exemple, JQuery, AngularJS, etc.), etc.

Contrôle n° 15 : fournir des preuves démontrables que les systèmes d’exploitation et composants logiciels non pris en charge ne sont pas utilisés dans l’environnement.

• Intention : les logiciels qui ne sont pas gérés par les fournisseurs souffrent, au fil du temps, de vulnérabilités connues qui ne sont pas corrigées. Par conséquent, l’utilisation de systèmes d’exploitation et de composants logiciels non pris en charge ne doit pas être utilisée dans des environnements de production.

• Exemple de recommandations en matière de preuves : fournissez une capture d’écran pour chaque appareil de l’exemple montrant la version du système d’exploitation en cours d’exécution (y compris le nom du serveur dans la capture d’écran). En outre, fournissez la preuve que les composants logiciels s’exécutant dans l’environnement exécutent des versions prises en charge. Pour ce faire, vous pouvez fournir la sortie des rapports d’analyse des vulnérabilités internes (à condition que l’analyse authentifiée soit incluse) et/ou la sortie d’outils qui case activée des bibliothèques tierces, telles que Snyk, Trivy ou NPM Audit. En cas d’exécution dans PaaS uniquement, seule la mise à jour corrective de bibliothèque tierce doit être couverte par les groupes de contrôle de mise à jour corrective.

• Exemple de preuve : les preuves suivantes montrent que le composant système dans l’étendue THOR exécute un logiciel pris en charge par le fournisseur, car Nessus n’a signalé aucun problème.

Note: Le rapport complet doit être partagé avec les analystes de certification.

• Exemple de preuve 2

Cette capture d’écran montre que le composant système dans l’étendue « CLARANET-SBU-WM » s’exécute sur une version de Windows prise en charge.

• Exemple de preuve 3

La capture d’écran suivante montre la sortie Trivy , dont le rapport complet ne répertorie aucune application non prise en charge.

Note: Le rapport complet doit être partagé avec les analystes de certification.

Analyse des vulnérabilités

En introduisant des évaluations régulières des vulnérabilités, les organisations peuvent détecter les faiblesses et les insécurités au sein de leurs environnements, ce qui peut fournir un point d’entrée pour qu’un acteur malveillant puisse compromettre l’environnement. L’analyse des vulnérabilités peut aider à identifier les correctifs manquants ou les configurations incorrectes dans l’environnement. En effectuant régulièrement ces analyses, un organization peut fournir une correction appropriée pour réduire le risque d’une compromission en raison de problèmes couramment récupérés par ces outils d’analyse des vulnérabilités.

Contrôle n° 16 : fournissez les rapports trimestriels d’analyse des vulnérabilités de l’infrastructure et des applications web. L’analyse doit être effectuée sur l’ensemble de l’empreinte publique (adresses IP et URL) et sur les plages d’adresses IP internes.

Note: Cela DOIT inclure toute l’étendue de l’environnement.

• Intention : l’analyse des vulnérabilités recherche les faiblesses possibles dans le système informatique, les réseaux et les applications web d’une organisation afin d’identifier les trous susceptibles d’entraîner des violations de sécurité et l’exposition de données sensibles. L’analyse des vulnérabilités est souvent requise par les normes du secteur et les réglementations gouvernementales, par exemple la norme PCI DSS (Payment Card Industry Data Security Standard).

• Un rapport de la métrique de sécurité intitulé « 2020 Security Metrics Guide to PCI DSS Compliance » indique qu'« en moyenne, il a fallu 166 jours à partir du moment où une organization a été considérée comme ayant des vulnérabilités pour qu’un attaquant compromisse le système. Une fois compromis, les attaquants ont eu accès aux données sensibles pendant une moyenne de 127 jours. Par conséquent, ce contrôle vise à identifier les failles de sécurité potentielles dans l’environnement dans l’étendue.

• Exemples de recommandations en matière de preuves : fournissez le ou les rapports d’analyse complets pour les analyses de vulnérabilité de chaque trimestre qui ont été effectuées au cours des 12 derniers mois. Les rapports doivent indiquer clairement les cibles pour valider que l’empreinte publique complète est incluse et, le cas échéant, chaque sous-réseau interne. Fournissez TOUS les rapports d’analyse pour CHAQUE trimestre.

• Exemple de preuve : l’exemple de preuve serait de fournir les rapports d’analyse à partir de l’outil d’analyse utilisé. Les rapports d’analyse de chaque trimestre doivent être fournis pour examen. L’analyse doit inclure l’ensemble des composants système de l’environnement ; chaque sous-réseau interne et chaque ADRESSE IP/URL publique disponible pour l’environnement.

Contrôle n° 17 : fournissez des preuves démontrables que la correction des vulnérabilités identifiées pendant l’analyse des vulnérabilités est corrigée conformément à votre période de mise à jour corrective documentée.

• Intention : le fait de ne pas identifier, gérer et corriger rapidement les vulnérabilités et les erreurs de configuration peut augmenter le risque d’une organization d’une compromission entraînant des violations de données potentielles. L’identification et la correction correctes des problèmes sont considérées comme importantes pour la posture de sécurité et l’environnement globaux d’un organization, qui sont conformes aux meilleures pratiques de divers frameworks de sécurité pour, par exemple, la norme ISO 27001 et la NORME PCI DSS.

• Exemple de recommandations en matière de preuves : fournissez des artefacts appropriés (c’est-à-dire des captures d’écran) montrant qu’un exemple de vulnérabilités découvertes lors de l’analyse des vulnérabilités est corrigé conformément aux fenêtres de mise à jour corrective déjà fournies dans le contrôle 13 ci-dessus.

• Exemple de preuve : la capture d’écran suivante montre une analyse Nessus de l’environnement dans l’étendue (une seule machine dans cet exemple nommée « THOR ») montrant les vulnérabilités le 2 août 2021.

La capture d’écran suivante montre que les problèmes ont été résolus, 2 jours plus tard, dans la fenêtre de mise à jour corrective définie dans la stratégie de mise à jour corrective.

Note: Pour ce contrôle, les analystes de certification doivent voir les rapports d’analyse des vulnérabilités et la correction pour chaque trimestre au cours des douze derniers mois.

Pare-feu

Les pare-feu fournissent souvent une limite de sécurité entre les environnements approuvés (réseau interne), non approuvés (Internet) et semi-fiables (DMZ). Il s’agit généralement de la première ligne de défense au sein d’une stratégie de sécurité de défense en profondeur d’une organisation, conçue pour contrôler les flux de trafic pour les services d’entrée et de sortie et pour bloquer le trafic indésirable. Ces appareils doivent être étroitement contrôlés pour s’assurer qu’ils fonctionnent efficacement et qu’ils sont exempts d’une configuration incorrecte qui pourrait mettre l’environnement en danger.

Contrôle n° 18 : Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures de gestion des pare-feu.

• Intention : les pare-feu constituent une première ligne de défense importante dans une stratégie de sécurité en couches (défense en profondeur), protégeant les environnements contre les zones réseau moins fiables. Les pare-feu contrôlent généralement les flux de trafic en fonction des adresses IP et des protocoles/ports. Les pare-feu plus riches en fonctionnalités peuvent également fournir des défenses supplémentaires de la « couche application » en inspectant le trafic des applications pour se protéger contre les mauvaises utilisations, les vulnérabilités et les menaces en fonction de l’accès aux applications. Ces protections sont uniquement aussi bonnes que la configuration du pare-feu. Par conséquent, des stratégies de pare-feu fortes et des procédures de support doivent être en place pour garantir qu’elles sont configurées pour fournir une protection adéquate des ressources internes. Par exemple, un pare-feu avec une règle pour autoriser TOUT le trafic de N’IMPORTE QUELLE source vers N’IMPORTE QUELLE destination agit simplement comme un routeur.

• Exemple de recommandations en matière de preuves : fournissez la documentation complète de votre stratégie/procédure de pare-feu. Ce document doit couvrir tous les points ci-dessous et toutes les bonnes pratiques supplémentaires applicables à votre environnement.

• Exemple de preuve : voici un exemple du type de document de stratégie de pare-feu dont nous avons besoin (il s’agit d’une démonstration qui peut ne pas être complète).

Contrôle n° 19 : fournir une preuve démontrable que toutes les informations d’identification administratives par défaut sont modifiées avant l’installation dans les environnements de production.

• Intention : les organisations doivent tenir compte des informations d’identification d’administration par défaut fournies par le fournisseur qui sont configurées lors de la configuration de l’appareil ou du logiciel. Les informations d’identification par défaut sont souvent disponibles publiquement par les fournisseurs et peuvent fournir à un groupe d’activités externe la possibilité de compromettre un environnement. Par exemple, une simple recherche sur Internet des informations d’identification iDrac (contrôleur d’accès à distance Dell intégré) par défaut met en évidence root ::calvin comme nom d’utilisateur et mot de passe par défaut. Cela permet à une personne d’accéder à distance à la gestion des serveurs distants. L’objectif de ce contrôle est de s’assurer que les environnements ne sont pas vulnérables aux attaques via les informations d’identification du fournisseur par défaut qui n’ont pas été modifiées pendant le renforcement de l’appareil/de l’application.

• Exemples de recommandations en matière de preuves

• Cela peut être démontré dans une session de partage d’écran où l’analyste de certification peut essayer de s’authentifier auprès des appareils dans l’étendue à l’aide des informations d’identification par défaut.

• Exemple de preuve

La capture d’écran ci-dessous montre ce que l’analyste de certification verrait à partir d’un nom d’utilisateur/mot de passe non valide d’un pare-feu WatchGuard.

Contrôle 20 : Fournir des preuves démontrables que les pare-feu sont installés à la limite de l’environnement dans l’étendue et installés entre le réseau de périmètre (également appelé zone DMZ, zone démilitarisée et sous-réseau filtré) et les réseaux approuvés internes.

• Intention : les pare-feu permettent de contrôler le trafic entre différentes zones réseau de différents niveaux de sécurité. Étant donné que tous les environnements sont connectés à Internet, les pare-feu doivent être installés à la limite, c’est-à-dire entre Internet et l’environnement dans l’étendue. En outre, des pare-feu doivent être installés entre les réseaux DMZ (zone de militarisation) moins fiables et les réseaux internes approuvés. Les DMZ sont généralement utilisées pour traiter le trafic à partir d’Internet et sont donc une cible d’attaque. En implémentant une zone DMZ et en utilisant un pare-feu pour contrôler les flux de trafic, une compromission de la zone DMZ n’implique pas nécessairement une compromission des réseaux internes approuvés et des données d’entreprise/client. Une journalisation et des alertes adéquates doivent être en place pour aider les organisations à identifier rapidement un compromis afin de minimiser la possibilité pour le groupe d’activités de compromettre davantage les réseaux internes de confiance. L’objectif de ce contrôle est de s’assurer qu’il existe un contrôle adéquat entre les réseaux approuvés et les réseaux moins approuvés.

• Exemples de recommandations en matière de preuves : les preuves doivent être fournies au moyen de fichiers de configuration de pare-feu ou de captures d’écran montrant qu’une zone DMZ est en place. Cela doit correspondre aux diagrammes architecturaux fournis illustrant les différents réseaux prenant en charge l’environnement. Une capture d’écran des interfaces réseau sur le pare-feu, associée au diagramme réseau déjà fourni dans le cadre de la soumission initiale du document, doit fournir cette preuve.

• Exemple de preuve : Vous trouverez ci-dessous une capture d’écran d’un pare-feu WatchGuard montrant deux zones DMZ, l’une pour les services entrants (nomméeS DMZ), l’autre servant la jumpbox (Hôte Bastian).

Contrôle 21 : Fournir des preuves démontrables que tout accès public se termine dans la zone démilitarisée (DMZ).

• Intention : les ressources accessibles au public sont ouvertes à une myriade d’attaques. Comme indiqué ci-dessus, l’objectif d’une zone DMZ est de segmenter les réseaux moins approuvés à partir de réseaux internes approuvés qui peuvent contenir des données sensibles. Une zone DMZ est considérée comme moins fiable, car il existe un grand risque que des hôtes accessibles publiquement soient compromis par des groupes d’activités externes. L’accès public doit toujours se terminer dans ces réseaux moins fiables qui sont correctement segmentés par le pare-feu pour protéger les ressources et les données internes. L’objectif de ce contrôle est de s’assurer que tous les accès publics se terminent dans ces zones DMZ moins fiables, comme si les ressources des réseaux internes approuvés étaient publiques, une compromission de ces ressources fournit un groupe d’activités un pied dans le réseau où des données sensibles sont conservées.

• Exemples de recommandations en matière de preuves

• La preuve fournie à cet effet peut être des configurations de pare-feu qui affichent les règles de trafic entrant et où ces règles se terminent, soit en acheminant les adresses IP publiques vers les ressources, soit en fournissant la traduction d’adresses réseau (NAT) du trafic entrant.

• Exemple de preuve

Dans la capture d’écran ci-dessous, il y a trois règles entrantes, chacune montrant le NAT pour les sous-réseaux 10.0.3.x et 10.0.4.x, qui sont les sous-réseaux DMZ

Contrôle 22 : Fournir des preuves démontrables que tout le trafic autorisé via le pare-feu passe par un processus d’approbation.

• Intention : Étant donné que les pare-feu sont une barrière défensive entre le trafic non approuvé et les ressources internes, et entre les réseaux de différents niveaux de confiance, les pare-feu doivent être configurés en toute sécurité et garantir que seul le trafic nécessaire pour les opérations de l’entreprise est activé. En autorisant un flux de trafic inutile, ou un flux de trafic trop permissif, cela peut introduire des faiblesses au sein de la défense à la limite de ces différentes zones réseau. En établissant un processus d’approbation robuste pour toutes les modifications de pare-feu, le risque d’introduire une règle qui introduit un risque significatif pour l’environnement est réduit. Le rapport d’enquête sur les violations de données 2020 de Verizon souligne que les « erreurs », qui incluent des erreurs de configuration, sont le seul type d’action qui augmente constamment d’une année à l’autre.

• Exemples de recommandations en matière de preuves : les preuves peuvent prendre la forme d’une documentation montrant qu’une demande de modification de pare-feu est autorisée, ce qui peut être des minutes d’une réunion du CAB (Change Advisor Board) ou par un système de contrôle des modifications qui suit toutes les modifications.

• Exemple de preuve : la capture d’écran suivante montre une modification de règle de pare-feu demandée et autorisée à l’aide d’un processus papier. Cela peut être réalisé par le biais de quelque chose comme DevOps ou Jira, par exemple.

Contrôle 23 : fournir une preuve démontrable que la base de règles de pare-feu est configurée pour supprimer le trafic non défini explicitement.

• Intention : la plupart des pare-feu traitent les règles dans une approche descendante pour essayer de trouver une règle correspondante. Si une règle correspond, l’action de cette règle est appliquée et tout traitement ultérieur des règles s’arrête. Si aucune règle de correspondance n’est trouvée, le trafic est refusé par défaut. L’objectif de ce contrôle est que si le pare-feu ne supprime pas le trafic par défaut si aucune règle correspondante n’est trouvée, la base de règles doit inclure une règle « Refuser tout » à la fin de TOUTES les listes de pare-feu. Cela permet de s’assurer que le pare-feu ne passe pas par défaut à un état d’autorisation par défaut lors du traitement des règles, ce qui autorise le trafic qui n’a pas été défini explicitement.

• Exemples d’instructions de preuve : les preuves peuvent être fournies par le biais de la configuration du pare-feu, ou par des captures d’écran montrant toutes les règles de pare-feu affichant une règle « Refuser tout » à la fin, ou si le pare-feu supprime le trafic qui ne correspond pas à une règle par défaut, fournissez une capture d’écran de toutes les règles de pare-feu et un lien vers les guides administratifs du fournisseur mettant en évidence que par défaut, le pare-feu supprime tout le trafic non correspondant.

• Exemple de preuve : vous trouverez ci-dessous une capture d’écran de la base de règles de pare-feu WatchGuard qui montre qu’aucune règle n’est configurée pour autoriser tout le trafic. Il n’y a pas de règle de refus à la fin, car WatchGuard supprime le trafic qui ne correspond pas par défaut.

Lien du Centre d’aide WatchGuard suivant : https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policies_about_c.html inclut les informations suivantes :

Contrôle 24 : fournir des preuves démontrables que le pare-feu prend uniquement en charge le chiffrement fort sur toutes les interfaces d’administration non-console.

• Intention : Pour atténuer les attaques de l’intercepteur du trafic administratif, toutes les interfaces d’administration non-console doivent prendre en charge uniquement le chiffrement fort. L’intention main de ce contrôle est de protéger les informations d’identification d’administration à mesure que la connexion non-console est configurée. En outre, cela peut également aider à se protéger contre l’écoute clandestine dans la connexion, en essayant de relire les fonctions d’administration pour reconfigurer l’appareil ou dans le cadre de la reconnaissance.

• Exemples de recommandations en matière de preuves : fournissez la configuration du pare-feu, si la configuration fournit la configuration de chiffrement des interfaces d’administration non-console (tous les appareils n’incluront pas cette configuration en tant qu’options configurables). Si ce n’est pas dans la configuration, vous pouvez émettre des commandes sur l’appareil pour afficher ce qui est configuré pour ces connexions. Certains fournisseurs peuvent publier ces informations dans des articles, ce qui peut également être un moyen de prouver ces informations. Enfin, vous devrez peut-être exécuter des outils pour afficher le chiffrement pris en charge.

• Exemple de preuve : la capture d’écran ci-dessous montre la sortie de SSLScan sur l’interface web Administration du pare-feu WatchGuard sur le port TCP 8080. Cela montre TLS 1.2 ou version ultérieure avec un chiffrement de chiffrement minimal AES-128bit.

Remarque : Les pare-feu WatchGuard prennent également en charge les fonctions d’administration à l’aide de SSH (port TCP 4118) et WatchGuard System Manager (ports TCP 4105 & 4117). La preuve de ces interfaces d’administration non-console doit également être fournie.

Contrôle 25 : fournissez des preuves démontrables que vous effectuez des révisions de règles de pare-feu au moins tous les 6 mois.

• Intention : Au fil du temps, il existe un risque de fluage de configuration dans les composants système avec l’environnement dans l’étendue. Cela peut souvent introduire des insécurités ou des configurations incorrectes qui peuvent augmenter le risque de compromission de l’environnement. Le fluage de configuration peut être introduit pour de nombreuses raisons, telles que des modifications temporaires pour faciliter la résolution des problèmes, des modifications temporaires pour des modifications fonctionnelles ad hoc, pour introduire des correctifs rapides aux problèmes qui peuvent parfois être trop permissifs en raison des pressions liées à l’introduction d’un correctif rapide. Par exemple, vous pouvez introduire une règle de pare-feu temporaire « Autoriser tout » pour résoudre un problème urgent. L’objectif de ce contrôle est double : d’une part, identifier les erreurs de configuration susceptibles d’introduire des insécurités et, d’autre part, aider à identifier les règles de pare-feu qui ne sont plus nécessaires et qui peuvent donc être supprimées, c’est-à-dire si un service a été mis hors service mais que la règle de pare-feu a été laissée pour compte.

• Exemples de recommandations en matière de preuves : Les preuves doivent être en mesure de démontrer que les réunions d’examen ont eu lieu. Pour ce faire, vous pouvez partager les minutes de réunion de la révision du pare-feu et toute preuve de contrôle des modifications supplémentaire montrant les actions effectuées à partir de la révision. Assurez-vous que les dates sont présentes, car nous avons besoin de voir au moins deux de ces réunions (c’est-à-dire tous les six mois)

• Exemple de preuve : la capture d’écran suivante montre la preuve d’une révision du pare-feu en janvier 2021.

La capture d’écran suivante montre la preuve d’une révision du pare-feu en juillet 2021.

Pare-feu – WAFs

Il est facultatif de déployer un Web Application Firewall (WAF) dans la solution. Si un WAF est utilisé, il est comptabilisé comme des crédits supplémentaires pour la matrice de scoring dans le domaine de sécurité « Operational Security ». Les fichiers WAF peuvent inspecter le trafic web pour filtrer et surveiller le trafic web entre Internet et les applications web publiées afin d’identifier les attaques spécifiques aux applications web. Les applications web peuvent subir de nombreuses attaques spécifiques aux applications web, telles que l’injection SQL (SQLi), l’écriture de scripts intersites (XSS), la falsification de requête intersites (CSRF/XSRF), etc. et les fichiers WAF sont conçus pour se protéger contre ces types de charges utiles malveillantes afin de protéger les applications web contre les attaques et les compromissions potentielles.

Contrôle 26 : fournir une preuve démontrable que le Web Application Firewall (WAF) est configuré pour surveiller activement, alerter et bloquer le trafic malveillant.

• Intention : ce contrôle est en place pour confirmer que le WAF est en place pour toutes les connexions web entrantes et qu’il est configuré pour bloquer ou alerter le trafic malveillant. Pour fournir une couche supplémentaire de défense pour le trafic web, les wafs doivent être configurés pour toutes les connexions web entrantes. Sinon, les groupes d’activités externes pourraient contourner les wafs conçus pour fournir cette couche supplémentaire de protection. Si le WAF n’est pas configuré pour bloquer activement le trafic malveillant, le WAF doit être en mesure de fournir une alerte immédiate au personnel qui peut réagir rapidement au trafic malveillant potentiel pour aider à maintenir la sécurité de l’environnement et arrêter les attaques.

• Exemples de recommandations en matière de preuves : fournissez une sortie de configuration à partir du WAF qui met en évidence les connexions web entrantes traitées et que la configuration bloque activement le trafic malveillant ou surveille et génère des alertes. Vous pouvez également partager des captures d’écran des paramètres spécifiques pour montrer qu’une organization répond à ce contrôle.

• Exemple de preuve : les captures d’écran suivantes montrent que la stratégie WAF de Contoso Production Azure Application Gateway est activée et qu’elle est configurée pour le mode « Prévention », qui supprime activement le trafic malveillant.

La capture d’écran ci-dessous montre la configuration d’adresse IP frontale

Note: Les preuves doivent démontrer toutes les adresses IP publiques utilisées par l’environnement pour garantir que tous les points d’entrée sont couverts, ce qui explique pourquoi cette capture d’écran est également incluse.

La capture d’écran ci-dessous montre les connexions web entrantes utilisant ce WAF.

La capture d’écran suivante montre le Contoso_AppGW_CoreRules montrant qu’il s’agit du service api.contoso.com.

Contrôle 27 : Fournir des preuves démontrables que le WAF prend en charge le déchargement SSL.

• Intention : la possibilité pour le WAF d’être configuré pour prendre en charge le déchargement SSL est importante, sinon le WAF ne pourra pas inspecter le trafic HTTPS. Étant donné que ces environnements doivent prendre en charge le trafic HTTPS, il s’agit d’une fonction essentielle pour le WAF afin de garantir que les charges utiles malveillantes au sein du trafic HTTPS peuvent être identifiées et arrêtées.

• Exemple d’instructions de preuve : fournissez des preuves de configuration via une exportation de configuration ou des captures d’écran montrant que le déchargement SSL est pris en charge et configuré.

• Exemple de preuve : Dans Azure Application Gateway configuration d’un déchargement SSL activé par l’écouteur SSL, consultez la page Vue d’ensemble de la terminaison TLS et du protocole TLS de bout en bout avec Application Gateway page Microsoft Docs. La capture d’écran suivante montre cette configuration pour le Azure Application Gateway de production Contoso.

Contrôle 28 : « Fournir des preuves démontrables que le WAF protège contre une partie ou la totalité des classes de vulnérabilités suivantes conformément à l’ensemble de règles de base OWASP (3.0 ou 3.1) :

• problèmes de protocole et d’encodage,

• injection d’en-tête, trafic de demandes et fractionnement des réponses,

• attaques de traversée de fichiers et de chemins d’accès,

• attaques par inclusion de fichiers distants (RFI),

• attaques d’exécution de code à distance,

• Attaques par injection DE PHP,

• attaques de script intersites,

• Attaques par injection de code SQL,

• attaques de fixation de session.

• Intention : Les fichiers WAF doivent être configurés pour identifier les charges utiles d’attaque pour les classes de vulnérabilités courantes. Ce contrôle vise à garantir que la détection adéquate des classes de vulnérabilité est couverte en tirant parti de l’ensemble de règles de base OWASP.

• Exemples de recommandations en matière de preuves : fournissez des preuves de configuration via une exportation de configuration ou des captures d’écran montrant que la plupart des classes de vulnérabilité identifiées ci-dessus sont couvertes par l’analyse.

• Exemple de preuve : la capture d’écran ci-dessous montre que la stratégie WAF de Contoso Production Azure Application Gateway est configurée pour analyser l’ensemble de règles OWASP Core Rule Set version 3.2.

Modifier le contrôle

Un processus de contrôle des modifications établi et compris est essentiel pour garantir que toutes les modifications passent par un processus structuré et reproductible. En veillant à ce que toutes les modifications passent par un processus structuré, les organisations peuvent s’assurer que les modifications sont gérées efficacement, examinées par les pairs et testées de manière adéquate avant d’être signées. Cela permet non seulement de réduire le risque de pannes du système, mais également de réduire le risque d’incidents de sécurité potentiels grâce à l’introduction de modifications incorrectes.

Contrôle 29 : fournissez une documentation de stratégie qui régit les processus de contrôle des modifications.

• Intention : Pour maintenir un environnement sécurisé et une application sécurisée, un processus de contrôle des modifications robuste doit être établi pour garantir que toutes les modifications d’infrastructure et de code sont effectuées avec une supervision forte et des processus définis. Cela garantit que les modifications sont documentées, que les implications en matière de sécurité sont prises en compte, que la réflexion a été prise en compte sur l’impact sur la sécurité de la modification, etc. L’objectif est de s’assurer que le processus de contrôle des modifications est documenté pour garantir qu’une approche sécurisée et cohérente est adoptée pour toutes les modifications au sein de l’environnement et des pratiques de développement d’applications.

• Exemples de recommandations en matière de preuves : les stratégies/procédures de contrôle des modifications documentées doivent être partagées avec les analystes de certification.

• Exemple de preuve : ci-dessous montre le début d’un exemple de stratégie de gestion des modifications. Veuillez fournir vos politiques et procédures complètes dans le cadre de l’évaluation.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 30 : fournir des preuves démontrables que les environnements de développement et de test appliquent la séparation des tâches de l’environnement de production.

• Intention : la plupart des environnements de développement/test de organization ne sont pas configurés avec la même vigueur que les environnements de production et sont donc moins sécurisés. En outre, les tests ne doivent pas être effectués dans l’environnement de production, car cela peut introduire des problèmes de sécurité ou peut nuire à la prestation des services pour les clients. En conservant des environnements distincts qui appliquent une séparation des tâches, les organisations peuvent s’assurer que les modifications sont appliquées aux environnements appropriés, ce qui réduit le risque d’erreurs en implémentant les modifications apportées aux environnements de production lorsqu’elles étaient destinées à l’environnement de développement/test.

• Exemples de recommandations en matière de preuves : des captures d’écran montrant différents environnements utilisés pour les environnements de développement/test et les environnements de production peuvent être fournis. En règle générale, vous avez des personnes/équipes différentes ayant accès à chaque environnement, ou, lorsque cela n’est pas possible, les environnements utilisent différents services d’autorisation pour s’assurer que les utilisateurs ne peuvent pas se connecter par erreur dans le mauvais environnement pour appliquer les modifications.

• Exemple de preuve : la capture d’écran suivante montre un abonnement Azure pour l’environnement TEST de Contoso.

Cette capture d’écran suivante montre un abonnement Azure distinct pour l’environnement « PRODUCTION » de Contoso.

Contrôle 31 : fournir des preuves démontrables que les données de production sensibles ne sont pas utilisées dans les environnements de développement ou de test.

• Intention : Comme indiqué ci-dessus, les organisations n’implémentent pas les mesures de sécurité d’un environnement de développement/test avec la même vigueur que l’environnement de production. Par conséquent, en utilisant des données de production sensibles dans ces environnements de développement/test, vous augmentez le risque de compromission et vous devez éviter d’utiliser des données actives/sensibles dans ces environnements de développement/test.

Note: Vous pouvez utiliser des données actives dans des environnements de développement/test, à condition que le développement/test soit inclus dans l’étendue de l’évaluation afin que la sécurité puisse être évaluée par rapport aux contrôles de certification Microsoft 365.

• Exemples d’instructions de preuve : les preuves peuvent être fournies en partageant des captures d’écran de la sortie de la même requête SQL sur une base de données de production (rédaction de toutes les informations sensibles) et la base de données de développement/test. La sortie des mêmes commandes doit produire des jeux de données différents. Lorsque les fichiers sont stockés, l’affichage du contenu des dossiers dans les deux environnements doit également présenter différents jeux de données.

• Exemple de preuve : la capture d’écran suivante montre les 3 premiers enregistrements (pour l’envoi des preuves, indiquez les 20 premiers) de la base de données de production.

La capture d’écran suivante montre la même requête à partir de la base de données de développement, montrant différents enregistrements.

Cela montre que les jeux de données sont différents.

Contrôle 32 : Fournissez des preuves démontrables que les demandes de modification documentées contiennent l’impact de la modification, les détails des procédures de back-out et des tests à effectuer.

• Intention : l’objectif de ce contrôle est de s’assurer que la réflexion a été prise en compte dans la modification demandée. L’impact de la modification sur la sécurité du système/de l’environnement doit être pris en compte et clairement documenté, toutes les procédures de back-out doivent être documentées pour faciliter la récupération en cas de problème, et enfin les détails des tests nécessaires pour valider la réussite de la modification doivent également être pensés et documentés.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies en exportant un échantillon de demandes de modification, en fournissant des demandes de modification sur papier ou en fournissant des captures d’écran des demandes de modification montrant ces trois détails contenus dans la demande de modification.

• Exemple de preuve : l’image ci-dessous montre une nouvelle vulnérabilité XSS (Cross Site Scripting Vulnerability) affectée et documente la demande de modification.

Les tickets ci-dessous indiquent les informations qui ont été définies ou ajoutées au ticket lors de son trajet en cours de résolution.

Les deux tickets ci-dessous montrent l’impact de la modification apportée au système et les procédures de recul qui peuvent être nécessaires en cas de problème. Vous pouvez voir l’impact des modifications et des procédures de sauvegarde ont fait l’objet d’un processus d’approbation et ont été approuvées pour les tests.

Sur la gauche de l’écran, vous pouvez voir que le test des modifications a été approuvé ; à droite, vous voyez que les modifications ont maintenant été approuvées et testées.

Tout au long du processus, notez que la personne qui effectue le travail, la personne qui en fait rapport et la personne qui approuve le travail à accomplir sont des personnes différentes.

Le ticket ci-dessus montre que les modifications ont maintenant été approuvées pour l’implémentation dans l’environnement de production. La zone de droite indique que le test a fonctionné et a réussi et que les modifications ont maintenant été implémentées dans Prod Environment.

Contrôle 33 : Fournir des preuves démontrables que les demandes de modification subissent un processus d’autorisation et de déconnexion.

• Intention : le processus doit être implémenté, ce qui interdit l’exécution de modifications sans autorisation et déconnexion appropriées. La modification doit être autorisée avant d’être implémentée et la modification doit être signée une fois terminée. Cela garantit que les demandes de modification ont été correctement examinées et qu’une personne autorisée a approuvé la modification.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies en exportant un échantillon de demandes de modification, en fournissant des demandes de modification papier ou en fournissant des captures d’écran des demandes de modification montrant que la modification a été autorisée, avant l’implémentation, et que la modification a été signée une fois terminée.

• Exemple de preuve : la capture d’écran ci-dessous montre un exemple de ticket Jira montrant que la modification doit être autorisée avant d’être implémentée et approuvée par une personne autre que le développeur/demandeur. Vous pouvez voir que les modifications sont approuvées ici par une personne autorisée. Sur la droite a été signé par dp une fois terminé.

Dans le ticket ci-dessous, vous pouvez voir que la modification a été signée une fois terminée et indique le travail terminé et fermé.

Développement/déploiement de logiciels sécurisés

Les organisations impliquées dans les activités de développement de logiciels sont souvent confrontées à des priorités concurrentes entre la sécurité et les pressions TTM (Time to Market), mais l’implémentation d’activités liées à la sécurité tout au long du cycle de vie du développement logiciel (SDLC) peut non seulement économiser de l’argent, mais également gagner du temps. Lorsque la sécurité est laissée après coup, les problèmes sont généralement identifiés uniquement pendant la phase de test du (DSLC), ce qui peut souvent prendre plus de temps et de coût à résoudre. L’objectif de cette section de sécurité est de s’assurer que les pratiques de développement de logiciels sécurisés sont suivies afin de réduire le risque d’introduction de défauts de codage dans le logiciel qui est développé. En outre, cette section cherche à inclure certains contrôles pour faciliter le déploiement sécurisé des logiciels.

Contrôle 34 : Fournissez des stratégies et des procédures qui prennent en charge le développement et le déploiement de logiciels sécurisés, y compris des conseils de bonnes pratiques en matière de codage sécurisé pour les classes de vulnérabilité courantes telles que OWASP Top 10 ou SANS Top 25 CWE.

• Intention : les organisations doivent faire tout ce qui est en leur pouvoir pour s’assurer que les logiciels sont développés en toute sécurité et exempts de vulnérabilités. Pour ce faire, il convient d’établir un cycle de vie de développement logiciel sécurisé (SDLC) et des meilleures pratiques de codage sécurisés pour promouvoir des techniques de codage sécurisées et un développement sécurisé tout au long du processus de développement logiciel. L’objectif est de réduire le nombre et la gravité des vulnérabilités dans le logiciel.

• Exemple d’instructions de preuve : fournissez la documentation sdlC et/ou de support documentée qui montre qu’un cycle de vie de développement sécurisé est en cours d’utilisation et que des conseils sont fournis à tous les développeurs pour promouvoir les meilleures pratiques de codage sécurisé. Jetez un coup d’œil à OWASP dans SDLC et au modèle SAMM ( Software Assurance Maturity Model) OWASP .

• Exemple de preuve : Ce qui suit est un extrait de la procédure de développement logiciel sécurisé de Contoso, qui illustre les pratiques de développement et de codage sécurisés.

Note: Ces captures d’écran montrent le document de développement de logiciels sécurisé. L’attente est que les éditeurs de logiciels indépendants partagent la documentation de prise en charge réelle et ne fournissent pas simplement une capture d’écran.

Contrôle 35 : fournir des preuves démontrables que les modifications du code sont soumises à un processus de révision et d’autorisation par un deuxième réviseur.

• Intention : l’objectif de ce contrôle est d’effectuer une révision du code par un autre développeur pour aider à identifier les erreurs de codage susceptibles d’introduire une vulnérabilité dans le logiciel. L’autorisation doit être établie pour s’assurer que les révisions de code sont effectuées, que les tests sont effectués, etc. avant le déploiement. L’étape d’autorisation peut vérifier que les processus appropriés ont été suivis, ce qui sous-tend le SDLC défini ci-dessus.

• Exemples de recommandations en matière de preuves : fournissez la preuve que le code fait l’objet d’une révision par les pairs et doit être autorisé avant de pouvoir être appliqué à l’environnement de production. Cette preuve peut se faire par le biais d’une exportation de tickets de modification, démontrant que des révisions de code ont été effectuées et que les modifications ont été autorisées, ou par le biais d’un logiciel de révision de code tel que Crucible (https://www.atlassian.com/software/crucible).

• Exemple de preuve

Vous trouverez ci-dessous un ticket qui montre que les modifications du code sont soumises à un processus de révision et d’autorisation par une personne autre que le développeur d’origine. Il montre qu’une révision du code a été demandée par le destinataire et sera affectée à une autre personne pour la révision du code.

L’image ci-dessous montre que la révision de code a été attribuée à une personne autre que le développeur d’origine, comme indiqué dans la section mise en surbrillance sur le côté droit de l’image ci-dessous. Sur le côté gauche, vous pouvez voir que le code a été révisé et a reçu une « RÉVISION DU CODE RÉUSSIE » status par le réviseur de code.

Le ticket doit maintenant obtenir l’approbation d’un responsable avant que les modifications puissent être apportées aux systèmes de production en direct.

Le L’image ci-dessus montre que le code révisé a reçu l’autorisation d’être implémenté sur les systèmes de production en direct.

Une fois que les modifications de code ont été effectuées, le travail final est déconnecté, comme illustré dans l’image ci-dessus.

Notez que tout au long du processus, trois personnes sont impliquées : le développeur d’origine du code, le réviseur de code et un responsable pour donner l’approbation et se déconnecter. Afin de répondre aux critères de ce contrôle, on s’attend à ce que vos billets suivent ce processus. D’un minimum de trois personnes impliquées dans le processus de contrôle des modifications pour vos révisions de code.

Contrôle 36 : Fournir des preuves démontrables que les développeurs suivent une formation de développement de logiciels sécurisé chaque année.

• Intention : les meilleures pratiques et techniques de codage existent pour tous les langages de programmation afin de garantir que le code est développé en toute sécurité. Il existe des cours de formation externes conçus pour enseigner aux développeurs les différents types de classes de vulnérabilités logicielles et les techniques de codage qui peuvent être utilisées pour arrêter l’introduction de ces vulnérabilités dans le logiciel. L’objectif de ce contrôle est d’enseigner ces techniques à tous les développeurs et de s’assurer que ces techniques ne sont pas oubliées, ou que des techniques plus récentes sont apprises en effectuant cela sur une base annuelle.

• Exemples de recommandations en matière de preuves : fournissez des preuves au moyen de certificats si elles sont effectuées par une société de formation externe, ou en fournissant des captures d’écran des journaux de formation ou d’autres artefacts qui montrent que les développeurs ont participé à la formation. Si cette formation est effectuée via des ressources internes, fournissez également des preuves du matériel de formation.

• Exemple de preuve : vous trouverez ci-dessous l’e-mail demandant au personnel de l’équipe DevOps de s’inscrire à la formation annuelle des dix meilleures formations OWASP

L’exemple ci-dessous montre que la formation a été demandée avec justification et approbation de l’entreprise. Cette opération est suivie de captures d’écran tirées de la formation et d’un enregistrement d’achèvement montrant que la personne a terminé la formation annuelle.

Contrôle 37 : Fournir des preuves démontrables que les dépôts de code sont sécurisés avec l’authentification multifacteur (MFA).

• Intention : si un groupe d’activités peut accéder à la base de code d’un logiciel et le modifier, il peut introduire des vulnérabilités, des portes dérobées ou du code malveillant dans la base de code et donc dans l’application. Il y a déjà eu plusieurs cas de cela, avec probablement le plus médiatisé étant l’attaque NotPetya Ransomware qui serait infecté par une mise à jour compromise du logiciel fiscal ukrainien appelé M.E.Doc (voir Qu’est-ce que tPetya).

• Exemples de recommandations en matière de preuves : fournissez des preuves par le biais de captures d’écran du référentiel de code indiquant que L’authentification MFA est activée pour TOUS les utilisateurs.

• Exemple de preuve : la capture d’écran suivante montre que l’authentification multifacteur est activée sur les 8 utilisateurs GitLab.

Contrôle 38 : fournir des preuves démontrables que des contrôles d’accès sont en place pour sécuriser les dépôts de code.

• Intention : à partir du contrôle précédent, les contrôles d’accès doivent être implémentés pour limiter l’accès uniquement aux utilisateurs individuels qui travaillent sur des projets particuliers. En limitant l’accès, vous limitez le risque que des modifications non autorisées soient effectuées et introduisez ainsi des modifications de code non sécurisées. Une approche des privilèges minimum doit être adoptée pour protéger le dépôt de code.

• Exemple de recommandations en matière de preuves : fournissez des preuves à l’appui de captures d’écran du référentiel de code indiquant que l’accès est limité aux personnes nécessaires, y compris les différents privilèges.

• Exemple de preuve : la capture d’écran suivante montre les membres du projet « Clients » dans GitLab, qui est le « Portail client » de Contoso. Comme vous pouvez le voir dans la capture d’écran, les utilisateurs ont des « rôles » différents pour limiter l’accès au projet.

Gestion des comptes

Les pratiques de gestion des comptes sécurisées sont importantes, car les comptes d’utilisateur constituent la base de l’autorisation de l’accès aux systèmes d’information, aux environnements système et aux données. Les comptes d’utilisateur doivent être correctement sécurisés, car une compromission des informations d’identification de l’utilisateur peut non seulement fournir un accès à l’environnement et l’accès aux données sensibles, mais peut également fournir un contrôle administratif sur l’ensemble de l’environnement ou des systèmes clés si les informations d’identification de l’utilisateur disposent de privilèges administratifs.

Contrôle 39 : Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures de gestion des comptes.

• Intention : les comptes d’utilisateur continuent d’être ciblés par des groupes d’activités et sont souvent la source d’une compromission des données. En configurant des comptes trop permissifs, les organisations augmentent non seulement le pool de comptes « privilégiés » qui peuvent être utilisés par un groupe d’activités pour effectuer une violation de données, mais peuvent également augmenter le risque d’exploitation réussie d’une vulnérabilité qui nécessiterait des privilèges spécifiques pour réussir.

• BeyondTrust produit chaque année un « Rapport sur les vulnérabilités Microsoft » qui analyse les vulnérabilités de sécurité Microsoft pour l’année précédente et détaille les pourcentages de ces vulnérabilités qui reposent sur le compte d’utilisateur disposant de droits d’administrateur. Dans un billet de blog récent intitulé « New Microsoft Vulnerabilities Report reveals a 48 % YoY Increase in Vulnerabilities & How They Could Be Mitigated with Least Privilege », 90 % des vulnérabilités critiques dans Internet Explorer, 85 % des vulnérabilités critiques dans Microsoft Edge et 100 % des vulnérabilités critiques dans Microsoft Outlook auraient été atténuées en supprimant les droits d’administrateur. Pour prendre en charge la gestion sécurisée des comptes, les organisations doivent s’assurer que les stratégies et procédures de prise en charge qui favorisent les meilleures pratiques de sécurité sont en place et suivies pour atténuer ces menaces.

• Exemple de recommandations en matière de preuves : fournissez les stratégies et les documents de procédure documentés qui couvrent vos pratiques de gestion de compte. Au minimum, les rubriques couvertes doivent s’aligner sur les contrôles de la certification Microsoft 365.

• Exemple de preuve : la capture d’écran suivante montre un exemple de stratégie de gestion de compte pour Contoso.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 40 : fournir une preuve démontrable que les informations d’identification par défaut sont désactivées, supprimées ou modifiées dans les composants système échantillonnées.

• Intention : Bien que cela devienne moins populaire, il existe encore des cas où les groupes d’activités peuvent tirer parti des informations d’identification utilisateur par défaut et bien documentées pour compromettre les composants du système de production. L’exemple le plus courant est le contrôleur d’accès à distance Dell iDRAC (Integrated Dell Remote Access Controller). Ce système peut être utilisé pour gérer à distance un serveur Dell, qui peut être utilisé par un groupe d’activités pour prendre le contrôle du système d’exploitation du serveur. Les informations d’identification par défaut de root ::calvin sont documentées et peuvent souvent être utilisées par les groupes d’activités pour accéder aux systèmes utilisés par les organisations. L’objectif de ce contrôle est de s’assurer que ces informations d’identification par défaut sont désactivées ou supprimées

• Exemples de recommandations en matière de preuves : il existe différentes façons de recueillir des preuves pour soutenir ce contrôle. Les captures d’écran des utilisateurs configurés sur tous les composants système peuvent aider, c’est-à-dire que les captures d’écran des fichiers /etc/shadow et /etc/passwd Linux vous aideront à montrer si les comptes ont été désactivés. Notez que le fichier /etc/shadow est nécessaire pour montrer que les comptes sont réellement désactivés en observant que le hachage de mot de passe commence par un caractère non valide tel que « ! » indiquant que le mot de passe est inutilisable. Le conseil serait de désactiver seulement quelques caractères du mot de passe a et de ressaisiter le reste. D’autres options sont les sessions de partage d’écran dans lesquelles l’évaluateur a pu essayer manuellement les informations d’identification par défaut. Par exemple, dans la discussion ci-dessus sur Dell iDRAC, l’évaluateur doit essayer de s’authentifier auprès de toutes les interfaces iDRAC Dell à l’aide des informations d’identification par défaut.

• Exemple de preuve : la capture d’écran suivante montre les comptes d’utilisateur configurés pour le composant système dans l’étendue « CLARANET-SBU-WM ». affiche plusieurs comptes par défaut ; Administrator, DefaultAccount et Guest, toutefois, les captures d’écran suivantes montrent que ces comptes sont désactivés.

Cette capture d’écran suivante montre que le compte Administrateur est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Cette capture d’écran suivante montre que le compte invité est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Cette capture d’écran suivante montre que defaultAccount est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Contrôle 41 : fournir des preuves démontrables que la création, la modification et la suppression de comptes passent par un processus d’approbation établi.

• Intention : L’objectif est de disposer d’un processus établi pour s’assurer que toutes les activités de gestion de compte sont approuvées, ce qui garantit que les privilèges de compte respectent les principes de privilège minimum et que les activités de gestion des comptes peuvent être correctement examinées et suivies.

• Exemple de recommandations en matière de preuves : les preuves se présentent généralement sous la forme de tickets de demande de modification, de demandes ITSM (gestion des services informatiques) ou de documents indiquant que les demandes de création, de modification ou de suppression de comptes ont fait l’objet d’un processus d’approbation.

• Exemple de preuve : les images ci-dessous montrent la création d’un compte pour un nouveau démarrage pour l’équipe DevOps qui doit disposer d’un paramètre de contrôle d’accès en fonction du rôle basé sur les autorisations de l’environnement de production sans accès à l’environnement de développement et un accès non privilégié standard à tout le reste.

La création du compte a suivi le processus d’approbation et le processus de déconnexion une fois le compte créé et le ticket fermé.

Contrôle 42 : fournir des preuves démontrables qu’un processus est en place pour désactiver ou supprimer des comptes non utilisés dans les 3 mois.

• Intention : les comptes inactifs peuvent parfois être compromis, soit parce qu’ils sont la cible d’attaques par force brute qui peuvent ne pas être marquées comme l’utilisateur ne tente pas de se connecter aux comptes, ou par le biais d’une violation de la base de données de mot de passe où le mot de passe d’un utilisateur a été réutilisé et est disponible dans un vidage de nom d’utilisateur/mot de passe sur Internet. Les comptes inutilisés doivent être désactivés/supprimés pour réduire la surface d’attaque d’un groupe d’activités pour effectuer des activités de compromission de compte. Ces comptes peuvent être dus à un processus de départ qui n’est pas effectué correctement, à un membre du personnel en cas de maladie de longue durée ou à un membre du personnel en congé de maternité/paternité. En implémentant un processus trimestriel pour identifier ces comptes, les organisations peuvent réduire la surface d’attaque.

• Exemples de recommandations en matière de preuves : les preuves doivent être doubles. Tout d’abord, une capture d’écran ou une exportation de fichier montrant la « dernière connexion » de tous les comptes d’utilisateur dans l’environnement dans l’étendue. Il peut s’agir de comptes locaux ou de comptes au sein d’un service d’annuaire centralisé, comme Microsoft Entra ID. Cela montre qu’aucun compte de plus de 3 mois n’est activé. Deuxièmement, la preuve du processus de révision trimestrielle qui peut être une preuve documentaire de l’achèvement de la tâche dans ado (Azure DevOps) ou des tickets JIRA, ou via des enregistrements papier qui doivent être signés.

• Exemple de preuve : cette première capture d’écran montre la sortie du script qui est exécuté tous les trimestres pour afficher le dernier attribut de connexion pour les utilisateurs dans Microsoft Entra ID.

Comme vous pouvez le voir dans la capture d’écran ci-dessus, deux utilisateurs indiquent qu’ils ne se sont pas connectés depuis un certain temps. Les deux captures d’écran suivantes montrent que ces deux utilisateurs sont désactivés.

Contrôle 43 : fournir des preuves démontrables qu’une stratégie de mot de passe fort ou d’autres mesures d’atténuation appropriées pour protéger les informations d’identification de l’utilisateur sont en place. Les recommandations suivantes doivent être utilisées au minimum :

• Longueur minimale du mot de passe de 8 caractères

• Seuil de verrouillage de compte de 10 tentatives au plus

• Historique des mots de passe d’un minimum de 5 mots de passe

• Application de l’utilisation d’un mot de passe fort

• Intention : Comme nous l’avons déjà vu, les informations d’identification de l’utilisateur sont souvent la cible d’attaques par des groupes d’activités qui tentent d’accéder à l’environnement d’un organization. L’objectif d’une stratégie de mot de passe fort est d’essayer de forcer les utilisateurs à choisir des mots de passe forts afin d’atténuer les risques que les groupes d’activités puissent les forcer par force brute. L’intention de l’ajout de « ou d’autres atténuations appropriées » est de reconnaître que les organisations peuvent mettre en œuvre d’autres mesures de sécurité pour aider à protéger les informations d’identification des utilisateurs en fonction des développements du secteur, tels que « NIST Special Publication 800-63B ».

• Exemple de recommandations en matière de preuves : les preuves permettant de démontrer une stratégie de mot de passe fort peuvent se présenter sous la forme d’une capture d’écran d’une organisation stratégie de groupe des paramètres d’objet ou de sécurité locale « Stratégies de compte à stratégie de mot de passe » et « Stratégies de compte à stratégie de verrouillage de compte ». Les données probantes dépendent des technologies utilisées ; autrement dit, pour Linux, il peut s’agir du fichier de configuration /etc/pam.d/common-password, pour BitBucket de la section « Stratégies d’authentification » dans le portail Administration (https://support.atlassian.com/security-and-access-policies/docs/manage-your-password-policy/), etc.

• Exemple de preuve : la preuve ci-dessous montre la stratégie de mot de passe configurée dans la « Stratégie de sécurité locale » du composant système dans l’étendue « CLARANET-SBU-WM ».

La capture d’écran ci-dessous montre les paramètres de verrouillage de compte pour un pare-feu WatchGuard.

Voici un exemple de longueur minimale de phrase secrète pour le pare-feu WatchGaurd.

Contrôle 44 : fournir des preuves démontrables que des comptes d’utilisateur uniques sont émis à tous les utilisateurs.

• Intention : l’objectif de ce contrôle est la responsabilité. En émettant des utilisateurs avec leur propre compte d’utilisateur unique, les utilisateurs seront responsables de leurs actions, car l’activité de l’utilisateur peut être suivie auprès d’un utilisateur individuel.

• Exemple de recommandations en matière de preuves : les preuves sont effectuées via des captures d’écran montrant des comptes d’utilisateur configurés dans les composants système dans l’étendue, qui peuvent inclure des serveurs, des dépôts de code, des plateformes de gestion cloud, Active Directory, des pare-feu, etc.

• Exemple de preuve : la capture d’écran suivante montre les comptes d’utilisateur configurés pour le composant système dans l’étendue « CLARANET-SBU-WM ».

Cette capture d’écran suivante montre que le compte Administrateur est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Cette capture d’écran suivante montre que le compte invité est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Cette capture d’écran suivante montre que defaultAccount est désactivé sur le composant système dans l’étendue « CLARANET-SBU-WM ».

Contrôle 45 : Fournir des preuves démontrables que les principes des privilèges minimum sont respectés dans l’environnement.

• Intention : les utilisateurs doivent uniquement obtenir les privilèges nécessaires pour remplir leur fonction de travail. Il s’agit de limiter le risque qu’un utilisateur accède intentionnellement ou involontairement à des données qu’il ne devrait pas ou qu’il effectue un acte malveillant. En suivant ce principe, il réduit également la surface d’attaque potentielle (autrement dit, les comptes privilégiés) qui peut être ciblée par un groupe d’activités malveillantes.

• Exemples de recommandations en matière de preuves : la plupart des organisations utilisent des groupes pour attribuer des privilèges en fonction des équipes au sein du organization. Les preuves peuvent être des captures d’écran montrant les différents groupes privilégiés et uniquement les comptes d’utilisateur des équipes qui ont besoin de ces privilèges. En règle générale, cela est sauvegardé avec des stratégies/processus de prise en charge définissant chaque groupe défini avec les privilèges requis et la justification métier et une hiérarchie de membres de l’équipe pour valider l’appartenance au groupe est configurée correctement.

• Par exemple : dans Azure, le groupe Propriétaires doit être limité. Il doit donc être documenté et doit avoir un nombre limité de personnes affectées à ce groupe. Un autre exemple peut être un nombre limité de membres du personnel ayant la capacité d’apporter des modifications au code. Un groupe peut être configuré avec ce privilège avec les membres du personnel considérés comme ayant besoin de cette autorisation configurée. Cela doit être documenté afin que l’analyste de certification puisse croiser le document avec les groupes configurés, etc.

• Exemple de preuve : la capture d’écran suivante montre que l’environnement est configuré avec des groupes attribués en fonction de la fonction de travail.

La capture d’écran suivante montre que les utilisateurs sont alloués à des groupes en fonction de leur fonction de travail.

Contrôle 46 : fournissez des preuves démontrables qu’un processus est en place pour sécuriser ou renforcer les comptes de service et que le processus est suivi.

• Intention : les comptes de service sont souvent ciblés par des groupes d’activités, car ils sont souvent configurés avec des privilèges élevés. Ces comptes peuvent ne pas suivre les stratégies de mot de passe standard, car l’expiration des mots de passe de compte de service interrompt souvent les fonctionnalités. Par conséquent, ils peuvent être configurés avec des mots de passe faibles ou des mots de passe réutilisés dans le organization. Un autre problème potentiel, en particulier au sein d’un environnement Windows, peut être que le système d’exploitation met en cache le hachage de mot de passe. Cela peut être un gros problème si le compte de service est configuré dans un service d’annuaire, étant donné que ce compte peut être utilisé sur plusieurs systèmes avec le niveau de privilèges configuré, ou si le compte de service est local, il est probable que le même compte/mot de passe soit utilisé sur plusieurs systèmes au sein de l’environnement. Les problèmes ci-dessus peuvent amener un groupe d’activités à accéder à davantage de systèmes dans l’environnement et peuvent entraîner une élévation supplémentaire des privilèges et/ou un mouvement latéral. L’objectif est donc de s’assurer que les comptes de service sont correctement renforcés et sécurisés pour les protéger contre leur prise en charge par un groupe d’activités, ou en limitant le risque en cas de compromission de l’un de ces comptes de service.

• Exemples de recommandations en matière de preuves : Il existe de nombreux guides sur Internet pour renforcer les comptes de service. Les preuves peuvent se présenter sous la forme de captures d’écran montrant comment le organization a implémenté le renforcement sécurisé du compte. Voici quelques exemples (on s’attend à ce que plusieurs techniques soient utilisées) :

• Restreindre les comptes à un ensemble d’ordinateurs dans Active Directory,

• La définition du compte de sorte que la connexion interactive n’est pas autorisée,

• Définition d’un mot de passe extrêmement complexe,

• Pour Active Directory, activez l’indicateur « Le compte est sensible et ne peut pas être délégué ». Ces techniques sont décrites dans l’article suivant « Segmentation et Active Directory partagé pour un environnement de données de titulaires de carte ».

• Exemple de preuve : Il existe plusieurs façons de renforcer un compte de service, qui dépendent de chaque environnement individuel. Les mécanismes appropriés pour votre environnement, qui sont utilisés, sont documentés plus tôt dans le document de stratégie/procédure de gestion des comptes, qui vous aidera à examiner ces preuves. Voici quelques-uns des mécanismes qui peuvent être utilisés :

La capture d’écran suivante montre que l’option « Le compte est sensible et se connecter à délégué » est sélectionnée sur le compte de service « _Prod compte de service SQL ».

Cette capture d’écran suivante montre que le compte de service « _Prod compte de service SQL » est verrouillé sur le SQL Server et peut uniquement se connecter à ce serveur.

Cette capture d’écran suivante montre que le compte de service « _Prod compte de service SQL » est uniquement autorisé à se connecter en tant que service.

Contrôle 47 : Fournir une preuve démontrable que l’authentification multifacteur est configurée pour toutes les connexions d’accès à distance et toutes les interfaces d’administration non-console.

Termes définis comme suit :

• Accès à distance : en règle générale, il s’agit des technologies utilisées pour accéder à l’environnement de prise en charge. Par exemple, VPN IPSec d’accès à distance, VPN SSL ou Hôte Jumpbox/Bastian.

• Interfaces d’administration non-console : en règle générale, il s’agit des connexions d’administration réseau aux composants système. Cela peut être via le Bureau à distance, SSH ou une interface web.

• Intention : l’objectif de ce contrôle est de fournir des mesures d’atténuation contre la force brute des comptes privilégiés et des comptes disposant d’un accès sécurisé à l’environnement. En fournissant l’authentification multifacteur (MFA), un mot de passe compromis doit toujours être protégé contre une connexion réussie, car le mécanisme MFA doit toujours être sécurisé. Cela permet de garantir que toutes les actions d’accès et d’administration sont effectuées uniquement par des membres du personnel autorisés et approuvés.

• Exemples de recommandations en matière de preuves : Les preuves doivent montrer que l’authentification multifacteur est activée sur toutes les technologies qui correspondent aux catégories ci-dessus. Il peut s’agir d’une capture d’écran montrant que l’authentification multifacteur est activée au niveau du système. Au niveau du système, nous avons besoin d’une preuve indiquant qu’elle est activée pour tous les utilisateurs et pas seulement un exemple de compte avec l’authentification multifacteur activée. Lorsque la technologie est renvoyée à une solution MFA, nous avons besoin des preuves pour démontrer qu’elle est activée et en cours d’utilisation. Ce que cela veut dire, c’est : lorsque la technologie est configurée pour l’authentification Radius, qui pointe vers un fournisseur MFA, vous devez également prouver que le serveur Radius vers lequel il pointe est une solution MFA et que les comptes sont configurés pour l’utiliser.

• Exemple de preuve 1 : les captures d’écran suivantes montrent les domaines d’authentification configurés sur Pulse Secure, qui est utilisé pour l’accès à distance dans l’environnement. L’authentification est annulée par le service SaaS Duo pour la prise en charge de l’authentification multifacteur.

Cette capture d’écran montre qu’un serveur d’authentification supplémentaire est activé et pointe vers « Duo-LDAP » pour le domaine d’authentification « Duo - Route par défaut ».

Cette capture d’écran finale montre la configuration du serveur d’authentification Duo-LDAP, qui montre que cela pointe vers le service SaaS Duo pour l’authentification multifacteur.

Exemple de preuve 2 : les captures d’écran suivantes montrent que l’authentification MFA est activée pour tous les utilisateurs Azure.

Remarque : vous devez fournir des preuves pour toutes les connexions non-console afin de démontrer que l’authentification multifacteur est activée pour elles. Par exemple, si vous utilisez RDP ou SSH vers des serveurs ou d’autres composants système (c’est-à-dire des pare-feu).

Contrôle 48 : Fournir des preuves démontrables que le chiffrement fort est configuré pour toutes les connexions d’accès à distance et toutes les interfaces d’administration non-console, y compris l’accès aux dépôts de code et aux interfaces de gestion cloud.

Termes définis comme suit :

• Référentiels de code : la base de code de l’application doit être protégée contre les modifications malveillantes susceptibles d’introduire des programmes malveillants dans l’application. L’authentification multifacteur doit être configurée sur le référentiel de code.

• Interfaces de gestion cloud : lorsque tout ou partie de l’environnement est hébergé dans le fournisseur de services cloud (CSP), l’interface d’administration pour la gestion cloud est incluse ici.

• Intention : L’objectif de ce contrôle est de s’assurer que tout le trafic administratif est correctement chiffré pour se protéger contre les attaques de l’intercepteur.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies par des captures d’écran montrant les paramètres de chiffrement pour les technologies d’accès à distance, les interfaces RDP, SSH et Web Administration. Pour les interfaces web Administration, le scanneur Qualys SSL Labs (s’il est accessible publiquement, c’est-à-dire les interfaces de gestion cloud, les dépôts de code SaaS ou les connexions VPN SSL) peut être utilisé.

• Exemple de preuve : la preuve ci-dessous montre que le niveau de chiffrement RDP sur « Webserver01 » est configuré avec le paramètre « Niveau élevé ». Comme le montre le texte d’aide, il s’agit d’un chiffrement fort 128 bits (qui est le niveau le plus élevé pour Microsoft Windows RDP).

La preuve ci-dessous montre également que la sécurité de transport RDP est configurée pour utiliser TLS 1.0 sur « Webserver01 » (qui est le plus élevé pour Windows Server).

Contrôle 49 : Fournir une preuve démontrable que l’authentification multifacteur est utilisée pour protéger le portail d’administration que vous utilisez pour gérer et gérer tous les enregistrements DNS (Public Domain Name Service).

• Intention : si un groupe d’activités malveillantes peut accéder aux enregistrements DNS publics, il y a un risque qu’il puisse modifier les URL utilisées par l’application, ou que le fichier manifeste pointe pour introduire du code malveillant ou diriger le trafic utilisateur vers un point de terminaison sous le contrôle des acteurs. Cela peut entraîner une perte de données utilisateur ou des infections de logiciels malveillants/rançongiciels dans la base d’utilisateurs de l’application.

• Exemples de recommandations en matière de preuves : fournissez des preuves qui montrent que les portails d’administration DNS publics sont protégés par l’authentification multifacteur. Même si le DNS public est hébergé sur des serveurs au sein de l’environnement dans l’étendue (c’est-à-dire, le contrôle et l’exploitation par le organization), il peut toujours y avoir un Administration Portail quelque part où le nom de domaine a été inscrit, et les enregistrements DNS ont été « gérés » pour diriger les serveurs DNS vers votre propre infrastructure. Dans ce cas, l’authentification multifacteur doit être activée sur l’interface d’administration du bureau d’enregistrement de domaines si les enregistrements DNS des domaines peuvent être modifiés. Une capture d’écran doit être fournie montrant que l’interface d’administration est activée pour l’authentification multifacteur au niveau du système (autrement dit, tous les comptes privilégiés).

• Exemple de preuve : la capture d’écran suivante montre le contoso.com DNS est géré dans Microsoft Azure pour Contoso Corporation.

Note: Les adresses IP sont des adresses RFC 1918 privées et ne sont pas routées publiquement. C’est uniquement à des fins de démonstration.

Les captures d’écran suivantes montrent que l’authentification multifacteur est activée pour tous les utilisateurs Azure.

Détection et prévention des intrusions (facultatif)

Les systèmes de détection et de prévention des intrusions (IDPS) de la passerelle peuvent fournir une couche supplémentaire de protection contre une myriade de menaces internes et basées sur Internet. Ces systèmes peuvent aider à empêcher la réussite de ces menaces et fournir des fonctionnalités d’alerte cruciales pour alerter les organisations en cas de tentatives de compromission en direct afin de permettre aux organisations d’implémenter des stratégies défensives supplémentaires pour mieux protéger l’environnement contre ces menaces actives.

Cette section fait l’objet d’un crédit supplémentaire et est donc facultative. Ce n’est pas une exigence, mais si vous le faites, votre évaluation affichera une image plus complète de votre environnement et des contrôles et normes que vous avez mis en place.

Contrôle 50 : Fournir des preuves démontrables que les systèmes de détection et de prévention des intrusions (IDPS) sont déployés dans le périmètre des environnements dans l’étendue.

• Intention : Bien que certaines sources décrivent les menaces internes comme dépassant désormais les menaces des groupes d’activités externes, les menaces internes incluent également la négligence, avec une augmentation des erreurs humaines en pourcentage d’une année à l’autre. L’objectif de l’installation d’IDPS sur le périmètre des environnements dans l’étendue est que les menaces externes peuvent souvent être détectées par le biais de mécanismes IDPS en raison de la nature et des techniques utilisées par ces types de menaces.

• Exemple de recommandations en matière de preuves : des preuves doivent être fournies pour démontrer que l’IDPS est installé dans le périmètre, qu’il peut être directement sur le pare-feu si vous exécutez un pare-feu NextGen ou qu’il peut s’agir de capteurs IDPS de déploiement configurés sur miroir ports de commutateur pour garantir que tout le trafic est vu par les capteurs déployés. Si des capteurs IDPS sont utilisés, il peut être nécessaire de fournir des preuves supplémentaires pour démontrer que les capteurs sont en mesure de voir tous les flux de trafic externe.

• Exemple de preuve : la capture d’écran ci-dessous montre que la fonctionnalité IDPS est activée sur le pare-feu WatchGuard.

La capture d’écran supplémentaire ci-dessous montre que IDPS est activé sur toutes les règles dans la configuration du pare-feu WatchGuard.

Contrôle 51 : Fournir une preuve démontrable que les signatures IDPS sont conservées à jour (dans les 24 heures).

• Intention : Il existe plusieurs modes de fonctionnement pour IDPS, le plus courant consiste à utiliser des signatures pour identifier le trafic d’attaque. À mesure que les attaques évoluent et que de nouvelles vulnérabilités sont identifiées, il est important que les signatures IDPS soient à jour pour fournir une protection adéquate. L’objectif de ce contrôle est de s’assurer que idps est maintenu.

• Exemple de recommandations en matière de preuves : la preuve sera probablement avec une capture d’écran montrant que l’IDPS est configuré pour mettre à jour les signatures au moins quotidiennement et montrant la dernière mise à jour.

• Exemple de preuve : bien que cette capture d’écran ne montre pas que les signatures IDPS ont été mises à jour au cours des dernières 24 heures, elle montre que la dernière version est installée, qui date d’il y a une semaine (preuves collectées sur le 18__thmai). Ceci, combiné à la capture d’écran qui suit, montre que les signatures seront à jour dans un délai de 24 heures.

Contrôle 52 : fournir des preuves démontrables que IDPS est configuré pour prendre en charge l’inspection TLS de tout le trafic web entrant.

• Intention : étant donné qu’IDPS s’appuie sur des signatures, elle doit être en mesure d’inspecter tous les flux de trafic pour identifier le trafic d’attaque. Le trafic TLS est chiffré et idps ne peut donc pas inspecter correctement le trafic. Cela est essentiel pour le trafic HTTPS, car il existe une myriade de menaces communes aux services web. L’objectif de ce contrôle est de s’assurer que les flux de trafic chiffrés peuvent également être inspectés pour idps.

• Exemples de recommandations en matière de preuves : les preuves doivent être fournies à l’aide de captures d’écran, montrant que le trafic TLS chiffré est également inspecté par la solution IDPS.

• Exemple de preuve : cette capture d’écran montre les règles HTTPS sur le pare-feu

Cette capture d’écran suivante montre que IDPS est activé sur ces règles.

La capture d’écran suivante montre qu’une « action de proxy » est appliquée à la règle « Inbound_Bot_Traffic », qui est utilisée pour activer l’inspection du contenu.

La capture d’écran suivante montre que l’inspection du contenu est activée.

Contrôle 53 : fournir une preuve démontrable que idps est configuré pour surveiller tous les flux de trafic entrant.

• Intention : Comme indiqué précédemment, il est important que tous les flux de trafic entrant soient surveillés par IDPS pour identifier toute forme de trafic d’attaque.

• Exemples de recommandations en matière de preuves : des preuves par le biais de captures d’écran doivent être fournies pour montrer que tous les flux de trafic entrant sont surveillés. Il peut s’agir d’utiliser le pare-feu NextGen, montrant que toutes les règles entrantes sont activées pour IDPS, ou en utilisant des capteurs IDPS et en montrant que tout le trafic est configuré pour atteindre le capteur IDPS.

• Exemple de preuve : cette capture d’écran montre qu’IDPS est configuré sur toutes les règles (stratégies) du pare-feu WatchGuard.

Contrôle 54 : fournir des preuves démontrables que IDPS est configuré pour surveiller tous les flux de trafic sortant.

• Intention : Comme nous l’avons déjà vu, il est important que tous les flux de trafic sortant soient surveillés par IDPS pour identifier toute forme de trafic d’attaque. Certains systèmes IDPS peuvent également identifier les violations internes potentielles en surveillant tout le trafic sortant. Pour ce faire, identifiez le trafic destiné aux points de terminaison « Commande et contrôle ».

• Exemples de recommandations en matière de preuves : des preuves par le biais de captures d’écran doivent être fournies pour montrer que tous les flux de trafic sortant sont surveillés. Il peut s’agir d’utiliser le pare-feu NextGen, ce qui montre que toutes les règles sortantes sont activées pour IDPS, ou d’utiliser des capteurs IDPS et de montrer que tout le trafic est configuré pour atteindre le capteur IDPS.

• Exemple de preuve : cette capture d’écran montre qu’IDPS est configuré sur toutes les règles (stratégies) du pare-feu WatchGuard.

• Exemple de preuve 2 : Azure propose idps via des applications tierces. Dans l’exemple ci-dessous, la capture de paquets Netwatcher a été utilisée pour capturer des paquets et utilisée avec Suricata, qui est un outil IDS Open-Source.

En combinant la capture de paquets fournie par Network Watcher et des outils IDS open source tels que Suricata, vous pouvez effectuer une détection d’intrusion réseau pour un large éventail de menaces. L’image ci-dessous montre l’interface Suricata.

Les signatures sont utilisées pour déclencher des alertes, qui peuvent être installées et mises à jour facilement. L’image ci-dessous montre une instantané de certaines signatures.

L’image ci-dessous montre comment vous surveilleriez votre configuration IDPS des logiciels tiers Netwatcher et Suricata à l’aide de Sentinel SIEM/SOAR.

• Exemple de preuve 3 : l’image ci-dessous montre comment ajouter une signature d’intrusion de remplacement ou une règle de contournement pour la détection d’intrusion à l’aide de l’interface CLI

L’image ci-dessous montre comment répertorier toutes les configurations de détection d’intrusion à l’aide de l’interface CLI

• Exemple de preuve 4 : Azure a récemment commencé à proposer idps nommé Pare-feu Azure Premium qui permettra la configuration de TLS, Threat Intelligence et IDPS via des stratégies. Toutefois, notez que vous devrez toujours utiliser Front Door ou la passerelle d’application pour le déchargement SSL du trafic entrant, car Pare-feu Azure Premium ne prend pas en charge IDPS sur les connexions SSL entrantes.

Dans l’exemple ci-dessous, les paramètres Premium par défaut ont été utilisés pour la configuration des règles de stratégie et l’inspection TLS, le mode IDPS et le renseignement sur les menaces ont tous été activés avec la protection du réseau virtuel.

Journalisation des événements de sécurité

La journalisation des événements de sécurité fait partie intégrante du programme de sécurité d’un organization. Une journalisation adéquate des événements de sécurité associée à des processus d’alerte et de révision paramétrés aide les organisations à identifier les violations ou les tentatives de violation qui peuvent être utilisées par les organization pour améliorer la sécurité et les stratégies de sécurité défensives. En outre, une journalisation adéquate sera essentielle à une capacité de réponse aux incidents des organisations qui peut alimenter d’autres activités telles que la possibilité d’identifier avec précision les données et les personnes qui ont été compromises, la période de compromission, de fournir des rapports d’analyse détaillés aux organismes gouvernementaux, etc.

Contrôle 55 : Fournir une documentation de stratégie pour les meilleures pratiques et procédures qui régissent la journalisation des événements de sécurité.

• Intention : la journalisation des événements de sécurité est une fonction importante du programme de sécurité d’un organization. Des stratégies et des procédures doivent être en place pour fournir clarté et cohérence afin de garantir que les organisations implémentent des contrôles de journalisation conformément aux pratiques recommandées par les fournisseurs et le secteur. Cela permet de s’assurer que des journaux pertinents et détaillés sont consommés, qui ne sont pas seulement utiles pour identifier les événements de sécurité potentiels ou réels, mais ils peuvent également aider une activité de réponse aux incidents à identifier l’étendue d’une violation de sécurité.

• Exemple d’instructions de preuve : fournissez aux organisations des documents de stratégie et de procédure documentés qui couvrent les meilleures pratiques de journalisation des événements de sécurité.

• Exemple de preuve : vous trouverez ci-dessous un extrait de la stratégie/procédure de journalisation.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 56 : Fournissez des preuves démontrant que la journalisation des événements de sécurité est configurée sur tous les composants système échantillonnées pour enregistrer les événements suivants :

• Accès utilisateur aux composants système et à l’application

• Toutes les actions effectuées par un utilisateur disposant de privilèges élevés

• Tentatives d’accès logique non valides

• Création ou modification d’un compte privilégié

• Falsification du journal des événements

• Désactivation des outils de sécurité, tels que l’anti-programme malveillant ou la journalisation des événements

• Journalisation anti-programme malveillant, comme les mises à jour, la détection des programmes malveillants et les échecs d’analyse

• Événements IDPS et WAF, si configurés

• Intention : pour identifier les tentatives et les violations réelles, il est important que des journaux d’événements de sécurité adéquats soient collectés par tous les systèmes qui composent l’environnement. L’objectif de ce contrôle est de s’assurer que les types corrects d’événements de sécurité sont capturés, ce qui peut ensuite alimenter les processus de révision et d’alerte pour aider à identifier ces événements et à y répondre.

• Exemples d’instructions de preuve : des preuves par le biais de captures d’écran ou de paramètres de configuration doivent être fournies sur tous les appareils échantillonné et tous les composants système pertinents pour montrer comment la journalisation est configurée pour fournir l’assurance que ces types d’événements de sécurité sont capturés.

• Exemple de preuve 1 : la capture d’écran suivante montre les paramètres de configuration de l’un des appareils échantillonné appelé « VICTIM1-WINDOWS ». Les paramètres affichent différents paramètres d’audit activés dans les paramètres « Stratégie de sécurité locale  Stratégies locales  Stratégie d’audit ».

Cette capture d’écran suivante montre un événement dans lequel un utilisateur a effacé un journal des événements de l’un des appareils échantillonnés appelé « VICTIM1-WINDOWS ».

Cette dernière capture d’écran montre que le message de journalisation s’affiche dans la solution de journalisation centralisée.

Remarque : des captures d’écran sont requises pour tous les composants système échantillonnées etdoivent prouver tous les événements de sécurité détaillés ci-dessus.

Contrôle 57 : Fournissez des preuves démontrables que les événements de sécurité enregistrés contiennent les informations minimales suivantes :

• Utilisateur

• Type d’événement

• Date et heure

• Indicateurs de réussite ou d’échec

• Étiquette qui identifie le système affecté

• Intention : les événements de sécurité journalisés doivent fournir suffisamment d’informations pour aider à déterminer si le trafic d’attaque a réussi, quelles informations ont été consultées, à quel niveau, qui était responsable, d’où il provient, etc.

• Exemples de recommandations en matière de preuves : les preuves doivent afficher des exemples de journaux de tous les composants système montrant ces types d’événements de sécurité. Les journaux doivent inclure toutes les informations répertoriées ci-dessus.

• Exemple de preuve : la capture d’écran suivante montre les informations des événements de sécurité dans Windows observateur d'événements à partir du composant système dans l’étendue « SEGSVR02 ».

Remarque : des captures d’écran sont requises pour tous les composants système échantillonnées et doivent prouver tous les événements de sécurité détaillés dans le contrôle ci-dessus. il est probable que les éléments de preuve recueillis pour le contrôle ci-dessus satisfont également à ce contrôle, en fournissant des détails adéquats sur les informations de journalisation fournies.

Contrôle 58 : fournir des preuves démontrables que tous les composants système échantillonné sont synchronisés avec les mêmes serveurs principaux et secondaires.

• Intention : un composant essentiel de la journalisation consiste à s’assurer que les journaux sur tous les systèmes ont des horloges système qui sont toutes synchronisées. Cela est important lorsqu’une enquête est nécessaire pour suivre une compromission et/ou une violation de données. Le suivi des événements via différents systèmes peut devenir presque impossible si les journaux ont des horodatages différents, car des journaux importants peuvent être manqués et il sera difficile à suivre.

• Exemple d’instructions de preuve : Dans l’idéal, une topologie de synchronisation de l’heure doit être conservée qui montre comment l’heure est synchronisée dans le patrimoine. Les preuves peuvent ensuite être fournies par le biais de captures d’écran des paramètres de synchronisation de l’heure entre les composants système échantillonnées. Cela doit indiquer que toutes les synchronisations de l’heure sont effectuées sur le même serveur principal (ou s’il est en place sur un serveur secondaire).

• Exemple de preuve : ce diagramme montre la topologie de synchronisation de l’heure utilisée.

La capture d’écran suivante montre watchGuard configuré en tant que serveur NTP et pointant vers time.windows.com en tant que source de temps.

Cette capture d’écran finale montre le composant système dans l’étendue, « CLARANET-SBU-WM » est configuré pour que NTP pointe vers le serveur principal qui est le pare-feu WatchGuard (10.0.1.1).

Contrôle 59 : Fournir des preuves démontrables lorsque des systèmes accessibles au public sont en cours d’utilisation que les journaux des événements de sécurité sont envoyés à une solution de journalisation centralisée qui n’est pas dans le réseau de périmètre.

• Intention : l’objectif de ce contrôle est de garantir une séparation logique ou physique entre la zone DMZ et le point de terminaison de journalisation. Étant donné que la zone DMZ est publique, elle est exposée à des groupes d’activités externes et, par conséquent, à plus de risques que d’autres composants au sein de l’environnement. Si un composant DMZ est compromis, l’intégrité des données de journalisation doit être conservée non seulement pour empêcher le groupe d’activités de falsifier les journaux pour masquer la compromission, mais aussi pour faciliter tout travail d’investigation judiciaire qui peut être nécessaire. En se connectant à des systèmes en dehors de la zone DMZ, les contrôles de sécurité utilisés pour restreindre le trafic de la zone DMZ vers ces systèmes de sécurité doivent aider à les protéger contre les activités malveillantes et les tentatives de falsification.

• Exemple d’instructions de preuve : les preuves doivent être fournies avec des captures d’écran ou des paramètres de configuration, montrant que les journaux sont configurés pour être immédiatement (ou proches de immédiatement) envoyés à une solution de journalisation centralisée qui se trouve en dehors de la zone DMZ. Nous recherchons une expédition quasi immédiate des journaux, car plus il faut de temps pour que les journaux soient expédiés vers la solution de journalisation centralisée, plus un acteur de traitement aurait de temps à falsifier les journaux locaux avant l’expédition.

• Exemple de preuve : Les systèmes DMZ contoso utilisent NXLog pour l’expédition des fichiers journaux. La capture d’écran suivante montre le service « nxlog » en cours d’exécution sur la jumpbox DMZ « DESKTOP-7S65PN » qui est utilisée pour gérer tous les serveurs DMZ.

La capture d’écran suivante montre un extrait du fichier nxlog.conf, montrant que la destination est un collecteur de journaux interne dans le sous-réseau d’application sur 10.0.1.250 qui est utilisé pour l’expédition à AlienVault.

L’URL suivante pour NXLog (https://nxlog.co/documentation/nxlog-user-guide/modes.html) indique que la copie des journaux de transaction est en temps réel via l’extrait suivant :

Contrôle 60 : fournir des preuves démontrables pour montrer que la solution de journalisation centralisée est protégée contre la falsification non autorisée des données de journalisation.

• Intention : Bien que la séparation logique/physique soit souvent en place entre les appareils de journalisation et la solution de journalisation centralisée, il existe toujours un risque que quelqu’un tente de falsifier les journaux pour masquer ses activités. L’objectif de ce contrôle est de s’assurer que des mécanismes d’autorisation adéquats sont en place pour limiter le nombre d’utilisateurs pouvant effectuer des actions administratives sur la solution de journalisation centralisée.

• Exemple d’instructions de preuve : les preuves sont généralement avec des captures d’écran montrant la configuration de l’autorisation et de l’authentification de la solution de journalisation centralisée, montrant que les utilisateurs sont limités à ceux requis pour leur rôle/fonction de travail.

• Exemple de preuve : Le SOC externalisé de Contoso utilise AlienVault comme outils SIEM centralisés. AlienVault a été racheté par AT&T en 2018 et passe maintenant par USM Anywhere. La page web suivante (https://cybersecurity.att.com/documentation/usm-anywhere/deployment-guide/admin/usm-anywhere-data-security.htm) explique comment USM Anywhere protège les données contre toute falsification non autorisée. Le lien suivant (https://cybersecurity.att.com/documentation/usm-appliance/raw-logs/raw-log-management.htm) met en évidence la façon dont le produit USM Anywhere garantit également l’intégrité des journaux archivés.

Note: Si le SIEM est interne, des preuves devront être fournies pour démontrer que l’accès aux données de journalisation est limité à un nombre sélectionné d’utilisateurs en fonction de leurs besoins de travail et que la plateforme elle-même est protégée contre la falsification (la plupart des solutions l’intègrent dans les fonctionnalités de la solution de journalisation).

Contrôle 61 : fournir des preuves démontrables qu’un minimum de 30 jours de données de journalisation des événements de sécurité est immédiatement disponible, avec 90 jours de conservation des journaux des événements de sécurité.

• Intention : Parfois, il existe une différence de temps entre un événement de compromission ou de sécurité et un organization l’identifiant. L’objectif de ce contrôle est de s’assurer que le organization a accès aux données d’événements historiques pour faciliter la réponse à l’incident et tout travail d’investigation judiciaire qui peut être nécessaire.

• Exemples de recommandations en matière de preuves : il s’agit généralement d’afficher les paramètres de configuration de la solution de journalisation centralisée indiquant la durée de conservation des données. Les données de journalisation des événements de sécurité d’une valeur de 30 jours doivent être immédiatement disponibles dans la solution. Toutefois, lorsque les données sont archivées, cela doit démontrer qu’une valeur de 90 jours est disponible. Cela peut être en affichant les dossiers d’archivage avec les dates des données exportées.

• Exemple de preuve 1 : les captures d’écran suivantes montrent que 30 jours de journaux sont disponibles dans AlienVault.

Remarque : Étant donné qu’il s’agit d’un document public, le numéro de série du pare-feu a été rédigé. Toutefois, nous n’envisageons pas que les éditeurs de logiciels indépendants prennent en charge les captures d’écran expurgées, sauf s’ils contiennent des informations d’identification personnelle.

Cette capture d’écran suivante montre que les journaux sont disponibles en montrant un extrait de journal remontant à 5 mois.

Remarque : Étant donné qu’il s’agit d’un document public, les adresses IP publiques ont été supprimées, mais nous n’envisageons pas que les éditeurs de logiciels indépendants prennent en charge les captures d’écran expurgées, sauf s’ils contiennent des informations d’identification personnelle.

• Exemple de preuve 2 : la capture d’écran suivante montre que les événements de journal sont conservés pendant 30 jours disponibles en direct et 90 jours dans le stockage à froid dans Azure.

Révision du journal des événements de sécurité

L’examen des journaux de sécurité est une fonction importante pour aider les organisations à identifier les événements de sécurité qui peuvent indiquer une violation de la sécurité ou des activités de reconnaissance qui peuvent indiquer quelque chose à venir. Cette opération peut être effectuée quotidiennement par le biais d’un processus manuel ou à l’aide d’une solution SIEM (Security Information and Event Management) qui permet d’analyser les journaux d’audit, de rechercher les corrélations et les anomalies qui peuvent être signalées pour une inspection manuelle.

Contrôle 62 : Fournissez une documentation de stratégie qui régit les pratiques et procédures de révision des journaux.

• Intention : Un rapport d’IBM intitulé « Rapport sur le coût d’une violation de données 2020 » souligne que le temps moyen pour identifier et contenir une violation de données peut prendre 280 jours, ce qui est plus élevé lorsque la violation est effectuée par un groupe d’activités malveillantes qui est signalé comme 315 jours. Étant donné que le coût moyen d’une violation de données est rapporté en millions de dollars, il est essentiel que ce cycle de vie de violation de données soit réduit non seulement pour réduire la fenêtre d’exposition aux données, mais aussi pour réduire le délai dont dispose un groupe d’activités pour exfiltrer les données de l’environnement. En réduisant cette fenêtre, les organisations peuvent réduire le coût global d’une violation de données.

• En implémentant un processus d’examen et d’alerte robuste, les organisations sont mieux équipées pour identifier les violations plus tôt dans le cycle de vie des violations de données afin de réduire leur impact sur les organization. En outre, un processus fort peut aider à identifier les tentatives de violation, ce qui permet aux organisations de renforcer les mécanismes défensifs de sécurité pour atténuer cette menace accrue afin de réduire davantage les risques de compromission par la campagne d’attaque.

• Exemple de directives de preuve : fournissez aux organisations des documents de stratégie et de procédure documentés couvrant les meilleures pratiques en matière de révision des journaux.

• Exemple de preuve : vous trouverez ci-dessous un extrait de la stratégie/procédure de révision des journaux.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 63 : Fournir des preuves démontrables que les journaux sont examinés quotidiennement par un outil humain ou automatisé pour identifier les événements de sécurité potentiels.

• Intention : l’objectif de ce contrôle est de s’assurer que des révisions quotidiennes des journaux sont effectuées. Cela est important pour identifier les anomalies qui peuvent ne pas être détectées par les scripts/requêtes d’alerte configurés pour fournir des alertes d’événement de sécurité.

• Exemples de recommandations en matière de preuves : les preuves sont généralement fournies par capture d’écran ou par un partage d’écran, montrant que des révisions de journal sont effectuées. Il peut s’agir de formulaires remplis chaque jour, ou d’un ticket JIRA ou DevOps avec des commentaires pertinents affichés pour montrer que cette opération est effectuée quotidiennement. Par exemple, un ticket JIRA hebdomadaire peut être créé « Daily Log Review W/C 26th June 2021 », chaque jour où une personne publie les résultats de la révision quotidienne du journal. Si des anomalies sont signalées, cela peut être documenté dans ce même ticket pour illustrer le contrôle suivant dans un seul JIRA.

• Si des outils automatisés sont utilisés, une preuve de capture d’écran peut être fournie pour illustrer l’automatisation configurée et fournir des preuves supplémentaires pour montrer que l’automatisation est en cours d’exécution et qu’une personne examine la sortie automatisée.

• Exemple de preuve : Contoso utilise un fournisseur SOC tiers, Claranet Cyber Security, pour la corrélation des journaux et les révisions. AlienVault est utilisé par le fournisseur SOC, qui peut fournir une analyse automatisée des journaux pour les journaux anormaux et les événements chaînés susceptibles de mettre en évidence un événement de sécurité potentiel. Les trois captures d’écran suivantes montrent des règles de corrélation dans AlienVault.

Cette première capture d’écran identifie où un utilisateur a été ajouté au groupe « Administrateurs du domaine ».

Cette capture d’écran suivante identifie où plusieurs tentatives de connexion ayant échoué sont suivies d’une connexion réussie qui peut mettre en évidence une attaque par force brute réussie.

Cette capture d’écran finale identifie où une modification de stratégie de mot de passe s’est produite pour définir la stratégie, de sorte que les mots de passe de compte n’expirent pas.

Cette capture d’écran suivante montre qu’un ticket est automatiquement déclenché dans l’outil ServiceNow du SOC, ce qui déclenche la règle ci-dessus.

Contrôle 64 : Fournir des preuves démontrables que les événements et anomalies de sécurité potentiels sont examinés et corrigés.

• Intention : l’intention est que toutes les anomalies identifiées pendant le processus de révision quotidienne du journal soient examinées et qu’une correction ou une action appropriée soit effectuée. Cela implique généralement un processus de triage pour déterminer si les anomalies nécessitent une action, puis il peut être nécessaire d’appeler le processus de réponse aux incidents.

• Exemple de recommandations en matière de preuves : les preuves doivent être fournies avec une capture d’écran montrant que les anomalies identifiées dans le cadre de l’examen quotidien du journal sont suivies. Comme nous l’avons déjà vu ci-dessus, il peut s’agir de tickets JIRA montrant une anomalie signalée, puis détaillant les activités qui ont été effectuées par la suite. Cela peut inviter un ticket JIRA spécifique à être déclenché pour suivre toutes les activités en cours, ou il peut simplement être documenté dans le ticket de révision du journal quotidien. Si une action de réponse aux incidents est nécessaire, celle-ci doit être documentée dans le cadre du processus de réponse aux incidents et des preuves doivent être fournies pour le démontrer.

• Exemple de preuve : l’exemple de capture d’écran suivant montre une alerte de sécurité suivie dans ServiceNow par le SOC Claranet Cyber Security MDR (Managed Detection and Response).

Cette capture d’écran suivante montre la confirmation que cela a été résolu par David Ashton @ Contoso via une mise à jour dans le portail client ServiceNow.

Alertes d’événements de sécurité

Les événements de sécurité critiques doivent être immédiatement examinés pour réduire l’impact sur les données et l’environnement opérationnel. L’alerte permet de mettre immédiatement en évidence les violations de sécurité potentielles pour le personnel afin de garantir une réponse en temps voulu afin que le organization puisse contenir l’événement de sécurité le plus rapidement possible. En veillant à ce que les alertes fonctionnent efficacement, les organisations peuvent minimiser l’impact d’une violation de la sécurité, réduisant ainsi le risque d’une violation grave qui pourrait nuire à la marque de l’organisation et imposer des pertes financières par le biais d’amendes et de dommages à la réputation.

Contrôle 65 : Fournir une documentation de stratégie qui régit les pratiques et procédures d’alerte d’événements de sécurité.

• Intention : les alertes doivent être utilisées pour les événements de sécurité clés qui nécessitent une réponse immédiate d’un organization, car l’événement peut indiquer une violation de l’environnement et/ou une violation de données. Un processus fort autour du processus d’alerte doit être documenté pour s’assurer qu’il est effectué de manière cohérente et reproductible. Nous espérons que cela contribuera à réduire le « cycle de vie des violations de données » chronologie.

• Exemple de recommandations en matière de preuves : fournissez aux organisations des documents de stratégie et de procédure documentés qui couvrent les meilleures pratiques en matière d’alertes d’événements de sécurité.

• Exemple de preuve : vous trouverez ci-dessous un extrait de la stratégie/procédure d’alerte d’événement de sécurité. Veuillez fournir les documents complets sur la politique et la procédure à l’appui de votre évaluation.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 66 : Fournir des preuves démontrables que des alertes sont déclenchées pour le triage immédiat pour les types d’événements de sécurité suivants :

• Création ou modification d’un compte privilégié

• Événements de virus ou de programmes malveillants

• Falsification du journal des événements

• Événements IDPS ou WAF, si configurés

• Intention : vous trouverez ci-dessus une liste de certains types d’événements de sécurité qui peuvent mettre en évidence un événement de sécurité qui peut pointer vers une violation de l’environnement et/ou une violation de données.

• Exemples de recommandations en matière de preuves : les preuves doivent être fournies avec des captures d’écran de la configuration des alertes ET des preuves des alertes reçues. Les captures d’écran de configuration doivent montrer la logique qui déclenche les alertes et la façon dont les alertes sont envoyées. Les alertes peuvent être envoyées par SMS, Email, canaux Teams, canaux Slack, etc.

• Exemple de preuve : Contoso utilise un SOC tiers fourni par Claranet Cyber Security. L’exemple suivant montre que les alertes dans AlienVault, utilisées par le SOC, sont configurées pour envoyer une alerte à un membre de l’équipe SOC, Dan Turner chez Claranet Cyber Security.

Cette capture d’écran suivante montre une alerte reçue par Dan.

Contrôle 67 : Fournir des preuves démontrables montrant que le personnel est toujours disponible, toute la journée, tous les jours, pour répondre aux alertes de sécurité.

• Intention : il est important que les alertes de sécurité soient triées dès que possible pour limiter l’exposition à l’environnement et/ou aux données. Le personnel doit toujours être disponible pour répondre aux alertes et fournir un travail d’enquête critique si une violation est détectée. Plus ce processus démarre rapidement, plus vite l’incident de sécurité peut être contenu pour protéger les données ou limiter l’impact de la violation.
• Exemples de recommandations en matière de preuves : des preuves doivent être fournies pour démontrer que les membres du personnel sont disponibles 24 heures sur 24 pour répondre aux alertes de sécurité. Il peut s’agir d’une rotation.
• Exemple de preuve : la capture d’écran suivante montre une rotation d’appel pour décembre 2020 pour Contoso. L’équipe SOC Claranet Cyber Security alerte les membres de l’équipe d’appel contoso.

Gestion des risques liés à la sécurité des informations

La gestion des risques liés à la sécurité des informations est une activité importante que toutes les organisations doivent effectuer au moins une fois par an. Les organisations doivent comprendre leurs menaces et leurs risques pour atténuer efficacement ces menaces. Sans gestion efficace des risques, les organisations peuvent implémenter les meilleures pratiques de sécurité dans des domaines qu’elles jugent importants et donc investir des ressources, du temps et de l’argent dans ces domaines, lorsque d’autres menaces sont beaucoup plus probables et doivent donc être atténuées. Une gestion efficace des risques aidera les organisations à se concentrer sur les risques qui représentent le plus de menaces pour l’entreprise. Cela devrait être effectué chaque année, car le paysage de la sécurité est en constante évolution et, par conséquent, les menaces et les risques peuvent changer au fil du temps. Un bon exemple de cela peut être vu avec la COVID-19 qui a vu une augmentation massive des attaques par hameçonnage et le déploiement massif (et rapide) du travail à distance pour des centaines ou des milliers de travailleurs.

Contrôle 68 : Fournir des preuves démontrables qu’un processus formel de gestion des risques liés à la sécurité des informations est établi.

• Intention : Comme nous l’avons vu ci-dessus, un processus robuste de gestion des risques liés à la sécurité des informations est important pour aider les organisations à gérer efficacement les risques. Cela aidera les organisations à planifier des atténuations efficaces contre les menaces pour l’environnement.

Il est important que l’évaluation des risques inclue les risques liés à la sécurité des informations et pas seulement les risques généraux « métier ».

• Exemples de directives de preuve : le processus de gestion de l’évaluation des risques officiellement documenté doit être fourni.
• Exemple de preuve : la preuve suivante est une capture d’écran d’une partie du processus d’évaluation des risques de Contoso.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 69 : Fournir des preuves démontrables qu’une évaluation officielle des risques a lieu chaque année, au minimum.

• Intention : les menaces de sécurité changent constamment en fonction des modifications apportées à l’environnement, des modifications apportées aux services proposés, des influences externes, de l’évolution du paysage des menaces de sécurité, etc. Les organisations doivent suivre ce processus au moins une fois par an. Il est recommandé que ce processus soit également effectué en cas de modifications importantes, car les menaces peuvent changer.

• Exemple de recommandations en matière de preuves : les preuves peuvent être effectuées par le biais d’un suivi de version ou d’une preuve datée. Il convient de fournir des éléments de preuve indiquant la sortie de l’évaluation des risques liés à la sécurité de l’information et NON les dates du processus d’évaluation des risques liés à la sécurité de l’information proprement dit.

• Exemple de preuve : cette capture d’écran montre une réunion d’évaluation des risques planifiée tous les six mois.

Ces deux captures d’écran montrent les minutes de la réunion de deux réunions d’évaluation des risques.

Contrôle 70 : fournir des preuves démontrables que l’évaluation des risques liés à la sécurité des informations inclut les menaces, les vulnérabilités ou l’équivalent.

• Intention : les évaluations des risques liés à la sécurité des informations doivent être effectuées contre les menaces contre l’environnement et les données, et contre les vulnérabilités potentielles qui peuvent être présentes. Cela aidera les organisations à identifier la myriade de menaces/vulnérabilités qui peuvent présenter un risque significatif.
• Exemples de recommandations en matière de preuves : les preuves doivent être fournies non seulement par le biais du processus d’évaluation des risques pour la sécurité de l’information déjà fourni, mais également de la sortie de l’évaluation des risques (par le biais d’un registre des risques/plan de traitement des risques) qui doit inclure les risques et les vulnérabilités.
• Exemple de preuve : la capture d’écran suivante montre le registre des risques qui montre que les menaces et les vulnérabilités sont incluses.

Note: La documentation complète sur l’évaluation des risques doit être fournie au lieu d’une capture d’écran.

Contrôle 71 : Fournir des preuves démontrables que l’évaluation des risques liés à la sécurité de l’information inclut l’impact, la matrice des risques de probabilité ou l’équivalent.

• Intention : Les évaluations des risques liés à la sécurité des informations doivent documenter les évaluations de l’impact et de la probabilité. Ces matrices sont généralement utilisées pour aider à identifier une valeur de risque qui peut être utilisée par le organization pour hiérarchiser le traitement à risque afin d’aider à réduire la valeur de risque.
• Exemples de directives de preuve : Les preuves doivent être fournies non seulement par le biais du processus d’évaluation des risques en matière de sécurité de l’information déjà fourni, mais également de la sortie de l’évaluation des risques (par le biais d’un registre des risques/plan de traitement des risques) qui devrait inclure des évaluations de l’impact et de la probabilité.
• Exemple de preuve : la capture d’écran suivante montre le registre des risques qui montre l’impact et les probabilités sont incluses.

Note: Le assessment_ _document__ation de risque complet doit être fourni au lieu d’une capture d’écran.

Contrôle 72 : Fournir des preuves démontrables que l’évaluation des risques liés à la sécurité de l’information comprend un registre des risques et un plan de traitement.

• Intention : les organisations doivent gérer les risques efficacement. Cela doit faire l’objet d’un suivi approprié afin de fournir un enregistrement de l’un des quatre traitements à risque appliqués. Les traitements à risque sont les suivants :
• Éviter/Arrêter : l’entreprise peut déterminer que le coût de gestion du risque est supérieur au chiffre d’affaires généré par le service. L’entreprise peut donc choisir d’arrêter d’effectuer le service.
• Transfert/partage : l’entreprise peut choisir de transférer le risque à un tiers en déplaçant le traitement vers un tiers.
• Accepter/Tolérer/Conserver : l’entreprise peut décider que le risque est acceptable. Cela dépend beaucoup de l’appétit des entreprises au risque et peut varier selon les organization.
• Traiter/Atténuer/Modifier : l’entreprise décide d’implémenter des contrôles d’atténuation pour réduire le risque à un niveau acceptable.
• L’objectif de ce contrôle est d’obtenir l’assurance que le organization effectue l’évaluation des risques et qu’il agit en conséquence.
• Exemples de directives de preuve : Le plan de traitement des risques/registre des risques (ou quelque chose d’équivalent) doit être fourni pour démontrer que le processus d’évaluation des risques est effectué correctement.
• Exemple de preuve : Voici un registre des risques pour Contoso.

Note: La documentation complète sur l’évaluation des risques doit être fournie au lieu d’une capture d’écran.

La capture d’écran suivante montre un plan de traitement à risque.

Réponse aux incidents de sécurité

Une réponse aux incidents de sécurité est importante pour toutes les organisations, car elle peut réduire le temps passé par un organization à contenir un incident de sécurité et limiter le niveau d’exposition des organisations à l’exfiltration de données. En développant un plan complet et détaillé de réponse aux incidents de sécurité, cette exposition peut être réduite du moment de l’identification au moment de l’endiguement.

Un rapport d’IBM intitulé « Rapport sur le coût d’une violation de données 2020 » souligne qu’en moyenne, le temps nécessaire pour contenir une violation était de 73 jours. En outre, le même rapport identifie le plus grand économiseur de coûts pour les organisations qui ont subi une violation, à savoir la préparation à la réponse aux incidents, offrant une économie de coût moyenne de 2 000 000 $.

Les organisations doivent suivre les meilleures pratiques en matière de conformité de la sécurité à l’aide de frameworks standard du secteur tels que ISO 27001, NIST, SOC 2, PCI DSS, etc.

Contrôle 73 : Fournir le plan de réponse aux incidents de sécurité (IRP).

• Intention : Comme nous l’avons déjà vu, l’objectif de ce contrôle est d’exiger un plan de réponse aux incidents officiellement documenté. Cela permet de gérer une réponse aux incidents de sécurité plus efficace, ce qui peut finalement limiter l’exposition des organisations à la perte de données et réduire les coûts de la compromission.
• Exemples de recommandations en matière de preuves : fournissez la version complète du plan/procédure de réponse aux incidents. Cela doit inclure un processus de communication documenté qui est abordé dans le contrôle suivant.
• Exemple de preuve : la capture d’écran ci-dessous montre le début du plan de réponse aux incidents de Contoso. Dans le cadre de votre soumission de preuve, vous devez fournir l’ensemble du plan de réponse aux incidents.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 74 : Fournir des preuves démontrables que l’IRP de sécurité comprend un processus de communication documenté pour assurer une notification en temps voulu aux principales parties prenantes, telles que les marques de paiement et les acquéreurs, les organismes de réglementation, les autorités de surveillance, les administrateurs et les clients.

• Intention : les organisations peuvent avoir des obligations de notification de violation en fonction du ou des pays dans lesquels elles opèrent (par exemple, le Règlement général sur la protection des données ; RGPD), ou en fonction des fonctionnalités proposées (par exemple, PCI DSS si les données de paiement sont gérées). L’absence de notification en temps voulu peut avoir de graves conséquences. Par conséquent, pour s’assurer que les obligations de notification sont respectées, les plans de réponse aux incidents doivent inclure un processus de communication incluant la communication avec toutes les parties prenantes, les processus de communication avec les médias et les personnes qui peuvent et ne peuvent pas parler aux médias.
• Exemples de recommandations en matière de preuves : fournissez la version complète du plan/procédure de réponse aux incidents, qui doit inclure une section couvrant le processus de communication.
• Exemple de preuve : la capture d’écran suivante montre un extrait du plan de réponse aux incidents montrant le processus de communication.

Contrôle 75 : Fournir des preuves démontrables que tous les membres de l’équipe de réponse aux incidents ont suivi une formation annuelle ou un exercice de haut de tableau.

• Intention : Comme nous l’avons vu précédemment, plus il faut de temps pour qu’un organization contienne une compromission, plus le risque d’exfiltration de données est élevé, ce qui peut entraîner un plus grand volume de données exfiltrées et plus le coût global de la compromission est élevé. Il est important que les équipes de réponse aux incidents de organization soient équipées pour répondre aux incidents de sécurité en temps voulu. En effectuant une formation régulière et en effectuant des exercices de table, l’équipe peut ainsi gérer les incidents de sécurité rapidement et efficacement.

• Il est recommandé d’effectuer à la fois une formation interne sur la réponse aux incidents pour l’équipe de réponse aux incidents et d’effectuer des exercices de table réguliers, qui doivent être liés à l’évaluation des risques liés à la sécurité des informations pour identifier les incidents de sécurité les plus susceptibles de se produire. De cette façon, l’équipe saura quelles étapes prendre pour contenir et examiner rapidement les incidents de sécurité les plus probables.

• Exemples de recommandations en matière de preuves : vous devez fournir des preuves qui démontrent que la formation a été effectuée avec le partage du contenu de la formation, et des enregistrements montrant qui y a participé (ce qui doit inclure toute l’équipe de réponse aux incidents). Sinon, ou également, des enregistrements montrant qu’un exercice de table a été effectué. Tout cela doit avoir été effectué dans un délai de 12 mois à compter du moment où la preuve est soumise.

• Exemple de preuve : Contoso a effectué un exercice de table de réponse aux incidents à l’aide d’une société de sécurité externe appelée Claranet Cyber Security. Vous trouverez ci-dessous un exemple du rapport généré dans le cadre de la société de conseil.

Note: Le rapport complet doit être partagé. Cet exercice peut également être effectué en interne, car il n’existe aucune exigence Microsoft 365 pour que cela soit effectué par une société tierce.

Contrôle 76 : Fournissez des preuves démontrables pour montrer que la sécurité IRP est mise à jour en fonction des leçons apprises ou des changements organisationnels.

• Intention : Au fil du temps, le plan de réponse aux incidents (IRP) doit évoluer en fonction des changements organisationnels ou des leçons apprises lors de la mise en œuvre du IRP. Les modifications apportées à l’environnement d’exploitation peuvent nécessiter des modifications de l’IRP, car les menaces peuvent changer ou les exigences réglementaires peuvent changer. En outre, au fur et à mesure que des exercices de table et des réponses réelles aux incidents de sécurité sont effectués, cela peut souvent identifier les domaines de l’IRP qui peuvent être améliorés. Cela doit être intégré dans le plan et l’objectif de ce contrôle est de s’assurer que ce processus est inclus dans le PROCESSUS.

• Exemples de recommandations en matière de preuves : cela sera souvent démontré en examinant les résultats des incidents de sécurité ou des exercices de table où les leçons apprises ont été identifiées et ont été générées dans une mise à jour du IRP. L’IRP doit tenir à jour un journal des modifications, qui doit également référencer les modifications implémentées en fonction des leçons apprises ou des changements organisationnels.

• Exemple de preuve : les captures d’écran suivantes proviennent de l’IRP fourni, qui inclut une section sur la mise à jour de l’IRP en fonction des leçons apprises et/ou des modifications organization.

Le journal des modifications IRP indique une mise à jour effectuée au dos de l’exercice de table effectué en juillet 2021.

Domaine de sécurité : Sécurité et confidentialité de la gestion des données

Ce domaine de sécurité est inclus pour garantir que toutes les données consommées à partir de Microsoft 365 sont correctement protégées en transit et au repos. Ce domaine garantit également que les problèmes de confidentialité des consommateurs (personnes concernées par les données) sont satisfaits par l’éditeur de logiciels indépendants, conformément au Règlement général sur la protection des données (RGPD) qui concerne la confidentialité des citoyens de l’UE.

Données en transit

En raison des exigences de connectivité des applications/compléments développés par Microsoft 365, la communication s’effectuera sur des réseaux publics, à savoir Internet. Pour cette raison, les données en transit doivent être correctement protégées. Cette section traite de la protection des communications de données sur Internet.

Contrôle 1 : fournir des preuves démontrables que la configuration TLS répond ou dépasse les exigences de chiffrement dans les exigences de configuration du profil TLS.

• Intention : l’objectif de ce contrôle est de s’assurer que les données Microsoft 365 consommées par votre organization sont transmises en toute sécurité. La configuration du profil TLS définit des exigences spécifiques à TLS pour vous assurer que le trafic est sécurisé contre les attaques de l’intercepteur.

• Exemples de recommandations en matière de preuve : le moyen le plus simple d’en faire la preuve consiste à exécuter l’outil de test qualys SSL Server sur TOUS les écouteurs web, y compris ceux qui s’exécutent sur des ports non standard.

• N’oubliez pas de cocher l’option « Ne pas afficher les résultats sur les tableaux », ce qui empêche l’AJOUT de l’URL au site web.

• Vous pouvez également fournir des preuves pour illustrer les vérifications individuelles dans les exigences de configuration du profil TLS. Les paramètres de configuration peuvent être utilisés, ainsi que des scripts et des outils logiciels pour fournir des preuves de certains paramètres spécifiques, c’est-à-dire que la compression TLS est désactivée.

• Exemple de preuve : la capture d’écran ci-dessous montre les résultats de l’écouteur web www.clara.net:443 .

Remarque : Les analystes de certification examinent la sortie complète pour confirmer que toutes les exigences de configuration du profil TLS sont remplies (veuillez fournir des captures d’écran de la sortie d’analyse complète). Depending_ sur _what preuve fournie, les analystes peuvent exécuter leur propre analyse Qualys.

• Exemple de preuve 2 : la capture d’écran suivante montre que TLS 1.2 est configuré sur le stockage.

Note: Cette capture d’écran seule ne serait pas en mesure de répondre à cette exigence.

• Exemple de preuve 3 : les captures d’écran suivantes montrent que TLS V1.3 est activé uniquement sur le serveur.

Cet exemple utilise les clés de Registre pour désactiver ou activer un protocole en ajustant les valeurs comme suit :

Binaire : 0 - off 1 - on

Hexadécimal : 0x00000000 - désactivé 0xffffffff - activé

Remarque : - N’utilisez pas cette méthodologie si vous ne la comprenez pas, car nous (Microsoft) ne sommes pas responsables de l’utilisation ou du suivi de cet exemple, ni des effets que son utilisation peut avoir sur vos systèmes. Il s’agit simplement d’illustrer une autre façon de montrer si TLS est activé ou désactivé.

Remarque : ces captures d’écran seules ne pourraient pas répondre à cette exigence.

Contrôle 2 : fournir une preuve démontrable que la compression TLS est désactivée sur tous les services publics qui gèrent les requêtes web.

• Intention : il existe une vulnérabilité TLS spécifique, CRIME (CVE-2012-4929), qui affecte la compression TLS. Pour cette raison, les recommandations du secteur sont de désactiver cette fonctionnalité.

• Exemples de recommandations en matière de preuve : il peut s’agir d’une preuve via l’outil Qualys SSL Labs.

• Exemple de preuve : la capture d’écran suivante le montre via l’outil Qualys SSL Labs.

Contrôle 3 : fournissez des preuves démontrables que la sécurité de transport HTTP stricte tls est activée et configurée sur >= 15552000 sur tous les sites.

• Intention : Http Strict Transport Security (HSTS) est un mécanisme de sécurité conçu pour protéger les sites web contre les attaques de l’intercepteur en forçant les connexions TLS via un champ d’en-tête de réponse HTTPS nommé « Strict-Transport-Security ».

• Exemples de recommandations en matière de preuves : il peut s’agir d’une preuve via l’outil Qualys SSL Labs ou d’autres outils et compléments de navigateur web.

• Exemple de preuve : la capture d’écran suivante le montre via un complément de navigateur web appelé « HTTP Header Spy » pour le site web www.microsoft.com .

Données au repos

Lorsque les données consommées à partir de la plateforme Microsoft 365 sont stockées par les éditeurs de logiciels indépendants, les données doivent être correctement protégées. Cette section décrit les exigences de protection des données stockées dans les bases de données et les magasins de fichiers.

Contrôle 4 : fournir des preuves démontrables que les données au repos sont chiffrées en ligne avec les exigences du profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que AES, Blowfish, TDES et des tailles de clé de chiffrement de 128 bits et 256 bits.

• Intention : certains algorithmes de chiffrement plus anciens sont connus pour contenir certaines faiblesses de chiffrement, ce qui augmente les chances qu’un groupe d’activités puisse déchiffrer les données sans connaître la clé. Pour cette raison, l’objectif de ce contrôle est de garantir que seuls les algorithmes de chiffrement acceptés par le secteur sont utilisés pour protéger les données Microsoft 365 stockées.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies par le biais de captures d’écran, montrant le chiffrement utilisé pour protéger les données Microsoft 365 dans les bases de données et d’autres emplacements de stockage. La preuve doit démontrer que la configuration du chiffrement est conforme aux exigences de configuration du profil de chiffrement de la certification Microsoft 365.

• Exemple de preuve : la capture d’écran suivante montre que TDE (Transparent Data Encryption) est activé sur la base de données Contoso. La deuxième capture d’écran montre la page de documentation Microsoft « Transparent data encryption for SQL Database, SQL Managed Instance, and Azure Synapse Analytics » montrant que le chiffrement AES 256 est utilisé pour Azure TDE.

• Exemple de preuve 2 : la capture d’écran suivante montre le stockage Azure configuré avec le chiffrement pour les objets blob et les fichiers. La capture d’écran suivante montre la page Microsoft Docs « Chiffrement du stockage Azure pour les données au repos » montrant que stockage Azure utilise AES-256 pour le chiffrement.

Contrôle 5 : fournir des preuves démontrables que la fonction de hachage ou l’authentification de message (HMAC-SHA1) est utilisée uniquement pour protéger les données au repos avec les exigences de profil de chiffrement.

• Intention : comme avec les algorithmes de chiffrement, certaines fonctions de hachage et algorithmes d’authentification de message sont basés sur des algorithmes présentant des faiblesses de chiffrement. L’objectif de ce contrôle est de s’assurer que les données Microsoft 365 sont protégées par des fonctions de hachage fortes si le hachage est utilisé comme mécanisme de protection des données. Si cela n’est pas utilisé par l’environnement et/ou l’application, des preuves doivent être fournies pour corroborer cela.

• Exemple d’instructions de preuve : les preuves peuvent se présenter sous la forme de captures d’écran montrant des extraits de code dans lesquels la fonction de hachage fonctionne.

• Exemple de preuve : Contoso utilise la fonctionnalité de hachage au sein de son application. La capture d’écran ci-dessous montre que SHA256 est utilisé dans le cadre de la fonction de hachage.

Contrôle 6 : Fournissez un inventaire de toutes les données stockées, y compris l’emplacement de stockage et le chiffrement utilisés pour protéger les données.

• Intention : pour protéger correctement les données, les organisations doivent savoir quelles données leur environnement/systèmes consomment et où les données sont stockées. Une fois que cela est entièrement compris et documenté, les organisations sont en mesure non seulement d’implémenter une protection des données adéquate, mais également de consolider l’emplacement des données pour implémenter la protection plus efficacement. En outre, lorsque les données sont consolidées dans le moins d’emplacements possible, il est plus facile d’implémenter un contrôle d’accès en fonction du rôle (contrôle d’accès en fonction du rôle) approprié pour limiter l’accès à aussi peu d’employés que nécessaire.

• Exemple de recommandations en matière de preuves : les preuves doivent être fournies par le biais d’un document ou d’une exportation à partir d’un système interne, c’est-à-dire SharePoint ou Confluence, détaillant toutes les données consommées, tous les emplacements de stockage et le niveau de chiffrement implémenté.

• Exemple de preuve : la capture d’écran suivante montre un exemple de ce à quoi peut ressembler un document montrant des types de données.

Conservation et suppression de données

Lorsque les éditeurs de logiciels indépendants consomment et stockent des données Microsoft 365, cela risque de compromettre les données si un groupe d’activités compromet l’environnement des éditeurs de logiciels indépendants. Pour réduire ce risque, les organisations doivent conserver uniquement les données dont elles ont besoin pour fournir des services et non des données qui « pourraient » être utilisées à l’avenir. En outre, les données ne doivent être conservées que le temps nécessaire pour fournir les services pour 20000. La conservation des données doit être définie et communiquée aux utilisateurs. Une fois que les données dépassent la période de rétention définie, elles doivent être supprimées de manière sécurisée afin qu’elles ne puissent pas être reconstruites ou récupérées.

Contrôle 7 : fournir des preuves démontrables qu’une période de conservation des données approuvée et documentée est formellement établie.

• Intention : Une politique de conservation documentée et suivie est importante non seulement pour respecter certaines obligations légales, par exemple la législation sur la confidentialité des données, comme, mais sans s’y limiter, le Règlement général sur la protection des données (RGPD de l’UE) et la Loi sur la protection des données (DPA du Royaume-Uni 2018), mais également pour limiter les risques des organisations. En comprenant les exigences en matière de données des organisations et la durée pendant laquelle les données sont nécessaires pour que l’entreprise puisse remplir ses fonctions, les organisations peuvent s’assurer que les données sont correctement supprimées une fois leur utilité expirée. En réduisant les volumes de données stockées, les organisations réduisent la quantité de données qui seraient exposées en cas de compromission des données. Cela limitera l’impact global.

• Souvent, les organisations stockent des données simplement parce qu’il est « agréable d’avoir juste au cas où », toutefois, si le organization n’a pas besoin des données pour effectuer son service ou sa fonction métier, les données ne doivent pas être stockées, car cela augmente inutilement les risques de l’organisation.

• Exemple de recommandations en matière de preuves : fournissez la stratégie de conservation complète des données qui détaille clairement la durée pendant laquelle les données (qui doivent couvrir tous les types de données) doivent être conservées pour permettre à l’entreprise d’exécuter ses fonctions métier.

• Exemple de preuve : la capture d’écran ci-dessous montre la stratégie de rétention des données de Contoso.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 8 : fournir une preuve démontrable que les données conservées correspondent à la période de rétention définie.

• Intention : l’objectif de ce contrôle est simplement de valider que les périodes de conservation des données définies sont respectées. Comme nous l’avons déjà vu, les organisations peuvent avoir l’obligation légale de s’y conformer, mais également en conservant les données nécessaires et aussi longtemps que nécessaire permet de réduire le risque pour le organization en cas de violation de données.

• Exemples de recommandations en matière de preuves : fournissez une preuve de capture d’écran (ou via un partage d’écran) montrant que les données stockées (dans tous les différents emplacements de données, c’est-à-dire les bases de données, les partages de fichiers, les archives, etc.) ne dépassent pas la stratégie de conservation des données définie. Il peut s’agir, par exemple, de captures d’écran d’enregistrements de base de données avec un champ de date, de recherches effectuées dans l’ordre d’enregistrement le plus ancien et/ou d’emplacements de stockage de fichiers montrant les horodatages qui se trouvent dans la période de rétention.

Note: Toutes les données client personnelles/sensibles doivent être expurgées dans la capture d’écran.

• Exemple de preuve : la preuve suivante montre une requête SQL montrant le contenu de la table de base de données classées par ordre croissant sur le champ « DATE_TRANSACTION » pour afficher les enregistrements les plus anciens dans la base de données. Les données doivent être datant de deux mois, ce qui ne dépasse pas la période de rétention définie.

Note: Il s’agit d’une base de données de test. Par conséquent, il n’y a pas beaucoup de données historiques.

Contrôle 9 : Fournir des preuves démontrables que des processus sont en place pour supprimer les données en toute sécurité après leur période de conservation.

• Intention : l’objectif de ce contrôle est de s’assurer que le mécanisme utilisé pour supprimer les données qui dépassent la période de rétention le fait de manière sécurisée. Les données supprimées peuvent parfois être récupérées ; Par conséquent, le processus de suppression doit être suffisamment robuste pour garantir que les données ne peuvent pas être récupérées une fois supprimées.

• Exemple d’instructions de preuve : si le processus de suppression est effectué par programmation, fournissez une capture d’écran du script utilisé pour effectuer cette opération. S’il est exécuté selon une planification, fournissez une capture d’écran montrant la planification. Par exemple, un script pour supprimer des fichiers au sein d’un partage de fichiers peut être configuré en tant que travail CRON. Capture d’écran du travail CRON montrant la planification et le script qui sont exécutés et fournissez le script montrant la commande utilisée.

• Exemple de preuve 1 : Il s’agit d’un script simple qui peut être utilisé pour supprimer tous les enregistrements de données conservés en fonction de la date -WHERE DateAdd est -30 jours, ce qui vide tous les enregistrements conservés antérieurs à 30 jours après la date de conservation des données sélectionnée. Notez que nous aurons besoin du script, mais également de la preuve de l’exécution du travail et des résultats.

• Exemple de preuve 2 : Les éléments ci-dessous ont été extraits du plan de rétention des données Contoso dans le contrôle 7 : cela montre les procédures utilisées pour la destruction des données.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

• Exemple de preuve 3 : Dans cet exemple, un Runbook a été créé et une planification correspondante dans Azure pour supprimer en toute sécurité les enregistrements dont la date de fin a été créée à partir des 30 jours suivant l’expiration de la stratégie de conservation des enregistrements de données. Ce travail est défini pour s’exécuter tous les mois le dernier jour du mois.

La fenêtre ci-dessous montre que le runbook a été modifié pour rechercher des enregistrements et que les commandes de suppression ne sont pas visibles comme le script. Notez que l’URL et le nom d’utilisateur complets doivent être affichés pour ces captures d’écran et que les éditeurs de logiciels indépendants doivent afficher une capture d’écran du nombre d’enregistrements avant suppression et une capture d’écran du nombre d’enregistrements après suppression. Ces captures d’écran ne sont que des exemples des différentes façons d’aborder cette approche.

Gestion de l’accès aux données

L’accès aux données doit être limité à aussi peu de personnes que nécessaire pour réduire les risques de compromission malveillante ou accidentelle des données. L’accès aux données et aux clés de chiffrement doit être limité aux utilisateurs ayant un besoin métier légitime d’accès pour remplir leur rôle de travail. Cela doit être bien documenté et un processus bien établi pour demander l’accès doit être implémenté. L’accès aux données et aux clés de chiffrement doit suivre le principe du moindre privilège.

Contrôle 10:P roviser une liste de toutes les personnes ayant accès aux données ou aux clés de chiffrement, y compris la justification métier.

• Intention : les organisations doivent limiter l’accès aux données et aux clés de chiffrement au moins d’employés possible. L’objectif de ce contrôle est de garantir que l’accès des employés aux données et/ou aux clés de chiffrement est limité aux employés qui ont clairement besoin d’un tel accès.

• Exemple de recommandations en matière de preuves : documentation ou captures d’écran de systèmes internes qui documentent tous les employés ayant accès aux données et/ou aux clés de chiffrement, ainsi que la justification métier de la raison pour laquelle ces personnes doivent avoir accès. Cette liste sera utilisée par l’analyste de certification pour échantillonner les utilisateurs pour les contrôles suivants.

• Exemple de preuve : le document suivant montre la liste documentée des utilisateurs ayant accès aux données et la justification métier.

Contrôle 11 : fournir des preuves démontrables que les personnes échantillonnées qui ont accès aux données ou aux clés de chiffrement ont été officiellement approuvées, en détaillant les privilèges requis pour leur fonction de travail.

• Intention : le processus d’octroi de l’accès aux données et/ou aux clés de chiffrement doit inclure une approbation, garantissant que l’accès d’une personne est requis pour sa fonction de travail. Cela garantit que les employés dépourvus d’une véritable raison d’accès ne reçoivent pas d’accès inutile.

• Exemples de recommandations en matière de preuves : en règle générale, la preuve fournie pour le contrôle précédent peut aider à prendre en charge ce contrôle. S’il n’y a pas d’approbation formelle sur la documentation fournie, la preuve peut consister en une demande de modification déclenchée et approuvée pour l’accès au sein d’un outil tel qu’Azure DevOps ou Jira.

• Exemple de preuve : cet ensemble d’images montre Jira Tickets créés et approuvés pour la liste ci-dessus dans le contrôle 10 pour accorder ou refuser l’accès aux données sensibles et/ou aux clés de chiffrement.

Cette image montre qu’une demande a été créée dans Jira pour obtenir l’approbation quotidienne de Sam pour les clés de chiffrement sur l’environnement principal des systèmes. Cette opération est effectuée à l’étape suivante pour contrôler les points 10 ci-dessus où l’autorisation écrite a été obtenue.

Cela montre que la demande d’accorder à Sam l’accès quotidien a été approuvée par Jon Smith une personne de la direction qui peut être vu dans le contrôle 10. (Notez que l’approbation doit provenir d’une personne disposant d’une autorité suffisante pour autoriser la demande de modification. Il ne peut pas s’agir d’un autre développeur).

Le ci-dessus montre un flux de travail dans Jira pour ce processus, notez que rien ne peut être ajouté comme Terminé, sauf s’il a été passé par le processus d’approbation qui est automatisé, par conséquent, ne peut pas être passé.

Le tableau de projet ci-dessus montre maintenant qu’une approbation a été donnée pour l’accès de Sam Daily aux clés de chiffrement. Sous le backlog, vous trouverez l’approbation de la demande de Sam Daily et la personne affectée pour effectuer le travail.

Pour répondre aux exigences de ce contrôle, vous devez afficher toutes ces captures d’écran ou similaires avec une explication montrant que vous avez satisfait aux exigences du contrôle.

• Exemple de preuve 2 : Dans l’exemple ci-dessous, l’accès administrateur et les autorisations de contrôle total ont été demandés pour un utilisateur à la base de données de production. La demande a été envoyée pour approbation, comme vous pouvez le voir à droite de l’image, et elle a été approuvée comme vous pouvez le voir sur la gauche.

Ci-dessus, vous pouvez voir que l’accès a été approuvé et validé comme terminé.

Contrôle 12 : fournissez des preuves démontrables que les personnes échantillonnées qui ont accès aux données ou aux clés de chiffrement disposent uniquement des privilèges inclus dans l’approbation.

• Intention : l’objectif de ce contrôle est de confirmer que l’accès aux données et/ou à la clé de chiffrement est configuré conformément aux documents.

• Exemple de recommandations en matière de preuves : les preuves peuvent être fournies par le biais d’une capture d’écran montrant les privilèges d’accès aux données et/ou à la clé de chiffrement accordés aux personnes échantillonnées. Les preuves doivent couvrir tous les emplacements de données.

• Exemple de preuve : cette capture d’écran montre les autorisations accordées à l’utilisateur « John Smith » qui seraient croisées avec la demande d’approbation pour ce même utilisateur, conformément aux preuves du contrôle précédent.

Contrôle 13 : fournissez une liste de tous les tiers avec qui les données client sont partagées.

• Intention : lorsque des tiers sont utilisés pour le stockage ou le traitement des données Microsoft 365, ces entités peuvent présenter un risque important. Les organisations doivent développer un bon processus de vérification et de gestion de tiers pour s’assurer que ces tiers stockent/traitent les données de manière sécurisée et qu’ils respectent toutes les obligations légales qu’elles peuvent avoir, par exemple en tant que sous-traitant de données en vertu du RGPD.

• Les organisations doivent tenir à jour une liste de tous les tiers avec lesquels elles partagent des données avec tout ou partie des éléments suivants :

• quel(s) service(s) est(sont) fournis,

• quelles données sont partagées,

• pourquoi les données sont partagées,

• informations de contact clés (c’est-à-dire, contact principal, contact de notification de violation, DPO, etc.),

• renouvellement/expiration du contrat

• obligations légales/de conformité (c’est-à-dire, RGPD, HIPPA, PCI DSS, FedRamp, etc.)

• Exemples de recommandations en matière de preuves : fournissez une documentation détaillant toutes les parties tierces avec lesquelles les données Microsoft 365 sont partagées.

Note: Si des tiers ne sont pas utilisés, cela doit être confirmé par écrit (e-mail) par un membre de l’équipe de direction.

• Exemple de preuve 1

• Exemple de preuve 2 : cette capture d’écran montre un exemple d’e-mail d’un membre de l’équipe de direction confirmant qu’aucun tiers n’est utilisé pour traiter les données Microsoft 365.

Contrôle 14 : fournir des preuves démontrables que tous les tiers qui consomment des données client ont des accords de partage en place.

• Intention : Lorsque les données Microsoft 365 sont partagées avec des tiers, il est important que les données soient gérées de manière appropriée et sécurisée. Des accords de partage de données doivent être en place pour s’assurer que les tiers traitent les données uniquement en fonction des besoins et qu’ils comprennent leurs obligations en matière de sécurité. La sécurité d’une organisation est aussi forte que le lien le plus faible. L’objectif de ce contrôle est de s’assurer que les tiers ne deviennent pas un lien faible d’organisation.

• Exemple de recommandations en matière de preuves : partagez les accords de partage de données en place avec les tiers.

• Exemple de preuve : la capture d’écran suivante montre un exemple simpliste d’accord de partage de données.

Note: L’accord complet doit être partagé et non une capture d’écran.

RGPD

La plupart des organisations traiteront des données potentiellement des données de citoyens européens (personnes concernées). Lorsque les données d’une personne concernée sont traitées, les organisations devront respecter le Règlement général sur la protection des données (RGPD). Cela s’applique aux contrôleurs de données (vous capturez directement ces données) ou aux processeurs de données (vous traitez ces données pour le compte d’un contrôleur de données). Bien que cette section ne couvre pas l’ensemble du règlement, elle traite de certains des éléments clés du RGPD pour vous aider à obtenir l’assurance que le organization prend le RGPD au sérieux.

Contrôle 15 : Fournissez un processus de demande d’accès au sujet (SAR) documenté et fournissez des preuves démontrant que les personnes concernées sont en mesure d’émettre des demandes d’accès aux données.

• Intention : le RGPD inclut des obligations spécifiques qui doivent être respectées par les organisations qui traitent les données des personnes concernées. L’obligation pour les organisations de gérer les demandes d’accès des personnes concernées (RAC) est incluse dans l’article 12 qui, en vertu de l’article 12.3, donne au responsable du traitement des données un mois à compter de la réception du SAR pour répondre à la demande. Une prolongation est autorisée pour une période supplémentaire de deux mois si nécessaire. Même si votre organization agit en tant que processeur de données, cela sera toujours nécessaire pour aider vos clients (le contrôleur de données) à remplir leurs obligations en matière de SAP.

• Exemples de recommandations en matière de preuves : fournissez le processus documenté pour la gestion des DEMANDES de signature d’accès partagé.

• Exemple de preuve : l’exemple suivant montre un processus documenté pour la gestion des demandes d’accès partagé.

Note: Cette capture d’écran montre un document de stratégie/processus. L’objectif est que les éditeurs de logiciels indépendants partagent la documentation réelle sur la stratégie/procédure de prise en charge et ne fournissent pas simplement une capture d’écran.

Contrôle 16 : fournissez des preuves démontrables que vous êtes en mesure d’identifier tous les emplacements des données des personnes concernées lors de la réponse à un SAR.

• Intention : l’objectif de ce contrôle est de s’assurer que le organization dispose d’un mécanisme robuste pour identifier les données de toutes les personnes concernées. Il peut s’agir d’un processus manuel, car tout le stockage des données est bien documenté, ou d’autres outils peuvent être utilisés pour garantir que toutes les données sont localisées dans le cadre du processus des SAP.

• Exemples de recommandations en matière de preuves : les preuves peuvent être fournies par le biais d’une liste de tous les emplacements de données et d’un processus documenté pour rechercher des données dans tous les emplacements de données. Cela inclut toutes les commandes nécessaires pour rechercher des données, c’est-à-dire que si des emplacements SQL sont inclus, des instructions SQL spécifiques sont détaillées pour garantir que les données sont trouvées correctement.

• Exemple de preuve : la capture d’écran suivante est un extrait de la procédure sar ci-dessus qui montre comment les données seront trouvées.

Les quatre images ci-dessous montrent comment les emplacements des données ISV où ont été interrogées, puis l’Explorateur Stockage ont utilisé pour explorer les fichiers ou les objets blob qui devaient être supprimés du stockage pour se conformer à la demande DE SAP.

Cette requête confirme les comptes de stockage en cours d’utilisation. Vous pouvez interroger et supprimer du stockage, des objets blob et/ou des fichiers à l’aide de Resource Graph Explorer (Kusto) ou de PowerShell (voir ci-dessous).

L’image ci-dessus montre les données qui ont été trouvées dans le conteneur d’objets blob pour le client qui doit être supprimé et ci-dessous montre l’action pour supprimer ou supprimer de manière réversible les informations dans l’objet blob.

Contrôle 17 : Fournissez un lien vers l’avis de confidentialité qui doit contenir tous les éléments requis comme suit :

• Détails de l’entreprise (nom, adresse, etc.).

• Détaille les types de données personnelles en cours de traitement.

• Détaille la licéité du traitement des données personnelles.

• Détaille les droits de la personne concernée :

  • Droit d’être informé,
  • Droit d’accès par la personne concernée,
  • Droit à l’effacement,
  • Droit à la restriction du traitement,
  • Droit à la portabilité des données,
  • Droit à l’objet,
  • Droits relatifs à la prise de décision automatisée, y compris le profilage.

• Détails de la durée pendant laquelle les données personnelles seront conservées.

• Intention : l’article 13 du RGPD inclut des informations spécifiques qui doivent être fournies aux personnes concernées au moment de l’obtention des données personnelles. L’objectif de ce contrôle est de s’assurer que la déclaration de confidentialité des données des organisations fournit aux personnes concernées certaines des informations clés incluses dans l’article 13.

• Exemples de recommandations en matière de preuves : elles sont généralement fournies en fournissant l’avis de confidentialité des données. Les analystes de certification examineront ce point pour s’assurer que toutes les informations fournies dans le contrôle sont incluses dans l’avis de confidentialité des données.

• Exemple de preuve

Les images d’un avis de confidentialité ci-dessus et adjacent montrent un exemple de politique de confidentialité en ligne avec l’article 13 du RGPD inclus.

Vous trouverez ci-dessous une politique de protection des données qui peut être utilisée conjointement avec la déclaration de confidentialité indiquée précédemment.

L’image ci-dessus d’Azure montre comment Azure a été configuré pour répondre aux exigences de conformité du RGPD pour les données stockées dans un environnement back-end. La stratégie (qui peut être personnalisée ou générée à partir d’Azure Blueprints) permet à l’éditeur de logiciels indépendant de s’assurer que les données du client sont stockées correctement et qu’elles sont accessibles uniquement par les métriques et alertes définies pour garantir la conformité et affichent les données non conformes ou l’accès utilisateur sur le tableau de bord du Gestionnaire de conformité.

Livres

Murdoch D. (2018) Blue Team Handbook : Incident Response Edition : A condensed field guide for the Cyber Security Incident Responseer. 2e édition, Éditeur : CreateSpace Independent Publishing Platform.

References

• Signalement de cyberdéfense sur action fraud Disponible à l’adresse : https://www.actionfraud.police.uk/ (Consulté le 02/08/21).
• UE. (2021) Liste de contrôle RGPD pour les contrôleurs de données Disponible à l’adresse : https://gdpr.eu/checklist/ (Accessible le 21/01/01).
• Microsoft. (2018) Journalisation des événements (Windows Installer) Disponible à l’adresse : Journalisation des événements (Windows Installer) (accessible : 23/12/20).
• Technologies positives. (2020) Guide pratique pour aborder le développement logiciel sécurisé Disponible à l’adresse : https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessible : 21/12/20).
• Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (Règlement général sur la protection des données) (Texte présentant de l’intérêt pour l’EEE) (2016) Disponible à l’adresse : https://www.legislation.gov.uk/eur/2016/679/contents (Consulté : 11/01/2021).
• Métriques de sécurité. (2020) Guide des métriques de sécurité pour la conformité PCI DSS. Disponible à l’adresse : https://info.securitymetrics.com/pci-guide-2020(Accessible : 06/01/21).
• Williams J. OWASP Risk Ranking Disponible à l’adresse : https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Consulté : 08/12/20).
• Qualys. (2014) Ssl Labs : New Grades for Trust (T) and Mismatch (M) Issues disponibles à : https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Consulté : 29/01/21).
• NIST SP800-61r2 : Guide de gestion des incidents de sécurité informatique disponible à l’adresse :https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (accessible le 24/01/21).

Images extraites de Documents Microsoft

• https://www.sans.org/information-security-policy/(Consulté le 21/02/18). dans Obtenir l’analyse comportementale et la détection des anomalies (accessible le 21/02/16). dans Que sont les alertes Azure Monitor ? (accessible le 21/02/17). dans Obtenir l’analyse comportementale et la détection des anomalies (accessible le 22/02/21). dans Gérer et répondre aux alertes de sécurité dans Microsoft Defender pour le cloud (accessible le 24/02/21). dans Gérer et répondre aux alertes de sécurité dans Microsoft Defender pour le cloud (accessible le 24/02/21).
• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.htmldans Qu’est-ce qu’Azure Information Protection ? dans Chiffrement transparent des données pour SQL Database, SQL Managed Instance et Azure Synapse Analytics dans Démarrage rapide : Créer une affectation de stratégie pour identifier les ressources non conformes dans Configurer avancé Protection contre les menaces pour Azure SQL Database