Partager via

Annexe et glossaire de la documentation sur la conformité des applications Microsoft 365

  • Article

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.

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.

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.