Vue d’ensemble du guide de preuve de l’exemple de certification Microsoft 365
Cet exemple de guide de preuve aide les éditeurs de logiciels indépendants à produire la preuve correcte requise pour effectuer la certification Microsoft 365. Ce document inclut l’intention de chaque contrôle et de toutes les sous-parties d’un contrôle, ainsi que les méthodes possibles de collecte de preuves pour les contrôles avec des exemples de documents de preuve, des stratégies et des captures d’écran. En outre, ce guide fournit de l’aide sur la façon de structurer les preuves soumises.
Les exemples partagés dans ce document ne représentent pas la seule preuve pouvant être utilisée pour prouver que les contrôles sont respectés. Il s’agit de lignes directrices pour le type de preuve qui peut aider les analystes de certification à déterminer si le contrôle a été respecté par l’éditeur de logiciels indépendant.
Remarque : les interfaces, captures d’écran et documentation réelles utilisées pour répondre aux exigences de certification varient en fonction de l’utilisation du produit, de la configuration du système et des processus internes. Notez que, lorsque la documentation de stratégie ou de procédure est requise, l’éditeur de logiciels indépendant doit envoyer des versions complètes des documents réels et non des captures d’écran, comme peut-être illustré dans certains exemples.
Toutes les captures d’écran qui doivent être envoyées doivent être des captures d’écran en plein écran avec n’importe quelle URL, utilisateur connecté (vérifiez que le nom de l’utilisateur connecté est visible dans la capture d’écran) avec l’horodatage inclus. Pour les systèmes Basés sur Linux, incluez ces informations avec/sur la preuve de contrôle en utilisant l’invite de commandes pour les produire.
TOUS les éléments de preuve soumis doivent être inférieurs à 3 mois pour s’assurer qu’au moment où vous terminez la certification, la preuve est toujours pertinente et non périmée. Si cela n’est pas suivi, vous pouvez être invité à recueillir de nouvelles preuves.
Notez également qu’aucune API bêta ne peut être utilisée pour les besoins de cette certification ou de tout exemple utilisé dans ce processus.
Il est recommandé de suivre ces recommandations pour éviter que votre évaluation ne soit retardée en raison d’une preuve insuffisante.
Remarque
Si vous avez démarré la certification Microsoft 365 avant le 12 décembre 2023, reportez-vous au guide des exemples de preuves hérités.
Structure de certification Microsoft 365
La certification a été structurée autour de trois domaines de sécurité :
Sécurité des applications (y compris les vérifications de connectivité si nécessaire)
Un test d’intrusion est requis pour la certification et sera examiné sous le domaine de sécurité de l’application. Pour plus d’informations, consultez les sections 3 et 4 de la structure de soumission des preuves.
Les domaines de sécurité sont divisés en groupes de contrôle pour aider les éditeurs de logiciels indépendants à comprendre la structure des tâches et à fractionner la collection de preuves en petits éléments gérables. Ces groupes de contrôle ont été alignés sur les structures de ressources d’entreprise courantes pour aider à identifier les équipes internes pour le support, tout en permettant aux équipes de travailler en parallèle pour accélérer le processus de collecte des preuves.
Contrôle(s) : Description de l’activité d’évaluation : ces contrôles et le numéro associé (No.) sont directement extraits de la liste de contrôle de certification Microsoft 365.
Intention : intention de la raison pour laquelle le contrôle de sécurité est inclus dans le programme et le risque spécifique qu’il est destiné à atténuer. L’espoir est que ces informations fourniront aux éditeurs de logiciels indépendants le raisonnement derrière le contrôle pour mieux comprendre les types de preuves qui doivent être collectés et ce à quoi les ISV doivent prêter attention et avoir une connaissance et une compréhension de la production de leurs preuves.
Exemples de recommandations en matière de preuves : données pour guider les tâches de collecte de preuves sur la certification Microsoft 365. Cela permet aux éditeurs de logiciels indépendants de voir clairement des exemples du type de preuve qui peuvent être utilisés par l’analyste de certification qui les utilisera pour déterminer avec certitude qu’un contrôle est en place et maintenu – il n’est pas exhaustif par nature.
Exemple de preuve : cette section fournit des exemples de captures d’écran et d’images de preuves potentielles capturées sur chacun des contrôles de la certification Microsoft 365, en particulier pour les domaines de sécurité opérationnelle et de sécurité des données et de confidentialité. Notez que toutes les informations avec des flèches rouges et des zones dans les exemples sont pour vous aider à mieux comprendre les exigences nécessaires pour répondre à n’importe quel contrôle.
Structure de soumission des preuves
La soumission de preuves sur tous les contrôles applicables sera effectuée par le biais de l’Espace partenaires, à l’exception des évaluations à l’appui de l’enregistrement de conformité Microsoft et des certifications du centre de contacts. Ceux-ci doivent généralement passer par un processus manuel. Ignorez cette section et consultez la section suivante concernant l’achèvement de la certification si vous enregistrez la conformité & centre de contact.
Pour vous assurer que les analystes de certification peuvent facilement identifier les preuves fournies et les examiner correctement, suivez ces recommandations :
Pour chacune des sections, assurez-vous que la preuve est clairement étiquetée avant la soumission. S’il y a plusieurs éléments de preuve par contrôle, veuillez placer la preuve dans un seul fichier word/pdf, y compris un commentaire de ce que la preuve montre. Si la preuve se compose de plusieurs documents word/pdf, c’est-à-dire de la documentation à l’appui, chargez-les sous forme de fichiers individuels. Veuillez ne pas les placer dans un fichier zip pour le chargement dans l’Espace partenaires, car nous n’acceptons pas les fichiers zip en raison du risque de programmes malveillants.
Toutes les informations de l’infrastructure externe doivent être fournies dans leur intégralité sans rédaction (nous n’autorisons que le nom partiel des personnes à être expurgés de ces rapports, car cela relèverait des informations d’identification personnelle (PII)) - Toutes les parties des rapports doivent être incluses, par exemple, déclaration d’applicabilité ISO 2001 et certificat, rapport SOC 2 type 2 complet et/ou attestation de conformité PCI-DSS complète (AOC). Tous les documents sont couverts par le contrat De l’Espace partenaires Microsoft en vertu de la Clause 7.
L’article 7(a) comprend la NDA suivante :
Un rapport complet de test d’intrusion non expurgé doit être envoyé via l’Espace partenaires lorsque vous y êtes invité . NOTEZ que si ce n’est pas le cas, les analystes de certification ne pourront pas effectuer l’audit de votre certification Microsoft 365.
Test d’intrusion de l’infrastructure interne et externe et des applications web : un rapport de test d’intrusion est requis pour tous les environnements d’hébergement.
Pour l’infrastructure en tant que service (IaaS) ou l’isV hébergé (centre de données privé local), un test d’infrastructure interne et externe et d’application web est requis.
Pour Platform as a Service « PaaS/Serverless », le test de stylet doit provenir de votre application web et de l’infrastructure de prise en charge sous-jacente.
Remarque : Test d’intrusion gratuit : le test gratuit du stylet Microsoft est limité à douze jours uniquement. Si, lorsque nous définissons votre test de stylet, votre application nécessite plus de 12 jours de test, vous serez invité à payer les jours supplémentaires. En outre, si vous avez besoin de tests de stylet en dehors des heures, cela entraîne également des coûts supplémentaires. Le service de test de stylet fourni est également limité à un test de stylet (y compris un nouveau test) par an, par exemple si votre test d’intrusion a été effectué le 1er septembre 2022, vous ne pourrez pas en obtenir un autre jusqu’au 31 août 2023.
Cela s’applique à toutes les tentatives d’envoi, ce qui signifie que cela s’applique à votre cycle de soumission actuel, ainsi que si vous décidez de fermer votre soumission actuelle et de redémarrer le processus plus tard dans la même année, vous n’aurez pas droit à un test de stylet supplémentaire, car un test avait déjà été effectué pour vous.
- Tous les éditeurs de logiciels indépendants doivent effectuer leur soumission initiale de document dans les 14 jours (y compris les retours et les transfert avec votre analyste) après avoir reçu l’e-mail de début de ticket de l’équipe d’administration Microsoft. Le délai de 14 jours est celui de l’achèvement complet, de l’examen et du passage de la présentation à l’étape de la preuve complète. Les éditeurs de logiciels indépendants doivent vérifier régulièrement si leur analyste a exigé des modifications ou a demandé des informations ou des documents supplémentaires. Pendant la période de 14 jours, les éditeurs de logiciels indépendants peuvent soumettre les informations requises autant de fois que nécessaire, mais gardez à l’esprit que si la soumission n’est pas activement en cours de travail, elle sera considérée comme obsolète et fermée dans l’Espace partenaires et la certification devra être redémarrée. Dans certaines circonstances, un ISV peut être fourni jusqu’à 30 jours pour l’achèvement. Si un éditeur de logiciels indépendant n’est pas en mesure d’effectuer l’envoi initial du document dans le délai imparti, sa soumission est fermée.
En outre, tous les éditeurs de logiciels indépendants doivent terminer leur certification dans les 60 jours suivant le déplacement de leur soumission de la phase initiale de soumission de documents à l’étape complète de collecte des preuves. Cela inclut les révisions et les commentaires fournis par l’évaluateur/auditeur tout au long du processus. Le délai de 60 jours correspond à l’achèvement complet, à l’examen et à l’assurance qualité finale de votre preuve, ce qui signifie que les éditeurs de logiciels indépendants doivent soumettre leur preuve au moins deux semaines avant la date d’achèvement pour s’assurer que la certification est terminée à temps. Pendant la période de 60 jours, les éditeurs de logiciels indépendants peuvent soumettre des preuves à l’Espace partenaires autant de fois que nécessaire. Toutefois, gardez à l’esprit que la soumission finale, comme indiqué, est au moins deux semaines avant la date d’achèvement pour donner aux analystes de certification le temps d’examiner et d’AQ la soumission. Une fois vos 60 jours écoulés, les éditeurs de logiciels indépendants devront recommencer le processus.
Si des problèmes surviennent pendant le processus de certification, l’analyste de certification peut accorder une extension potentielle pour des problèmes valides. Un analyste peut, à sa discrétion, accorder une prolongation de délai jusqu’à un maximum de 30 jours supplémentaires si les éditeurs de logiciels indépendants travaillent activement sur votre soumission. Notez qu’en cas de prolongation de 0 à 30 jours, l’ÉDITEUR de logiciels indépendant devra s’assurer que les preuves sont disponibles pour examen deux semaines avant la date de fin de la prolongation.
Si une prolongation est accordée, mais que la preuve date de plus de 3 mois, elle peut échouer à l’assurance qualité, car cette preuve peut potentiellement être considérée comme obsolète en raison de la durée entre le moment où elle a été fournie et l’assurance qualité finale, ce qui signifie que de nouvelles preuves pour ce ou ces contrôles seront nécessaires. Une fois le délai de prolongation terminé, il n’y aura plus de prolongation et l’ÉDITEUR de logiciels indépendants sera censé soumettre ses preuves (au moins deux semaines avant la fin de la prolongation), s’il n’est pas soumis, la soumission sera classée comme ayant échoué et sera fermée. Si aucun travail actif sur la soumission n’a commencé à un moment quelconque pendant les 60 jours initiaux ou pendant le délai de prolongation (jusqu’à 30 jours), la soumission sera classée comme abandonnée et sera fermée.
Si la soumission a été classée comme abandonnée, l’ISV devra redémarrer le processus avec une nouvelle attestation et de nouvelles preuves, car la preuve actuelle sera considérée comme obsolète. Notez que les éditeurs de logiciels indépendants ne sont autorisés qu’à une seule soumission par an. Si, pour une raison quelconque, un éditeur de logiciels indépendant abandonne le processus une fois qu’il est à l’étape complète de la collecte des preuves et que sa soumission a été marquée comme abandonnée, il ne pourra pas redémarrer le processus avant l’année suivante.
Structure de soumission manuelle des preuves : enregistrement de la conformité & centre de contacts
Pour vous assurer que les analystes de certification peuvent facilement identifier les preuves fournies et les examiner correctement, suivez ces recommandations pour la structure de soumission des preuves si vous les soumettez manuellement à la demande de l’équipe de certification.
Créez un document unique, qui peut être facilement consulté (par exemple, dans Word ou PDF) pour chaque groupe de contrôle de sécurité (par exemple, antivirus, gestion des correctifs, etc.).
Nommez le document unique après le groupe de contrôle de sécurité pour indiquer clairement ce que contient le document.
Ajoutez-y vos artefacts de preuve, référencez la documentation de soutien de votre organization qui prend en charge le groupe de contrôle et toutes les notes supplémentaires pour l’analyste de certification expliquant ce qu’est l’artefact et comment cette preuve répond au contrôle (cela aidera vos analystes de certification si vous nommez les images avec leurs numéros de contrôle, c’est-à-dire, Contrôle de sécurité des données et de confidentialité n° 1).
Remarque : N’oubliez pas que lorsque l’échantillonnage est utilisé, les artefacts doivent être extraits de chaque appareil dans l’exemple d’ensemble, vérifiez que l’artefact affiche également le nom du système pour vérifier que l’artefact provient de l’appareil en cours d’évaluation et qu’aucune donnée n’est masquée ou expurgée.
- Toutes les informations de l’infrastructure externe doivent être fournies dans leur intégralité sans rédaction (nous n’autorisons que le nom des personnes à être expurgés de ces rapports, car ceux-ci relèvent des informations d’identification personnelles) - Toutes les parties des rapports doivent être incluses, par exemple, déclaration d’applicabilité ISO 2001 (SOA) et certificat, rapport SOC 2 type 2 complet et/ou attestation complète d’attestation de conformité PCI-DSS (AOC) rapport HIPAA complet ou FedRAMP. Tous les documents sont couverts par le contrat De l’Espace partenaires Microsoft en vertu de la section 7.
L’article 7(a) comprend la NDA suivante :
Un rapport complet de test d’intrusion non expurgée doit être envoyé à l’analyste de certification lorsque celui-ci est demandé . VEUILLEZ NOTER QUE si ce n’est pas fourni, l’analyste de certification ne sera pas en mesure d’effectuer votre certification Microsoft 365.
Infrastructure interne et externe et application web : un rapport de test d’intrusion est requis pour tous les environnements d’hébergement.
Pour l’infrastructure en tant que service (IaaS) ou l’isV hébergé (centre de données privé local), un test d’infrastructure interne et externe et d’application web est requis.
Pour Platform as a Service « PaaS/Serverless », le test de stylet doit provenir de votre application web et de l’infrastructure de prise en charge sous-jacente.
Test d’intrusion gratuit : notez que le test gratuit du stylet Microsoft est limité à douze jours uniquement. Si une application nécessite plus de 12 jours de test, l’éditeur de logiciels indépendant est invité à payer les jours supplémentaires. En outre, si l’ÉDITEUR de logiciels indépendant nécessite des tests de stylet en dehors des heures normales d’ouverture en fonction de l’emplacement de l’auditeur, cela entraîne également des coûts supplémentaires. Le service de test de stylet fourni est limité à un test de stylet gratuit (y compris un nouveau test) par an par tentative de soumission.
- Tous les éditeurs de logiciels indépendants doivent effectuer leur soumission initiale de document dans les 14 jours (y compris les retours et les transfert avec votre analyste) après avoir reçu l’e-mail de début de ticket de l’équipe d’administration Microsoft. Le délai de 14 jours est celui de l’achèvement complet, de l’examen et du passage de la présentation à l’étape de la preuve complète. Les éditeurs de logiciels indépendants doivent vérifier régulièrement si leur analyste a exigé des modifications ou a demandé des informations ou des documents supplémentaires. Pendant la période de 14 jours, les éditeurs de logiciels indépendants peuvent soumettre les informations requises autant de fois que nécessaire, mais gardez à l’esprit que si la soumission n’est pas activement en cours de travail, elle sera considérée comme obsolète et fermée dans l’Espace partenaires et la certification devra être redémarrée. Dans certaines circonstances, un ISV peut être fourni jusqu’à 30 jours pour l’achèvement. Si un éditeur de logiciels indépendant n’est pas en mesure d’effectuer l’envoi initial du document dans le délai imparti, sa soumission est fermée.
En outre, tous les éditeurs de logiciels indépendants doivent terminer leur certification dans les 60 jours suivant le déplacement de leur soumission de la phase initiale de soumission de documents à l’étape complète de collecte des preuves. Cela inclut les révisions et les commentaires fournis par l’évaluateur/auditeur tout au long du processus. Le délai de 60 jours correspond à l’achèvement complet, à l’examen et à l’assurance qualité finale de votre preuve, ce qui signifie que les éditeurs de logiciels indépendants doivent soumettre leur preuve au moins deux semaines avant la date d’achèvement pour s’assurer que la certification est terminée à temps. Pendant la période de 60 jours, les éditeurs de logiciels indépendants peuvent soumettre des preuves à l’Espace partenaires autant de fois que nécessaire. Toutefois, gardez à l’esprit que la soumission finale, comme indiqué, est au moins deux semaines avant la date d’achèvement pour donner aux analystes de certification le temps d’examiner et d’AQ la soumission. Une fois vos 60 jours écoulés, les éditeurs de logiciels indépendants devront recommencer le processus.
Si des problèmes surviennent pendant le processus de certification, l’analyste de certification peut accorder une extension potentielle pour des problèmes valides. Un analyste peut, à sa discrétion, accorder une prolongation de délai jusqu’à un maximum de 30 jours supplémentaires si les éditeurs de logiciels indépendants travaillent activement sur votre soumission. Notez qu’en cas de prolongation de 0 à 30 jours, l’ÉDITEUR de logiciels indépendant devra s’assurer que les preuves sont disponibles pour examen deux semaines avant la date de fin de la prolongation.
Si une prolongation est accordée, mais que la preuve date de plus de 3 mois, elle peut échouer à l’assurance qualité, car cette preuve peut potentiellement être considérée comme obsolète en raison de la durée entre le moment où elle a été fournie et l’assurance qualité finale, ce qui signifie que de nouvelles preuves pour ce ou ces contrôles seront nécessaires. Une fois le délai de prolongation terminé, il n’y aura plus de prolongation et l’ÉDITEUR de logiciels indépendants sera censé soumettre ses preuves (au moins deux semaines avant la fin de la prolongation), s’il n’est pas soumis, la soumission sera classée comme ayant échoué et sera fermée. Si aucun travail actif sur la soumission n’a commencé à un moment quelconque pendant les 60 jours initiaux ou pendant le délai de prolongation (jusqu’à 30 jours), la soumission sera classée comme abandonnée et sera fermée.
Si la soumission a été classée comme abandonnée, l’ISV devra redémarrer le processus avec une nouvelle attestation et de nouvelles preuves, car la preuve actuelle sera considérée comme obsolète. Notez que les éditeurs de logiciels indépendants ne sont autorisés qu’à une seule soumission par an. Si, pour une raison quelconque, un éditeur de logiciels indépendant abandonne le processus une fois qu’il est à l’étape complète de la collecte des preuves et que sa soumission a été marquée comme abandonnée, il ne pourra pas redémarrer le processus avant l’année suivante.
Création de la structure de dossiers pour l’enregistrement de conformité & centre de contacts
Suivez ces instructions pour créer la structure de dossiers nécessaire à l’analyste pour examiner les preuves fournies.
Terminez l’envoi initial du document afin que les contrôles puissent être étendus. Fournissez autant de détails que possible et que le diagramme architectural et le diagramme de flux de données ont également le même niveau de détail.
Créez un dossier interne ou en ligne et ajoutez-y tous vos documents.
Étiqueter le dossier partagé réel Microsoft Certification
Ajoutez vos informations d’envoi de document initial dans le dossier Microsoft Certification dans un dossier appelé IDS.
Dans le dossier Certification, créez quatre dossiers portant les noms suivants :
Sécurité des applications (il s’agit des informations de test de votre stylet)
Conformité (pour vos frameworks externes tels que SOC 2)
Sécurité opérationnelle (OS)
Sécurité des données & Confidentialité (DS&P)
À l’intérieur des dossiers système d’exploitation et DS&P, créez des groupes de contrôles pour chaque ensemble de contrôles, par exemple programmes malveillants, mise à jour corrective, etc. où vous pouvez ajouter des documents pour chacun des contrôles (si vous souhaitez être spécifique, vous pouvez créer un dossier pour chaque contrôle individuel, ce qui vous permet de suivre plus facilement les preuves par le nom du contrôle ; dans ce cas, appelez ces dossiers Control X où X signifie le numéro de contrôle). Notez que vous ne pourrez pas créer la structure de dossiers secondaires tant que vos contrôles n’auront pas été étendus.
Exemple de structure de dossiers Dossiers racines :
Sous-dossiers dans le dossier « Evidence » :
Une fois que vous avez chargé des documents sur le partage, accordez l’autorisation au dossier partagé et envoyez un e-mail à l’analyste de certification avec les détails. Envoyez tous les mots de passe dans un e-mail distinct.
Lors de la collecte des preuves, n’oubliez pas de prendre des captures d’écran en plein écran montrant tout utilisateur connecté, l’URL et l’horodatage. Si vous utilisez Linux, cette opération peut être effectuée à partir de l’invite de commandes. Fournissez une explication si nécessaire pour chaque contrôle et n’oubliez pas que pour les stratégies, une copie complète de la stratégie et non des extraits de code ou des captures d’écran sont nécessaires.
Reportez-vous à ce document pour mieux comprendre le contrôle et le type de preuve dont nous avons besoin.
Les tests de stylet qui peuvent être nécessaires ne seront pas planifiés et vous ne recevrez pas de documentation pour démarrer le processus tant que 50 % de vos contrôles n’ont pas été approuvés. Le test de stylet sera gratuit pendant 12 jours uniquement, mais si votre test de stylet s’exécute sur 12 jours, vous devrez payer les jours supplémentaires à l’avance avant le début du test.
Une fois que vous recevez une copie de vos contrôles délimités pour recueillir des preuves sur les contrôles, votre graduation démarre : vous recevez un e-mail à cet effet, et vous disposez de 60 jours pour terminer l’ensemble du processus de certification, y compris le test du stylet.
Essayez de soumettre la première itération des contrôles dans les 30 jours pour permettre l’identification des problèmes et les révisions demandées avant l’expiration des 60 jours.
En savoir plus
- Sécurité des applications (y compris les vérifications de connectivité si nécessaire)
- Exemple de preuve : sécurité opérationnelle
- Exemple de preuve : sécurité et confidentialité des données