Partager via

Vue d’ensemble de l’infrastructure de certification Microsoft 365

  • Article

Cet article fournit des informations détaillées, notamment la liste des contrôles de sécurité de la certification Microsoft 365 et la prise en charge des éditeurs de logiciels indépendants et des développeurs soumis à la certification Microsoft 365.

La certification Microsoft 365 est un audit indépendant de la sécurité et de la confidentialité des applications, des compléments et de l’environnement principal de prise en charge (collectivement appelés applications) qui s’intègre à la plateforme Microsoft 365. Les applications qui réussissent sont désignées certifiées Microsoft 365 dans l’écosystème Microsoft 365 et peuvent être facilement trouvées dans les marketplaces Microsoft 365 via des filtres de recherche et une personnalisation axés sur la conformité. Les éditeurs de logiciels indépendants auront la possibilité de partager leurs attributs de conformité d’applications sur des pages dédiées au sein de cet ensemble de documentation.

La certification Microsoft 365 est disponible pour les types d’applications suivants :

  • Compléments Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • Applications Teams
  • Solutions SharePoint
  • Applications web (SaaS)

Importante

La certification Microsoft 365 est un examen rigoureux de la sécurité et de la conformité d’une application par rapport à l’infrastructure de certification Microsoft 365 et nécessite un engagement considérable en matière de temps et de ressources. Passez en revue les frameworks de contrôle de conformité pour voir si votre application est éligible avant de commencer la certification. Pour toute question, envoyez un e-mail à appcert@microsoft.com.

Petits caractères

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.

Configuration requise

Pour que la certification Microsoft 365 puisse être accordée, une application doit effectuer les opérations suivantes :

Vérification de l’éditeur Lorsqu’une application a un éditeur vérifié, l’organisation qui publie l’application a été vérifiée comme étant authentique par Microsoft. La vérification d’une application inclut l’utilisation d’un compte du programme Microsoft Cloud Partner (CPP) qui a été vérifié et l’association de partnerID vérifié à une inscription d’application. Obtenir la vérification de l’éditeur

Publisher Attestation est un processus libre-service dans lequel les éditeurs de logiciels indépendants répondent à un ensemble de questions sur les pratiques de sécurité et de gestion des données de leur application. Les applications peuvent être attestées par l’éditeur dans l’Espace partenaires Microsoft et recevoir un badging et des filtres dédiés dans la Place de marché Microsoft AppSource une fois terminées.

Passer en revue les critères de contrôle Il n’est pas nécessaire de se conformer à tous les contrôles pour obtenir une certification. Toutefois, des seuils (qui ne seront pas divulgués) sont en place pour chacun des trois domaines de sécurité abordés dans ce document de présentation et doivent être passés. Certains contrôles seront classés comme un « échec dur », ce qui signifie que l’absence de ces contrôles de sécurité entraînera un échec d’évaluation.

Importante

Délai de soumission : En moyenne, le processus d’évaluation devrait prendre 30 jours, à condition que les éditeurs de logiciels indépendants soient en mesure de vérifier fréquemment l’état des soumissions et de répondre aux commentaires et aux demandes de preuves 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.

Étendue de la certification

L’environnement dans l’étendue prend en charge la remise du code d’application/complément et prend en charge tous les systèmes back-end avec ants avec ant l’application/le complément. Tous les environnements supplémentaires connectés à l’environnement dans l’étendue 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 distincts doivent également être inclus dans l’environnement dans l’étendue, car ces environnements sont nécessaires pour remplir le service en cas de problème avec l’environnement principal. Les environnements de sauvegarde à distance devront également être inclus, car ces environnements peuvent stocker des données Microsoft et, par conséquent, des contrôles de sécurité appropriés devront être en place.

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 défini. Les composants dans l’étendue incluent, mais ne sont pas limités à :

  • Application(s) web
  • Serveurs (physiques ou virtuels qui peuvent être locaux ou dans le cloud)
  • Contrôles de sécurité réseau (NSC), tels que les pare-feu
  • Commutateurs
  • Équilibreurs de charge
  • Infrastructure virtuelle
  • Portails de gestion web des fournisseurs de cloud
  • Ressources cloud (machines virtuelles, App Service, comptes de stockage, instances EC2, etc.)

Importante

Les composants du système public sont vulnérables aux attaques d’acteurs de menace externes et sont donc beaucoup plus exposés. En règle générale, ces systèmes sont segmentés loin des autres composants système internes à l’aide d’un contrôle de sécurité réseau (NSC) créant une zone démilitarisée (DMZ). L’intention étant que la zone DMZ est moins fiable que le réseau interne et qu’une sécurité supplémentaire aiderait à protéger davantage les systèmes internes et les données si les systèmes accessibles au public devenaient compromis. Dans l’idéal, une zone DMZ serait utilisée, mais cela n’est pas possible ou même nécessaire dans certains scénarios de déploiement.

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’environnement dans l’étendue 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. Les analystes 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 de conformité (AOC), ISO 27001 ou SOC 2 Type II.

L’annexe C fournit des détails sur les contrôles de sécurité susceptibles d’être applicables en fonction des types de déploiement suivants et selon que l’application 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é

Lorsque IaaS ou PaaS est déployé, des preuves de validation de l’alignement de l’environnement sur ces types de déploiement doivent être fournies.

Échantillonnage

Les demandes de preuves à l’appui de l’évaluation de 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, des différents types d’appareils (c.-à-d. serveurs, NSC, routeurs, etc.) et de l’emplacement. Un échantillon approprié sera sélectionné au début du processus de certification. Le tableau suivant doit être utilisé comme guide où l’échantillonnage sera déterminé en fonction des facteurs détaillés ci-dessus :

Taille de la population Échantillon
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 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 de bout en bout

Pour commencer la certification Microsoft 365 :

  1. Accédez à l’Espace partenaires et effectuez l’attestation de l’éditeur. Si la soumission date de plus de trois mois, veuillez soumettre à nouveau pour examen et validation.

  2. Dans l’Espace partenaires, sélectionnez « Démarrer la certification » pour commencer la soumission initiale du document. Cela aidera les analystes de certification à déterminer ce qui est dans l’étendue de l’évaluation en fonction de l’architecture de l’application et de la façon dont elle gère les données Microsoft.

Conseil

Suivez le guide pratique pour obtenir des instructions pas à pas pour obtenir votre application microsoft 365 certifiée.

Le processus de certification s’effectue en deux étapes, comme décrit ci-dessous :

L’envoi de document initial aide l’analyste à comprendre l’application, les flux de données, à définir l’environnement dans l’étendue, à identifier les contrôles de sécurité applicables et à déterminer les composants système à partir duquel les preuves devront être collectées. L’éditeur de logiciels indépendant doit fournir les informations demandées pour aider l’analyste de certification à terminer cette étape du processus, soit environ 5 % du processus global.

L’examen complet des preuves est le processus par lequel l’éditeur de logiciels indépendant envoie des artefacts de preuve montrant comment l’environnement dans l’étendue répond aux contrôles de sécurité. Il y aura plusieurs interactions entre l’éditeur de logiciels indépendant et l’analyste au cours de cette phase d’audit, qui constitue le reste du processus.

Évaluation

Une fois que l’envoi initial du document a été accepté, l’ensemble des contrôles de sécurité s’affiche automatiquement dans le portail. Les éditeurs de logiciels indépendants doivent fournir une preuve pour chaque contrôle montrant que le contrôle est en place et disposer de 60 jours pour soumettre toutes les preuves. Un analyste examinera la preuve et approuvera le contrôle ou demandera des preuves nouvelles ou supplémentaires.

Certification

Une fois qu’une soumission a été validée par un analyste, les éditeurs de logiciels indépendants sont informés de la décision de certification. Les applications ayant reçu une certification recevront un badge sur leur application dans AppSource, ainsi que des pages de documentation Microsoft dédiées avec des rapports détaillés sur leurs attributs de sécurité et de conformité.

Révision et recertification

Les applications certifiées Microsoft 365 doivent faire l’objet d’une recertification sur une base annuelle. Cela nécessite la revalidation des contrôles dans l’étendue par rapport à l’environnement actuel dans l’étendue. Ce processus peut commencer jusqu’à 90 jours avant l’expiration de la certification. Les certifications existantes n’expireront 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 la certification n’est pas renouvelée avant la date d’expiration, l’état de certification des applications est révoqué. Tous les badgings, icônes et personnalisation de certification associés seront supprimés de votre application, et les éditeurs de logiciels indépendants seront interdits de faire la publicité de votre application en tant que Microsoft 365 Certified.

Si une application subit des modifications importantes en dehors du délai de remise de la recertification, les éditeurs de logiciels indépendants sont invités à informer le Programme de conformité des applications Microsoft de toute mise à jour.

Envoi initial du document

Votre soumission initiale doit inclure les informations suivantes :

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 l’éditeur de logiciels indépendant n’effectue actuellement pas de tests d’intrusion annuels, Microsoft couvrira le coût des tests de stylet 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 l’application. Cela doit inclure tous les environnements d’hébergement et l’infrastructure de prise en charge prenant en charge l’application. 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 des 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 :
✓ Flux de données Microsoft 365 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 microsoft 365 données EUII et OII sont-ils reçus et stockés
✓ Période de conservation des données.
✓ Pourquoi les données Microsoft 365 sont capturées.
✓ Emplacement de stockage des données Microsoft 365 (doit également ê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 sécurité de la certification Microsoft 365. Actuellement, les quatre 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.
✓ Package d’autorisation FedRAMP FedRAMP et rapport d’évaluation de la préparation FedRAMP.
Dépendances web Documentation répertoriant toutes les dépendances utilisées par l’application avec les versions en cours d’exécution.
Inventaire des logiciels Un inventaire logiciel à jour qui inclut tous les logiciels utilisés dans l’environnement dans l’étendue, ainsi que les versions.
Inventaire du 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 des détails sur les services/ressources cloud 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 :

Collecte de preuves

  • Documentation initiale, mise en évidence dans le guide de soumission de la documentation initiale
  • 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
  • Minutes de réunion
  • Contrats/accords

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 spécifiques 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 fournies pour déterminer si tous les contrôles de la certification Microsoft 365 ont été respectés.

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

L’application et son infrastructure de prise en charge, ainsi que la documentation associée, seront évalués dans les trois 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 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-implémentation 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 trois domaines :

  • Validation d’autorisation GraphAPI
  • Vérifications de connectivité externe
  • Tests d’intrusion

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 l’éditeur de logiciels indépendant pour valider la justification métier des autorisations demandées. Toutes les différences par rapport à la soumission d’attestation de l’éditeur détectées lors de cette révision devront être corrigées.

Vérifications de connectivité externe

Dans le cadre de l’évaluation, une procédure détaillée des fonctionnalités des applications sera effectuée pour identifier les connexions établies 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.

Tests d’intrusion

Un examen adéquat des risques associés à l’application/complément et à l’environnement de prise en charge est essentiel pour fournir aux clients une assurance quant à 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 une fois déployée, votre application fonctionne de manière autonome en accédant uniquement au service Microsoft tel que GraphAPI, le test d’intrusion n’est pas nécessaire. Les tests d’intrusion sont toujours nécessaires si l’environnement dans l’étendue est hébergé dans Azure.

Étendue des tests d’intrusion

Pour les tests d’intrusion de l’infrastructure interne et externe, toutes 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/complément (par exemple, où le code d’application/complément est hébergé, qui sera généralement la ressource dans le fichier manifeste), ainsi que tous les environnements supplémentaires qui prennent en charge le fonctionnement de l’application/du 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 des tests d’intrusion, 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.

Il est recommandé d’effectuer des tests d’intrusion des applications web sur l’environnement de production en direct. Toutefois, il serait acceptable de tester uniquement l’application web à l’aide d’un environnement de test/UAT, à condition qu’il soit confirmé dans le rapport de test d’intrusion que le même code base fonctionnait exactement dans l’environnement de test/UAT au moment du test.

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.

Remarque

Les tests d’intrusion internes doivent être effectués, sauf si l’environnement d’hébergement est classé uniquement comme PaaS.

Exigences relatives aux 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.

Type de critères Contrôles de test d’intrusion
Critères généraux L’application web et les tests d’intrusion internes (le cas échéant) et externes 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é de l’éditeur de logiciels indépendants.
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 clairement documenté dans le rapport des tests d’intrusion.
À moins que l’environnement ne s’aligne sur PaaS, les réseaux internes complets DOIVENT être inclus dans l’étendue des tests d’intrusion et doivent être clairement documentés dans le rapport de test 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 est recommandé que cela soit détaillé dans le rapport des tests d’intrusion, sinon il sera difficile à démontrer.
Les vulnérabilités critiques et à haut risque ou les vulnérabilités considérées comme une défaillance automatique DOIVENT être testées à nouveau par l’entreprise de test d’intrusion et clairement mises en évidence comme étant corrigées dans le rapport de test d’intrusion.
Critères d’échec automatique : Présence d’un système d’exploitation non pris en charge ou d’une bibliothèque JavaScript non prise 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 relative aux tests d’intrusion ci-dessus peut être démontré.

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

  • Pour les éditeurs de logiciels indépendants qui n’effectuent actuellement pas de tests d’intrusion, les tests d’intrusion peuvent être effectués gratuitement pour 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 dans l’étendue. 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 test de stylet terminé sera remis à 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’attribution 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 rééchelonnement 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 d’une application avec les meilleures pratiques de sécurité.

Contrôles

Famille de contrôles Controls
Formation de sensibilisation Fournir des preuves que l’organisation fournit une formation de sensibilisation à la sécurité établie aux utilisateurs du système d’information (y compris les gestionnaires, les cadres supérieurs et les sous-traitants) dans le cadre de la formation initiale pour les nouveaux utilisateurs ou lorsque les changements du système d’information l’exigent.
Fournir la preuve d’une fréquence définie par l’organisation de formation de sensibilisation.
Fournir des preuves de documentation et de surveillance des activités individuelles de sensibilisation à la sécurité du système d’information tout en conservant les enregistrements de formation individuels sur une fréquence définie par l’organisation.
Protection contre les programmes malveillants - antivirus Indiquez que votre solution anti-programme malveillant est active et activée sur tous les composants système échantillonnées et configurée pour répondre aux critères suivants :
Si un antivirus est activé, l’analyse à l’accès est activée et les signatures sont à jour dans un délai d’un jour et bloque automatiquement les programmes malveillants ou les alertes et les mises en quarantaine lorsque des programmes malveillants sont détectés.
OU si EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), une analyse périodique est effectuée, des journaux d’audit sont générés et sont continuellement mis à jour et disposent de fonctionnalités d’auto-apprentissage.
Si EDR/NGAV, il bloque les programmes malveillants connus et identifie et bloque les nouvelles variantes de programmes malveillants en fonction des comportements de macro, ainsi que des fonctionnalités de liste de sécurité complètes.
Protection contre les programmes malveillants - contrôles d’application Fournir des preuves démontrables qu’une liste approuvée de logiciels/applications avec justification métier existe et est à jour.
Que chaque application soit soumise à un processus d’approbation et d’approbation avant son déploiement
Cette technologie de contrôle d’application est active, activée et configurée sur tous les composants système échantillonnés, comme indiqué.
Gestion des correctifs - mise à jour corrective et 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.
Indiquez que tous les composants système échantillonnés sont corrigés en fonction des délais de mise à jour corrective définis par l’organisation et que les systèmes d’exploitation et les composants logiciels non pris en charge ne sont pas utilisés. Le cas échéant, cela doit inclure la base de code si une technologie serverless ou PaaS est utilisée, ou l’infrastructure et la base de code si IaaS est utilisé.
Recommandations relatives à la période de mise à jour corrective : Critique – dans les 14 jours, Élevé – Dans les 30 jours, Moyen – Dans les 60 jours.
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.
Contrôles de sécurité réseau (NSC) Indiquez que les contrôles de sécurité réseau (NSC) sont installés à la limite de l’environnement dans l’étendue et installés entre le réseau de périmètre et les réseaux internes.
ET si l’iaaS hybride, local, fournit également la preuve que tout accès public se termine au niveau du réseau de périmètre.
Vérifiez que tous les contrôles de sécurité réseau (NSC) sont configurés pour supprimer le trafic qui n’est pas explicitement défini dans la base de règles et que les révisions des règles de contrôle de sécurité réseau (NSC) sont effectuées au moins tous les 6 mois.
Contrôle des modifications Fournir des preuves que les modifications introduites dans les environnements de production sont implémentées par le biais de demandes de modification documentées qui contiennent l’impact de la modification, les détails des procédures de back-out, les tests à effectuer, l’examen et l’approbation par le personnel autorisé.
Fournissez la preuve qu’il existe des environnements distincts afin que : les environnements de développement et de test/préproduction appliquent la séparation des tâches de l’environnement de production, la séparation des tâches est appliquée via des contrôles d’accès, et les données de production sensibles ne sont pas utilisées dans les environnements de développement ou de test/intermédiaire.
Développement/déploiement de logiciels sécurisés Fournissez des stratégies et des procédures qui prennent en charge le développement de logiciels sécurisés et incluent les normes du secteur et/ou les meilleures pratiques pour le codage sécurisé. Par exemple, Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Fournir des preuves que les dépôts de code sont sécurisés de sorte que : toutes les modifications de code font l’objet d’un processus de révision et d’approbation par un deuxième réviseur avant d’être fusionnées avec la branche principale, que les contrôles d’accès appropriés sont en place, que tous les accès sont appliqués via l’authentification multifacteur (MFA)
Fournissez la preuve que toutes les mises en production effectuées dans les environnements de production sont examinées et approuvées avant leur déploiement.
Gestion des comptes Indiquez que les informations d’identification par défaut sont désactivées, supprimées ou modifiées dans les composants système échantillonnées.
Indiquez qu’un processus est en place pour sécuriser (renforcer) les comptes de service et que ce processus a été suivi.
Fournissez la preuve que : des comptes d’utilisateur uniques sont émis pour tous les utilisateurs, que les principes des privilèges minimum des utilisateurs sont respectés dans l’environnement, qu’une stratégie de mot de passe/phrase secrète forte ou d’autres mesures d’atténuation appropriées sont en place, qu’un processus est en place et suivi au moins tous les trois mois pour désactiver ou supprimer les comptes non utilisés dans les trois mois.
Vérifiez que l’authentification multifacteur est configurée pour toutes les connexions d’accès à distance et toutes les interfaces d’administration hors console, y compris l’accès aux dépôts de code et aux interfaces de gestion cloud.
Journalisation, révision et alertes des événements de sécurité Fournissez la preuve 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.
Fournir des preuves que les journaux sont examinés régulièrement et que tous les événements/anomalies de sécurité potentiels identifiés pendant le processus de révision sont examinés et traités
Indiquez que les règles d’alerte sont configurées afin que les alertes soient déclenchées pour investigation pour les événements de sécurité suivants, le cas échéant : création/modifications de comptes privilégiés, activités ou opérations privilégiées/à haut risque, événements de programmes malveillants, falsification du journal des événements, événements IDPS/WAF. (si configuré)
Gestion des risques liés aux informations Fournir la preuve qu’une politique ou un processus officiel de gestion des risques liés à la sécurité de l’information ratifié est documenté et établi.
Fournir des preuves qu’une évaluation formelle des risques de sécurité des informations à l’échelle de l’entreprise est effectuée au moins une fois par an.
OR pour l’analyse des risques ciblés : une analyse ciblée des risques est documentée et effectuée au moins tous les 12 mois pour chaque instance où un contrôle traditionnel ou une bonne pratique du secteur n’est pas en place, où une limitation de conception/technologie crée un risque d’introduire une vulnérabilité dans l’environnement ou met les utilisateurs et les données en danger, en cas de suspicion ou de confirmation de compromission.
Vérifiez que l’évaluation des risques liés à la sécurité des informations inclut un composant système ou une ressource affectée, des menaces et des vulnérabilités ou des matrices d’impact et de probabilité équivalentes ou équivalentes, la création d’un registre des risques/plan de traitement des risques.
Indiquez que vous disposez d’un processus de gestion des risques qui évalue et gère les risques associés aux fournisseurs et aux partenaires commerciaux, et que vous pouvez identifier et évaluer les changements et les risques susceptibles d’avoir un impact sur votre système de contrôles internes.
Réponse aux incidents de sécurité Fournissez votre plan/procédure de réponse aux incidents de sécurité (IRP) ratifié.
Fournissez des preuves décrivant la façon dont votre organisation répond aux incidents, montrant comment elle est gérée et qu’elle inclut les détails de l’équipe de réponse aux incidents, y compris les informations de contact, un plan de communication interne pendant l’incident et la communication externe aux parties concernées telles que les principales parties prenantes, les marques de paiement et les acquéreurs, les organismes de réglementation (par exemple, 72 heures pour le RGPD). autorités de surveillance, directeurs, clients, ainsi que les étapes pour les activités telles que la classification des incidents, l’endiguement, l’atténuation, la récupération et le retour à des opérations normales selon le type d’incident
Fournissez la preuve que tous les membres de l’équipe de réponse aux incidents ont reçu une formation annuelle qui leur permet de répondre aux incidents.
Fournir des preuves que la stratégie de réponse aux incidents et la documentation connexe sont examinées et mises à jour en fonction des leçons tirées d’un exercice de haut de tableau, des leçons tirées de la réponse à un incident, des changements organisationnels.
Plan de continuité d’activité et plan de récupération d’urgence Fournissez la preuve que la documentation existe et qu’elle est conservée, ce qui décrit le plan de continuité d’activité.
Fournissez des preuves que le plan de continuité d’activité détaille le personnel concerné et ses rôles et responsabilités, notamment les fonctions métier avec les exigences et les objectifs d’urgence associés, les procédures de sauvegarde du système et des données, la configuration et la planification/rétention, les objectifs de priorité et de délai de récupération, un plan d’urgence détaillant les actions, les étapes et les procédures à suivre pour retourner les systèmes d’information critiques, les fonctions métier et les services à fonctionner en cas d’une opération interruption inattendue et non planifiée, un processus établi qui couvre la restauration complète du système et le retour à l’état d’origine.
Fournissez des preuves que la documentation existe, qu’elle est conservée et qu’elle décrit le plan de récupération d’urgence et inclut au minimum : personnel et leurs rôles, responsabilités et processus d’escalade, l’inventaire des systèmes d’information utilisés pour prendre en charge les fonctions et services métier critiques, les procédures et la configuration de sauvegarde des données et du système, un plan de récupération détaillant les actions et procédures à suivre pour restaurer les systèmes d’information critiques et les données à utiliser.
Fournir des preuves que le plan de continuité d’activité et le plan de reprise d’activité sont examinés au moins tous les 12 mois pour s’assurer qu’ils restent valides et efficaces dans les situations défavorables.
Fournissez des preuves que le plan de continuité d’activité est mis à jour en fonction de l’examen annuel du plan, que tous les employés concernés reçoivent une formation sur leurs rôles et responsabilités attribués dans les plans d’urgence, que les plans sont testés par le biais d’exercices de continuité d’activité ou de reprise d’activité, que les résultats des tests sont documentés, y compris les leçons tirées de l’exercice 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. (TLS v1.2+ est recommandé). 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 Indiquez que la configuration TLS est TLS1.2 ou ultérieure dans les exigences de configuration du profil TLS et qu’un inventaire des clés et certificats approuvés est conservé et tenu à jour.
Indiquez que la compression TLS est désactivée pour tous les services publics qui gèrent les requêtes web afin d’empêcher la fuite d’informations sur le taux de compression made easy (CRIME), et que TLS HSTS est activé et configuré sur 180 jours sur tous les sites.
Données au repos Fournissez la preuve que les données au repos sont chiffrées conformément aux exigences du profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que Advanced Encryption Standard (AES), RSA et Twofish avec des tailles de clé de chiffrement de 256 bits ou plus.
Conservation, sauvegarde et destruction des données Fournir la preuve qu’une période de conservation des données approuvée est formellement établie et documentée.
Indiquez que les données sont conservées uniquement pendant la période de rétention définie, comme indiqué dans le contrôle précédent.
Fournissez la preuve que des processus sont en place pour supprimer en toute sécurité les données après leur période de rétention.
Indiquez qu’un système de sauvegarde automatisé est en place et configuré pour effectuer des sauvegardes à des heures planifiées.
Fournir des preuves que les informations de sauvegarde sont testées conformément à la procédure de planification de sauvegarde et restaurées régulièrement pour confirmer la fiabilité et l’intégrité des données.
Fournir des preuves des contrôles d’accès et des mécanismes de protection appropriés (c’est-à-dire des sauvegardes immuables) sont implémentés pour garantir que les sauvegardes/captures instantanées système sont sécurisées contre les accès non autorisés et pour garantir la confidentialité, l’intégrité et la disponibilité des données de sauvegarde.
Gestion de l’accès aux données Fournissez la preuve qu’une liste d’utilisateurs ayant accès aux données et/ou aux clés de chiffrement est conservée. Inclusion de la justification métier pour chaque personne et confirmation que cette liste d’utilisateurs a été officiellement approuvée en fonction des privilèges d’accès requis pour leur fonction de travail et les utilisateurs sont configurés avec les privilèges décrits dans l’approbation.
Fournissez la preuve qu’une liste de tous les tiers avec qui les données sont partagées est conservée et que des accords de partage de données sont en place avec tous les tiers qui consomment des données.
Confidentialité Votre organisation dispose-t-elle d’un système PIM (Privacy Information Management) établi, implémenté et géré qui tient compte de l’engagement des dirigeants par le biais d’une stratégie ou d’une autre forme de documentation/système informatisé pour la façon dont vos efforts de gestion des informations de confidentialité sont maintenus pour la confidentialité et l’intégrité du système. Détermine les rôles, les responsabilités et les autorités de chaque personne qui gère le système, y compris les processeurs et les contrôleurs d’informations d’identification personnelle.
Fournir des preuves de processus pour vérifier que la réduction des piI est en cours, la désidentification et la suppression des informations d’identification personnelles sont effectuées à la fin de la période de traitement, des contrôles sont en place pour la transmission des informations d’identification personnelle, y compris toute confidentialité, l’enregistrement du transfert des informations personnelles d’un pays/région à un autre existe avec le consentement explicite pour le faire.
RGPD Fournissez la preuve que les personnes concernées sont en mesure d’émettre des demandes d’accès partagé, que l’éditeur de logiciels indépendant est en mesure d’identifier tous les emplacements des données des personnes concernées lorsqu’ils répondent à une demande de récupération de données, qu’il existe une période de rétention pour les sauvegardes qui permettent aux clients demandant la suppression de données par le biais de sar à mesure que les sauvegardes propagées sur une période sont supprimées (cycle de vie des suppressions de sauvegarde les plus anciennes/réécriture).
Fournissez la déclaration de confidentialité qui doit contenir tous les éléments requis comme suit : détails oranizational (nom, adresse et autres informations d’identification personnelle), le type de données personnelles en cours de traitement, la durée de conservation des données personnelles, la licéité du traitement des données personnelles, les droits des personnes concernées ; notamment : les droits de la personne concernée, le droit d’être informé, le droit d’accès par la personne concernée, le droit à l’effacement, le droit à la restriction du traitement, le droit à la portabilité des données, le droit d’opposition, les droits relatifs à la prise de décision automatisée, y compris le profilage.
Loi américaine HIPAA Fournissez la preuve qu’il existe une stratégie de gestion HIPAA et HIPAA au sein de votre organisation pour le personnel, les sous-traitants, les fournisseurs, etc. Vérifiez que notre organisation garantit la confidentialité, l’intégrité et la disponibilité d’ePH.
Vérifiez que vous : fournissez une protection contre les utilisations raisonnablement anticipées ou les divulgations de telles informations qui ne sont pas autorisées par la règle de confidentialité, assurez-vous que son personnel se conforme à la règle de sécurité. Fournissez un plan de sauvegarde et de récupération d’urgence des données sous 164.308 (a)(7)(ii)(A) et 164.308 (a)(7)(ii)(B).

Révision facultative des frameworks de conformité externes

Bien que cela ne soit pas obligatoire, si vous êtes actuellement conforme à ISO 27001, PCI DSS, FedRAMP ou SOC2, vous pouvez choisir d’utiliser ces certifications pour satisfaire certains des contrôles de certification Microsoft 365. Les analystes essaieront d’aligner les frameworks de sécurité externes existants sur le framework de 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 de la 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 sécurité de la 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 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 ce cadre de certification Microsoft 365.
FedRAMP Le Federal Risk and Authorization Management Program (FedRAMP) est un programme fédéral américain mis en place en 2011. Il fournit une approche standardisée de l’évaluation de la sécurité, de l’autorisation et de la surveillance continue des produits et services cloud.
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 normes/frameworks 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 qu’une application réussira 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 dans l’étendue ET tous les processus métier de prise en charge 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.

En savoir plus