Data Security Requirements

Se préparer à répondre aux questions sur la sécurité des données

Flux de données

Créez (ou mettez à jour, si nécessaire) un diagramme ou une description du flux de données qui illustre la manière dont l’application ou le système traite les données de la plateforme.

1. Côté client : incluez tous les logiciels clients, tels que les navigateurs, les appareils mobiles et tout autre type d’appareil pris en charge.
2. Côté serveur : incluez tout environnement de serveur ou de cloud connexe et identifiez :
1. Les composants où les données de la plateforme :
1. Entrent ou sortent de l’environnement ou des environnements du serveur (par exemple, les listeners web et les API REST)
2. Sont écrites sur un support de stockage persistant ou durable, tel que des bases de données, des disques ou des fichiers journaux
2. Le modèle d’hébergement, par exemple :
1. Auto-hébergement : les propres serveurs d’une organisation fonctionnant dans un centre de données possédé ou partagé.
2. Infrastructure as a Service (IaaS) : comme AWS EC2, Microsoft Azure IaaS, et Google Compute Engine.
3. Platform as a Service (PaaS) : comme AWS Elastic Beanstalk, Google App Engine, Force.com.
4. Backend as a Service (BaaS) : comme AWS Amplify, Azure Mobile Apps, Firebase, et MongoDB Switch.
5. Hybride : une combinaison des modèles ci-dessus.

En fin de compte, le diagramme ou la description du flux de données devrait inclure :

1. L’endroit où les token d’accès à l’API Meta sont générés et transmis/stockés/renouvelés, dans les logiciels client et serveur (si cela s’applique à la conception du système)
2. La manière dont vous récupérez les données de la plateforme à partir des API de Meta, en particulier les informations personnellement identifiables (IPI) telles que le nom, l’adresse e-mail, le sexe, la date de naissance et d’autres données des utilisateurs
3. Comment vous utilisez, stockez et transmettez ces données
4. Toute 4e partie à laquelle les données de la plateforme sont envoyées

Préparer vos justificatifs

Vous devrez peut-être fournir des justificatifs étayant vos réponses liées aux fonctionnalités de protection de la sécurité des données que vous mettez en œuvre. Nous vous recommandons de consulter le Guide des justificatifs dans ce document pour découvrir des exemples de justificatifs acceptables et les préparer en conséquence. Nous acceptons les types de fichiers courants, ainsi que les captures et les enregistrements d’écran. Veillez à ce que les fichiers ne soient pas protégés par un mot de passe. Vous pouvez importer plusieurs fichiers d’une taille maximale de 2 Go chacun. Nous acceptons les formats suivants : .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip et .zipx.

Types de justificatifs

Pour les applications invitées à importer des justificatifs relatifs aux fonctionnalités de protection de la sécurité des données, Meta exige deux types de documents différents :

1. Justificatif de politique ou de procédure : un document de politique ou de procédure qui explique l’approche en matière de sécurité des données pour [cette fonctionnalité de protection].
2. Justificatif de mise en œuvre : justificatifs du système ou de l’application, comme une configuration d’outil ou une capture d’écran, qui montrent comment vous avez mis en œuvre une fonctionnalité de protection en particulier.

Justificatif de politique ou de procédure

Les justificatifs de politique ou de procédure, parfois appelés contrôle administratif, sont des documents écrits qui décrivent l’approche d’une fonctionnalité de protection de la sécurité des données en particulier. Ils peuvent prendre différentes formes : il peut s’agir d’un extrait d’un ensemble de politiques internes, d’une partie ou de la totalité d’une page wiki interne, ou d’un document nouvellement créé que vous utilisez pour décrire l’approche si vous n’avez pas de documentation préexistante. Dans tous les cas, les justificatifs de politique ou de procédure que vous importez doivent expliquer clairement comment l’approche d’une fonctionnalité de protection en particulier se rapporte aux exigences de Meta. Veillez à ne fournir que la politique ou le contenu pertinent et nécessaire pour l’examen de sécurité de Meta, ou utilisez le champ de texte libre associé à la question pour orienter nos équipes d’examen vers la ou les sections pertinentes.

Justificatif de mise en œuvre

Les justificatifs de mise en œuvre illustrent la façon dont vous avez mis en pratique la politique ou la procédure, directement par le biais d’une capture ou d’un enregistrement d’écran. Les équipes de développement disposant de configurations différentes, nous ne pouvons pas fournir d’exemples pour tous les scénarios. Cela dit, les justificatifs de mise en œuvre doivent, dans la mesure du possible, présenter le même niveau de détail que les exemples que nous avons fournis.

Exhaustivité des justificatifs

Nous comprenons qu’il peut être très difficile de préparer des justificatifs de mise en œuvre qui prouvent de manière exhaustive la mise en œuvre d’une fonctionnalité de protection de la sécurité des données en particulier. Dans cette optique, vous devez envoyer les justificatifs conformément aux conseils fournis ici, en prenant soin de supprimer les informations sensibles qui y figurent avant envoi :

1. Les justificatifs de politique ou de procédure doivent clairement satisfaire ou dépasser les exigences de Meta.
1. Meta examinera les justificatifs de politique ou de procédure pour mettre en œuvre ses exigences relatives à la fonctionnalité de protection concernée.
2. Vous devez annoter le document pour mettre les sections pertinentes en évidence.
3. Par exemple, en ce qui concerne la protection « Activer TLS 1.2 ou une version supérieure pour toutes les connexions réseau où les données de la plateforme sont transmises », un justificatif acceptable comprendrait un document qui indique clairement ce qui suit :
1. Les données de la plateforme Meta ne doivent jamais être transmises sur des réseaux non fiables dans un format non chiffré.
2. Tous les auditeurs web (par exemple, les équilibreurs de charge orientés vers Internet) qui reçoivent ou renvoient des données de la plateforme seront configurés de manière à ce que TLS 1.2 soit activé.
3. Tous les auditeurs web qui reçoivent ou renvoient des données de la plateforme seront configurés de manière à ce que les protocoles suivants soient désactivés : SSL v2, SSL v3, TLS 1.0 et TLS 1.1
2. Un justificatif de mise en œuvre doit montrer un ou plusieurs exemples de la mise en œuvre de chaque politique ou procédure.
1. Vous devez importer un ou plusieurs documents, captures d’écran ou configurations d’outils qui illustrent la façon vous avez mis en œuvre chaque fonctionnalité de protection.
2. Meta examinera les justificatifs de mise en œuvre pour s’assurer qu’ils sont conformes aux justificatifs de politique ou de procédure.
3. Par exemple, en ce qui concerne la protection Activer TLS 1.2 ou une version supérieure pour toutes les connexions réseau où les données de la plateforme sont transmises, un justificatif acceptable comprendrait le rapport de test SSL Qualys pour l’un des domaines web configurés conformément à la politique ou à la procédure.

Données sensibles à supprimer des justificatifs

N’envoyez pas de justificatifs qui contiennent l’une de ces valeurs sous une forme lisible (non supprimée). Si vous utilisez un éditeur d’images pour une capture d’écran, recouvrez les valeurs d’un rectangle noir. Si vous utilisez un éditeur PDF, assurez-vous de rédiger le texte à l’aide d’un outil qui supprime réellement les valeurs plutôt que de simplement ajouter une couche tout en préservant le texte (par exemple, l’outil de rédaction de l’application Aperçu d’Apple).

• Données de santé
• Données financières
• Adresses IP
• Mots de passe, identifiants et tokens d’accès
• Clés de chiffrement
• Adresses postales
• Les informations à caractère personnel (ou PII) concernant une personne physique (entreprises ou organisations exclues), un membre du personnel ou d’autres personnes affiliées qui pourraient permettre d’identifier une personne directement ou indirectement, par exemple :

  • Nom
  • Adresses e-mail
  • ID d’utilisation
  • Dates de naissance
  • Données de lieu
  • Données de santé
  • Identité culturelle, sociale, politique
  • Données qui pourraient autrement permettre d’identifier une personne dans le contexte spécifique du justificatif
• Étapes détaillées de reproduction des vulnérabilités (par exemple, dans un rapport de test de pénétration)
• Données dont les équipes de développement savent ou devraient raisonnablement savoir qu’elles proviennent d’enfants de moins de 13 ans ou les concernent

Se protéger contre la perte des Données de la Plateforme stockées sur les appareils de l’organisation et les supports amovibles

Question : En ce qui concerne spécifiquement les données stockées sur des appareils personnels et de l’organisation : Imposez-vous le chiffrement au repos ou avez-vous mis en place des politiques et de règles visant à réduire le risque de perte de données, pour toutes les Données de la Plateforme stockées sur ces appareils ?

Intention

Si un développeur permet la présence de Données de la Plateforme dans des appareils comme les ordinateurs portables des employés ou les supports de stockage amovibles (par ex. les clés USB), ces données sont exposées à un risque élevé d’accès non autorisé en cas de perte ou de vol des appareils. Les développeurs devraient prendre des mesures pour limiter ce risque.

Résumé des exigences

• Pour réduire les risques d’accès non autorisé aux Données de la Plateforme, les Développeurs doivent mettre en place des solutions pertinentes de contrôle technique (option privilégiée) ou administratif (option non privilégiée mais valable) sur les appareils de l’organisation (par ex. les ordinateurs portables) et les supports amovibles.

  • Solutions de contrôle technique - il peut s’agir par exemple de : 1) N’autoriser la connexion au réseau de l’entreprise qu’aux appareils gérés, 2) Imposer le chiffrement sur la totalité du disque des appareils gérés (par ex. BitLocker), 3) Bloquer la connexion des supports amovibles (par ex. les clés USB) aux appareils gérés, 4) Utiliser la technologie de prévention de la perte de données sur les appareils gérés.
  • Solutions de contrôle administratif - il peut s’agir par exemple de règles écrites et de formations annuelles sur la bonne façon de gérer les Données de la Plateforme sur les appareils personnels et de l’organisation.

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

Vous pouvez utiliser l’une de ces solutions ou les deux : a) contrôles techniques (par ex. chiffrement du disque), ou b) règles/politiques pour réduire le risque de perte des Données de la Plateforme stockées sur les appareils de l’organisation, comme les ordinateurs portables ou les téléphones mobiles.

Les contrôles techniques peuvent consister à :

• Bloquer la connexion des appareils non gérés à des services sensibles comme le réseau de production.
• Imposer le chiffrement du disque sur les appareils gérés (par ex. via BitLocker sur Windows ou FileVault sur Mac).
• Bloquer l’utilisation de supports amovibles (par ex. les clés USB) sur les appareils gérés.
• Utiliser un logiciel de prévention de la perte de données sur les appareils gérés afin d’empêcher la mauvaise gestion des Données de la Plateforme (par ex. leur envoi en pièce jointe dans e-mail).

Les règles/politique peuvent comprendre :

• Des documents décrivant les manières valables et non valables de gérer les données en général, et les Données de la Plateforme en particulier.
• Un mécanisme de transmission des règles aux membres de l’organisation (par ex. un accord contractuel à signer lors de l’embauche, des formations, des rappels périodiques par e-mail).

Exemples de justificatifs

Une organisation classe les Données de la Plateforme de Meta comme « données confidentielles » dans le cadre de sa politique de classification des données. Elle a créé un Règlement sur la gestion des données que tout le personnel est tenu de comprendre et respecter.

Protéger les données de la plateforme transmises sur les réseaux avec un chiffrement en transit

Question : Activez-vous le protocole de sécurité TLS 1.2 ou supérieur pour toutes les connexions réseau qui passent par, ou connectent, ou traversent des réseaux publics où les Données de la Plateforme sont transmises ? De plus, veillez-vous à ce que les données de la plateforme ne soient jamais transmises via des réseaux publics de façon non chiffrée (ex. via HTTP ou FTP), et à ce que les protocoles de sécurité SSL v2 et SSL v3 ne soient jamais utilisés ?

Intention

Les Données de la Plateforme transmises sur Internet sont accessibles à quiconque peut observer le trafic réseau. Il faut donc les protéger à l’aide du chiffrement pour éviter que les parties non autorisées puissent les lire.

• Le chiffrement du transfert protège les Données de la Plateforme lorsqu’elles sont transmises sur des réseaux non fiables (par ex. Internet) en les rendant indéchiffrables, sauf pour les appareils d’origine et de destination
• Autrement dit, les intermédiaires du transfert ne peuvent pas lire les Données de la Plateforme, même s’ils peuvent voir le trafic réseau (évitant ainsi les attaques de l’homme du milieu)
• La TLS est la modalité de chiffrement en transit la plus répandue, s’agissant de la technologie utilisée par les navigateurs pour sécuriser les communications vers les sites web comme ceux des banques

Résumé des exigences

Indépendamment du fait que vous traitiez ou non les données de la plateforme côté serveur :

• Les données de la plateforme ne doivent jamais être transmises sur des réseaux non fiables dans un format non chiffré.
• Pour tous les auditeurs web (par exemple, les équilibreurs de charge orientés vers Internet) qui reçoivent ou renvoient des données de la plateforme, vous devez :

  • Activer TLS 1.2 ou versions ultérieures
  • Désactiver SSL v2 et SSL v3
• TLS 1.0 et TLS 1.1 ne peuvent être utilisés qu’à des fins de compatibilité avec les appareils clients qui ne peuvent pas utiliser TLS 1.2+.
• Meta recommande, mais ne requiert pas, que le chiffrement en transit soit appliqué aux transferts de données de la plateforme qui sont entièrement au sein de réseaux privés, par exemple, au sein d’un cloud privé virtuel (VPC).

Le tableau ci-dessous résume la politique de chiffrement en transit pour différents types de transferts.

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place. Une façon simple de produire des justificatifs de mise en œuvre qui démontrent la configuration de l’un des auditeurs web est d’utiliser l’outil Qualys SSL Server Test.

• Exécuter l’outil Qualys SSL Server Test contre un ou plusieurs auditeurs web configurés de manière identique (y compris ceux qui fonctionnent sur des ports non standard).
• Cocher l’option « Ne pas afficher les résultats sur les tableaux » pour empêcher l’ajout des résultats sur le site web de Qualys. Imprimer l’ensemble de la page des résultats du test au format PDF Répétez les étapes ci-dessus pour tous les auditeurs web auxquels vous transférez des données de la plateforme et à partir desquels vous avez une configuration TLS différente.

Exemple de justificatif de mise en place

Voici un exemple de sortie de l’outil Qualys SSL Server Test. Noter les annotations rouges dans la section Configuration, qui résume les versions SSL/TLS prises en charge. Remarque : cet exemple ne comprend que les deux premières pages, mais vous devriez inclure la totalité du résultat du test.

Mesures de protection alternatives valables

Vous pouvez protéger les données de la plateforme en transit en utilisant un autre type de chiffrement que TLS ; cela peut être acceptable si l’approche fournit une protection équivalente. En l’espèce, vous devez fournir des détails sur le chiffrement utilisé afin que Meta puisse l’examiner :

• Chiffrement symétrique ou asymétrique ?
• Algorithme de chiffrement (par exemple, AES, BitLocker, TDES, RSA) ?
• Quelle est la longueur minimale de la clé ?

Tester l’application et les systèmes pour identifier d’éventuelles vulnérabilités et problèmes de sécurité

Question : testez-vous l’application et les systèmes pour identifier d’éventuelles vulnérabilités et problèmes de sécurité au moins tous les 12 mois ? (Effectuez-vous par exemple un test d’intrusion manuel ?)

Intention

Les équipes de développement doivent tester les vulnérabilités et problèmes de sécurité afin de les détecter proactivement, en évitant dans l’idéal les incidents de sécurité avant qu’ils ne se produisent.

• Équipes de développement d’applications qui utilisent la plateforme Meta pour traiter les données de la plateforme avec des logiciels qu’ils rédigent via des applications/systèmes qu’ils configurent et exploitent.
• Les logiciels et les configurations des systèmes peuvent contenir des vulnérabilités de sécurité susceptibles d’être exploitées par des personnes malintentionnées, ce qui entraînerait l’accès non autorisé à des données de la plateforme.

Résumé des exigences

Exigences pour toutes les équipes de développement :

• Vous devez avoir testé le logiciel utilisé pour traiter les données de la plateforme en vue de détecter les vulnérabilités de sécurité en effectuant l’une ou l’autre des opérations suivantes :

  • Un test d’intrusion dans l’application ou le système, ou
  • Une analyse de vulnérabilité/analyse statique du logiciel
• Le résultat du test doit montrer qu’il n’existe pas de vulnérabilités critiques ou très graves non réglées.
• Le test doit avoir été réalisé au cours des 12 derniers mois.

Exigences supplémentaires pour les équipes de développement qui traitent les données de la plateforme côté serveur :

• Vous devez avoir testé spécifiquement les logiciels côté serveur pour détecter les vulnérabilités de sécurité, en effectuant :

  • Un test d’intrusion dans l’application ou le système, ou
  • Une analyse de vulnérabilité/une analyse statique. Vous devez également avoir testé la configuration cloud pour détecter d’éventuels problèmes de sécurité si vous utilisez un fournisseur d’hébergement cloud. Cette exigence s’applique quelle que soit l’approche en matière d’hébergement (par exemple, BaaS, PaaS, IaaS, auto-hébergé ou hybride).

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

Si l’organisation traite les données de la plateforme dans un environnement cloud ou de serveur :

• Fournissez un justificatif prouvant qu’un test d’intrusion ou l’exécution d’un outil SAST ont été réalisés. Le justificatif doit comprendre :

  • Une indication du champ d’application du test.
  • La date à laquelle le test a été effectué (cette date doit être comprise dans les 12 derniers mois).
  • Soit un résumé, soit une liste des vulnérabilités détectées lors du test. Le résumé ou la liste doit comprendre une catégorisation de la gravité (par exemple, critique, élevée, moyenne, faible, informative). Il ne devrait pas exister de vulnérabilités critiques ou très graves non réglées.

• Le cas échéant (c’est-à-dire si vous utilisez un hôte cloud comme AWS, GCP, Azure ou un hôte similaire), envoyez un justificatif indiquant qu’un examen de la configuration cloud a été entrepris. Il peut s’agir par exemple du résultat d’une exécution de NCC Scout Suite, AWS Config ou d’un outil similaire. Si cela n’est pas applicable à l’organisation, ajoutez un document qui explique pourquoi un examen de la configuration cloud n’est pas pertinent dans ce cas.
• Supprimez les informations sensibles, comme les étapes détaillées de reproduction de la vulnérabilité, des justificatifs avant de les envoyer.

Si l’organisation ne traite PAS les données de la plateforme dans un environnement cloud ou de serveur :

• Fournissez un justificatif prouvant qu’un test d’intrusion ou l’exécution d’un outil SAST ont été réalisés. Le justificatif doit comprendre :

  • Une indication du champ d’application du test.
  • La date à laquelle le test a été effectué (cette date doit être comprise dans les 12 derniers mois).
  • Soit un résumé, soit une liste des vulnérabilités détectées lors du test. Le résumé ou la liste doit comprendre une catégorisation de la gravité (par exemple, critique, élevée, moyenne, faible, informative). Il ne devrait pas exister de vulnérabilités critiques ou très graves non réglées.
• Supprimez les informations sensibles, comme les étapes détaillées de reproduction de la vulnérabilité, des justificatifs avant de les envoyer.

Exemples de justificatifs

Test d’intrusion : une organisation commande un test d’intrusion de son logiciel fonctionnant côté serveur qui s’intègre aux API Meta et traite les données de la plateforme. L’entreprise de test termine ce dernier et produit une lettre de synthèse semblable à celle présentée ci-dessous. Les annotations rouges indiquent la date à laquelle le test a eu lieu (dans les 12 derniers mois). On trouve également un résumé des résultats de gravité critique/élevée non résolus à la fin du test (ou du second test, le cas échéant). N’oubliez pas de supprimer les informations sensibles du rapport (en particulier toute étape détaillée de reproduction de la vulnérabilité) avant de l’envoyer.

Analyse statique : si vous utilisez une approche différente, par exemple un outil SAST, exportez les résultats dans un document qui comprend la date d’exécution du SAST et une liste de résultats comprenant le type de chaque résultat et sa gravité ou son état critique.

Examen de la configuration cloud

Une équipe de développement utilise NCC Scout Suite en utilisant l’ensemble de règles par défaut de son fournisseur cloud (dans ce cas, AWS) pour examiner sa configuration cloud en quête de vulnérabilités et de problèmes de sécurité. L’outil produit un fichier JSON contenant les résultats détaillés de l’exécution. Dans cet exemple, on constate un certain nombre de problèmes dont la gravité correspond à un « danger », et que l’équipe de développement doit examiner et résoudre.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Autre approche d’examen de la configuration cloud pour les équipes de développement utilisant l’ensemble de règles d’Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

\\\\\Mesures de protection alternatives valables

Si vous exploitez un programme de divulgation des vulnérabilités (VDP) opérationnel, par exemple à l’aide des plateformes BugCrowd ou HackerOne, vous pouvez le présenter comme une fonctionnalité de protection alternative au lieu d’un test d’intrusion ou d’une analyse de vulnérabilité. Pour le prouver, vous devez soumettre des justificatifs selon lesquels :

• Il n’y a pas d’exclusions au champ d’application du VDP concernant la manière dont vous traitez les données de la plateforme.
• Il existe des recherches et des rapports sur les vulnérabilités au cours des 12 derniers mois, ce que prouve généralement au moins un rapport valide sur les vulnérabilités par mois.
• Les vulnérabilités (valables) envoyées se voient attribuer un score de gravité, par exemple en utilisant CVSS 3.1.
• Les vulnérabilités sont résolues dans un délai raisonnable, généralement moins de 90 jours après la date d’envoi.

Dans ce cas, les justificatifs doivent comprendre :

• Une déclaration sur le champ d’application et la manière dont il est lié au logiciel utilisé pour traiter les données de la plateforme.
• Et un rapport sur les véritables signalements de vulnérabilité dans le programme au cours des 12 derniers mois. Le rapport doit comprendre le titre de la vulnérabilité, la date d’envoi, la date de résolution (le cas échéant) et la catégorie/le score de gravité.

Protégez la clé secrète et les tokens d’accès de l’API Meta

Question : La clé secrète et les tokens d’accès de l’API Meta sont-ils protégés de l’une des manières suivantes ?

1. En ne stockant jamais les tokens d’accès de l’API Meta sur les appareils de clients là où ils peuvent être accessibles en dehors de l’application et de l’utilisateur actuels.
2. En utilisant une base de données (par ex. Vault by Hashicorp) avec un service de gestion des clés distinct si celles-ci sont stockées sur un environnement de cloud, de serveur ou de data center.

Intention

La clé secrète et les tokens d’accès sont essentiels à la sécurité des décisions prises par l’API Meta concernant les actions à autoriser. Si une partie non autorisée accédait à ces identifiants, elle pourrait appeler les API de Meta, en usurpant l’identité du vrai développeur, et réaliser l’une des actions que nous avons accordées à l’application (par ex. lire des données de l’API Meta sur les utilisateurs de l’application).

• Vous avez accès à des identifiants sensibles dans le cadre de votre utilisation de la plateforme Meta. Plus particulièrement :

  • Token d’accès - lorsqu’un utilisateur autorise l’application, le logiciel obtient un identifiant appelé « token d’accès », utilisé dans les appels d’API suivants.
  • Clé secrète - Meta partage une clé secrète avec les développeurs, étant attendu que seules les parties de confiance (par ex. les admins d’application) au sein de l’organisation aient accès à cette clé.
• Une partie non autorisée capable de lire ces identifiants sensibles peut les utiliser pour appeler les API de Meta en se faisant passer pour vous (cela reçoit parfois le nom d’usurpation de token), ce qui risque d’aboutir à un accès non autorisé aux Données de la Plateforme.
• En conséquence, ces identifiants doivent être protégés de l’accès non autorisé afin d’éviter l’usurpation.

Résumé des exigences

Tokens d’accès

1. Sur les appareils de clients - Les tokens d’accès de Meta ne doivent pas être écrits de sorte qu’un autre utilisateur ou processus puisse les lire.
2. Côté serveur - si vous traitez ou stockez des tokens d’accès Meta côté serveur, ces derniers :
1. Doivent être protégés en utilisant une base de données (par ex. Vault by Hashicorp) avec un service de gestion des clés distinct et avec un accès à la clé de déchiffrement limité à l’application.
2. Ne doivent pas être écrits dans des fichiers journaux

Clé secrète - l’une de ces deux exigences doit être respectée :

1. Vous n’exposez jamais la clé secrète en dehors d’un environnement serveur sécurisé (par ex. la clé secrète n’est jamais renvoyée par un appel réseau à un navigateur ou à une application mobile et la clé n’est pas intégrée dans un code distribué aux clients mobile ou natifs/de bureau).
2. Ou vous devez avoir configuré l’application avec le type natif/bureau de sorte que l’API Meta n’accepte plus les appels d’API incluant la clé secrète.

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

Incluez des documents sur le règlement visant à protéger les tokens d’accès de l’API Meta et la clé secrète. Si l’application traite les tokens d’accès Meta côté serveur, incluez un justificatif des mesures de protection que vous appliquez (par ex. utiliser un modèle de base de données de type vault, démontrer que les valeurs sont stockées sous forme chiffrée, configurer l’application de manière à exiger des preuves de clé secrète).

Exemples de justificatifs

Une organisation utilise AWS Secrets Manager pour le stockage sécurisé des données sensibles, et notamment de la clé secrète Meta.

Une organisation a configuré son application Meta pour demander une preuve de clé secrète pour les appels d’API :

Mesures de protection alternatives valables

1. Si vous ne protégez pas les tokens d’accès stockés côté serveur avec une base de données de type vault ou via un chiffrement au niveau de l’application, vous pouvez :
1. Protéger la clé secrète en utilisant une salle des coffres ou en chiffrant l’application lorsque la clé n’est accessible que par l’application
2. Et configurer l’application de manière à demander une preuve de clé secrète pour tous les appels d’API à Meta
2. Si l’approche no1 n’est pas valable (impossibilité de demander une preuve de clé secrète sous peine de bloquer certains appels d’API nécessaires), Meta prendra en compte tous les autres contrôles que vous avez mis en place pour limiter le risque d’utilisation non autorisée des tokens d’accès en fonction du risque d’utilisation détournée associé.

Mettez en place un plan de réponse en cas d’incident et testez les systèmes et processus d’intervention correspondants

Question : Testez-vous les systèmes et processus que vous utiliseriez pour répondre à un incident de sécurité (par ex., une violation de données ou une cyberattaque) au moins tous les 12 mois ?

Intention

Tôt ou tard, toutes les entreprises sont touchées par des incidents de sécurité. Il est donc essentiel que les organisations prévoient à l’avance quelles personnes seront chargées de traiter l’incident et de quelle manière, de communiquer avec les parties prenantes, de le régler et d’en tirer les leçons pour l’avenir.

• Face à un incident de sécurité, en ayant préparé un plan ou un guide et une équipe formée pour réagir au mieux, la durée de l’incident peut être réduite et à l’arrivée, l’exposition des Données de la Plateforme se trouve limitée.
• Bien que le niveau de sophistication de la réponse en cas d’incident varie selon les organisations, nous exigeons au moins un plan de base incluant des actions indispensables, comme détecter, réagir, opérer un retour à la normale et vérifier, avec les fonctions et responsabilités attribuées à chaque membre du personnel.

Résumé des exigences

Le développeur doit avoir mis en place :

• Un plan de réponse en cas d’incident conforme aux critères minimaux de Meta.
• Ce document doit inclure (au moins) : (1) les rôles et responsabilités, (2) la détection, (3) les étapes du processus d’intervention d’après ce qui est exigé par la loi (par ex. la notification de la violation des données aux autorités de contrôle pertinentes et aux titulaires des données) et rétablissement, et (4) un processus d’examen après l’incident
• Des justificatifs montrant que le plan a été récemment testé (au cours des 12 derniers mois) et que tout le personnel identifié dans le plan y a effectivement participé.

Guide des justificatifs

Veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

• Envoyez le plan de réponse en cas d’incident (un ou plusieurs documents). Il devrait contenir les aspects suivants : rôles et responsabilités, détection, réaction et rétablissement et examen après l’incident.

  • Si vous ne possédez pas de plan de réponse en cas d’incident, il existe de nombreuses ressources disponibles sur Internet qui pourraient vous aider. Consultez par exemple le modèle de plan de réponse en cas d’incident de Counteractive, ainsi que des références et lectures supplémentaires
• Envoyez un justificatif montrant que vous avez testé le plan au cours des 12 derniers mois. Ce justificatif peut revêtir plusieurs formes, mais il devrait toujours inclure :

  • Une description d’un cas de figure (par ex. un exercice de simulation de réponse à une attaque par rançonlogiciel).
  • La date á laquelle le test a été réalisé.
  • Le rôle rempli par chaque participant.
  • Et si un membre du personnel identifié dans la section des rôles et responsabilités du plan ne participe pas, la justification de cette absence.
• Veuillez retirer les informations sensibles (par ex. les informations personnelles identifiables comme le nom et l’adresse e-mail) du justificatif avant de l’envoyer. Exemple de justificatif.

Plan de réponse en cas d’incident

Un développeur a créé un plan de réponse complet aux incidents d’après ce modèle. Ces images représentent seulement la table des matières, mais un lien vers l’intégralité du modèle figure en dessous.

Voir le modèle de plan de réponse en cas d’incident de Counteractive (format docx)

Test d’intervention en cas d’incident

Un développeur a mené un test sur son plan de réponse en cas d’incident via un exercice de simulation et il a noté les résultats en utilisant ce modèle.

Exiger l’authentification à plusieurs facteurs pour l’accès à distance

Question : Exigez-vous l’authentification à plusieurs facteurs pour l’accès à distance à chaque compte pouvant se connecter au cloud ou à l’environnement serveur et/ou pour accéder aux services que vous utilisez afin de déployer, assurer la maintenance de, surveiller et exploiter les systèmes dans lesquels vous stockez des Données de la Plateforme de Meta ?

Intention

Une technique ordinaire utilisée par les adversaires pour accéder aux données confidentielles consiste à commencer par obtenir l’accès aux outils utilisés par le développeur pour créer ou exploiter son application/système. Il existe des outils sophistiqués permettant de pirater les comptes protégés seulement par des mots de passe ; l’authentification à plusieurs facteurs offre un niveau de sécurité supplémentaire contre ce risque.

• Les développeurs de logiciel utilisent différents outils pour développer, déployer et administrer leurs applications/systèmes.
• Il est courant d’utiliser ces outils à distance sur Internet (par ex. un employé en télétravail qui expédie une nouvelle fonction de logiciel ou met à jour la configuration du cloud).
• Les outils protégés par une authentification à un seul facteur (nom d’utilisateur et mot de passe) sont fortement exposés au risque de piratage par prise de contrôle du compte. Par exemple, les pirates peuvent les utiliser pour tester des combinaisons de nom d’utilisateur et mot de passe ayant fuité d’un outil pour accéder à un autre outil.
• L’authentification à plusieurs facteurs protège contre ce type d’attaques en demandant un facteur supplémentaire lors de la connexion, en plus du mot de passe. Il peut s’agir par exemple d’un code généré par une application d’authentification.

Résumé des exigences

Dans le cadre du traitement des Données de la Plateforme par une organisation, l’accès à distance à ces outils doit être protégé par l’authentification à plusieurs facteurs (c’est à dire pas simplement par un mot de passe) :

• Outils utilisés pour déployer et gérer les changements de code/configuration dans l’application/le système.
• Accès administratif à un cloud ou à un environnement serveur, le cas échéant.

Plus particulièrement, l’authentification à plusieurs facteurs ou une autre mesure de protection valable sont exigées dans les cas suivants :

• Outils de collaboration/communication, par exemple e-mail professionnel ou Slack.
• Dépôt de code, par ex. GitHub ou un autre outil utilisé pour établir un suivi des modifications de l’application/du code du système/de la configuration.
• Et si vous traitez des Données de la Plateforme côté serveur :

  • Outils de déploiement de logiciel - outils utilisés pour déployer le code dans le cloud/un environnement serveur, par ex. Jenkins ou un autre outil d’intégration continue/déploiement continu (CI/CD).
  • Outils administratifs - portail ou autre accès utilisé pour gérer/surveiller le cloud ou l’environnement serveur.
  • Accès à distance aux serveurs - SSH, bureau à distance ou outils semblables utilisés pour se connecter à distance aux serveurs fonctionnant côté serveur.

En ce qui concerne la mise en place de l’authentification à plusieurs facteurs :

• Il est recommandé d’utiliser un dispositif ou une application d’authentification (par ex. YubiKey) plutôt que des codes envoyés par SMS.
• Mais les organisations peuvent utiliser n’importe quelle mise en place d’authentification à plusieurs facteurs.

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

• Le justificatif de mise en place devrait montrer que l’authentification à plusieurs facteurs a été installée sur les outils applicables à l’environnement indiqués plus haut (c’est à dire les outils de collaboration, les dépôts de code, le déploiement dans le cloud/sur un serveur, les portails administratifs dans le cloud/sur un serveur, l’accès à distance au cloud/à un serveur).
• La mise en place varie en fonction de la configuration :

  • Par exemple, si vous utilisez un fournisseur SSO, il peut s’agir de la capture d’écran de la configuration générale pour l’organisation ou d’une capture d’écran de la configuration par application.
  • Si vous n’avez pas de fournisseur SSO, il peut s’agir de la capture d’écran de la configuration d’un outil spécifique.
• Dans tous les cas, il nous faut une preuve de l’activation de l’authentification à plusieurs facteurs pour tous les utilisateurs, pas simplement un exemple de compte sur lequel cette authentification aurait été activée.

Exemples de justificatifs

AzureAD

Une organisation utilise AzureAD comme solution d’authentification unique. Ce règlement exige une authentification à plusieurs facteurs.

Ce règlement est alors associé aux applications cloud auxquelles il est applicable. En utilisant cette approche, le justificatif devrait refléter la totalité de la section Éléments sélectionnés afin d’indiquer clairement quelles applications cloud exigent l’authentification à plusieurs facteurs.

Okta

Cette règle demande l’authentification à plusieurs facteurs pour toutes les connexions.

AWS IAM

Voici un exemple de politique AWS IAM qui permet la configuration de l’authentification à plusieurs facteurs mais qui interdit d’autres actions en l’absence de cette dernière.

GitHub

Une organisation a configuré l’authentification sur GitHub de manière à exiger l’authentification à plusieurs facteurs pour tous les membres de l’organisation.

Mesures de protection alternatives valables

• Pour tous les types d’accès à distance existant au sein de l’organisation sur lesquels l’authentification à plusieurs facteurs n’a pas été mise en place, vous devriez indiquer si vous avez recours à une ou plusieurs des approches suivantes pour éviter les prises de contrôle de compte :

  • Mot de passe fort exigé - par ex., un minimum de complexité pour le mot de passe, interdiction des mots figurant dans le dictionnaire, interdiction de mots de passe connus pour avoir été déjà compromis.
  • Report de l’authentification - utilisation d’un outil introduisant des délais d’attente de plus en plus longs entre chaque tentative de connexion infructueuse de la même source.
  • Blocage automatique - par ex., un mécanisme pour bloquer automatiquement la connexion à un compte après 10 tentatives infructueuses.

Mettre en place un système pour la maintenance des comptes

Question : Disposez-vous d’un système pour la maintenance des comptes (affectation, révocation et examen des accès et des privilèges) ?

Intention

Les bonnes habitudes en matière de gestion de comptes sont importantes pour éviter que des comptes ne soient utilisés par des personnes non autorisées pour accéder aux données de la plateforme. Les développeurs doivent surtout s’assurer que l’accès aux ressources et aux systèmes est révoqué lorsqu’il n’est plus nécessaire.

• Les comptes sont l’unité de gestion de base pour autoriser l’accès aux systèmes, aux données et aux fonctions administratives.
• Les comptes disposent d’autorisations associées à des actions particulières, et conformément au principe de moindre privilège, il est recommandé de ne leur accorder que les autorisations minimales requises.
• Lorsqu’une personne quitte une organisation, il est essentiel de désactiver au plus tôt ses comptes, et ceci pour deux raisons :

  • (1) pour bloquer l’accès de cette personne, qui ne fait plus partie de l’organisation, et
  • (2) pour réduire la probabilité qu’une personne non autorisée utilise le compte sans se faire remarquer. Par exemple, une personne malintentionnée pourrait avoir recours à l’ingénierie sociale pour que le service informatique réinitialise le mot de passe du compte. Si le compte appartient à un membre du personnel en activité, ce dernier signalera probablement qu’il ne parvient pas à s’y connecter, alors que si le compte demeure actif mais appartient à un ancien membre, le stratagème a plus de chances de passer inaperçu.
• En tenant compte de cela, les organisations doivent adopter une approche systématique pour gérer les comptes, accorder des autorisations ou des privilèges et révoquer l’accès lorsqu’il n’est plus nécessaire.

Résumé des exigences

• Vous devez disposer d’un outil ou d’un processus de gestion des comptes pour :

  • Les outils/systèmes/applications utilisés pour la communication, par ex. Slack ou une adresse e-mail professionnelle
  • Les outils/systèmes/applications utilisés pour expédier les logiciels, par ex. un dépôt de code, et
  • Administrer et exploiter le système (tel qu’applicable pour traiter les données de la plateforme)
• Vous devez régulièrement (au moins tous les 12 mois) examiner les accès accordés et mettre en place un processus de révocation de l’accès lorsque : (1) celui-ci n’est plus nécessaire ou (2) n’est plus utilisé.
• Vous devez également disposer d’un processus permettant de révoquer rapidement l’accès à ces outils lorsqu’un membre du personnel quitte l’organisation.
• Meta n’exige pas :

  • Qu’un outil particulier soit utilisé : les développeurs peuvent utiliser des annuaires tels que Google Cloud Identity ou Microsoft Azure Active Directory, des produits de cloud comme AWS Identity and Access Management (IAM) ou une feuille de calcul régulièrement mise à jour
  • Qu’il n’y ait qu’un seul outil consolidé pour la gestion des comptes pour ces différents types d’accès

Guide des justificatifs

Suivez les instructions de la section Préparer vos justificatifs pour préparer vos documents démontrant vos politiques/procédures et votre mise en œuvre.

• Politiques/procédures - Fournissez des documents approuvés sur les politiques et les procédures qui couvrent vos pratiques de gestion de comptes. Ces documents doivent contenir vos politiques et vos procédures pour la création de comptes, les autorisations, le niveau de sécurité des mots de passe, le blocage des comptes, l’authentification multifacteur, la réinitialisation de compte et la révocation de l’accès après une période d’inactivité et lorsque des personnes quittent l’organisation (par ex., lorsqu’un membre du personnel démissionne ou est licencié).
• Mise en œuvre - Fournissez un justificatif démontrant que vous avez mis en place au moins l’un des outils ou processus suivants pour gérer les comptes (s’ils ne sont pas applicables à l’environnement, indiquez-le) : (1) adresse e-mail professionnelle et outils de collaboration, (2) dépôt de code, (3) outils de déploiement dans le cloud/sur serveur, (4) portail administratif dans le cloud/sur serveur, (5) connexion à distance dans le cloud/sur serveur (par ex., SSH ou bureau à distance). Pour l’outil ou le processus distinct représentatif, vos justificatifs doivent démontrer que :

  • L’accès à ces outils a été révoqué pour les personnes qui ont quitté l’organisation (par ex., un rapport de rapprochement comparant les comptes aux données des membres actuels de l’organisation)
  • Les accès qui n’ont pas été utilisés pendant un certain temps ont été révoqués (par ex., un rapport indiquant que la dernière date d’accès d’une personne titulaire d’un compte actif représentatif remonte aux 90 derniers jours si la période d’inactivité maximale est de trois mois)

Exemples de justificatifs

Politiques/procédures - Un développeur a créé un standard de gestion du cycle de vie des accès qui comprend des procédures visant à accorder, à examiner et à révoquer des accès.

Exemple de mise en œuvre - L’accès est révoqué pour les membres du personnel qui quittent l’organisation

Un développeur utilise Workday en tant que source de référence pour les données des ressources humaines (RH), notamment la situation professionnelle actuelle. Ce développeur utilise Google Cloud Identity en tant que fournisseur d’identité pour gérer les comptes et accorder des accès aux outils et aux systèmes d’information.

Un développeur fournit un justificatif démontrant que l’accès a été révoqué pour les membres du personnel qui ont quitté l’entreprise : un document indiquant qu’un rapport de rapprochement a été effectué récemment (au cours des 12 derniers mois) et montrant qu’il n’y a aucun compte Google Cloud Identity actif pour des personnes qui ne font pas actuellement partie du personnel, selon la liste du personnel de Workday.

Exemple de mise en œuvre - L’accès est révoqué lorsque les comptes ne sont plus utilisés

Un développeur utilise Google Cloud Identity en tant que fournisseur d’identité pour gérer les comptes et accorder des accès aux outils et aux systèmes d’information.

Un développeur fournit un justificatif démontrant que l’accès est révoqué lorsque les comptes ne sont plus utilisés (par ex., aucune connexion au cours des 6 derniers mois), son annuaire de comptes trié par dernière connexion, afin de démontrer qu’il n’y a pas de comptes actifs avec une dernière connexion plus ancienne que cela.

Exemple de mise en œuvre - GitHub (dépôt de code)

Un développeur utilise un outil d’authentification unique pour gérer les identités et accorder des accès aux outils et aux systèmes d’information. Le développeur a configuré GitHub de façon à exiger une authentification unique.

Maintenez vos logiciels à jour

Question : Avez-vous mis en place un système pour tenir à jour le code et les environnements du système, y compris les serveurs, les machines virtuelles, les distributions, les bibliothèques, les packages et les logiciels antivirus ?

Intention

Les composants logiciels sont régulièrement mis à jour ou corrigés pour régler les vulnérabilités de sécurité. Leur durée de vie se termine lorsqu’ils ne sont plus pris en charge. Les développeurs qui utilisent ou dépendent de ces composants doivent en faire le suivi pour éviter le fonctionnement de logiciels présentant des vulnérabilités identifiées.

• Les développeurs d’applications font appel à différents logiciels tiers pour le fonctionnement des applications/systèmes qui traitent les Données de la Plateforme.
• Par exemple, un développeur fait habituellement appel à certains des éléments suivants :

  • Bibliothèques, SDK, packages - les développeurs les allient à leurs propres codes personnalisés pour développer les applications.
  • Images de machines virtuelles, conteneurs d’applications et systèmes d’exploitation - les applications fonctionnent dans un ou plusieurs de ces conteneurs, qui offrent des services comme la virtualisation ou l’accès aux réseaux et le stockage.
  • Les navigateurs, les système d’exploitation et autres applications utilisées par les employés/contributeurs - logiciel fonctionnant sur appareil mobile et ordinateur portable utilisé par le développeur pour faire fonctionner son système.
• Des vulnérabilités de sécurité sont régulièrement détectées dans ces composants, ce qui entraîne la mise en place de correctifs.
• Les vulnérabilités réglées à l’aide de correctifs sont ensuite diffusées dans les bases de données publiques avec une évaluation de leur gravité (faible, moyenne, élevée ou critique).
• En conséquence, les développeurs qui utilisent la plateforme Meta doivent disposer d’une manière systématique de gérer les correctifs :

  • En identifiant les correctifs pertinents pour leur application/système.
  • En définissant la priorité de l’urgence en fonction de l’exposition, et
  • En exécutant des correctifs de manière habituelle.

Résumé des exigences

Pour les composants logiciels suivants, le cas échéant, vous devez disposer d’une manière définie et réitérable d’identifier les correctifs disponibles pour régler les vulnérabilités de sécurité, en établissant des priorités en fonction du risque et en appliquant des correctifs de manière habituelle :

1. Bibliothèques, SDK, packages, conteneurs d’applications et systèmes d’exploitation utilisés dans le cloud ou un environnement serveur.
2. Bibliothèques, SDK, packages utilisés sur des appareils client, par ex. dans des applications mobile.
3. Systèmes d’exploitation et applications utilisés par les membres pour développer et exploiter leur application/système, par ex. des systèmes d’exploitation et navigateurs fonctionnant sur les ordinateurs portables d’employés.

Meta n’exige pas l’utilisation d’un outil particulier pour ces activités. Il est courant que les organisations adoptent des approches différentes pour garder à jour différents types de logiciel (par ex. les bibliothèques intégrées à l’application vs la mise à jour de système pour les ordinateurs des employés).

Le diagramme ci-dessous illustre les cas dans lesquels un correctif peut être demandé pour différents types d’architecture.

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

Commencez par identifier les types de logiciel concernés dans l’environnement, par ex. les bibliothèques, les SDK, les packages, les images de machines virtuelles, les conteneurs d’applications, les systèmes d’exploitation, les navigateurs et les autres applications utilisées par les employés/contributeurs.

Peut-être avez-vous un ou plusieurs outils que vous utilisez pour les activités suivantes :

• Inventaire - justifier via une capture d’écran ou document l’existence d’un outil ou processus représentant une liste concernée de bibliothèques, packages, SDK, conteneurs, serveurs d’application et systèmes d’exploitation devant être corrigés. Des inventaires doivent exister pour les représentants de types de logiciels (par ex. application(s) cloud, application(s) client, appareils des employés).
• Identifier les correctifs de logiciel disponibles - un outil ou processus doit exister pour identifier les correctifs de sécurité existants et pertinents pour l’inventaire.
• Établir des priorités - un outil ou processus (par ex. tickets Jira, problèmes dans GitHub issues, feuille de calcul pour le suivi) doit exister pour définir la priorité des correctifs pertinents.

  • Correctifs
  • Justifier via une capture d’écran ou document qu’une fois les correctifs pertinents identifiés et classés par priorité, ils sont déployés au niveau de leurs différentes destinations.
• Inclut des règlements sur le délai de résolution et l’utilisation de logiciels en fin de vie.

Exemples de justificatifs

Snyk pour une application NodeJS - Un développeur utilise l’interface de ligne de commande Synk pour identifier les dépendances de tiers intégrées ayant présenté des vulnérabilités de sécurité et établir des priorités en fonction de leur gravité.

NPM Audit

Un développeur utilise NPM Audit pour trouver des vulnérabilités dans les dépendances utilisées dans une application Node. L’image figurant ci-dessous à titre d’exemple reflète des vulnérabilités à haute gravité demandant un correctif.

Trivy

Un développeur utilise Trivy pour trouver des vulnérabilités dans une image de machine. L’image figurant ci-dessous à titre d’exemple reflète des vulnérabilités à haute gravité dans des bibliothèques demandant un correctif.

Windows Server Update Services (WSUS)

Un développeur utilise Windows Server Update Services (WSUS) pour la gestion de sa flotte de serveurs et PC/ordinateurs portables. L’image figurant ci-dessous à titre d’exemple montre une vue admin de l’outil WSUS, permettant la vérification, l’approbation et le déploiement des mises à jour de Windows.

Mettez un système en place pour consigner les accès aux Données de la Plateforme et suivre où les Données de la Plateforme ont été envoyées et stockées

Intention

En l’absence de fichiers journaux fiables, il peut être difficile, voire impossible, pour un développeur de détecter les accès non autorisés aux Données de la Plateforme.

• Les journaux d’audit permettent aux organisations d’enregistrer lorsqu’un évènement se produit, par exemple si un utilisateur particulier a réalisé une recherche dans des tables de base de données contenant des Données de la Plateforme.
• Ces journaux peuvent alors prendre en charge des processus comme le déclenchement d’alertes suite à une activité suspecte ou une analyse après l’identification d’un incident de sécurité.

Résumé des exigences

Si vous traitez des Données de la Plateforme côté serveur, dans cet environnement :

• Vous devriez tenir des journaux d’audit enregistrant les évènements clés (par ex. l’accès aux Données de la Plateforme, l’utilisation de comptes avec des autorisations élevées, des modifications introduites dans la configuration des journaux d’audit).
• Les journaux d’audit devraient être regroupés dans un référentiel central et protégés contre les altérations ou les suppressions.

Guide des justificatifs

S’il vous est demandé d’importer un justificatif, ce dernier doit montrer que :

• Vous êtes au courant de la manière dont les Données de la Plateforme sont stockées, consultées et transférées, par exemple via un diagramme de flux de données à jour reflétant une vision globale du système, désignant les services de stockage des Données de la Plateforme et montrant des points d’entrée et de sortie, y compris les transferts attendus vers des services externes.
• Vous avez mis en place des journaux d’audit à l’épreuve des altérations.
• Les évènements en lien avec l’accès aux Données de la Plateforme sont capturés dans les journaux.

Surveillez les transferts de Données de la Plateforme et les points clés, où les Données de la Plateforme peuvent quitter le système (par ex. des tiers ou des points de terminaison publics).

Intention

Une bonne compréhension de la manière dont les Données de la Plateforme doivent être traitées et dont la surveillance de ce traitement doit se dérouler permet aux organisations de veiller à ce que les Données de la Plateforme ne soient utilisées qu’aux fins prévues.

• Les développeurs doivent se tenir au courant de la manière dont les Données de la Plateforme sont stockées, transmises via les réseaux et enregistrées dans les sauvegardes (qui peuvent être reproduites ailleurs).
• Par exemple, des situations dans lesquelles les Données de la Plateforme sont transmises d’une manière non prévue ou via un réseau sans le chiffrement adéquat pourraient être détectées lors de la surveillance, vous permettant ainsi d’agir.

Résumé des exigences

Si vous traitez des Données de la Plateforme côté serveur, dans cet environnement serveur, vous devriez :

• Tenir un diagramme de flux de données précis reflétant l’endroit où les Données de la Plateforme sont stockées, traitées et transmises dans les réseaux.
• Configurer la surveillance (par ex. journaux d’audit avec un produit de surveillance automatisés) des transferts des Données de la Plateforme en dehors du système.
• Configurer, si possible, le système de surveillance de sorte à déclencher des alertes qui sont examinées dans les meilleurs délais en cas de transferts non prévus de Données de la Plateforme (consultez aussi l’exigence ci-dessous - Configurer un système automatisé pour surveiller les journaux et autres évènements de sécurité, et générer des alertes d’évènements anormaux ou liés à la sécurité ).

Guide des justificatifs

S’il vous est demandé de produire un justificatif de cette protection, veuillez suivre les instructions de la section Préparation de justificatif afin de préparer les justificatifs en matière de règlement/procédure et de mise en place.

Vous devriez fournir des justificatifs montrant que :

• Vous êtes au courant de la manière dont les Données de la Plateforme sont stockées, consultées et transférées, par exemple via un diagramme de flux de données à jour reflétant une vision globale du système, désignant les services de stockage des Données de la Plateforme et montrant des points d’entrée et de sortie, y compris les transferts attendus vers des services externes.
• Des journaux d’audit à l’épreuve des altérations ont été mis en place.
• Les évènements en lien avec les transferts des Données de Plateforme figurent dans les journaux ; les évènements doivent inclure l’heure, l’identité de l’utilisateur ou l’application réalisant l’action, ainsi que la source et la destination.

Mettez en place un système de surveillance des journaux et autres évènements de sécurité, et de génération d’alertes d’évènements anormaux ou liés à la sécurité.

Intention

Il n’est pas réaliste de confier à des humains l’examen et l’identification de comportements inattendus dans un système moderne accessible sur Internet. Mieux vaut faire appel aux outils existants, capables de traiter les fichiers journaux et autres signaux pour déclencher des alertes. Ces alertes peuvent alors être soumises à un examen humain plus poussé.

Résumé des exigences

Si vous traitez des Données de la Plateforme côté serveur, dans cet environnement serveur, vous devriez :

• Disposer d’un outil capable de traiter des fichiers journaux et d’autres évènements, en établissant des règles déclenchant des alertes et un mécanisme permettant de les transmettre aux personnes voulues (par ex. un collaborateur d’astreinte chargé de la sécurité).
• Transmettre les signaux pertinents à l’outil (par ex. les journaux d’accès web, les tentatives d’authentification, les actions réalisées par les utilisateurs à privilèges élevés).
• Au fil du temps, ajustez et affinez les règles pour équilibrer le signal sur bruit (par ex. en évitant un nombre trop élevé de fausses alertes sans pour autant ignorer les évènements qui méritent d’être examinés).

Guide des justificatifs

Les développeurs adoptent en général à cet effet un outil de gestion des informations et des évènements de sécurité (SIEM), par exemple :

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

Vous devriez fournir des justificatifs montrant que les sources de signaux pertinentes sont transmises à l’outil correspondant, que les déclencheurs et les alertes ont été configurés, que les alertes sont transmises au personnel responsable du suivi, et enfin qu’il existe un processus permettant d’ajuster régulièrement les alertes (par ex. via des cycles mensuels de vérification et mise à jour).