Guide de soumission de certification Microsoft 365

Dans cet article

• Introduction
• Conditions préalables
• Spécification de certification Microsoft 365 Mises à jour
• Étendue de la certification
• Processus de certification
• Envoi initial du document
• Activités de collecte et d’évaluation des preuves
• Critères de certification
• Sécurité des applications
• Sécurité opérationnelle
• Sécurité et confidentialité de la gestion des données
• Révision facultative des frameworks de conformité externe
• Annexe A
• Annexe B
• Annexe C
• Annexe D
• Annexe E
• Annexe F
• Annexe G
• En savoir plus
• Glossaire

Introduction

Dans le cadre du programme de conformité des applications Microsoft 365, la certification Microsoft 365 offre aux organisations d’entreprise l’assurance et la confiance que les données et la confidentialité sont correctement sécurisées et protégées lors de l’intégration d’applications/compléments de développement tiers dans la plateforme Microsoft 365. Les applications et les compléments qui réussissent la validation seront désignés microsoft 365 Certified dans l’écosystème Microsoft 365.

En participant au programme de certification Microsoft 365, vous acceptez ces conditions supplémentaires et vous conformez à toute documentation connexe qui s’applique à votre participation au programme de certification Microsoft 365 avec Microsoft Corporation (« Microsoft », « nous », « nous » ou « notre »). Vous déclarez et garantissez que vous avez le pouvoir d’accepter ces conditions supplémentaires de la certification Microsoft 365 au nom de vous-même, d’une société et/ou d’une autre entité, le cas échéant. Nous pouvons modifier, modifier ou mettre fin à ces conditions supplémentaires à tout moment. Votre participation continue au programme de certification Microsoft 365 après toute modification ou modification signifie que vous acceptez les nouvelles conditions supplémentaires. Si vous n’acceptez pas les nouvelles conditions supplémentaires ou si nous mettons fin à ces conditions supplémentaires, vous devez cesser de participer au programme de certification Microsoft 365.

Ce document s’adresse aux éditeurs de logiciels indépendants pour fournir des informations sur le processus de certification Microsoft 365, les conditions préalables au démarrage du processus et les détails des contrôles de sécurité spécifiques que les éditeurs de logiciels indépendants doivent mettre en place. Vous trouverez des informations générales sur le programme De conformité des applications Microsoft 365 dans la page du programme De conformité des applications Microsoft 365.

Importante

Actuellement, la certification Microsoft 365 s’applique à tous :

• Applications Microsoft Teams (onglets, bots, etc.) .
• Applications/compléments Sharepoint
• Compléments Office (Word, Excel, PowerPoint, Outlook, Project, OneNote)
• Webapps

Configuration requise

Attestation de l’éditeur

Avant de recevoir le processus de certification Microsoft 365, vous devez avoir effectué l’attestation publisher. Toutefois, vous pouvez démarrer le processus de certification Microsoft 365 avant de terminer l’attestation publisher.

Lire la spécification de certification Microsoft 365

Microsoft recommande à tous les éditeurs de logiciels indépendants de lire cette spécification de certification Microsoft 365 dans son intégralité pour s’assurer que tous les contrôles applicables sont respectés par l’environnement dans l’étendue et l’application/complément. Cela permet de garantir un processus d’évaluation sans heurts.

Spécification de certification Microsoft 365 Mises à jour

Mises à jour à la spécification de la certification Microsoft 365 sont prévues environ tous les six à 12 mois. Ces mises à jour peuvent introduire de nouveaux domaines de sécurité cibles et/ou contrôles de sécurité. Mises à jour sera basé sur les commentaires des développeurs, les modifications apportées au paysage des menaces et pour augmenter la base de référence de sécurité du programme à mesure qu’il mûrit.

Les éditeurs de logiciels indépendants qui ont déjà démarré l’évaluation de la certification Microsoft 365 peuvent poursuivre l’évaluation avec la version de la spécification de certification Microsoft 365 qui était valide au démarrage de l’évaluation. Toutes les nouvelles soumissions, y compris la recertification annuelle, devront être évaluées par rapport à la version publiée.

Remarque

Vous n’êtes pas obligé de vous conformer à tous les contrôles de cette spécification de certification Microsoft 365 pour obtenir une certification. Toutefois, des seuils de passage (qui ne seront pas divulgués) sont en place pour chacun des domaines de sécurité abordés dans cette Spécification de certification Microsoft 365. Certains contrôles seront classés comme « Échec dur », ce qui signifie que l’absence de ces contrôles de sécurité entraînera l’échec de l’évaluation.

Étendue de la certification

L’environnement dans l’étendue est l’environnement qui prend en charge la remise du code d’application/complément et prend en charge tous les systèmes back-end avec ants avec ants que l’application/complément peut communiquer. Tous les environnements connectés supplémentaires seront également inclus dans l’étendue, sauf si une segmentation adéquate est en place ET que les environnements connectés ne peuvent pas avoir d’impact sur la sécurité de l’environnement dans l’étendue. Tous les environnements de récupération d’urgence devront également être inclus dans l’étendue de l’évaluation, car ces environnements seraient nécessaires pour remplir le service en cas de problème avec l’environnement principal. Le terme composants système dans l’étendue fait référence à TOUS les appareils et systèmes utilisés dans l’environnement dans l’étendue. Les composants dans l’étendue incluent, mais ne sont pas limités à :

• La ou les applications web.
• Serveurs.
• Pare-feu (ou équivalent).
• Commutateurs.
• Équilibreurs de charge.
• Infrastructure virtuelle.
• Portails de gestion web des fournisseurs de cloud

Importante

L’environnement dans l’étendue doit avoir une zone DMZ et l’environnement de prise en charge de l’application/du complément doit être segmenté à partir des systèmes d’entreprise internes et des environnements d’entreprise, ce qui limite l’étendue des activités d’évaluation aux systèmes dans l’étendue uniquement. Les analystes de certification valideront les techniques de segmentation pendant l’évaluation, ainsi que l’examen des rapports de tests d’intrusion qui auraient dû inclure des tests pour valider l’efficacité des techniques de segmentation utilisées.

Infrastructure as a Service (IaaS), PaaS (Platform as a Service) et Software as a Service (SaaS)

Lorsque IaaS et/ou PaaS sont utilisés pour prendre en charge l’infrastructure de l’application ou de la remise de code de complément en cours d’examen, le fournisseur de plateforme cloud est responsable de certains contrôles de sécurité évalués tout au long du processus de certification. Par conséquent, les analystes de certification devront disposer d’une vérification externe indépendante des bonnes pratiques de sécurité par le fournisseur de plateforme cloud via des rapports de conformité externes tels que [PCI DSS] Attestation of Compliance (AOC), ISO27001 ou [SOC 2] De type II.

L’annexe F fournit des détails sur les contrôles de sécurité qui seront probablement applicables en fonction des types de déploiement suivants et selon que l’application/le complément exfiltre ou non les données Microsoft 365 :

• Éditeur de logiciels indépendants hébergés
• IaaS hébergé
• PaaS/Serverless Hébergé
• Hybride hébergé
• Hébergé partagé

Là où IaaS ou PaaS est déployé, vous devez fournir la preuve que l’environnement est hébergé dans ces types de déploiement.

Échantillonnage

Les demandes de preuves à l’appui de l’évaluation de la certification doivent être basées sur un échantillon des composants système dans l’étendue en tenant compte des différents systèmes d’exploitation, de la fonction principale de l’appareil et des différents types d’appareils. Un échantillon approprié sera sélectionné au début du processus de certification. Le tableau suivant doit être utilisé comme guide sur la taille de l’échantillon :

Taille de la population	Échantillon
<5	1
>5 & <10	2
>9 & <25	3
>24	4

Remarque

Si des écarts sont identifiés entre les appareils inclus dans l’échantillon initial, la taille de l’échantillon peut être augmentée pendant l’évaluation.

Processus de certification

Avant de commencer le processus de certification, vous devez avoir effectué votre attestation de serveur de publication. Une fois terminé, votre processus de certification Microsoft 365 se poursuit comme suit :

Préparation

1. Accédez à l’Espace partenaires et passez en revue votre documentation d’attestation d’éditeur terminée. Si nécessaire, vous pouvez modifier et mettre à jour vos réponses. Toutefois, si vous le faites, vous devrez soumettre à nouveau votre documentation d’attestation pour approbation. Si votre soumission date de plus de trois mois, nous vous demanderons de soumettre à nouveau l’attestation de l’éditeur pour révision et validation.
2. Lisez attentivement le Guide de soumission de certification Microsoft 365 pour comprendre ce qui vous sera demandé. Assurez-vous que vous serez en mesure de répondre aux exigences de contrôle spécifiées dans le Guide de soumission de certification Microsoft 365.
3. Dans l’Espace partenaires, sélectionnez « Démarrer la certification ». Cela vous amènera à votre portail de soumission de document initial. Envoyez votre soumission de document initial. Cela nous aidera à déterminer ce qui est dans l’étendue de votre évaluation en fonction de la façon dont votre application est conçue et gère les données client. Consultez cette page fréquemment pour voir si votre soumission a été acceptée.

Remarque

Pour toutes les applications office, vous pouvez consulter notre Guide de l’utilisateur des applications Office. Pour toutes les applications web, vous pouvez référencer notre Guide de l’utilisateur de l’application SaaS.

Évaluation

1. Une fois que votre soumission initiale de document a été acceptée, l’ensemble des contrôles de sécurité requis pour votre application s’affiche automatiquement dans le portail. Vous devrez ensuite soumettre des preuves pour chaque contrôle montrant que le contrôle est en place. Gardez à l’esprit que vous aurez 60 jours pour soumettre toutes les preuves. Un analyste examinera votre preuve et approuvera le contrôle ou demandera des preuves nouvelles ou supplémentaires. Consultez fréquemment cette page pour voir si votre preuve a été acceptée.

Certification

1. Une fois que votre soumission a été validée par un analyste, vous êtes informé de votre décision de certification. Les applications certifiées recevront un badge sur leur application dans AppSource et les pages de documentation Microsoft . Vous pouvez en savoir plus sur les avantages complets de la certification ici.

Révision et recertification

Si votre application subit des modifications importantes à un moment donné, vous devrez nous en informer.

Vous devrez également passer par la recertification sur une base annuelle. Cela nécessite la revalidation des contrôles dans l’étendue par rapport à votre environnement actuel. Ce processus peut commencer jusqu’à 90 jours avant l’expiration de votre certification. Votre certification existante n’expirera pas pendant la période de recertification. La recertification de tous les programmes expire le jour du premier anniversaire de votre certification Microsoft 365.

Si votre certification n’est pas renouvelée avant la date d’expiration, vos status de certification d’applications sont révoquées. Toutes les marques de signalisation, d’icônes et de certification associées seront supprimées de votre application, et il vous sera interdit de faire de la publicité de votre application en tant que Microsoft 365 Certified.

Importante

Délai de soumission : On prévoit que le processus d’évaluation devrait prendre en moyenne 30 jours, à condition que vous soyez en mesure de case activée votre soumission status fréquemment et de répondre aux commentaires et aux demandes de preuve supplémentaires dans les délais impartis. Au début du processus de certification, un maximum de 60 jours est autorisé pour terminer l’évaluation. Si toutes les soumissions n’ont pas été effectuées dans le délai de 60 jours, la soumission sera émise en échec et le processus doit recommencer. Ces résultats ne seront pas rendus publics.

Envoi initial du document

La soumission initiale du document aidera les analystes de certification à définir la portée de votre évaluation. Après quoi vous devrez soumettre la documentation à l’appui et les preuves utilisées pour effectuer l’évaluation. Votre soumission initiale doit inclure les informations spécifiées ci-dessous. Pour obtenir des conseils supplémentaires, consultez le Guide de soumission de document initial.

Vue d’ensemble de la documentation	Détails de la documentation
Description de l’application/du complément	Description de l’objectif et des fonctionnalités de l’application/du complément. Cela doit fournir à l’analyste de certification une bonne compréhension du fonctionnement de l’application/complément et de son utilisation prévue
Rapport de test d’intrusion	Un rapport de test d’intrusion s’est terminé au cours des 12 derniers mois. Ce rapport doit inclure l’environnement qui prend en charge le déploiement de l’application/de l’ajout, ainsi que tout environnement supplémentaire qui prend en charge le fonctionnement de l’application/du complément. Remarque : si vous n’effectuez pas de tests d’intrusion annuels, vous pouvez choisir de les faire effectuer via le processus de certification.
Diagrammes d’architecture	Diagramme d’architecture logique représentant une vue d’ensemble générale de l’infrastructure de prise en charge de votre application/complément. Cela doit inclure tous les environnements d’hébergement et l’infrastructure de prise en charge prenant en charge l’application/complément. Ce diagramme DOIT représenter tous les différents composants système de prise en charge au sein de l’environnement pour aider les analystes de certification à comprendre les systèmes dans l’étendue et à déterminer l’échantillonnage. Indiquez également le type d’environnement d’hébergement utilisé . IsV Hébergé, IaaS, PaaS ou Hybride. Note: Lorsque SaaS est utilisé, indiquez les différents services SaaS utilisés pour fournir les services de prise en charge au sein de l’environnement.
Empreinte publique	Détail de toutes les adresses IP publiques et URL utilisées par l’infrastructure de prise en charge. Cela doit inclure la plage d’adresses IP routables complète allouée à l’environnement, sauf si une segmentation adéquate a été implémentée pour fractionner la plage en cours d’utilisation (une preuve adéquate de la segmentation sera requise)
Diagrammes de flux de données	Diagrammes de flux détaillant les éléments suivants :
	✓ Microsoft 365 Flux de données vers et depuis l’application/complément (y compris EUII et OII ).
	✓ Flux de données Microsoft 365 au sein de l’infrastructure de prise en charge (le cas échéant)
	✓ Diagrammes mettant en évidence où et quelles données sont stockées, comment les données sont transmises à des tiers externes (y compris les détails des tiers), et comment les données sont protégées en transit sur des réseaux ouverts/publics et au repos.
Détails du point de terminaison d’API	Liste complète de tous les points de terminaison d’API utilisés par votre application. Pour vous aider à comprendre l’étendue de l’environnement, fournissez des emplacements de point de terminaison d’API au sein de votre environnement.
Autorisations de l’API Microsoft	Fournir une documentation détaillant toutes les API Microsoft utilisées, ainsi que les autorisations demandées pour le fonctionnement de l’application/du complément, ainsi qu’une justification des autorisations demandées
Types de stockage de données	Documents de stockage et de gestion des données décrivant :
	✓ Dans quelle mesure vos clients Microsoft 365 Data EUII et OII sont-ils reçus et stockés
	✓ Période de conservation des données.
	✓ Pourquoi les données Microsoft 365 du client sont capturées.
	✓ Emplacement de stockage des données Microsoft 365 du client (doivent être inclus dans les diagrammes de flux de données fournis ci-dessus).
Confirmation de la conformité	Documentation de support pour les frameworks de sécurité externes inclus dans la soumission de l’attestation de l’éditeur ou à prendre en compte lors de l’examen des contrôles de certification Microsoft 365. Actuellement, les trois éléments suivants sont pris en charge :
	✓ Attestation de conformité PCI DSS (AOC).
	✓ Rapports soc 2 type I/type II.
	✓ ISMS / IEC - 1S0/IEC 27001 Déclaration d’applicabilité (SoA) et de certification.
Dépendances web	Documentation répertoriant toutes les dépendances utilisées par l’application/le complément avec les versions en cours d’exécution.
Inventaire logiciel	Un inventaire logiciel à jour qui inclut tous les logiciels utilisés dans l’environnement dans l’étendue, ainsi que les versions.
Inventaire matériel	Un inventaire matériel à jour utilisé par l’infrastructure de prise en charge. Cela sera utilisé pour faciliter l’échantillonnage lors de l’exécution de la phase d’évaluation. Si votre environnement inclut PaaS, fournissez les détails des services consommés.

Activités de collecte et d’évaluation des preuves

Les analystes de certification devront examiner les preuves de tous les composants système dans l’exemple d’ensemble défini. Les types de preuves nécessaires pour soutenir le processus d’évaluation incluent tout ou partie des éléments suivants :

Collection de preuves

• Documentation initiale, mise en évidence dans la section Envoi de documentation initiale ci-dessus
• Documents de stratégie
• Traiter des documents
• Paramètres de configuration système
• Modifier les tickets
• Modifier les enregistrements de contrôle
• Rapports système

Diverses méthodes seront utilisées pour recueillir les preuves nécessaires à la réalisation du processus d’évaluation. Cette collection de preuves peut se présenter sous la forme suivante :

• Documents
• Captures d’écran
• Entrevues
• Partage d’écran

Les techniques de collecte de preuves utilisées seront déterminées pendant le processus d’évaluation. Pour obtenir des exemples concrets du type de preuve requis dans votre soumission, consultez le Guide des exemples de preuves.

Activités d’évaluation

Les analystes de certification examineront les preuves que vous fournissez pour déterminer si vous avez respecté les contrôles de cette spécification de certification Microsoft 365.

Si possible et pour réduire le temps nécessaire pour effectuer l’évaluation, tout ou partie de la documentation détaillée dans la soumission de la documentation initiale doit être fournie à l’avance.

Les analystes de certification passent d’abord en revue les éléments de preuve fournis à partir de la soumission initiale de la documentation et les informations d’attestation de l’éditeur pour identifier les champs d’enquête appropriés, la taille d’échantillonnage et la nécessité d’obtenir des preuves supplémentaires, comme indiqué ci-dessus. Les analystes de certification analysent toutes les informations collectées pour tirer des conclusions quant à la façon dont et si vous respectez les contrôles de cette spécification de certification Microsoft 365.

Critères de certification des applications

Votre application, l’infrastructure de prise en charge et la documentation associée seront évalués dans les domaines de sécurité suivants :

1. Sécurité des applications
2. Sécurité opérationnelle / Déploiement sécurisé
3. Sécurité et confidentialité de la gestion des données

Chacun de ces domaines de sécurité comprend des contrôles clés spécifiques englobant une ou plusieurs exigences spécifiques qui seront évaluées dans le cadre du processus d’évaluation. Pour garantir que la certification Microsoft 365 est inclusive pour les développeurs de toutes tailles, chacun des domaines de sécurité est évalué à l’aide d’un système de scoring pour déterminer un score global à partir de chacun des domaines. Les scores pour chacun des contrôles de certification Microsoft 365 sont alloués entre 1 (faible) et 3 (élevé) en fonction du risque perçu de non-respect de ce contrôle. Chacun des domaines de sécurité aura une marque de pourcentage minimale à considérer comme une réussite. Certains éléments de cette spécification incluent certains critères d’échec automatique :

• Les autorisations d’API ne suivent pas le principe du moindre privilège (PoLP).
• Aucun rapport de test d’intrusion quand il est nécessaire.
• Aucune défense anti-programme malveillant
• L’authentification multifacteur n’est pas utilisée pour protéger l’accès administratif.
• Aucun processus de mise à jour corrective.
• Aucun avis de confidentialité RGPD approprié.

Sécurité des applications

Le domaine de sécurité des applications se concentre sur les trois domaines suivants :

• Validation d’autorisation GraphAPI
• Vérifications de connectivité externe
• Test de sécurité des applications

Validation d’autorisation GraphAPI

La validation des autorisations GraphAPI est effectuée pour vérifier que l’application/le complément ne demande pas d’autorisations trop permissives. Pour ce faire, vérifiez manuellement les autorisations demandées. Les analystes de certification feront référence à ces vérifications par rapport à la soumission de l’attestation de l’éditeur et évalueront le niveau d’accès demandé pour s’assurer que les pratiques de « privilège minimum » sont respectées. Lorsque les analystes de certification estiment que ces pratiques de « privilège minimum » ne sont pas respectées, les analystes de certification auront une discussion ouverte avec vous pour valider la justification métier des autorisations demandées. Tout écart par rapport à votre soumission d’attestation d’éditeur trouvé pendant cette révision recevra également des commentaires afin que votre attestation d’éditeur puisse être mise à jour.

Vérifications de connectivité externe

Dans le cadre de l’évaluation, un analyste effectuera une procédure pas à pas légère des fonctionnalités des applications pour identifier les connexions en dehors de Microsoft 365. Toutes les connexions qui ne sont pas identifiées comme étant Microsoft ou des connexions directes à votre service seront signalées et abordées pendant l’évaluation.

Test de sécurité des applications

Un examen adéquat des risques associés à votre application/complément et à l’environnement de prise en charge est essentiel pour garantir aux clients la sécurité de l’application/du complément. Les tests de sécurité des applications sous forme de tests d’intrusion DOIVENT être effectués si votre application dispose d’une connectivité à un service non publié par Microsoft. Si votre application fonctionne de manière autonome sans connectivité à un service ou back-end non-Microsoft, aucun test d’intrusion n’est nécessaire.

Étendue des tests d’intrusion

Les activités de test d’intrusion DOIVENT être effectuées sur l’environnement de production actif qui prend en charge le déploiement de l’application/du complément (par exemple, où le code de l’application/du complément est hébergé, qui est généralement la ressource dans le fichier manifeste), ainsi que tout environnement supplémentaire prenant en charge le fonctionnement de l’application/complément (par exemple, si l’application/le complément communique avec d’autres applications web en dehors de Microsoft 365). Lors de la définition de l’étendue, vous devez veiller à ce que tous les systèmes ou environnements « connectés » qui peuvent avoir un impact sur la sécurité de l’environnement dans l’étendue soient également inclus dans TOUTES les activités de test d’intrusion.

Lorsque des techniques sont utilisées pour segmenter les environnements dans l’étendue à partir d’autres environnements, les activités de test d’intrusion DOIVENT valider l’efficacité de ces techniques de segmentation. Cela doit être détaillé dans le rapport des tests d’intrusion.

Les rapports de tests d’intrusion seront examinés pour s’assurer qu’il n’y a pas de vulnérabilités qui répondent aux critères d’échec automatique suivants décrits dans les contrôles ci-dessous.

Conditions requises pour les tests d’intrusion

Type de critères	Contrôles de test d’intrusion
Critères généraux	Controls
	Les tests d’intrusion de l’application et de l’infrastructure DOIVENT avoir lieu chaque année (tous les 12 mois) et menés par une entreprise indépendante de bonne réputation.
	La correction des vulnérabilités critiques et à haut risque identifiées DOIT être effectuée dans un délai d’un mois après la conclusion du test d’intrusion, ou plus tôt en fonction du processus de mise à jour corrective documenté.
	L’empreinte externe complète (adresses IP, URL, points de terminaison d’API, etc.) DOIT être inclus dans l’étendue des tests d’intrusion et doit être documenté dans le rapport des tests d’intrusion.
	Les tests d’intrusion des applications web DOIVENT inclure toutes les classes de vulnérabilité ; par exemple, le OWASP Top 10 ou sans Top 25 CWE le plus actuel.
	Il n’est pas nécessaire de retester les vulnérabilités identifiées par l’entreprise de test d’intrusion . Toutefois, la correction et l’auto-évaluation sont suffisantes. Toutefois, des preuves adéquates doivent être fournies pendant l’évaluation.
Critères d’échec automatique :	Controls
	Présence d’un système d’exploitation non pris en charge.
	Présence de comptes d’administration par défaut, énumérables ou devinables.
	Présence de risques d’injection de code SQL.
	Présence de scripts intersites.
	Présence de vulnérabilités de traversée de répertoires (chemin d’accès de fichier).
	Présence de vulnérabilités HTTP, par exemple, fractionnement de la réponse d’en-tête, trafic de demandes et attaques asynchrones.
	Présence de la divulgation du code source (y compris LFI).
	Tout score critique ou élevé tel que défini par les instructions de gestion des correctifs CVSS.
	Toute vulnérabilité technique importante qui peut être facilement exploitée pour compromettre une grande quantité d’EUII ou OUI.

Importante

Les rapports doivent être en mesure de fournir suffisamment d’assurance que tout ce qui est détaillé dans la section Spécification du test de sécurité des applications peut être illustré.

Exigences et règles de test d’intrusion complémentaires

• Pour les éditeurs de logiciels indépendants qui ne participent pas actuellement à des tests d’intrusion, les tests d’intrusion peuvent être effectués gratuitement avec la certification Microsoft 365. Microsoft organisera et couvrira le coût d’un test d’intrusion pour un maximum de 12 jours de test manuel. Les coûts des tests d’intrusion sont calculés en fonction du nombre de jours nécessaires pour tester l’environnement. Toutes les dépenses supérieures à 12 jours de test seront de la responsabilité de l’éditeur de logiciels indépendant.
• Les éditeurs de logiciels indépendants devront soumettre des preuves et recevoir l’approbation de 50 % des contrôles dans l’étendue avant la réalisation du test d’intrusion. Pour commencer, remplissez votre soumission initiale de document et choisissez d’inclure un test d’intrusion dans le cadre de votre évaluation. Vous serez contacté pour définir l’étendue et planifier votre test d’intrusion lorsque vous aurez terminé 50 % des contrôles.
• Le rapport émis une fois le pentest terminé sera fourni à l’éditeur de logiciels indépendant une fois qu’il aura terminé la certification. Ce rapport, ainsi que votre certification Microsoft 365, peuvent être utilisés pour montrer aux clients potentiels que votre environnement est sécurisé.
• Les éditeurs de logiciels indépendants seront également chargés de démontrer que les vulnérabilités identifiées dans le test d’intrusion ont été corrigées avant l’octroi d’une certification, mais n’ont pas besoin de produire un rapport propre.

Une fois qu’un test d’intrusion est organisé, l’ISV est responsable des frais associés au rééchelonnement et aux annulations comme suit :

Échelle de temps de replanification des frais	Proportion Payable
Demande de replanification reçue plus de 30 jours avant la date de début planifiée.	0 % payable
Demande de replanification reçue 8 à 30 jours avant la date de début planifiée.	25 % payable
Demande de replanification reçue dans les 2 à 7 jours précédant la date de début planifiée avec une date de réacriture ferme.	50 % payable
Demande de replanification reçue moins de 2 jours avant la date de début.	100 % payable

Échelle de temps des frais d’annulation	Proportion Payable
La demande d’annulation a été reçue plus de 30 jours avant la date de début planifiée.	25 % payable
La demande d’annulation a été reçue 8 à 30 jours avant la date de début planifiée.	50 % payable
Demande d’annulation reçue dans les 7 jours précédant la date de début planifiée.	90 % payable

Sécurité opérationnelle

Ce domaine mesure l’alignement de l’infrastructure de prise en charge et des processus de déploiement de votre application avec les meilleures pratiques de sécurité.

Contrôles

Famille de contrôles	Controls
Protection contre les programmes malveillants - Antivirus	Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures antivirus.
	Fournir des preuves démontrables que le logiciel antivirus s’exécute sur tous les composants système échantillonné.
	Fournir des preuves démontrables que les signatures antivirus sont à jour dans tous les environnements (dans un délai de 1 jour).
	Fournissez 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. Remarque : Si l’analyse à l’accès n’est pas activée, l’analyse quotidienne et les alertes doivent être activées au minimum.
	Fournissez 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ées.
Contrôles d’application : obligatoire uniquement si l’anti-programme malveillant traditionnel n’est pas utilisé	Fournir des preuves démontrables que les applications sont approuvées avant d’être déployées.
	Fournir des preuves démontrables qu’une liste complète des applications approuvées avec justification métier existe et est conservée.
	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. (Exemple : Liste autorisée : sample1, sample3, signature de code)
	Fournissez des preuves démontrables que le contrôle d’application est configuré comme documenté à partir de tous les composants système échantillonnés.
Gestion des correctifs - Classement des risques	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.
	Fournir des preuves de la façon dont les nouvelles vulnérabilités de sécurité sont identifiées.
	Fournissez des preuves montrant que toutes les vulnérabilités se voient attribuer un classement des risques une fois identifiées.
Gestion des correctifs - Mise à jour corrective	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.
	Fournir des preuves démontrables que tous les composants système échantillonnés sont corrigés.
	Fournissez 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.
Analyse des vulnérabilités	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.
	Fournissez des preuves démontrables que les corrections des vulnérabilités identifiées pendant l’analyse des vulnérabilités sont corrigées conformément à votre période de mise à jour corrective documentée.
Pare-feu	Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures de gestion des pare-feu.
	Fournir des preuves démontrables que toutes les informations d’identification d’administration par défaut sont modifiées avant l’installation dans les environnements de production.
	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.
	Fournir une preuve démontrable que tout accès public se termine dans la zone démilitarisée (DMZ).
	Fournir des preuves démontrables que tout le trafic autorisé via le pare-feu passe par un processus d’approbation.
	Fournir des preuves démontrables que la base de règles de pare-feu est configurée pour supprimer le trafic non défini explicitement.
	Fournir des preuves démontrables que le pare-feu prend uniquement en charge le chiffrement fort sur toutes les interfaces d’administration non-console.
	Fournissez des preuves démontrables que vous effectuez des révisions de règles de pare-feu au moins tous les 6 mois.
Web Application Firewall (WAF) (FACULTATIF) : un crédit supplémentaire sera récompensé pour satisfaire aux contrôles suivants.	Fournissez des preuves démontrables que le Web Application Firewall (WAF) est configuré pour surveiller activement, alerter et bloquer le trafic malveillant.
	Fournissez des preuves démontrables que le WAF prend en charge le déchargement SSL.
	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)
Modifier le contrôle	Fournissez une documentation de stratégie qui régit les processus de contrôle des modifications.
	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.
	Fournissez 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.
	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 sauvegarde et des tests à effectuer.
	Fournissez des preuves démontrables que les demandes de modification font l’objet d’un processus d’autorisation et de déconnexion.
Développement/déploiement de logiciels sécurisés	Fournissez des stratégies et des procédures qui prennent en charge le développement et le déploiement de logiciels sécurisés, notamment des conseils sur les meilleures pratiques de codage sécurisé pour les classes de vulnérabilité courantes telles que OWASP Top 10 ou SANS Top 25 CWE.
	Fournir des preuves démontrables que les modifications de code font l’objet d’un processus de révision et d’autorisation par un deuxième réviseur.
	Fournir des preuves démontrables que les développeurs suivent une formation de développement de logiciels sécurisé chaque année.
	Fournir des preuves démontrables que les dépôts de code sont sécurisés avec l’authentification multifacteur (MFA).
	Fournissez des preuves démontrables que des contrôles d’accès sont en place pour sécuriser les dépôts de code.
Gestion des comptes	Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures de gestion des comptes.
	Fournissez des preuves démontrables que les informations d’identification par défaut sont désactivées, supprimées ou modifiées sur les composants système échantillonnées.
	Fournir des preuves démontrables que la création, la modification et la suppression de compte passent par un processus d’approbation établi.
	Fournissez des preuves démontrables qu’un processus est en place pour désactiver ou supprimer des comptes non utilisés dans les 3 mois.
	Fournissez 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 ne dépassant pas 10 tentatives, historique des mots de passe d’un minimum de 5 mots de passe, application de l’utilisation d’un mot de passe fort
	Fournissez des preuves démontrables que des comptes d’utilisateur uniques sont émis pour tous les utilisateurs.
	Fournir des preuves démontrables que les principes des privilèges minimum sont respectés dans l’environnement.
	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.
	Fournissez des preuves démontrables que l’authentification multifacteur est configurée pour toutes les connexions d’accès à distance et toutes les interfaces d’administration non-console.
	Fournissez 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.
	Fournissez des preuves démontrables 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).
Détection et prévention des intrusions (FACULTATIF) : Un crédit supplémentaire sera récompensé pour satisfaire aux contrôles suivants	Fournissez 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.
	Fournir des preuves démontrables que les signatures IDPS sont conservées à jour (dans les 24 heures).
	Fournissez des preuves démontrables que IDPS est configuré pour prendre en charge l’inspection TLS de tout le trafic web entrant.
	Fournissez des preuves démontrables que IDPS est configuré pour surveiller tous les flux de trafic entrant.
	Fournissez des preuves démontrables que IDPS est configuré pour surveiller tous les flux de trafic sortant.
Journalisation des événements de sécurité	Fournissez une documentation de stratégie pour les meilleures pratiques et procédures qui régissent la journalisation des événements de sécurité.
	Fournir 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 journaliser 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 de compte privilégié, Falsification du journal des événements, Désactivation des outils de sécurité (par exemple, anti-programme malveillant ou journalisation des événements), journalisation anti-programme malveillant (par exemple, mises à jour, détection de programmes malveillants et échecs d’analyse). Événements IDPS et WAF, si configuré
	Fournir 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é
	Fournir des preuves démontrables que tous les composants système échantillonné sont synchronisés avec les mêmes serveurs principaux et secondaires.
	Fournissez 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.
	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.
	Fournissez 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 journaux d’événements de sécurité conservés.
Révisions du journal des événements de sécurité	Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures de révision des journaux.
	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.
	Fournir des preuves démontrables que les événements et anomalies de sécurité potentiels sont examinés et corrigés.
Alerte	Fournissez une documentation sur les stratégies qui régissent les pratiques et procédures d’alerte d’événements de sécurité.
	Fournir des preuves démontrables que des alertes sont déclenchées pour un tri immédiat pour les types d’événements de sécurité suivants : création ou modifications de comptes privilégiés, événements de virus ou de programmes malveillants, falsification du journal des événements, événements IDPS ou WAF
	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é.
Gestion des risques	Fournir des preuves démontrables qu’un processus formel de gestion des risques liés à la sécurité des informations est établi.
	Fournir des preuves démontrables qu’une évaluation officielle des risques a lieu chaque année, au minimum.
	Fournissez 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.
	Fournir des preuves démontrables que l’évaluation des risques liés à la sécurité des informations inclut l’impact, la matrice des risques de probabilité ou l’équivalent.
	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.
Réponse aux incidents	Fournissez le plan de réponse aux incidents de sécurité (IRP).
	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 acheteurs, les organismes de réglementation, les autorités de surveillance, les administrateurs et les clients.
	Fournissez 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.
	Fournissez des preuves démontrables pour montrer que l’IRP de sécurité est mis à jour en fonction des leçons apprises ou des changements organisationnels.

Sécurité et confidentialité de la gestion des données

Les données en transit entre l’utilisateur de l’application, les services intermédiaires et les systèmes de l’éditeur de logiciels indépendants doivent être protégées par chiffrement via une connexion TLS prenant en charge un minimum de TLS v1.1. VoirAnnexe A.

Lorsque votre application récupère et stocke des données Microsoft 365, vous devez implémenter un schéma de chiffrement de stockage de données qui suit la spécification définie à l’Annexe B.

Contrôles

Famille de contrôles	Controls
Données en transit	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
	Fournissez des preuves démontrables que la compression TLS est désactivée sur tous les services publics qui gèrent les requêtes web.
	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.
Données au repos	Fournissez des preuves démontrables que les données au repos sont chiffrées en ligne avec les exigences de profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que AES, Blowfish, TDES et de tailles de clé de chiffrement de 128 bits et 256 bits.
	Fournissez 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.
	Fournissez un inventaire montrant toutes les données stockées, y compris l’emplacement de stockage et le chiffrement utilisé pour protéger les données.
Conservation et suppression de données	Fournir des preuves démontrables qu’une période de conservation des données approuvée et documentée est formellement établie.
	Fournissez des preuves démontrables que les données conservées correspondent à la période de rétention définie.
	Fournir des preuves démontrables que des processus sont en place pour supprimer en toute sécurité les données après leur période de rétention.
Gestion de l’accès aux données	Fournissez une liste de toutes les personnes ayant accès aux données ou aux clés de chiffrement, y compris la justification métier.
	Fournissez 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.
	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.
	Fournissez une liste de toutes les parties tierces avec lesquelles les données client sont partagées.
	Fournir des preuves démontrables que tous les tiers qui consomment des données client ont des contrats de partage en place.
RGPD (le cas échéant)	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.
	Fournir 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.
	Vous conservez une déclaration de confidentialité qui doit contenir les détails de l’entreprise (nom, adresse, etc.).
	Vous conservez une déclaration de confidentialité qui doit expliquer les types de données personnelles traitées.
	Vous conservez une déclaration de confidentialité qui doit expliquer la licéité du traitement des données personnelles
	Vous conservez une déclaration de confidentialité qui explique en détail 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 d’opposition, Droits relatifs à la prise de décision automatisée, y compris le profilage.
	Vous conservez une déclaration de confidentialité qui doit expliquer la durée pendant laquelle les données personnelles seront conservées.

Révision facultative des frameworks de conformité externe

Bien que cela ne soit pas obligatoire, si vous êtes actuellement conforme à iso 27001, PCI DSS ou SOC2, vous pouvez choisir d’utiliser ces certifications pour satisfaire certains des contrôles de certification Microsoft 365. Les analystes de certification tenteront d’aligner les frameworks de sécurité externes existants sur la spécification de la certification Microsoft 365. Toutefois, si la documentation à l’appui n’est pas en mesure de fournir l’assurance que les contrôles de certification Microsoft 365 ont été évalués dans le cadre de l’audit/évaluation des infrastructures de sécurité externes, vous devrez fournir des preuves supplémentaires des contrôles en place.

La documentation doit démontrer correctement que l’environnement dans l’étendue de la certification Microsoft 365 a été inclus dans l’étendue de ces frameworks de sécurité externes. La validation de ces frameworks de sécurité sera effectuée en acceptant la preuve de certifications valides effectuées par des sociétés tierces externes dignes de confiance. Ces entreprises réputées doivent être membres d’organismes d’accréditation internationaux pour les programmes de conformité pertinents. Consultez Normes de certification et de conformité ISO pour ISO 27001 et Évaluateurs de sécurité qualifiés (QSA) pour PCI DSS.

Le tableau suivant met en évidence les frameworks externes et la documentation requis par les analystes de certification dans le cadre de ce processus de validation :

Standard	Conditions requises
ISO 27001	Une version publique de la déclaration d’applicabilité (SOA) et une copie du certificat ISO 27001 émis seront nécessaires. La SOA résume votre position sur chacun des 114 contrôles de sécurité des informations et sera utilisée pour identifier si une exclusion de contrôles qui ne sont pas correctement détaillés dans le certificat ISO 27001. Si cela ne peut pas être déterminé en examinant la version publique du SOA, l’analyste peut avoir besoin d’accéder à la SOA complète si ISO 27001 est utilisé pour valider certains des contrôles de spécification de certification Microsoft 365. En plus de valider l’étendue des activités d’évaluation ISO 27001, les analystes confirmeront également la validité de l’entreprise d’audit comme décrit ci-dessus.
PCI DSS	Un document d’attestation de conformité (AOC) de niveau 1 valide doit être fourni, identifiant clairement les composants système et d’application dans l’étendue. Un AOC d’auto-évaluation ne sera pas accepté comme preuve de respect des bonnes pratiques de sécurité. L’AOC sera utilisé pour déterminer quels contrôles de la spécification de certification Microsoft 365 ont été évalués et confirmés dans le cadre de l’évaluation PCI DSS.
SOC 2	Le rapport SOC 2 (type I ou type II) doit être à jour (émis au cours des 15 derniers mois et la période déclarée commencée au cours des 27 derniers mois) pour être utilisé comme preuve de conformité avec l’un des contrôles d’évaluation dans cette spécification de certification Microsoft 365.

Si des infrastructures de sécurité externes ont été incluses dans l’attestation du serveur de publication, les analystes de certification devront case activée la validité de ces infrastructures de conformité de sécurité dans le cadre de l’évaluation de la certification Microsoft 365.

Infrastructure	Considérations supplémentaires
ISO 27001	Annexe C : Collection de preuves – Deltas pour ISO 27001.
PCI DSS	Annexe D : Collecte de preuves – Deltas pour PCI DSS.
SOC 2	Annexe E : Collecte de preuves – Deltas pour SOC 2.

Remarque

Bien que les frameworks/normes de sécurité externes mentionnés ci-dessus puissent être soumis comme preuve de conformité à certains des contrôles de certification Microsoft 365, la réussite de la certification Microsoft 365 ne signifie pas que vous réussirez un audit par rapport à ces normes/frameworks. La spécification de certification Microsoft 365 n’est qu’un petit sous-ensemble de ces normes/frameworks de sécurité qui permettent à Microsoft d’obtenir un niveau d’assurance en référence à votre posture de sécurité.

Conditions requises pour utiliser des frameworks de conformité externes

✓ L’environnement de prise en charge de l’application/complément et tous les processus métier associés doivent être inclus dans l’étendue de tous les frameworks de conformité de sécurité externes pris en charge et doivent être clairement indiqués dans la documentation fournie.

✓ Les frameworks de conformité de sécurité externes pris en charge DOIVENT être à jour, c’est-à-dire au cours des 12 derniers mois (ou dans les 15 mois si la réévaluation est en cours et que des preuves peuvent être fournies).

✓ Les infrastructures de conformité de sécurité externes prises en charge doivent être effectuées par une entreprise indépendante accréditée.

Annexe A

Configuration requise du profil TLS

Tout le trafic réseau, qu’il soit au sein d’un réseau virtuel, d’un service cloud ou d’un centre de données, doit être protégé avec un minimum de TLS v1.1 (TLS v1.2+ est recommandé) ou d’un autre protocole applicable. Les exceptions à cette exigence sont les suivantes :

• Redirection HTTP vers HTTPS. Votre application peut répondre via HTTP pour rediriger les clients vers HTTPS, mais la réponse ne doit pas contenir de données sensibles (cookies, en-têtes, contenu). Aucune autre réponse HTTP autre que les redirections vers HTTPS et la réponse aux sondes d’intégrité n’est autorisée. Voir ci-dessous.
• Sondes d’intégrité. Votre application peut répondre aux sondes d’intégrité via HTTP uniquement si les sondes d’intégrité HTTPS ne sont pas prises en charge par la partie de vérification.
• Accès au certificat. L’accès aux points de terminaison CRL, OCSP et AIA à des fins de validation de certificat et de vérification de révocation est autorisé via HTTP.
• Communications locales. Votre application peut utiliser HTTP (ou d’autres protocoles non protégés) pour les communications qui ne quittent pas le système d’exploitation, par exemple la connexion à un point de terminaison de serveur web exposé sur localhost.

La compression TLS DOIT être désactivée.

Annexe B

Configuration requise du profil de chiffrement

Seuls les primitives et les paramètres de chiffrement sont autorisés comme suit :

Chiffrement symétrique

Chiffrement

 ✓ Seuls AES, BitLocker, Blowfish ou TDES sont autorisés. Toutes les longueurs de clé prises en charge =128 sont autorisées >(128 bits, 192 bits et 256 bits) et peuvent être utilisées (les clés de 256 bits sont recommandées).

 ✓ Seul le mode CBC est autorisé. Chaque opération de chiffrement doit utiliser un vecteur d’initialisation (IV) généré de manière aléatoire.

 ✓ L’utilisation de chiffrements de flux, tels que RC4, N’EST PAS autorisée.

Fonctions de hachage

 ✓ Tout nouveau code doit utiliser SHA-256, SHA-384 ou SHA-512 (collectivement appelé SHA-2). La sortie peut être tronquée à au moins 128 bits

 ✓ SHA-1 ne peut être utilisé que pour des raisons de compatibilité.

 ✓ L’utilisation de MD5, MD4, MD2 et d’autres fonctions de hachage N’EST PAS autorisée, même pour les applications non cryptographiques.

Authentification des messages

 ✓ Tout nouveau code DOIT utiliser HMAC avec l’une des fonctions de hachage approuvées. La sortie de HMAC peut être tronquée à au moins 128 bits.

 ✓ HMAC-SHA1 ne peut être utilisé que pour des raisons de compatibilité.

 ✓ La clé HMAC DOIT être d’au moins 128 bits. Les clés 256 bits sont recommandées.

Algorithmes asymétriques

Chiffrement

 ✓ RSA est autorisé. La clé DOIT être d’au moins 2 048 bits et le remplissage OAEP doit être utilisé. L’utilisation du remplissage PKCS est autorisée uniquement pour des raisons de compatibilité.

Signatures

 ✓ RSA est autorisé. La clé DOIT être d’au moins 2 048 bits et le remplissage PSS doit être utilisé. L’utilisation du remplissage PKCS est autorisée uniquement pour des raisons de compatibilité.

 ✓ECDSA est autorisé. La clé DOIT être d’au moins 256 bits. La courbe NIST P-256, P-384 ou P-521 doit être utilisée.

Échange de clés

 ✓ ECDH est autorisé. La clé DOIT être d’au moins 256 bits. La courbe NIST P-256, P-384 ou P-521 doit être utilisée.

 ✓ ECDH est autorisé. La clé DOIT être d’au moins 256 bits. La courbe NIST P-256, P-384 ou P-521 doit être utilisée.

Annexe C

Collection de preuves – Delta pour ISO 27001

Lorsque vous avez déjà atteint ISO27001 conformité, les lacunes du delta suivantes qui ne sont pas entièrement couvertes par la norme ISO 27001 devront, au minimum, être examinées dans le cadre de cette certification Microsoft 365.

Remarque

Dans le cadre de votre évaluation de la certification Microsoft 365, l’analyste de certification détermine si l’un des contrôles ISO 27001 mappés n’a pas été inclus dans le cadre de l’évaluation ISO 27001 et peut également décider d’échantillonner les contrôles qui ont été trouvés pour être inclus pour fournir une assurance supplémentaire. Toutes les exigences manquantes dans la norme ISO 27001 doivent être incluses dans vos activités d’évaluation de la certification Microsoft 365.

Protection contre les programmes malveillants – Antivirus

Si la protection contre les programmes malveillants est en place à l’aide du contrôle d’application et qu’elle est attestée dans le rapport ISO 27001, aucune investigation supplémentaire n’est nécessaire. Si aucun contrôle d’application n’est en place, les analystes de certification doivent identifier et évaluer les preuves des mécanismes de contrôle des applications pour empêcher la détonation de programmes malveillants dans l’environnement. Pour cela, vous devez :

• Démontrer que les logiciels antivirus s’exécutent sur tous les composants système échantillonné.

• Démontrez que l’antivirus est configuré sur tous les composants système échantillonnées pour bloquer automatiquement les programmes malveillants, mettre en quarantaine & alerte ou alerter.

• Les logiciels antivirus DOIVENT être configurés pour journaliser toutes les activités.

Gestion des correctifs – Mise à jour corrective

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement cette catégorie, vous devez :

• Les composants logiciels et les systèmes d’exploitation qui ne sont plus pris en charge par le fournisseur ne DOIVENT pas être utilisés dans l’environnement. Des stratégies de prise en charge doivent être en place pour garantir que les composants logiciels/systèmes d’exploitation non pris en charge seront supprimés de l’environnement et qu’un processus d’identification de la fin de vie des composants logiciels doit être en place

Analyse des vulnérabilités

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement cette catégorie, vous devez :

• Démontrer que l’analyse des vulnérabilités internes et externes est effectuée tous les trimestres.

• Vérifiez que la documentation de prise en charge est en place pour la correction des vulnérabilités en fonction du classement des risques et conformément à la spécification comme suit :

✓ Corrigez tous les problèmes de risque critique et élevé en ligne avec le classement des risques pour l’analyse interne.

✓ Correction de tous les problèmes de risque critique, élevé et moyen en ligne avec le classement des risques pour l’analyse externe.

✓ Démontrez que la correction est effectuée conformément à la stratégie de correction des vulnérabilités documentée.

Pare-feu : pare-feu (ou technologies équivalentes)

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement cette catégorie, vous devez :

• Démontrer que les pare-feu sont installés à la limite de l’environnement dans l’étendue.

• Démontrez que les pare-feu sont installés entre la zone DMZ et les réseaux approuvés.

• Démontrez que tous les accès publics se terminent dans la zone DMZ.

• Démontrez que les informations d’identification d’administration par défaut sont modifiées avant l’installation dans l’environnement actif.

• Démontrer que tout le trafic autorisé via le ou les pare-feu passe par un processus d’autorisation, qui aboutit à la documentation de tout le trafic avec une justification métier.

• Démontrez que tous les pare-feu sont configurés pour supprimer le trafic non défini explicitement.

• Démontrez que les pare-feu prennent uniquement en charge le chiffrement fort sur toutes les interfaces d’administration non-console.

• Démontrez que les interfaces d’administration non-console du pare-feu exposées à Internet prennent en charge l’authentification multifacteur.

• Démontrer que les révisions des règles de pare-feu sont effectuées au moins tous les 6 mois

Pare-feu – Pare-feu d’applications web (WAF)

Un crédit supplémentaire sera accordé si un WAF est déployé pour vous protéger contre la myriade de menaces et de vulnérabilités d’application web auxquelles l’application peut être exposée. Lorsqu’un PARE-feu d’applications web ou similaire est présent, vous devez effectuer les actions suivantes :

• Démontrer que le WAF est configuré en mode de défense active ou qu’il en surveille davantage avec des alertes.

• Démontrer que le WAF est configuré pour prendre en charge le déchargement SSL.

• Est configuré conformément à l’ensemble de règles OWASP Core (3.0 ou 3.1) pour vous protéger contre la plupart des types d’attaques suivants :

✓ 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 par script intersites.

✓ Attaques par injection de code SQL.

✓ Attaques de fixation de session.

Modifier le contrôle

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des processus de demande de modification, vous devez :

• Démontrez que les demandes de modification présentent les détails suivants :

✓ Impact documenté.

✓ Détails des tests de fonctionnalités à effectuer.

✓ Détails des procédures de back-out.

• Démontrez que les tests de fonctionnalités sont effectués une fois les modifications terminées.

• Démontrez que les demandes de modification sont signées après le test des fonctionnalités.

Gestion des comptes

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des processus de gestion des comptes, vous devez :

• Montrer comment les ✓s sont implémentés pour atténuer les attaques par relecture (par exemple, MFA, Kerberos).
• Montrer comment les comptes qui n’ont pas été utilisés depuis 3 mois sont désactivés ou supprimés.
• ✓ou d’autres atténuations appropriées doivent être configurées pour protéger les informations d’identification de l’utilisateur. La stratégie de mot de passe minimale suivante doit être utilisée comme guide :

✓ 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 cinq mots de passe.

✓ Application de l’utilisation de mots de passe forts.

• Démontrer que l’authentification multifacteur est configurée pour toutes les solutions d’accès à distance.

• Démontrez que le chiffrement fort est configuré sur toutes les solutions d’accès à distance.

• Lorsque la gestion du DNS public est en dehors de l’environnement dans l’étendue, tous les comptes d’utilisateur capables d’apporter des modifications DNS DOIVENT être configurés pour utiliser l’authentification multifacteur.

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

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des processus des services de détection et de prévention des intrusions (IDPS), vous devez :

• IDPS DOIT être déployé dans le périmètre de l’environnement de prise en charge.

• Les signatures IDPS DOIVENT être tenues à jour au cours de la dernière journée.

• IDPS DOIT être configuré pour l’inspection TLS.

• IDPS DOIT être configuré pour tout le trafic entrant et sortant.

• IDPS DOIT être configuré pour les alertes.

Journalisation des événements

Comme les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des processus de journalisation des événements de sécurité, vous devez :

• Démontrez que les systèmes publics sont connectés à une solution de journalisation centralisée qui ne se trouve pas dans la zone DMZ.

• Montrer comment un minimum de 30 jours de données de journalisation est immédiatement disponible, avec 90 jours conservés.

Révision (données de journalisation)

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments de cette catégorie, vous devez :

• Montrez comment les révisions quotidiennes des journaux sont effectuées et comment les exceptions et les anomalies sont identifiées en montrant comment elles sont gérées.

Alerte

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments de cette catégorie, vous devez :

• Montrer comment les événements de sécurité sont configurés pour déclencher des alertes pour un tri immédiat.

• Montrer comment le personnel est disponible 24h/24 et 7 j/7 pour répondre aux alertes de sécurité.

Gestion des risques

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des processus d’évaluation des risques, vous devez :

• Démontrer qu’un processus formel de gestion des risques est établi.

Réponse aux incidents

Étant donné que les audits ISO 27001 n’évaluent pas spécifiquement certains éléments des stratégies et processus de réponse aux incidents, vous devez :

• Démontrez que le plan/procédure de réponse aux incidents inclut :

✓ Procédures de réponse spécifiques pour les modèles de menace attendus.

✓ Les fonctionnalités de gestion des incidents s’alignent sur l’infrastructure de cybersécurité NIST (Identifier, Protéger, Détecter, Répondre, Récupérer).

✓ L’IRP couvre les systèmes dans l’étendue.

✓ Formation annuelle pour l’équipe de réponse aux incidents.

Annexe D

Collection de preuves – Deltas pour PCI DSS

Si vous avez déjà atteint la conformité PCI DSS, les (lacunes) delta suivantes qui ne sont pas entièrement couvertes par PCI DSS devront, au minimum, être examinées dans le cadre de cette certification Microsoft 365.

Remarque

Dans le cadre de l’évaluation de la certification Microsoft 365, l’analyste de certification détermine si l’un des contrôles PCI DSS mappés n’a pas été inclus dans le cadre de l’évaluation PCI DSS et peut également décider d’échantillonner les contrôles qui ont été inclus pour fournir une assurance supplémentaire. Toutes les exigences manquantes dans la norme PCI DSS doivent être incluses dans les activités d’évaluation de la certification Microsoft 365.

Protection contre les programmes malveillants - Contrôle d’application

Si la protection contre les programmes malveillants est en place par le biais de l’utilisation d’un antivirus et qu’elle est attestée dans le rapport PCI DSS, aucune enquête supplémentaire n’est nécessaire. Si aucun antivirus n’est en place, les analystes de certification devront identifier et évaluer les preuves des mécanismes de contrôle des applications pour empêcher la détonation de programmes malveillants dans l’environnement. Pour cela, vous devez :

• Montrez comment l’approbation de l’application est effectuée et vérifiez que cette opération est terminée.

• Démontrer qu’il existe une liste complète des applications approuvées avec justification métier.

• Fournissez ou démontrez que la documentation à l’appui est en place, détaillant la façon dont le logiciel de contrôle d’application est configuré pour répondre à des mécanismes de contrôle d’application spécifiques (c’est-à-dire, liste d’autorisation, signature de code, etc.).

• Démontrez que sur tous les composants système échantillonnés, le contrôle d’application est configuré comme documenté.

Gestion des correctifs – Classement des risques

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement cette catégorie, vous devez :

• Montrer comment le classement des risques des vulnérabilités est effectué.

Analyse des vulnérabilités

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement cette catégorie, vous devez :

• Démontrer que la correction est effectuée conformément à la stratégie de correction des vulnérabilités documentée.

Pare-feu : pare-feu (ou technologies équivalentes)

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement cette catégorie, vous devez :

• Démontrez que les pare-feu prennent uniquement en charge le chiffrement fort sur toutes les interfaces d’administration non-console.

• Démontrez que les interfaces d’administration non-console du pare-feu exposées à Internet prennent en charge l’authentification multifacteur.

Un crédit supplémentaire sera accordé si un Web Application Firewall (WAF) est déployé pour vous protéger contre la myriade de menaces et de vulnérabilités d’application web auxquelles l’application peut être exposée. Lorsqu’un PARE-feu d’applications web ou similaire est présent, vous devez effectuer les actions suivantes :

• Démontrer que le WAF est configuré en mode de défense active ou qu’il en surveille davantage avec des alertes.

• Démontrer que le WAF est configuré pour prendre en charge le déchargement SSL.

• Est configuré conformément à l’ensemble de règles OWASP Core (3.0 ou 3.1) pour vous protéger contre la plupart des types d’attaques suivants :

✓ 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 par script intersites.

✓ Attaques par injection de code SQL.

✓ Attaques de fixation de session.

Modifier le contrôle

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement certains éléments des processus de demande de modification, vous devez :

• Démontrez que les demandes de modification sont déclenchées avant d’être effectuées dans des environnements de production.

• Démontrer que les modifications sont autorisées avant de passer en production.

• Démontrez que les tests de fonctionnalités sont effectués une fois les modifications terminées.

• Démontrez que les demandes de modification sont signées après le test des fonctionnalités.

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

Comme les audits PCI DSS n’accèdent pas spécifiquement à certains éléments des processus de développement et de déploiement de logiciels sécurisés ; pour cela, vous devez :

• Les dépôts de code DOIVENT être sécurisés par MFA.

• Des contrôles d’accès adéquats DOIVENT être en place pour protéger les dépôts de code contre les modifications de code malveillantes.

Gestion des comptes

Comme les audits PCI DSS n’évaluent pas spécifiquement certains éléments des processus de gestion de compte, vous devez :

• Montrer comment les mécanismes d’autorisation sont implémentés pour atténuer les attaques par relecture (par exemple, MFA, Kerberos).

• Les stratégies de mot de passe forts ou d’autres mesures d’atténuation appropriées doivent être configurées pour protéger les informations d’identification de l’utilisateur. La stratégie de mot de passe minimale suivante doit être utilisée comme guide :

✓ 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 cinq mots de passe.

✓ Application de l’utilisation de mots de passe forts.

• Démontrez que le chiffrement fort est configuré sur toutes les solutions d’accès à distance.

• Lorsque la gestion du DNS public est en dehors de l’environnement dans l’étendue, tous les comptes d’utilisateur capables d’apporter des modifications DNS DOIVENT être configurés pour utiliser l’authentification multifacteur.

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

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement certains éléments des processus des services de détection et de prévention des intrusions (IDPS), vous devez :

• IDPS DOIT être configuré pour l’inspection TLS.

• IDPS DOIT être configuré pour tout le trafic entrant et sortant.

Gestion des risques

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement certains éléments des processus d’évaluation des risques, vous devez :

• Démontrer que l’évaluation des risques inclut des matrices d’impact et de probabilité.

Réponse aux incidents

Étant donné que les audits PCI DSS n’évaluent pas spécifiquement certains éléments des stratégies et processus de réponse aux incidents, le développeur devra :

• Démontrer que les fonctionnalités de gestion des incidents s’alignent sur L’infrastructure de cybersécurité NIST (Identifier, Protéger, Détecter, Répondre, Récupérer).

Annexe E

Collection de preuves - Deltas pour SOC 2

Lorsque vous avez déjà atteint la conformité SOC 2, les lacunes du delta suivantes qui ne sont pas entièrement couvertes par SOC 2 devront être examinées dans le cadre de cette certification Microsoft 365.

Remarque

Dans le cadre de l’évaluation de la certification Microsoft 365, l’analyste de certification détermine si l’un des contrôles SOC 2 mappés n’a pas été inclus dans le cadre de votre évaluation SOC 2 et peut également décider d’échantillonner les contrôles qui ont été détectés pour fournir une assurance supplémentaire. Toutes les exigences manquantes dans votre évaluation SOC 2 doivent être incluses dans le cadre des activités d’évaluation de la certification Microsoft 365.

Protection contre les programmes malveillants - Contrôle d’application

Si la protection contre les programmes malveillants est en place par le biais de l’utilisation d’un antivirus et qu’elle est attestée dans votre rapport SOC 2, aucune investigation supplémentaire n’est nécessaire. Si aucun antivirus n’est en place, les analystes de certification devront identifier et évaluer les preuves des mécanismes de contrôle des applications pour empêcher la détonation de programmes malveillants dans l’environnement. Pour cela, vous devez :

• Fournissez ou démontrez que la documentation à l’appui est en place, détaillant la façon dont le logiciel de contrôle d’application est configuré pour répondre à des mécanismes de contrôle d’application spécifiques (c’est-à-dire, liste d’autorisation, signature de code, etc.).

• Montrez comment l’approbation de l’application est effectuée et vérifiez que cette opération est terminée.

• Démontrer qu’il existe une liste complète des applications approuvées avec justification métier.

• Démontrez que sur tous les composants système échantillonnés, le contrôle d’application est configuré comme documenté.

Gestion des correctifs – Mise à jour corrective

Comme les audits SOC 2 n’évaluent pas spécifiquement cette catégorie, vous devez :

• Tout problème faible, moyen, élevé ou critique doit être corrigé dans les fenêtres normales d’activité de mise à jour corrective.

• Les composants logiciels et les systèmes d’exploitation qui ne sont plus pris en charge par le fournisseur ne DOIVENT pas être utilisés dans l’environnement. Des stratégies de prise en charge doivent être en place pour garantir que les composants logiciels/systèmes d’exploitation non pris en charge seront supprimés de l’environnement et qu’un processus permettant d’identifier le moment où les composants logiciels arrivent en fin de vie doit être en place.

Pare-feu – Pare-feu

Comme les audits SOC 2 n’évaluent pas spécifiquement les contrôles de modification pour les listes de contrôle d’accès de pare-feu, vous devez :

• Démontrer que tout le trafic autorisé via le ou les pare-feu passe par un processus d’autorisation qui aboutit à la documentation de tout le trafic avec une justification métier.

• Démontrer que les révisions des règles de pare-feu sont effectuées au moins tous les six mois.

Un crédit supplémentaire sera accordé si un Web Application Firewall (WAF) ou similaire est déployé pour vous protéger contre la myriade de menaces et de vulnérabilités d’application web auxquelles l’application peut être exposée. Lorsqu’un PARE-feu d’applications web ou similaire est présent, vous devez effectuer les actions suivantes :

• Démontrer que le WAF est configuré en mode de défense active ou qu’il en surveille davantage avec des alertes.

• Démontrer que le WAF est configuré pour prendre en charge le déchargement SSL.

• Est configuré conformément à l’ensemble de règles OWASP Core ((3.0 ou 3.1) pour protéger contre la plupart des types d’attaques suivants :

 ✓ 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 par script intersites.

 ✓ Attaques par injection de code SQL.

 ✓ Attaques de fixation de session.

Modifier le contrôle

Étant donné que les audits SOC 2 n’évaluent pas spécifiquement certains éléments des processus de demande de modification, le développeur doit :

• Montrer comment les environnements de développement/test sont distincts de l’environnement de production en appliquant la séparation des tâches.

• Montrer comment les données actives ne sont pas utilisées dans les environnements de développement/test.

• Démontrez que les tests de fonctionnalités sont effectués une fois les modifications terminées.

• Démontrez que les demandes de modification sont signées après le test des fonctionnalités.

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

Comme les audits SOC 2 n’accèdent pas spécifiquement à certains éléments des processus de développement et de déploiement de logiciels sécurisés ; pour cela, vous devez :

• Vous DEVEZ disposer d’un processus de développement logiciel établi et documenté couvrant l’ensemble du cycle de vie du développement logiciel.

• Les développeurs DOIVENT suivre une formation de codage logiciel sécurisé au moins une fois par an.

• Les dépôts de code DOIVENT être sécurisés par MFA.

• Des contrôles d’accès adéquats DOIVENT être en place pour protéger les dépôts de code contre les modifications de code malveillantes.

Gestion des comptes

Étant donné que les audits SOC2 n’évaluent pas spécifiquement certains éléments des processus de gestion des comptes, vous devez :

• Montrer comment les mécanismes d’autorisation sont implémentés pour atténuer les attaques par relecture (par exemple, MFA, Kerberos).

• Montrer comment les comptes qui n’ont pas été utilisés depuis 3 mois sont désactivés ou supprimés.

• Les stratégies de mot de passe forts ou d’autres mesures d’atténuation appropriées doivent être configurées pour protéger les informations d’identification de l’utilisateur. La stratégie de mot de passe minimale suivante doit être utilisée comme guide :

 ✓ 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 de mots de passe forts

• Démontrer que des comptes d’utilisateur uniques sont émis pour tous les utilisateurs.

• Lorsque la gestion du DNS public est en dehors de l’environnement dans l’étendue, tous les comptes d’utilisateur capables d’apporter des modifications DNS DOIVENT être configurés pour utiliser l’authentification multifacteur.

Détection et prévention des intrusions (FACULTATIF).

Comme les audits SOC 2 n’évaluent pas spécifiquement certains éléments des processus des services de détection et de prévention des intrusions (IDPS), vous devez :

• Les signatures IDPS DOIVENT être conservées à jour au cours de la dernière journée

• IDPS DOIT être configuré pour l’inspection TLS

• IDPS DOIT être configuré pour TOUT le trafic entrant et sortant

Journalisation des événements

Étant donné que les audits SOC 2 n’évaluent pas spécifiquement certains éléments des processus de journalisation des événements de sécurité, vous devez :

• Montrer comment, sur tous les composants système de l’exemple de jeu, les systèmes suivants sont configurés pour journaliser les événements suivants

 ✓ Accès utilisateur aux composants système et aux applications.

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

 ✓ Tentatives d’accès logique non valides.

Démontrer que les événements enregistrés contiennent ; au minimum, les informations suivantes :

 ✓ Utilisateur.

 ✓ Type d’événement.

 ✓ Date et heure.

 ✓ Indicateur de réussite/d’échec.

 ✓ Étiquette pour identifier le système affecté.

• Démontrez que tous les composants système de l’exemple d’ensemble sont configurés pour utiliser la synchronisation de l’heure et qu’ils sont identiques aux serveurs de temps principaux/secondaires.

• Démontrez que les systèmes publics sont connectés à une solution de journalisation centralisée qui ne se trouve pas dans la zone DMZ.

• Démontrez que les systèmes publics sont connectés à une solution de journalisation centralisée qui ne se trouve pas dans la zone DMZ.

• Montrer comment la solution de journalisation centralisée est protégée contre la falsification non autorisée des données de journalisation.

• Montrer comment un minimum de 30 jours de données de journalisation est immédiatement disponible, avec 90 jours ou plus conservés.

Gestion des risques

Comme les audits SOC2 n’évaluent pas spécifiquement certains éléments des processus d’évaluation des risques, vous devez :

• Démontrer qu’une évaluation officielle des risques est effectuée au moins une fois par an.

Réponse aux incidents.

Comme les audits SOC2 n’évaluent pas spécifiquement certains éléments des stratégies et processus de réponse aux incidents, vous devez :

• Démontrez que le plan/procédure de réponse aux incidents inclut :

 ✓ Procédures de réponse spécifiques pour les modèles de menace attendus.

 ✓ Processus de communication documenté pour assurer la notification en temps voulu des principales parties prenantes (marques/acquéreurs de paiement, organismes de réglementation, autorités de surveillance, administrateurs, clients, etc.

Annexe F

Types de déploiement d’hébergement

Microsoft reconnaît que vous allez déployer des applications et stocker du code d’application/complément dans différents environnements d’hébergement. Les responsabilités globales de certains contrôles de sécurité dans la certification Microsoft 365 dépendent de l’environnement d’hébergement utilisé. L’annexe F examine les types de déploiement courants et les mappe aux contrôles de sécurité qui sont évalués dans le cadre du processus d’évaluation. Les types de déploiement d’hébergement suivants ont été identifiés :

Types d’hébergement	Description
Éditeur de logiciels indépendants hébergés	Les types hébergés par les éditeurs de logiciels indépendants peuvent être définis comme étant l’endroit où vous êtes responsable de l’infrastructure utilisée pour prendre en charge l’environnement d’application/complément. Cela peut être physiquement situé dans vos propres centres de données ou des centres de données tiers avec un service de colocalisation. En fin de compte, vous disposez d’une propriété et d’un contrôle administratif complets sur l’infrastructure et l’environnement d’exploitation pris en charge.
Infrastructure as a Service (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/)	Infrastructure as a Service est un service fourni dans lequel l’infrastructure de prise en charge physique est gérée et gérée en son nom par le fournisseur de services cloud (CSP). En règle générale, la mise en réseau, le stockage, les serveurs physiques et l’infrastructure de virtualisation relèvent de la responsabilité du fournisseur de solutions Cloud. Le système d’exploitation, le middleware, le runtime, les données et les applications sont vos responsabilités. Les fonctionnalités de pare-feu seraient également gérées et gérées par le tiers, mais la maintenance de la base de règles de pare-feu serait généralement toujours la responsabilité des consommateurs.
Platform as a Service/Serverless (PaaS) (https://azure.microsoft.com/overview/what-is-paas/)	Avec la plateforme en tant que service, vous êtes approvisionné avec une plateforme managée présentant un service qui peut être consommé. Vous n’avez pas besoin d’effectuer des fonctions sysadmin, car le système d’exploitation et l’infrastructure de prise en charge sont gérés par le fournisseur de solutions Cloud. Cela est généralement utilisé lorsque les organisations ne veulent pas se préoccuper de la présentation d’un service web et peuvent se concentrer sur la création du code source de l’application web et la publication de l’application web sur les services web gérés dans le cloud. Un autre exemple peut être un service de base de données où la connectivité est donnée à une base de données, mais l’infrastructure et l’application de base de données de prise en charge sont extraites du consommateur. Remarque : Serverless et PaaS sont similaires. Ainsi, pour les besoins du type de déploiement d’hébergement de certification Microsoft 365 serverless et PasS sont considérés comme identiques
Hybride hébergé	Avec le type hébergé hybride, vous pouvez utiliser plusieurs types hébergés pour prendre en charge différentes parties de l’environnement de prise en charge. Cela peut être davantage le cas lorsque les applications/compléments sont utilisés sur plusieurs piles Microsoft 365. Bien que la certification Microsoft 365 prend en charge l’emplacement où les applications/modules complémentaires de plusieurs services Microsoft 365 sont développés, une évaluation de l’ensemble de l’environnement de prise en charge (entre les applications/compléments) doit être évaluée en fonction de chacun des « mappages de types hébergés » applicables. Parfois, vous pouvez utiliser différents types hébergés pour un complément unique, où cette opération est effectuée. L’applicabilité des critères doit toujours suivre les critères « Mappages de type hébergé » sur les différents types hébergés.
Hébergement partagé	L’hébergement partagé est l’endroit où vous hébergez l’environnement au sein d’une plateforme partagée par plusieurs consommateurs individuels. La spécification de certification Microsoft 365 n’a pas été écrite pour tenir compte de cela en raison de l’adoption du cloud, l’hébergement partagé n’est pas courant. Si vous pensez qu’il est utilisé, contactez Microsoft, car des exigences supplémentaires devront être créées pour prendre en compte les risques supplémentaires liés à ce type d’hébergement.

Annexe G

En savoir plus

Vue d’ensemble du programme de conformité des applications Microsoft 365 Qu’est-ce que l’attestation d’éditeur d’applications Microsoft 365 ?Qu’est-ce que la certification Microsoft 365 ?

Glossaire

AIA

*L’accès aux informations de l’autorité est un descripteur d’emplacement de service utilisé pour rechercher le certificat de l’autorité de certification émettrice.

LCR

*La liste de révocation de certificats permet à un point de terminaison SSL (Secure Sockets Layer) de vérifier qu’un certificat reçu d’un hôte distant est valide et digne de confiance.

Score CVSS

*Common Vulnerability Scoring System est une norme publiée qui mesure la vulnérabilité et calcule un score numérique en fonction de sa gravité.

Instructions de gestion des correctifs CVSS

• Critique (9.0 - 10.0)
• Élevé (7.0 - 8.9)
• Moyen (4.0 - 6.9)
• Faible (0,0 - 3,9)

DMZ

*La zone démilitarisée est un réseau intermédiaire physique ou logique qui interagit directement avec des réseaux externes ou non propriétaires tout en conservant le réseau interne, privé et isolé de l’hôte.

EUII

Informations d’identification de l’utilisateur final.

RGPD

*Le règlement général sur la protection des données est un règlement de l’Union européenne (UE) sur la protection de la vie privée et de la protection des données pour toutes les données des citoyens de l’UE, quel que soit l’emplacement de votre site d’application.

HSTS

*Http Strict Transport Security utilise un en-tête de réponse HTTP qui indique au navigateur web d’accéder uniquement au contenu via HTTPS. Ceci est conçu pour protéger contre les attaques de rétrogradation et le détournement de cookies.

CEI

*International Electrotechnical Commission.

DOCTRINES

*Système de gestion de la sécurité des informations.

ISV

Les fournisseurs de sécurité indépendants sont des individus et des organisations qui développent, commercialisent et vendent des logiciels qui s’exécutent sur des plateformes logicielles et matérielles tierces.

ISO 27001

Infrastructure de spécification du système de gestion de la sécurité des informations pour tous les contrôles techniques dans les processus de stratégies et de procédures de gestion des risques d’une organisation.

LFI

L’inclusion de fichiers locaux permet à un attaquant d’inclure des fichiers sur un serveur via le navigateur web.

NIST

Le National Institute of Standards (NIST), un organisme non réglementaire du Département du commerce des États-Unis fournit des conseils aux organisations du secteur privé aux États-Unis pour évaluer et approuver leur capacité à prévenir, détecter et répondre aux cyberattaques.

Modifications non significatives

• Correctifs de bogues mineurs.
• Améliorations mineures des performances.
• Systèmes d’exploitation/bibliothèques/correctifs des applications clientes et serveur.

OCSP

Le protocole d’état des certificats en ligne est utilisé pour case activée la status de révocation des certificats numériques X.509.

OII

Informations d’identification organisationnelles.

OWASP

Ouvrez le projet de sécurité des applications web.

PCI DSS

Payment Card Industry Data Security Standard, un organization qui maintient des normes pour la sécurité des données des titulaires de carte dans le monde entier.

Test du stylet

Le test d’intrusion est une méthode de test d’une application web en simulant des attaques malveillantes pour trouver les vulnérabilités de sécurité qu’un attaquant pourrait exploiter.

SAML

Security Assertion Markup Language est un standard ouvert pour l’échange de données d’authentification et d’autorisation entre l’utilisateur, le fournisseur d’identité et le fournisseur de services.

Données sensibles

• Données de contrôle d’accès.
• Contenu client.
• Informations d’identité de l’utilisateur final.
• Données de prise en charge.
• Données personnelles publiques.
• Informations pseudonymes de l’utilisateur final.

Changements importants

• Déplacement de l’environnement d’hébergement.
• Des mises à niveau majeures de l’infrastructure de soutien ; par exemple, l’implémentation d’un nouveau pare-feu, les mises à niveau majeures des services frontaux, etc.
• Ajout de fonctionnalités et d’extensions /ou à votre application.
• Mises à jour à votre application qui capturent des données sensibles supplémentaires.
• Modifications apportées aux flux de données ou aux modèles d’autorisation de votre application
• Ajout de points de terminaison d’API ou de fonctions de point de terminaison d’API.

SOC 2

Service Organization Control 2, une procédure d’audit technique composée de cinq principes de service d’approbation pour garantir que les fournisseurs de services gèrent en toute sécurité les données et la confidentialité des clients d’un organization.

SSL

Couche de sockets sécurisés.

TLS

Transport Layer Security.