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

Protection des Données de la Plateforme stockées côté serveur avec le chiffrement au repos

Question : Appliquez-vous le chiffrement au repos à toutes les Données de la Plateforme stockées dans le cloud, sur un serveur ou dans un environnement de centre de données ?

Intention

Le chiffrement au repos protège les Données de la Plateforme en rendant les données indéchiffrables sans clé de déchiffrement distincte. Cela offre un niveau de protection supplémentaire contre l’accès en lecture non autorisé.

• Sur les serveurs ou dans un environnement cloud, concentrant généralement les Données de la Plateforme liées à tous les utilisateurs d’une application, le chiffrement au repos réduit le risque de violation de données.
• Par exemple, le chiffrement au repos protège contre les menaces comme les accès non autorisés à une sauvegarde de base de données, susceptible de ne pas être aussi bien protégée que la base de données de production.

Résumé des exigences

Si vous stockez des Données de la Plateforme côté serveur :

• Vous DEVEZ protéger ces données :

  • Avec le chiffrement au repos, ou
  • En utilisant d’autres mesures de protection valables (voir les mesures de protection valables)

• En fonction du type de chiffrement utilisé :

  • Soit le chiffrement au niveau de l’application (par ex. un logiciel qui chiffre/déchiffre des colonnes spécifiques dans une base de données) soit le chiffrement sur la totalité du disque sont valables.
  • Si nous recommandons l’utilisation d’un chiffrement standard du secteur (par ex. AES, BitLocker, Blowfish, TDES, RSA), nous n’exigeons pas d’algorithme ni de longueur de clé spécifiques.

Si le développeur NE stocke PAS des Données de la Plateforme côté serveur, cette exigence ne lui est pas applicable.

Cas spéciaux

Stockage côté serveur à l’aide de l’IaaS, de l’auto-hébergement ou d’un hébergement hybride

Si vous stockez des Données de la Plateforme via un l’hébergement IaaS (par ex. AWS EC2, Microsoft Azure IaaS et Google Compute Engine), l’auto-hébergement ou une approche hybride, alors cette question ne s’applique pas.

Stockage côté serveur à l’aide de produits SaaS, PaaS ou BaaS

Mais certains autres modèles d’hébergement backend constituent des cas particuliers :

Si vous stockez des Données de la Plateforme uniquement via l’un de ces derniers (sans utiliser l’IaaS, l’auto-hébergement ou un hébergement hybride), cette question ne s’applique pas. Vous devriez plutôt décrire cette relation dans la section Fournisseur de services de l’évaluation de la protection des données.

• BaaS - par ex. AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase et MongoDB Switch
• PaaS - par ex. AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS - par ex. MailChimp ou Salesforce

Stockage côté serveur à l’aide des API de Meta

Si vous stockez des Données de la Plateforme uniquement via une API Meta, par exemple en utilisant player.setDataAsync(), dans le SDK Instant Games, cette question ne s’applique pas.

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.

Exemple de justificatif de mise en place

AWS RDS

AWS RDS - le chiffrement au repos est configurable dans AWS RDS, donc les développeurs doivent s’assurer que l’option de configuration est définie de manière à appliquer cette protection.

Pour une instance de RDS représentative contenant des Données de la Plateforme, utilisez l’outil AWS CLI afin d’obtenir sa configuration StorageEncrypted.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

AWS DynamoDB est chiffré au repos par défaut. Vous pouvez obtenir la configuration de chiffrement au repos pour un tableau en utilisant ces commandes.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB doit être configuré de manière à appliquer le chiffrement au repos. Pour un cluster représentatif contenant des Données de la Plateforme, utilisez ces commandes afin d’obtenir la configuration StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

Les buckets AWS S3 doivent être configurés de manière à appliquer le chiffrement au repos à tous les objets créés dans le bucket. Utilisez ces commandes pour faire apparaître les buckets et récupérer la configuration du chiffrement de bucket par défaut.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Consultez les documents de Microsoft sur le chiffrement au repos dans Azure qui correspondent à l’utilisation de ces services par l’organisation.

Google Cloud Platform

Consultez les documents de Google sur le chiffrement au repos sur la Google Cloud Platform.

Mesures de protection alternatives valables

Si vous ne mettez pas en place le chiffrement au repos dans l’environnement côté serveur, vous pouvez protéger les Données de la Plateforme d’une autre manière valable. Dans ce cas, vous devriez décrire les aspects suivants :

1. Sensibilité des Données de la Plateforme - le stockage des Données de la Plateforme spécifiques peut être associé à un risque plus bas ou plus élevé. Il vous faudra étudier quels attributs spécifiques d’utilisateur des Données de la plateforme sont stockés côtés serveur.
2. Contrôles appliqués pour réduire la probabilité de préjudices spécifiques
1. Contrôles pour protéger les réseaux contenant des Données de la Plateforme
2. Contrôles pour protéger les applications/systèmes ayant accès aux Données de la plateforme
3. Contrôles pour éviter la perte de supports de stockage physiques (par ex. les périphériques de stockage réseau déclassés) contenant des Données de la Plateforme
4. Contrôles pour éviter la perte de supports de stockage physiques (par ex. les périphériques de stockage réseau déclassés) contenant des Données de la Plateforme
5. Contrôles pour éviter l’accès non autorisé aux copies de sauvegarde stockées contenant des sauvegardes des Données de la Plateforme
3. Valeur des justificatifs - si ces mesures de protection ont été évaluées par un auditeur indépendant, par exemple dans le cadre d’un audit SOC2, veuillez l’indiquer.

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).

Glossaire

A

Tierce partie : en gestion des risques, la tierce partie fait référence aux équipes de développement qui utilisent la plateforme de Meta (la première partie (interne) étant Meta, et la deuxième les personnes qui utilisent ses produits).

Quatrième partie : en gestion des risques, la quatrième partie fait référence aux entreprises qui fournissent aux équipes de développement les services nécessaires à leur activité (la première partie (interne) étant Meta, la deuxième partie les personnes qui utilisent ses produits et la tierce partie les équipes de développement qui utilisent la plateforme de Meta). Token d’accès : un identifiant, tel qu’un mot de passe, qui permet à un logiciel d’appeler une API pour effectuer une action (par exemple, lire les données d’un profil).

Amazon Web Services (AWS) : la suite de services de cloud computing d’Amazon.

ASID (ID spécifique à une application) : un identifiant unique que Meta génère lorsqu’une personne choisit d’utiliser une application. Les ASID renforcent la confidentialité en rendant plus difficile la mise en correspondance des personnes entre les applications via les ensembles de données, car une personne utilisant deux applications aura des ASID différents dans chaque application.

Clé secrète : une clé secrète partagée que Meta met à la disposition des équipes de développement via le tableau de bord de l’application. La possession de la clé secrète autorise le logiciel à effectuer certaines actions via l’API Graph. Les équipes de développement doivent donc veiller à ce que les parties non autorisées ne puissent pas y accéder.

Compromission d’une application : lorsqu’une personne malintentionnée obtient un accès non autorisé au réseau interne d’une organisation en raison d’une erreur de configuration ou d’une vulnérabilité dans son application (par exemple, une vulnérabilité logicielle dans une application web). Pour éviter la compromission d’une application, vous pouvez effectuer un test d’intrusion. Voir également Compromission réseau.

Conteneur d’application : un conteneur regroupe le code logiciel et les dépendances associées afin qu’une application puisse s’exécuter sur différents types de serveurs (par exemple, des serveurs utilisant différents systèmes d’exploitation, comme Linux ou Windows Server). Une équipe de développement créera une image de conteneur pour son application. Une plateforme de conteneurisation héberge (exécute) l’image de conteneur.

Chiffrement d’application : une méthode de protection des données dans laquelle le logiciel de l’application effectue lui-même les opérations de chiffrement et de déchiffrement. La Transport Layer Security (TLS) chiffre quant à elle de manière transparente les données en transit lorsqu’une application établit une connexion sécurisée à un serveur distant (par exemple, via le protocole HTTPS), et les fournisseurs de cloud offrent des services permettant de chiffrer de manière transparente les données au repos.

API (interface de programmation d’application) : permet à deux ordinateurs de communiquer via un réseau. Par exemple, une application mobile récupérant la météo du jour pour un certain lieu à partir d’un système de prévisions météorologiques centralisé.

Preuve de clé secrète : une protection supplémentaire pour les appels d’API à Meta. Elle permet aux équipes de développement de générer un paramètre (la preuve de clé secrète) qui démontre qu’elles possèdent la clé secrète. La preuve de clé secrète est le produit d’une fonction de hachage (également appelée fonction à sens unique) basée sur la clé secrète et le token d’accès. Configurer une application de façon à exiger des preuves de clé secrète lors des invocations de l’API Graph réduit les risques potentiels liés à la fuite des tokens d’accès utilisateur, car ces token d’accès ne peuvent pas être utilisés sans ce paramètre supplémentaire.

B

Backend as a Service (BaaS) : un type de cloud computing qui fournit une suite de fonctionnalités côté serveur à une équipe de développement d’applications, afin qu’elle puisse se concentrer sur la création du frontend (la partie d’une application avec laquelle les personnes interagissent). Les solutions BaaS sont similaires au PaaS, mais comprennent également des services tels que l’authentification et les notifications push mobiles. Quelques exemples de produits BaaS populaires : AWS Amplify, Azure Mobile Apps, Firebase et MongoDB Switch.

C

Texte chiffré : synonyme de données chiffrées, texte chiffré est le nom attribué aux données rendues illisibles par un algorithme de chiffrement. Le contraire de texte chiffré est texte brut.

Côté client : le public interagit généralement avec les services accessibles sur Internet en ouvrant un site web dans un navigateur ou une application mobile sur un téléphone ou une tablette. Les navigateurs et les applications mobiles sont qualifiés de clients locaux ou côté client. Les clients envoient des requêtes à partir d’ordinateurs distants (serveurs) via Internet.

Cloud computing : un type de gestion des ordinateurs serveurs, des réseaux et du stockage qui permet à une organisation de ne pas avoir à se soucier de l’environnement physique (un centre de données rempli de racks de serveurs et de câbles réseau). Au lieu de cela, l’organisation peut utiliser ces ressources à la demande et payer les services qu’elle consomme uniquement.

Configuration cloud : l’ensemble d’options de cloud computing qu’une organisation a définies en lien avec son utilisation d’un fournisseur de cloud exécutant certains logiciels. Par exemple, les types de connexions réseau autorisées ou bloquées, l’endroit où les fichiers journaux sont conservés et pendant combien de temps, et l’ensemble de personnes autorisées à apporter des modifications à la configuration cloud.

Contrôle de compensation : un contrôle de sécurité qui diffère d’un ensemble d’exigences de base, mais qui vise à fournir une protection comparable contre un risque.

D

Base de données : un logiciel qui permet de stocker, de lire, de mettre à jour et de supprimer des données arbitraires. Les bases de données peuvent s’exécuter sur des clients ou sur des serveurs. Les organisations qui intègrent la plateforme Meta stockent généralement les données qu’elles récupèrent à partir de l’API Graph dans une base de données qui s’exécute côté serveur.

Déchiffrement : le processus par lequel les données chiffrées sont retranscrites dans leur format d’origine. En d’autres termes, le déchiffrement transforme le texte chiffré en texte brut.

E

Chiffrement : le processus par lequel les données sont transcrites dans un format inutilisable pour les personnes ne pouvant pas les déchiffrer. En d’autres termes, le chiffrement transforme le texte brut en texte chiffré.

Chiffrement au repos : les données qui ont été protégées par chiffrement lorsqu’elles sont conservées dans un espace de stockage persistant (comme un disque dur). Le chiffrement au repos fournit une protection supplémentaire contre les accès non autorisés, car une personne pouvant lire les fichiers bruts sur le périphérique de stockage verra le texte chiffré et ne pourra pas le déchiffrer, à moins qu’elle n’ait également accès à la clé de déchiffrement.

Chiffrement en transit : les données qui ont été protégées par chiffrement lors de leur transmission sur un réseau. Le chiffrement en transit fournit une protection contre l’écoute clandestine tout au long du chemin réseau, car une personne pouvant lire les paquets réseau verra le texte chiffré et ne pourra pas le déchiffrer, à moins qu’elle n’ait également accès à la clé de déchiffrement.

Logiciel en fin de vie : lorsqu’une organisation décide d’arrêter de maintenir un produit logiciel (par exemple, en utilisant des correctifs pour résoudre les vulnérabilités), on dit qu’il est en fin de vie. Le logiciel n’étant plus maintenu, il devient très risqué de l’exécuter.

G

Google Cloud Platform (GCP) : la suite de services de cloud computing de Google. API Graph : le principal moyen pour les applications de lire et d’écrire sur le graphe social de Meta. Tous les SDK et produits de Meta interagissent avec l’API Graph d’une manière ou d’une autre.

H.

Fonction de hachage : une fonction cryptographique qui transforme les données d’entrée en un code court qui ne peut pas être retranscrit dans son format d’origine. En cryptographie, les fonctions de hachage sont utilisées pour protéger des données telles que les mots de passe. Plutôt que de stocker le mot de passe d’une personne en texte brut pouvant être volé, les mots de passe sont d’abord hachés, puis stockés. Par la suite, pour confirmer qu’une personne a saisi le bon mot de passe, le système utilisera la même fonction de hachage pour transformer les données d’entrée et comparer le hash généré à la valeur stockée. Également appelée fonction à sens unique, car le hash généré ne peut pas être retranscrit dans son format d’origine.

Environnement d’hébergement : un ensemble de serveurs distants, de réseaux et de périphériques de stockage qu’une organisation exécute dans son propre centre de données ou dans un centre de données en colocation. Depuis que le cloud computing est devenu populaire, ce modèle est plutôt rare.

I

Fournisseur d’identité : un service de cloud utilisé pour l’authentification et pour centraliser la gestion des identités digitales. Les organisations qui utilisent un fournisseur d’identité configurent généralement les applications cloud de façon à ce qu’elles s’appuient sur ce fournisseur d’identité pour l’authentification. L’organisation peut ensuite créer des comptes, leur accorder un accès à certaines applications et les désactiver de manière centralisée via le fournisseur d’identité plutôt que d’avoir à le faire pour chaque application cloud une par une.

Gestion des identités et des accès : les outils et processus utilisés pour gérer les comptes et accorder des accès aux systèmes.

Infrastructure as a Service (IaaS) : un modèle de cloud computing qui permet aux clients de configurer des services de calcul, de stockage et de mise en réseau sans être responsables des ressources physiques (par exemple, un centre de données rempli de serveurs, de périphériques réseau et de baies de stockage). Par rapport au Paas, l’IaaS donne aux organisations plus de contrôle sur la configuration de leurs ressources dans le cloud. La gestion de ces ressources est toutefois plus complexe. Quelques exemples de produits IaaS populaires : AWS EC2, Microsoft Azure IaaS et Google Compute Engine.

L

Bibliothèque : composants logiciels préexistants provenant généralement d’une entreprise ou d’équipes de développement externes et utilisés pour gérer certaines tâches au sein de l’application ou du système d’une autre équipe. Les bibliothèques simplifient le développement d’une application, car l’équipe de développement n’a pas à innover inutilement lorsqu’une bibliothèque existe déjà pour une fonction donnée. Les bibliothèques peuvent toutefois présenter des vulnérabilités ou inclure d’autres bibliothèques qui en présentent. Les équipes de développement qui utilisent des bibliothèques pour développer leur application doivent donc savoir quelles bibliothèques sont en cours d’utilisation et les tenir à jour au fil du temps.

M

Client mobile ou application mobile : une application qu’une personne installe sur un téléphone ou une tablette à partir d’une boutique d’applications (comme l’App Store ou le Google Play Store). Les clients mobiles communiquent souvent sur Internet via l’API REST d’une organisation et peuvent également communiquer avec d’autres parties (comme l’API Graph via le SDK Facebook pour Android).

Authentification multifacteur : une méthode d’authentification qui exige plusieurs facteurs pour accéder à une application ou à un système. L’authentification multifacteur, contrairement à l’authentification à facteur unique, qui repose uniquement sur un mot de passe, demande généralement un code envoyé par e-mail ou par SMS, un code envoyé via une application d’authentification, un scan biométrique ou une clé de sécurité, voire plusieurs de ces options, en plus du mot de passe. L’authentification multifacteur protège contre le piratage en rendant plus difficile pour les personnes non autorisées de forcer l’accès à un compte (par exemple, en essayant de se connecter à un compte à plusieurs reprises en utilisant une adresse e-mail connue et des mots de passe communs).

N

Logiciel natif : les applications téléchargées et installées sur des ordinateurs portables ou des appareils mobiles sont qualifiées de logiciels natifs (par exemple, l’application Facebook pour iOS). En revanche, une application qui s’exécute dans un navigateur est qualifiée d’application web (par exemple, Facebook dans Chrome).

Compromission réseau : lorsqu’une personne malintentionnée obtient un accès non autorisé au réseau interne d’une organisation en raison d’une erreur de configuration ou d’une vulnérabilité dans le réseau. Pour éviter la compromission réseau, vous pouvez effectuer une analyse réseau afin d’identifier les erreurs de configuration et les vulnérabilités du réseau connecté à Internet. Voir également Compromission d’une application.

Analyse réseau : un processus de gestion des risques qui utilise un logiciel pour : (1) identifier les serveurs actifs d’un réseau qui répondront aux communications à distance, puis (2) déterminer si l’un de ces serveurs exécute d’anciennes versions de logiciels vulnérables à un ou plusieurs exploits. Une organisation peut effectuer des analyses réseau régulières afin de s’assurer qu’il n’y a pas de ports ouverts imprévus sur son périmètre réseau, par exemple.

Node Package Manager (NPM) : un outil utilisé par les équipes de développement JavaScript pour accélérer le développement en permettant l’inclusion de packages prédéfinis dans l’application ou le système d’une équipe. NPM comprend des fonctionnalités qui permettent d’examiner l’ensemble de packages utilisés par une application et d’identifier les packages présentant des vulnérabilités connues.

O

Buckets de stockage d’objets : un type de stockage dans le cloud qui permet aux organisations de stocker facilement des fichiers dans un espace de stockage persistant, y compris des fichiers très volumineux, sans avoir à se soucier des ressources physiques, comme les baies de stockage, ou de sauvegarder ces fichiers pour s’assurer qu’ils ne seront pas perdus en cas de catastrophe, comme un incendie ou une inondation.

Système d’exploitation : le logiciel exécuté sur un ordinateur ou un appareil mobile qui permet aux applications d’exécuter et d’utiliser le processeur, la mémoire, le stockage et les ressources réseau de cet ordinateur. Par exemple, Windows de Microsoft, macOS ou iOS d’Apple et Linux.

Membre de l’organisation : personne ayant un rôle et des responsabilités au sein d’une organisation (personnel fixe ou occasionnel, sous-traitant, stagiaire, bénévole, etc.).

Appareil appartenant à l’organisation : un ordinateur ou un appareil mobile utilisé par un membre d’une organisation dans le cadre du travail effectué pour cette organisation.

P

Condition 6.a.i de la plateforme : la section (6), titre (a), paragraphe (i) des Conditions générales de la Plateforme Meta, qui décrit les obligations des équipes de développement qui utilisent la plateforme en matière de sécurité des données.

Package : synonyme de bibliothèque.

Correctif : mise à jour logicielle visant à résoudre des problèmes de sécurité, à corriger des bugs ou à ajouter de nouvelles fonctionnalités. Toutes sortes de logiciels peuvent être corrigés, y compris les systèmes d’exploitation, les conteneurs, les bibliothèques et les SDK.

Test d’intrusion : une attaque simulée contre une application ou un système afin de trouver des vulnérabilités dans le code ou la configuration qui pourraient être exploitées par une personne non autorisée. Les personnes chargées de ces tests, appelées « pentesters », utilisent des outils similaires à ceux des cybercriminels pour effectuer une reconnaissance, rechercher des faiblesses potentielles et tester des vulnérabilités qui pourraient être utilisées pour obtenir un accès non autorisé. À la fin du test d’intrusion, les pentesters créent un rapport sur les vulnérabilités trouvées et sur leur gravité. L’organisation qui maintient le logiciel doit alors se charger de trouver des solutions à ces vulnérabilités.

Texte brut : synonyme de données non chiffrées, texte brut est le nom attribué aux données qui n’ont pas été protégées par chiffrement. Platform as a Service (PaaS) : un modèle de cloud computing dans lequel un client déploie une application sur une plateforme gérée par le fournisseur de cloud. Par rapport à l’IaaS, le PaaS est plus simple à gérer pour les clients, car à la fois les ressources physiques (serveurs, périphériques de stockage et périphériques réseau), le système d’exploitation et le conteneur dans lequel l’application du client s’exécute sont gérés par le fournisseur de cloud. Quelques exemples de produits PaaS populaires : AWS Elastic Beanstalk, Google App Engine et Force.com.

Port : lorsqu’un client se connecte à un serveur via Internet, l’adresse de destination comprend deux parties : (1) l’adresse IP du serveur et (2) un numéro de port auquel une application particulière répondra sur ce serveur. Les protocoles communs utilisent des ports réservés (par exemple, 443 pour HTTPS), mais s’ils le souhaitent, les équipes de développement peuvent utiliser des ports personnalisés pour les communications réseau.

R

API REST : un type très populaire de développement de services accessibles sur le web dans lequel le client et le serveur communiquent via le protocole HTTP. Une équipe de développement sur la plateforme Meta peut héberger une API REST sur un sous-domaine tel que api.example.com vers ou depuis lequel son application mobile envoie et reçoit les données de la plateforme.

S

Secure Shell (SSH) : un protocole de communication sécurisé qui permet aux admins de se connecter à distance aux serveurs et d’exécuter des programmes sur ces serveurs. Il est désigné comme sécurisé car les communications entre le client et le serveur sont protégées contre l’écoute clandestine, contrairement aux protocoles plus anciens, comme Telnet. Également appelé Secure Socket Shell.

Secure Sockets Layer (SSL) : une version obsolète et non sécurisée du chiffrement en transit. La version sécurisée moderne est appelée Transport Layer Security (TLS).

Serveur : un ordinateur qui fournit des services à distance via un réseau. Les navigateurs et les applications mobiles se connectent à des serveurs via Internet.

Informatique sans serveur : un type de cloud computing dans lequel le fournisseur de cloud gère l’infrastructure physique, le système d’exploitation du serveur et le conteneur. L’équipe de développement est uniquement responsable du code personnalisé et des bibliothèques associées ainsi que de la configuration cloud.

Côté serveur : les données ou les calculs de l’autre côté d’une connexion réseau (c’est-à-dire sur un serveur) sont qualifiés de côté serveur. Les données ou les calculs sur un appareil local, comme un ordinateur portable ou un appareil mobile, sont quant à eux qualifiés de côté client.

Authentification unique : un modèle dans lequel les applications s’appuient sur un annuaire centralisé (fournisseur d’identité) pour l’authentification. En plus de centraliser l’administration des comptes et de l’accès aux applications pour l’organisation, elle permet de n’utiliser qu’un seul ensemble d’identifiants. Pas besoin d’avoir des identifiants différents (comme un nom d’utilisateur et un mot de passe) pour chaque application.

SDK (kit de développement logiciel) : comprend un code qu’une équipe de développement peut utiliser pour simplifier le processus de développement pour un besoin donné. Par exemple, Meta crée et maintient des SDK qui simplifient l’utilisation de l’API Graph pour les équipes de développement iOS et Android. Comme pour les bibliothèques, les équipes de développement qui utilisent des SDK dans leurs applications doivent les tenir à jour au fil du temps.

Software as a Service (SaaS) : permet aux clients d’utiliser des applications basées dans le cloud via Internet. Contrairement au PaaS ou à l’IaaS, le client d’une application SaaS ne déploie pas de code personnalisé et n’est pas responsable de la configuration, de la mise à niveau, ni des correctifs de l’application SaaS. Il s’agit de responsabilités qui incombent au fournisseur de logiciel SaaS. Quelques exemples de produits SaaS populaires : Dopbox, MailChip, Salesforce et Slack.

Analyse statique : voir Test de sécurité d’application statique.

Test de sécurité d’application statique (SAST) : une approche permettant de trouver des vulnérabilités dans un logiciel en appliquant un outil spécialisé au code source. Les outils SAST identifient les vulnérabilités potentielles, telles que celles répertoriées dans le top 10 du projet OWASP, et l’équipe de développement doit ensuite examiner les résultats, distinguer les vrais positifs des faux positifs et corriger les vulnérabilités du logiciel. Les tests de sécurité d’application statique permettent aux équipes de développement de trouver des vulnérabilités avant que l’application ne soit mise en production. Mais contrairement aux tests d’intrusion, les outils SAST ne peuvent pas trouver de vulnérabilités liées à la configuration de la production de l’application.

T

Chiffrement transparent des données : un type de chiffrement au repos qui s’applique généralement au stockage en base de données (à la fois au contenu de la base de données et à ses fichiers journaux). Dans ce modèle, le logiciel de base de données gère les clés de chiffrement et traite les opérations de chiffrement (écriture) et de déchiffrement (lecture) de manière transparente.

Transport Layer Security (TLS) : un protocole de chiffrement en transit qui utilise le chiffrement pour protéger les données transmises via des réseaux contre l’écoute clandestine tout au long du chemin réseau. La TLS est la version sécurisée moderne de la technologie obsolète appelée SSL.

Authentification à deux facteurs : un synonyme d’authentification multifacteur. Vault : un système de gestion des secrets pour les données sensibles telles que les clés de chiffrement, les token d’accès et d’autres identifiants. Cet outil permet de contrôler qui peut accéder aux secrets qu’il contient et offre des services supplémentaires, tels que des journaux d’audit.

V

Machine virtuelle : très similaire à un conteneur, une machine virtuelle s’exécute sur un hyperviseur, alors qu’un conteneur s’exécute dans une plateforme de conteneurisation. La principale différence est qu’une image de machine virtuelle contient un système d’exploitation, tandis qu’un conteneur n’en contient pas. À la fois les machines virtuelles et les conteneurs contiennent des applications et des dépendances, comme les bibliothèques.

Cloud privé virtuel : un terme utilisé par AWS pour désigner un ensemble de ressources dans le cloud qui ressemble au réseau d’un centre de données traditionnel, lorsque le cloud n’existait pas encore.

Vulnérabilité : une faille dans un système ou une application qui pourrait être exploitée. Par exemple, lorsqu’une personne lit des données qu’elle n’a pas le droit de lire.

Programme de divulgation des vulnérabilités : un modèle dans lequel les organisations sollicitent des rapports sur les vulnérabilités à des équipes de recherche (ou « hackers éthiques »), afin que les vulnérabilités soient découvertes et corrigées avant que des personnes malintentionnées ne puissent les exploiter. Pour qu’un programme de divulgation des vulnérabilités soit efficace, il doit comprendre une équipe qui recherche activement les vulnérabilités, des analystes qui examinent et trient les divulgations entrantes et des équipes d’ingénierie qui connaissent bien le domaine de la cybersécurité et qui sont capables de déployer des solutions aux vulnérabilités.

Analyse de vulnérabilité : une méthode qui s’appuie sur un logiciel pour rechercher des vulnérabilités dans les serveurs, les réseaux et les applications. Par rapport à un test d’intrusion, une analyse de vulnérabilité est moins chère et peut donc être exécutée à plusieurs reprises (par exemple, une fois par mois ou par trimestre). Mais un test d’intrusion peut trouver des vulnérabilités qu’une analyse de vulnérabilité ne trouvera pas, car les pentesters ont des instincts et des compétences analytiques difficiles à reproduire avec des approches strictement automatisées. Voir également Analyse réseau.

W

Application web : les applications web sont des programmes qui s’exécutent dans des navigateurs et qui se composent de ressources telles que des documents HTML, un code JavaScript, des vidéos et d’autres contenus multimédia, et du CSS pour le style. Par rapport aux applications mobiles, qui doivent être installées sur un appareil mobile à partir d’une boutique d’applications, les applications web sont récupérées via un navigateur à partir d’un serveur distant (par exemple, www.facebook.com) et sans installation.