Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)

Faculté des sciences Ain Chock Casablanca MASTER SPECIALISE UNIVERSITAIRE : Sécurité de l’Information et des Systèmes.

Implémentation de la norme PCI DSS dans le Cloud

Cas d’un Cloud IaaS public hébergeant deux sites e-commerce

Nouh DROUSSI

2014/2015


Faculté des sciences Ain Chock Page 1

Faculté des sciences Ain Chock Casablanca MASTER SPECIALISE UNIVERSITAIRE : Sécurité de l’Information et des Systèmes.

INTELLCAP


Cas d’un Cloud IaaS public hébergeant deux sites e-commerce Présenté par : Mr Nouh DROUSSI Encadrant de la faculté : Mr Abderrahim SEKKAKI Encadrant de l’entreprise : Mr Hamza AKASBI

2014/2015



Table des matières

Présentation de l’entreprise …………………………………………………...4 1 Généralités…………………………………………………………………….5 1.1 Terminologie……………………………………………………………………………….5 1.2 Conclusion générale ……………………………………………………………………….5 1.3 Utilisation prévue ………………………………………………………………………… 6 1.4 Publique…………………………………………………………………………………....6 1.6 Présentation du Cloud …………………………………………………………………….7 1.6 Problématique...……………………………………………………………………………8 1.7 Exemples de contremesures de sécurité - (exemple AWS Amazon Web Services) ……9 1.7.1 Vue générale ……………………………………………………………………………9 1.7.2 Contremesures …………………………………………………………………………..9 1.7.3 Compatibilité PCI DSS ………………………………………………………………..11 1.7.4 Conformité AWS ……………………………………………………………………11

2 Etapes pour certifier un client ……………………………………………………12 3 Valider le Client avec la norme PCI DSS ………………………………………13

3.1 Prudence et diligence raisonnable ………………………………………………………. 13 3.2 Les CSP compatibles et non compatibles ………………………………………………..14 3.3 Elaborer un SLA entre le client et son CSP ……………………………………………...16 3.4 Définir l'environnement ………………………………………………………………….17 3.5 Exiger un inventaire ……………………………………………………………………..17 3.6 Partage de rôles et responsabilités ……………………………………………………….19 3.7 Défis de conformité ……………………………………………………………………...28 3.8 Définir d'utilisation appropriée des outils de gestion …………………………………….29 3.9 Etablir des politiques et des procédures pour chaque exigence de sécurité PCI DSS, ainsi

que la gestion des rapports ……………………………………………………………….29 3.10 Considérations et recommandations pour l’environnement Cloud déployé ……………29 3.10.1 Considérations de segmentation ……………………………………………………...30 3.10.2 Recommandations pour les environnements en mode mixte ………………………...31 3.10.3 Considérations de scoping …………………………………………………………..32 3.10.4 Composants systèmes virtuels et le scoping …………………………………………32 3.11 Planning des documents que le client doit demander au CSP …………………………33 3.12 Considérations de sécurité ……………………………………………………………...34 3.12.1 Gestion de risque ……………………………………………………………………..34 3.12.2 Evaluer les risques associés aux technologies de virtualisation ……………………...35 3.12.3 Identifier les menaces ………………………………………………………………..36 3.12.4 Identifier les vulnérabilités …………………………………………………………...36 3.13 Installations et accès physique ………………………………………………………….36 3.14 Considérations sur la sécurité des données ……………………………………………..37 3.14.1 Images et clichés instantanés ………………………………………………………...37



3.14.2 Machines dormantes ou inactives ……………………………………………………38 3.14.3 Reconnaître la nature dynamique des VM …………………………………………..38 3.14.4 La gestion du cycle de vie des données ……………………………………………...39 3.14.5 Classification des données …………………………………………………………...39 3.14.6 Chiffrement des données et gestion des clés cryptographiques (HSM ou Cloud HSM) ………………………………………………………………………………………...39 3.14.7 Elimination des données ……………………………………………………………...40 3.14.8 Identité et gestion d’accès …………………………………………………………….40 3.14.9 Introspection …………………………………………………………………………..41 3.14.10 Mettre en œuvre la défense en profondeur …………………………………………42 3.14.11 Isolation des fonctions de sécurité …………………………………………………42 3.14.12 Appliquer le moindre privilège et la séparation des fonctions ………………………43 3.14.13 Evaluer les technologies d'hyperviseur ……………………………………………...43 3.14.14 Solidifier l’hyperviseur ……………………………………………………………..43 3.14.15 Solidifier les machines virtuelles et autres composants ……………………………..44 3.14.16 Meilleures pratiques pour les applications de paiement …………………………….44 3.15 Considérations de Cloud pour PCI DSS ……………………………………………….46



Présentation de l’entreprise :

INTELLCAP est une société de droit marocain crée en 2008 à l’initiative de Monsieur ILALI Idriss. INTELLCAP, spécialisé en la formation, la recherche, le développement et l'innovation technologique, entre autres, dans les domaines des énergies renouvelables et de l'eau, proposant des solutions intégrées et à la demande pour les entreprises et organisations, déclare posséder l'expertise lui permettant de réaliser sa mission avec professionnalisme

INTELLCAP opère dans plusieurs domaines d’activités :

• Aéronautique, Aerospace, Energies renouvelables, véhicules électriques, production et prototypages…

• La R&D, le développement technologique de solutions innovantes par la réalisation de systèmes technologiques développés clés en main qui ont pour but d’intégrer le pays dans l’ère de l’industrialisation.

• La formation des jeunes et leur accompagnement dans la création de startups innovantes sur la base de technologies nationales.

De plus pour chaque domaine : Recherche et Développement: INTELLCAP à tisser des partenariats avec des

organismes et bureaux d’études afin de développer des solutions innovantes en matières de véhicules électriques, systèmes de stockages et de production de l’énergie propre, l’aéronautique.

Technologie & Ingénierie : INTELLCAP à tisser des partenariats avec des organismes et bureaux d’études afin de développer des solutions innovantes en matières de véhicules électriques, systèmes de stockages et de production de l’énergie propre, l’aéronautique.

Education & Formation : Education Par le recours au processus de l’apprentissage par la pratique. INTELLCAP a développé dans le cadre de plusieurs partenariats le concept et la pratique des ateliers pédagogiques qui ont pour but d’initier les jeunes scolarisés et non scolarisés à des techniques industriels et technologiques respectueuses de l’environnement .

Services : Consiste en le Conseil juridique et financier, scientifique industriel et technologique par l’accompagnement des STRATUPS dans leur montage juridique et financier jusqu’à la phase de la création et de la mise en œuvre de leur stratégie de développement.



Note importante :

• Ce document traite les exigences PCI DSS pour les réseaux physiques ordinaires, ainsi il étudie les nouvelles menaces de Cloud, virtualisation, relations clients-CSP, et contient de nouvelles considérations de sécurité du Cloud qui peuvent s’ajouter aux exigences PCI DSS déjà existantes.

• Le but de ce document est de fournir une CHECKLIST additionnelle (non exhaustive) pour vérifier les exigences PCI DSS v3.0, en y ajoutant les nouvelles menaces et vulnérabilités du Cloud et Virtualisation.

• Les nouvelles menaces et considérations de sécurité qui doivent être ajoutées au SAQ officiel de PCI DSS v3.0 sont en forme italique et gras.

• Ce document fait l’implémentation uniquement de 2 conditions PCI DSS v3.0 de sécurité.



1Généralités : 1.1 Terminologie : Entité : Une entité est une organisation qui a la responsabilité de protéger les données de cartes et peut faire appel à un fournisseur de services tiers pour l’a soutenir dans les activités de traitement de carte ou pour sécuriser les données de cartes. CSP (Cloud Service Provider): Le CSP, ou fournisseur de Cloud, est l'entité fournissant le service de Cloud. Le CSP acquiert et gère l'infrastructure nécessaire à la fourniture des services, dirige le logiciel Cloud qui fournit les services, et offre les services de Cloud Computing dans l'accès réseau. Client Cloud : L'entité utilisant un service fourni par un fournisseur de Cloud. Inclut les commerçants, prestataires de services, et d'autres entités qui utilisent les services de Cloud Computing. Mais également peut être un locataire de Cloud. TPSP (Third-Party Service Provider) : Un prestataire de services est une entreprise qui n’est pas une marque de paiement, directement impliquée dans le traitement, le stockage ou la transmission des données des détenteurs de cartes au nom d'une autre entité. Cela comprend également les entreprises qui fournissent des services de contrôle ou qui peuvent avoir un impact sur la sécurité des données des titulaires de cartes. Il existe de nombreux types d'entreprises qui peuvent tomber dans la catégorie de «fournisseur de service », ça dépend des services fournis.

1.2 Conclusion générale : Le « Cloud Computing » est une méthode d’utilisation à la demande des applications, plateformes ou infrastructures réseaux et systèmes distribuées sans la nécessité de savoir leurs localisations géographiques. Il existe un certain nombre de facteurs à prendre en considération lors de la migration à des services de Cloud Computing, et les organisations doivent clairement comprendre leur besoins avant qu'ils puissent déterminer si et comment ils seront accueillis par une solution ou fournisseur particulier. Comme le Cloud Computing est encore une technologie en évolution, les évaluations des risques et des avantages peuvent changer selon la technologie. La sécurité du Cloud est une responsabilité partagée entre le fournisseur de services Cloud (CSP) et ses clients. Si les données de la carte de paiement sont stockées, traitées ou transmises dans un environnement de Cloud Computing, la norme PCI DSS sera applicable à cet environnement, et impliquera typiquement la validation de l'infrastructure à la fois par le CSP et le client. La répartition des responsabilités entre le client et le fournisseur pour la gestion des contrôles de sécurité ne dispense pas un client de sa responsabilité à veiller à ce que la sécurité de leurs données de titulaire de carte est correctement fixée selon les exigences PCI DSS.



Des politiques et des procédures claires doivent être convenus entre le client et le fournisseur de Cloud pour chaque exigence de sécurité, et les responsabilités pour le fonctionnement, la gestion et les rapports doivent être clairement définis et compris pour chaque exigence.

Le commerce électronique, communément appelé e-commerce, est l'achat et la vente de produits ou de services sur des systèmes électroniques tels que l'Internet. Dans notre cas le commerçant a choisi de vendre ses biens et services en ligne en gardant des responsabilités sur l’infrastructure:

• Le commerçant peut choisir de conserver les différents niveaux de contrôle et de responsabilité pour la gestion de l'infrastructure Cloud. Par exemple, le commerçant peut choisir de gérer une partie du réseau Cloud public avec le modèle de service IaaS : externaliser les réseaux et les serveurs, la gestion de tous les systèmes et les infrastructures pour les fournisseurs de service Cloud, et de gérer certains composants à distance en utilisant l’interface Web ou les API du CSP. Cette option de modèle de service ne supprime pas les responsabilités PCI DSS du fournisseur, mais garde la responsabilité partagée entre les deux parties.

• Les applications de paiement e-commerce tels que les cartes d’achat doivent être validées selon la norme PA-DSS, et confirmées pour être incluses sur la liste de PCI SSC des applications de paiement validées. Pour les applications e-commerce développées en interne, PA-DSS doit être utilisée comme une meilleure pratique au cours du développement.

• Les relations avec les tiers et les responsabilités PCI DSS du marchand et chaque tierce-partie doivent être clairement documentées dans un accord de niveau de service SLA pour assurer que chaque partie comprend et met en œuvre les contrôles PCI DSS appropriés.

1.3 Utilisation prévue : Ce document est utilisé pour plusieurs facteurs :

• Il fournit des indications sur l'utilisation des technologies de Cloud Computing et les considérations pour le maintien des exigences PCI DSS dans les environnements de Cloud Computing.

• Le but est de fournir des conseils sur l'utilisation des technologies de e-commerce conformément à la Payment Card Industry Data Security Standard (PCI DSS).

1.4 Publique : Le public concerné par ce document est :

• Les marchands qui utilisent ou envisagent l'utilisation des technologies e-commerce dans un environnement de données de titulaire de carte (CDE).

• Les fournisseurs de services tiers qui fournissent des services de e-commerce dans le Cloud.



• Ce document peut également avoir de la valeur pour les évaluateurs qualifiés de sécurité (QSA) examinant les environnements e-commerce dans le cadre d'une évaluation PCI DSS.

• Les acquéreurs (aussi connus comme "les banques acquéreuses», «banques d'affaires», ou «institutions d'acquisition financières") - en tant qu’entité qui initie et entretient des relations avec les commerçants pour l'acceptation des cartes de paiement, un acquéreur est responsable de veiller à ce que les marchands de son portefeuille s’engagent avec des TPSP sécurisés.

1.5 Présentation du Cloud : Par définition, le « Cloud Computing » fait référence à la fourniture à la demande de ressources et d’applications informatiques qui peuvent être rapidement provisionnés et libérés avec un effort minime de gestion pour le client. Le Cloud Computing se décline en trois principaux types, généralement connus sous le nom de IaaS (Infrastructure en tant que service), PaaS (Plate-forme en tant que service) et SaaS (Logiciel en tant que service). En sélectionnant le type de Cloud Computing qui correspond le mieux à nos besoins, nous pouvons combiner à la fois le niveau de contrôle approprié et éviter un remaniement en profondeur.

Infrastructure en tant que service (IaaS) :

L'infrastructure en tant que service (IaaS) donne habituellement l’accès à des fonctionnalités de mise en réseau, à des ordinateurs (virtuels ou sur du matériel dédié) et à de l'espace de stockage de données. Le service IaaS offre le niveau le plus élevé de flexibilité et de contrôle de gestion en ce qui concerne les ressources informatiques et est très similaire aux ressources informatiques existantes avec lesquelles les services informatiques et les développeurs sont aujourd'hui familiarisés.

Plate-forme en tant que service (PaaS) :

Grâce au service PaaS, les entreprises n'ont plus besoin de gérer l'infrastructure sous-jacente (en règle générale, le matériel et les systèmes d'exploitation) et le client peut se concentrer sur le déploiement et la gestion de ses applications. Le client sera ainsi plus efficace, car il n’a pas à se soucier de l'approvisionnement des ressources, de la planification des capacités, de la maintenance logicielle, de l'application de correctifs ou de toute autre charge indifférenciée liée à l'exécution de son application.

Logiciel en tant que service (SaaS) :

Le logiciel en tant que service offre un produit final qui est exécuté et géré par le prestataire de services. Dans la plupart des cas, les personnes qui font référence au service Saas pensent aux applications des utilisateurs finaux. Avec une offre SaaS, le client n'a pas à songer à la maintenance du service ou à la gestion de l'infrastructure sous-jacente, il doit juste réfléchir à l'utilisation de ce logiciel spécifique. Une messagerie Web dans laquelle on peut envoyer et recevoir des e-mails sans avoir à gérer des ajouts de fonctionnalités ni à effectuer la



maintenance des serveurs et des systèmes d'exploitation sur lesquels elle s'exécute est un exemple courant d'application SaaS.

1.6 Problématique :

Le marché mondial du e-commerce : 1 000 milliards de dollars dépensés en 2012 - D’après eMarketer.com, ce sont 1 000 milliards de dollars qui ont été dépensés dans le monde en 2012 sur le marché du e-commerce , soit une croissance de 21,1% par rapport à 2011. Les Etats-Unis ont représenté à eux seuls 343,43 milliards de dollars de dépenses l’année dernière. Mais la plus forte croissance (33%) est à inscrire au crédit de la région Asie-Pacifique (332,46 milliards en 2012). Avantages du Cloud Computing :

• L'agilité dans la mutualisation des ressources : Il est possible d'affecter des ressources technologiques supplémentaires aux départements métiers de l'entreprise lorsque celles-ci sont nécessaires pour faire face à un pic d'activité par exemple, puis de les libérer une fois la charge ramenée à la normale.

• La maîtrise et l'agilité de son outil informatique : Avec un Cloud Privé, l'entreprise maîtrise la gestion de son système d'information de bout en bout car elle reste propriétaire de son infrastructure.

Avantages du Cloud public :

• Plutôt que d'investir massivement dans des centres de données et des serveurs, les clients peuvent ne payer que lorsqu’elles consomment des ressources de calcul. Ainsi, les clients ne paient qu'en fonction de ce qu’elles consomment.

• À l'aide du Cloud Computing public, les clients peuvent obtenir un coût variable moins élevé que celui que le client aurait de son côté. Dans la mesure où l'utilisation de centaines de milliers de clients est regroupée dans le Cloud, les fournisseurs tels qu'Amazon Web Services ou Google Cloud Computing peuvent bénéficier de plus grandes économies d'échelle, ce qui se traduit par des prix moins élevés à l'utilisation.

• Le client ne pourra jamais deviner exactement quels seront ses besoins en termes de capacités d'infrastructure. Grâce au Cloud Computing le client peut accéder à toutes les ressources qu’il souhaite, et les augmenter ou les réduire en fonction de ses besoins en quelques minutes.

• Le client peut se concentrer sur des projets qui permettent à son entreprise de se démarquer, et non sur son infrastructure. L’équipe informatique est chez le CSP.

Problèmes de sécurité en Cloud Computing :

• L’idée que les informations confidentielles du client se trouvent entre les mains d’une tierce-partie l’angoisse surement. L’une des conséquences du Cloud Computing peut en effet être une perte de contrôle. Transférer le traitement de vos données vers un tiers, c’est transférer également un peu de la responsabilité qui leur est associée en matière de sécurité et de conformité. Il n’est donc pas étonnant que les professionnels



de la sécurité soient inquiets. Par conséquent, il est capital que le client ait entièrement confiance en son CSP.

• La gouvernance en matière de sécurité des informations doit résulter d’une collaboration entre les clients et les fournisseurs afin d’atteindre des objectifs fixés qui permettent la mise en œuvre de la mission de l’entreprise et du programme de sécurité des informations.

• L’une des premières mesures que les entreprises doivent prendre est d’acquérir une véritable compréhension de la nature des données de leur organisation. Dans notre cas on est censés stocker, traiter et transmettre des données de cartes de paiements, la norme qui sera applicable dans ce cas est PCI DSS.

1.7 Exemples de contremesures de sécurité - (exemple AWS Amazon Web Services) : 1.7.1 Vue générale :

• L'infrastructure du Cloud doit être hébergée dans des centres de données extrêmement sécurisés.

• La sécurité doit être assurée par une surveillance électronique très sophistiquée et des systèmes de contrôle d'accès multi-facteurs.

• Les centres de sécurité doivent être gardés 24h/24 et 7j/7 par des agents de sécurité formés et l'accès sera strictement contrôlé en fonction du principe du moindre privilège.

• Tous les membres du personnel font l'objet d'un contrôle lorsqu'ils quittent des zones renfermant des données client.

• Des systèmes environnementaux sont intégrés aux centres de données afin de minimiser l'impact des perturbations sur leur fonctionnement.

• Si possible, plusieurs régions géographiques et zones de disponibilité permettront une résilience face à la plupart des modes de défaillance, y compris les catastrophes naturelles ou les défaillances du système.

• Veiller à fournir une disponibilité optimale, tout en garantissant une confidentialité complète et un isolement des clients.

• Une séparation du trafic réseau entre le réseau du CSP et son service de Cloud devra être garantie.

1.7.2 Contremesures :

• Accès sécurisé – Les points d'accès des clients, également appelés points de terminaison des API, autorisent un accès HTTP sécurisé (HTTPS) afin que les clients puissent établir des sessions de communication sécurisées avec leurs services AWS via SSL/TLS.

• Pare-feu intégrés – En configurant des règles de pare-feu intégrées, le client peut déterminer le degré d'accessibilité de ses instances, depuis un accès totalement public à un accès entièrement privé, en passant par différents échelons intermédiaires. Et



lorsque les instances du client résident dans un sous-réseau Virtual Private Cloud (VPC), les clients peuvent contrôler aussi bien les sorties que les entrées.

• Utilisateurs uniques – L'outil AWS Identity and Access Management (IAM) permet de contrôler le niveau d'accès d’utilisateurs clients par rapport aux services reposant sur l'infrastructure AWS. Avec AWS IAM, chaque utilisateur peut posséder des identifiants de sécurité uniques, ce qui évite d'avoir à partager les mots de passe ou clés et permet d'appliquer les bonnes pratiques de sécurité telles que la séparation des rôles et le principe de moindre privilège.

• Authentification multi-facteurs (MFA) – AWS intègre la prise en charge de l'authentification multi-facteurs (MFA) sur le compte racine AWS ainsi que sur les comptes individuels des utilisateurs IAM correspondants.

• Sous-réseaux privés – Le service AWS Virtual Private Cloud (VPC) permet d'ajouter une couche de sécurité réseau supplémentaire aux instances en créant des sous-réseaux privés et, même, en ajoutant un tunnel VPN IPsec entre le réseau interne client et son VPC AWS.

• Stockage de données chiffrées – Les clients peuvent chiffrer automatiquement les données et objets qu'ils stockent dans Amazon EBS, Amazon S3, Glacier, Redshift, ainsi que sur RDS pour Oracle et SQL Server, en utilisant Advanced Encryption Standard (AES) 256, une norme de chiffrement par clé symétrique sécurisée utilisant des clés de chiffrement de 256 bits.

• Option de connexion dédiée – Le service AWS Direct Connect permet l'établissement d'une connexion réseau dédiée depuis ses locaux vers AWS. Utilisant des VLAN 802.1q aux normes de l'industrie, cette connexion dédiée peut être partitionnée en plusieurs connexions logiques afin de permettre l'accès à des environnements IP aussi bien publics que privés au sein du Cloud client AWS.

• Perfect Forward Secrecy (confidentialité persistante) – Pour une confidentialité renforcée des communications, plusieurs services AWS tels qu'Elastic Load Balancer et Amazon CloudFront offrent de nouvelles suites de chiffrement (cipher) plus robustes. Ces suites de chiffrement permettent aux clients SSL/TLS d'utiliser la technologie PFS (Perfect Forward Secrecy), laquelle est basée sur des clés de session éphémères qui ne sont enregistrées nulle part. Ainsi, il est impossible de décoder les données interceptées, même si la clé secrète à long terme est compromise.

• Journaux de sécurité – AWS CloudTrail fournit les journaux consignant les activités de tous les utilisateurs au sein du compte client AWS. Le client peut voir quelles sont les actions ayant été effectuées sur chacune des ressources AWS et leur auteur. L'historique des appels d'API AWS généré par CloudTrail permet de réaliser une analyse de sécurité, le suivi des modifications au niveau des ressources, ainsi que l'audit de conformité.

• Identification et configuration des actifs – Le service AWS Config permet de détecter immédiatement toutes les ressources AWS et de vérifier la configuration de chacune d'entre elles. Le client peut choisir de recevoir une notification à chaque modification de la configuration et explorer l'historique de configuration à des fins d'analyse des incidents.

• Gestion centralisée des clés – Les clients ayant largement recours au chiffrement nécessitent un contrôle strict de leurs clés. C'est pourquoi AWS Key Management



Service dispose d'une option de gestion particulièrement utile permettant de créer et de gérer les clés utilisées pour chiffrer les données au repos.

• Région GovCloud isolée – Pour les clients ayant besoin de mesures supplémentaires afin de se conformer à la réglementation américaine ITAR sur le trafic international d'armes, AWS fournit une région totalement séparée, appelée AWS GovCloud (USA), qui offre un environnement au sein duquel les clients peuvent exécuter des applications conformes aux exigences ITAR et des points de terminaison spécifiques qui utilisent le chiffrement FIPS 140-2.

• CloudHSM – Pour les clients qui doivent utiliser des modules de sécurité matériels ou HSM (Hardware Security Module) pour le stockage de clés cryptographiques, AWS CloudHSM constitue un moyen pratique et hautement sécurisé de stocker et gérer des clés.

• Trusted Advisor – Fourni automatiquement lorsque le client s’inscrit au Premium Support, le service Trusted Advisor est un moyen pratique de voir quels services on peut sécuriser encore davantage. Il surveille les ressources AWS et avertit lorsqu'il détecte des failles dans la configuration de sécurité, telles que l'accès trop vaste à certains ports d'instance EC2 et compartiments de stockage S3, l'utilisation minimale de la séparation des rôles avec IAM, et des politiques de gestion des mots de passe fragiles.

1.7.3 Compatibilité PCI DSS : PCI-DSS est une norme qui spécifie les meilleures pratiques et les divers contrôles de sécurité. Toute entité qui stocke, traite ou transmet des données de titulaire de carte est censée être certifiée PCI DSS. La certification de la norme PCI DSS exige aux organisations :

• Création et gestion d’un réseau et d’un système sécurisés. • Protection des données du titulaire. • Gestion d’un programme de gestion des vulnérabilités. • Mise en œuvre de mesures de contrôle d’accès strictes. • Surveillance et test réguliers des réseaux. • Gestion d’une politique de sécurité des informations.

1.7.4 Conformité AWS : L'infrastructure du nuage AWS est conçue et gérée conformément à diverses réglementations, normes et bonnes pratiques, notamment :

• HIPAA : AWS permet aux entités et à leurs collaborateurs entrant dans le cadre de la législation américaine HIPAA (Health Insurance Portability and Accountability Act) de tirer parti de l'environnement sûr d'AWS pour traiter, gérer et stocker des données de santé à caractère personnel.

• SOC 1/SSAE 16/ISAE 3402 : Ce rapport reposant sur deux normes américaines répond à une grande variété de critères d'audit exigés par les organismes d'audit américains et internationaux. L'audit du rapport SOC 1 atteste que les objectifs de



contrôle d'AWS sont définis de manière appropriée et que les contrôles établis pour protéger les données des clients sont efficaces.

• SOC 2 : En plus du rapport SOC 1, AWS publie un rapport SOC 2 (Service Organization Controls 2), de type II. A l'instar du SOC 1 en matière d'évaluation des contrôles, le rapport SOC 2 est une attestation qui développe l'évaluation des contrôles par rapport aux critères stipulés par l'AICPA (American Institute of Certified Public Accountants) dans ses principes sur les services de confiance (« Trust Services Principles »). . Ces principes définissent des contrôles portant sur les pratiques majeures relatives à la sécurité, à la disponibilité, à l'intégrité de traitement, à la confidentialité et au respect de la vie privée, et s'appliquent aux prestataires de services tels qu'AWS.

• PCI DSS, niveau 1 : De plus, AWS a obtenu la certification de niveau 1 conformément à la norme de sécurité des données dans le secteur des cartes de paiement : la norme PCI DSS (Payment Card Industry Data Security Standard). Nos clients peuvent donc exécuter des applications sur notre infrastructure technologique conforme à la norme PCI pour stocker, traiter et transmettre des informations relatives aux cartes de paiement dans le nuage.

• ISO 27001 : AWS est certifié ISO 27001 conformément à la norme ISO 27001 édictée par l'Organisation internationale de normalisation. La norme ISO 27001 est une norme de sécurité internationale très largement adoptée qui définit des exigences à respecter pour les systèmes de gestion de la sécurité des informations. Elle fournit une approche systématique pour la gestion des informations des entreprises et des clients qui repose sur des évaluations régulières des risques.

• FedRAMP (SM) : FedRAMP est un programme mis en place par le gouvernement américain afin de normaliser l'évaluation de la sécurité, les autorisations et la surveillance continue des produits et services de Cloud Computing jusqu'à un niveau Modéré.

Figure 1 : Niveaux de responsabilités pour les trois modèles de services :



2 Etapes pour certifier un client :

1. Valider le CSP avec la norme PCI DSS. 2. Effectuer une diligence raisonnable. 3. Etablir un accord SLA entre CSP et client. 4. Valider le client avec la norme PCI DSS. 5. Délivrance d’une attestation de conformité (AOC) 6. Délivrance d’un rapport de conformité (ROC). 7. Le client est maintenant conforme PCI DSS

3 Valider le Client avec la norme PCI DSS :

3.1 Prudence et diligence raisonnable :

Un examen minutieux des CSP par le biais de Diligence raisonnable, avant d'établir une relation, aide les entités dans l'examen et la sélection des bons TPSP avec les compétences et les expériences appropriées à l'engagement.

Mettre en place un processus de diligence raisonnable du CSP :

• Etudier l’image du CSP dans le marché au niveau mondial ou national.

• Chercher le nom du CSP qui a dit qu’il est conforme PCI DSS dans la liste des entreprises conformes PCI DSS publiée par une marque de carte de paiement : il peut se trouver dans la liste comme il peut ne pas se trouver.

• Etudier les procédures ressources humaines du CSP : La gestion des ressources humaines du CSP est en grande partie hors du contrôle du client. Le processus diligence raisonnable du client doit inclure une compréhension des ressources humaines du CSP et ses pratiques d'engagement du personnel, car le personnel inapproprié ou sous-qualifiés peut exposer les données à des risques inutiles. L’exigence PCI DSS 12.7 fournit une base pour évaluer le processus de recrutement et de licenciement du CSP.

• Confirmer que le fournisseur à une bonne réputation des pratiques de travail et qu’il effectue légitimement les services que le client croit qu'elles sont faites.

• Vérifier que la réputation du fournisseur est compatible avec l'image de l'entreprise cliente.

• Identifier les risques potentiels ou les circonstances associées au fournisseur qui peuvent influer sur l’exploitation ou les activités du client.

• Les éléments du service qui ont besoin d'être clarifiées, et ce besoin identification à inclure dans contrats ou des accords de services.



• Les CSP qui ont subi une évaluation PCI DSS indépendante pour valider leur conformité auront les résultats résumés dans une attestation de conformité (AOC) et détaillés dans un rapport sur la conformité (ROC), le client doit examiner ces documents attentivement.

• Les CSP qui ont subi une évaluation PCI DSS de conformité et de validation doivent être en mesure de fournir à leurs clients les éléments suivant: � Preuve de la documentation de conformité (comme l'AOC et les articles

applicables de la ROC), y compris la date de l'évaluation de la conformité. � Des preuves documentées de composants système et des services qui ont été inclus

dans l’évaluation de la norme PCI DSS. � Des preuves documentées de composants système et des services qui ont été

exclus de la norme PCI DSS l'évaluation, le cas échéant au service. � Etudier les rapports PCI DSS du CSP: quels services et composants du système

sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et 6.2 portent sur la nécessité que les vulnérabilités doivent être identifiées, selon leur indice et selon le risque, et corrigées en un temps minime. Si pas correctement défini, un client pourrait supposer que le CSP gère ce processus (Voir celui de AWS) pour tout l'environnement Cloud, alors que le CSP pourrait gérer uniquement les vulnérabilités de son infrastructure sous-jacente, en supposant que le client gère des vulnérabilités des systèmes d'exploitation, des applications et des sites web (pour e-commerce)).

Figure 2 : Processus engagement CSP

Figure 3: Exemple de processus diligence raisonnable.



3.2 Les CSP compatibles et non compatibles :

Comme avec tous les services hébergés dans le périmètre de la norme PCI DSS, l'organisation du client doit demander la preuve et l'assurance suffisante de leur CSP que tous les processus et composants dans-le-champ sont conformes PCI DSS. Cette vérification peut être remplie par l'évaluateur du client (par exemple comme un QSA ou ISA) dans le cadre de l'évaluation PCI DSS du client.

• Les CSP qui ont subi une évaluation PCI DSS de conformité et de validation doivent être en mesure de fournir à leurs clients les éléments suivant:

� Preuve de la documentation de conformité (comme l'AOC et les articles applicables de la ROC), y compris la date de l'évaluation de la conformité.

� Des preuves documentées de composants système et des services qui ont été inclus dans l’évaluation de la norme PCI DSS.

� Des preuves documentées de composants système et des services qui ont été exclus de la norme PCI DSS l'évaluation, le cas échéant au service.

� Etudier les rapports PCI DSS du CSP: quels services et composants du système sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et 6.2 portent sur la nécessité que les vulnérabilités doivent être identifiées, selon leur indice et selon le risque, et corrigées en un temps minime. Si pas correctement défini, un client pourrait supposer que le CSP gère ce processus pour tout l'environnement Cloud, alors que le CSP pourrait gérer uniquement les vulnérabilités de son infrastructure sous-jacente, en supposant que le client



gère des vulnérabilités des systèmes d'exploitation, des applications et des sites web (pour e-commerce)).

• Les CSP qui n’ont pas subi une évaluation de la conformité PCI DSS devront être

inclus dans l'évaluation du client. Le CSP devra accepter de permettre à l'évaluateur du client un accès à leur environnement pour que le client puisse compléter leur évaluation. Les assesseurs du client peuvent exiger sur place l’accès à des informations détaillées du CSP, y compris, mais sans s'y limiter:

� L'accès aux systèmes, les installations et le personnel pour les examens sur place, des interviews, etc.

� Les politiques et procédures, la documentation des processus, des normes de configuration, dossiers de formation, les plans d'intervention sur l’incident, etc.

� Preuve (telles que les configurations, des captures d'écran, des revues de processus, etc.) pour montrer que toutes les exigences PCI DSS sont respectées pour les composants in-scope de système.

Figure 4: Processus de certification de la partie CSP

• Vérifier que le service utilisé est validé : Les clients doivent d'abord vérifier que le service qu'ils utilisent est celui qui a été validé.

3.3 Elaborer un SLA entre le client et son CSP :

L'utilisation de services de Cloud Computing comprend le déploiement d'un modèle de service défini et doit toujours être souscrite par des accords globaux de niveau de service (SLA). L'incapacité de développer des accords SLA appropriées peuvent entraîner des problèmes pour le client si le service de Cloud ne répond pas aux besoins et aux exigences de leur entreprise.



• Identifier toutes les relations entre le client et ses tiers est important pour comprendre les ramifications potentielles à l'environnement d'un client.

• Les activités de tests définis et leurs contrôles et autorisations associées doivent être détaillées dans le SLA.

• La délimitation des responsabilités entre les parties, y compris les responsabilités pour la mise en œuvre et la gestion de différents contrôles de sécurité pour un modèle de Cloud public/IAAS.

• Respecter le "up-time", la haute disponibilité et l'assurance de la sécurité.

• Les activités de validation PCI DSS et de test de conformité (avec les contrôles associés, les autorisations et les tâches planifiées) doivent également être clairement détaillées dans le SLA.

• Les performances, la disponibilité, l'intégrité et la confidentialité doivent être envisagées dans le SLA pour chaque service géré.

• Dans le SLA exiger la délivrance des logs des services qui tombent in-scope du CSP périodiquement.

3.4 Définir l'environnement :

Avant que les menaces et les vulnérabilités puissent être identifiées et évaluées, une entité doit d'abord comprendre son environnement ainsi que les personnes, les processus et les technologies qui interagissent avec cet environnement. Lors de la définition de l'environnement à évaluer, les entités doivent tenir compte de tous aspects qui ont un impact potentiel de risque, indépendamment du fait qu'ils sont considérés in-scope ou hors du champ de la norme PCI DSS.

• Une entité doit d'abord comprendre leur environnement ainsi que les personnes, les processus et les technologies qui comprennent ou interagissent avec cet environnement.

• La définition de l'environnement virtuel doit inclure, au minimum, les activités suivantes: � Identification de tous les composants, y compris les hyperviseurs, les charges de

travail, les hôtes, les réseaux, les consoles de gestion et d'autres composants; � Détails physiques du site pour chaque composant; � Description des fonctions primaires et les propriétaires affectés pour chaque

composant; � Détails de visibilité dans et entre les composants; � Identification des flux de trafic entre les différentes composantes, entre les

composants et les hyperviseurs, et entre les composants et les systèmes hôtes sous-jacents ou les ressources matérielles;

� Identification de toutes les communications intra-hôtes et les flux de données, ainsi que celles entre les composants virtuels et les autres composants du système;



� Détails de toutes les interfaces de gestion et des mécanismes d'accès à l'hyperviseur, y compris les rôles et autorisations définis;

� Tous les composants matériels physiques et virtuels tels que les lecteurs de disques amovibles et USB, ports parallèle et série.

� Détails sur le nombre et les types de composants virtuels sur chaque hôte, les types de segmentation entre les composants et les hôtes, les fonctions et les niveaux de tous les composants virtuels de sécurité, etc.

• Les recommandations pour réduire et simplifier les exigences PCI DSS à in-scope dans un environnement de Cloud Computing comprennent: � Mettre en œuvre une infrastructure physique dédiée qui est utilisée seulement pour

l'environnement CDE. � Réduire la dépendance sur les CSP tiers pour protéger les données de cartes de

paiement.

3.5 Exiger un inventaire :

L’utilisation d'un inventaire peut aider à identifier les types de composants impliqués dans la livraison du service et les responsables pour les sécuriser. Tableau 1 : Exemple de tableau d’inventaire à remplir Type / couche

Composant Description / But

Type de composante

Nombre de composants

Notes d’implémentation

La responsabilité de sécurité des composants

Remarque: couches réels varieront en fonction de la structure de Offres de services CSP

Par exemple: Pare-feu, OS, l'application, serveur web, hyperviseur, routeur, base de données, etc.

Par exemple: Est composante physique, logique ou virtuelle? Statique ou dynamique?

Nombre de composants utilisé en relation avec ce client service

Utilisation défini, l'emplacement, etc., le cas échéant

Par exemple: CSP seulement, client seulement, ou partagée

Données

Interfaces (APIs, GUIs)

Applications

Pile de Solution (Languages de programmation)

Système d'exploitation (OS)



Machines virtuelles VMs

Infrastructure réseau virtuel

Hyperviseurs

Processeur et mémoire

Stockage de données (Disques durs-disques amovibles-stockage..etc)

Réseau (Interfaces et périphériques- infrastructure de communications)

Installations physiques/Centre de données

3.6 Partage de rôles et responsabilités :

La responsabilité de la mise en œuvre, l'exploitation et la gestion des contrôles de sécurité sera partagée entre le CSP et son client. Si ces responsabilités en matière de sécurité ne sont pas correctement assignées, communiquées et comprises, des configurations et vulnérabilités non sécurisées peuvent impacter la sécurité générale de l’environnement, en résultant un exploit potentiel, la perte de données et d'autres compromis.

• Il faut partager les responsabilités entre le CSP et le client pour gérer la sécurité (La segmentation et séparation est une responsabilité du CSP, et le client doit vérifier par ses outils que son environnement est séparé de l’environnement des autres clients qui pourront être non sécurisés.).

• Dresser des politiques et des procédures claires entre le client et le CSP pour chaque exigence et responsabilité, et délivrer un rapport pour chacun.

• Dans un modèle Cloud public, la responsabilité est partagée, il faut déterminer le niveau de responsabilité du CSP et celui du client. Il faut bien détailler ces niveaux de responsabilités (Délivrer les journaux au client, le client doit analyser les logs, le client ne doit jamais lever sa main sur la sécurité des données CHD, car c’est lui le responsable finale.)



• Il faut détailler la nature de responsabilité partagée, c’est quoi ce partage ?= (responsabilités sur les opérations techniques (Administration des composants virtuels), la gestion et la génération de rapports pour chaque exigence)

• Les responsabilités délimitées entre le client et le CSP pour la gestion des contrôles PCI DSS sont influencées par un certain nombre de variables, y compris, mais sans s'y limiter: � Le but pour lequel le client utilise le service de Cloud. � Le scope des exigences PCI DSS que le client externalise au CSP. � Les services et les composants du système que le CSP a validé dans ses propres

opérations. � L'option de service que le client a choisi d'engager le CSP (IaaS, PaaS ou SaaS). � Le scope de tous les services supplémentaires le CSP fournit une gestion proactive

de la conformité du client (Par exemple, plus les services de sécurité gérés). • Détailler les responsabilités PCI DSS pour uniquement le modèle de service IaaS. • Il y a les rôles sur les composants de l’environnement virtuel, et les rôles sur les

exigences PCI DSS. • Il doit être particulièrement nécessaire de définir des rôles granulaires d’utilisateurs

(par exemple, la séparation d’administrateur réseau de l'administrateur du serveur).

• Lorsque le CSP conserve la responsabilité des contrôles PCI DSS, le client est toujours responsable de la surveillance de la conformité continue du CSP pour toutes les exigences applicables (logs, les documents de conformité pour chaque exigence).

• Pour chaque control PCI DSS, il faut identifier le responsable.

• Le client doit avoir une visibilité sur les exigences de sécurité qui ne sont pas couverts par le CSP et qui rentrent dans les responsabilités du client à gérer, implémenter et valider comme leur propre exigence PCI DSS.

Tableau 2: La description de chaque couche du Cloud Couche Description Application Program Interface (API) ou Interface graphique d’utilisateur (GUI)

L'interface utilisée par le client ou leurs clients pour interagir avec l’application. L'API la plus courante est actuellement RESTful http ou HTTPS. Le GUI le plus utilisé est un site Web HTTP ou HTTPS.

Application L’application actuelle est utilisée par un ou plusieurs clients ou leurs clients.

Suite de solutions Ceci est le langage de programmation utilisé pour créer et déployer les applications. Quelques exemples incluent .NET, Python, Ruby, Perl, etc.

Les systèmes d'exploitation (OS) Dans un environnement virtuel, l'OS fonctionne au sein de chaque VM. Alternativement, s’il n'y a pas d’hyperviseur



sous-jacent présent, le système d'exploitation s’exécute directement sur le matériel de stockage.

Machine virtuelle (VM) Le conteneur virtuel assigné pour une utilisation client.

Infrastructure de réseau virtuel Pour les communications à l'intérieur et entre les machines virtuelles

Hyperviseur Lorsque la virtualisation est utilisée pour gérer les ressources, l'hyperviseur est responsable de l'allocation des ressources à chaque machine virtuelle. Il est également possible de l’utiliser pour mettre en œuvre la sécurité.

Traitement et mémoire Le matériel physique qui fournit de temps CPU et de la mémoire physique.

Stockage de données Le matériel physique utilisé pour le stockage de fichiers.

Réseau Cela peut être un réseau physique ou virtuel. Il est responsable de l'exécution les communications entre les systèmes et éventuellement l'internet.

Installation physique Le bâtiment physique réel où se trouvent les systèmes de Cloud Computing .

Tableau 3 : Exemple de comment les contrôles peuvent être affectés entre le CSP et le Client au niveau du modèle de service IaaS.

Client CSP Couche Cloud IaaS

Données

Interfaces (APIs, GUIs)

Applications

Pile de Solution (Languages de programmation) Système d'exploitation (OS)

Machines virtuelles VMs

Infrastructure réseau virtuel

Hyperviseurs

Processeur et mémoire

Stockage de données (Disques durs-disques



amovibles-stockage..etc) Réseau (Interfaces et périphériques-

infrastructure de communications) Installations physiques/Centre de données

Tableau 4 : exemple de comment les responsabilités peuvent être partagées entre le CSP et le client Client

CSP

Les deux Client et CSP

Exigence PCI DSS IaaS 1: Installer et gérer une configuration de pare-feu pour protéger les données du titulaire

Les deux

2: Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur Les

deux

3: Protéger les données du titulaire stockées Les deux

4: Crypter la transmission des données du titulaire sur les réseaux publics ouverts Client

5: Protéger tous les systèmes contre les logiciels malveillants et mettre à jour régulièrement les logiciels anti-virus ou programmes

Client

6: Développer et gérer des systèmes et des applications sécurisés Les deux

7: Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les connaître

Les deux

8: Identifier et authentifier l’accès aux composants du système Les deux

9: Restreindre l’accès physique aux données du titulaire CSP

10: Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données du titulaire

Les deux



11: Tester régulièrement les processus et les systèmes de sécurité Les deux

12: Maintenir une politique qui adresse les informations de sécurité pour l’ensemble du personnel

Les deux

Tableau 5 : Partage de responsabilité pour chaque exigence. Exigences PCI DSS Considérations communes IaaS 1: Installer et gérer une configuration de pare-feu pour protéger les données du titulaire

IaaS: Typiquement, la sécurité du réseau est une responsabilité partagée: le client est responsable de la sécurisation des réseaux au sein et entre leurs propres environnements, tandis que le CSP offre la sécurité du réseau au niveau du périmètre de nuages et entre les clients du CSP. Le CSP gère les pare-feu sur le réseau de CSP-gérés et les pare-feu et non d'infrastructure visibles pour le client de Cloud. Tout pare-feu au-dessus de la couche de l'infrastructure peuvent être le responsabilité du client de Cloud. Les pare-feu de CSP gérés peuvent également être partagés par plusieurs clients de nuages.

Client et CSP

2: Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur

IaaS: Configuration sécurisée de l'OS et des applications est généralement la responsabilité du client tandis que la configuration sécurisée des appareils sous-jacents est de la responsabilité du CSP. Il peut y avoir être aussi des périphériques virtuels que le client est responsable du maintien.

Client et CSP

3: Protéger les données du titulaire stockées

IaaS et PaaS: Le client est généralement responsable de la manière informations qui est fixé (comme l'utilisation de mécanismes de chiffrement) et dans quel format pour- par exemple, fichiers plats, bases de données entrées, etc. Emplacements physiques des magasins de l'information peuvent être inconnus pour le client, et peuvent avoir besoin d'être identifié emplacements de stockage. Données rétention est défini par le client; toutefois, le CSP contrôle les zones de stockage réels. L'utilisation de contrôles pour prévenir la rétention involontaire ou supplémentaires (par exemple, par l'intermédiaire instantanés, les

Client et CSP



sauvegardes, etc.) doivent également être pris en considération.

4: Crypter la transmission des données du titulaire sur les réseaux publics ouverts

IaaS et PaaS: Typiquement mécanismes de transmission sont commandés par le client tandis que le la technologie sous-jacente est géré par le CSP; toutefois, cela dépendra des technologies en usage. Contrôle pour prévenir la transmission involontaire de données en dehors de environnement client sont généralement mis à jour par le DSP, en fonction du particulier service. Le client doit être conscient de la façon dont les données sont transmises entre les composants dans Afin d'assurer que les données sont cryptées pour toutes les transmissions sur des canaux non-privés. Cette peut comprendre des émissions dans l'environnement propre au client (par exemple, entre client VM).

Client

5: Protéger tous les systèmes contre les logiciels malveillants et mettre à jour régulièrement les logiciels anti-virus ou programmes

IaaS: Protection de l'OS et le client VM est généralement la responsabilité du client. Anti-mises à jour antivirus appliquent à l'OS hôte ainsi que toute VM dans l'environnement client exécutant leur propre OS. Il peut aussi y avoir des périphériques virtuels que le client est responsable de tenir à jour. La protection anti-malware pour les appareils sous-jacente / infrastructures reste de la responsabilité du CSP.

Client

6: Développer et gérer des systèmes et des applications sécurisés

IaaS: Patcher et la maintenance de l'OS et les applications sont généralement à la responsabilité du client, tout en rapiéçage et la maintenance des dispositifs sous-jacents reste le responsabilité du CSP. Il peut aussi y avoir des périphériques virtuels que le client est responsable pour le maintien. Codage sécurisé est typiquement de la responsabilité du client (ils peuvent soit utiliser leurs propres applications ou choisir des applications commerciales sécurisées).

Client et CSP

7: Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les

IaaS et PaaS: En général, le client est responsable de définir l'accès à des fichiers de données Hwy. Emplacement physique des

Client et CSP



connaître

magasins de l'information pourrait être inconnu du client et peut avoir besoin à identifier. Le CSP contrôle les zones de stockage physiques et CSP gérés les contrôles d'accès sont souvent cumulatifs aux commandes définies par le client. L'utilisation de contrôles pour empêcher l'accès involontaire aux données (par exemple, pour les données saisies par l'intermédiaire des clichés, sauvegardes, etc.) doivent également être considérés.

8: Identifier et authentifier l’accès aux composants du système

IaaS et PaaS: Le client est responsable pour assurer que tous les comptes sous contrôle Hwy utiliser des identifiants uniques et l'authentification forte. Le CSP est chargé de veiller à forte authentification est utilisée pour l'infrastructure sous-jacente. Par rapport au modèle IaaS, le CSP conserve les droits d'accès administratif important dans Modèles SaaS et PaaS.

Client et CSP

9: Restreindre l’accès physique aux données du titulaire

Tous les modèles de service: En général gérés par le service CSP pour tous les modèles. Le client a rarement accès physique aux systèmes de Cloud Computing ; et le CSP pourrait permettre pas sur place visites ou audits client. Cela dépendra de la CSP particulier, ainsi que la distribution de données à travers différents endroits; les clients ne peuvent pas savoir à quel endroit abrite leur donnée.

CSP

10: Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données du titulaire

IaaS et PaaS: Le CSP Gère Typiquement surveillance et la journalisation pour sous-jacente dispositifs et des infrastructures, y compris les hyperviseurs, alors que le client est responsable de le suivi et l'exploitation forestière au sein de leurs propres environnements virtuels. La capacité à associer divers fichiers journaux afin de reconstituer les événements peuvent nécessiter corrélation entre client- journaux contrôlés et ceux contrôlés par le CSP. Certaines activités de surveillance peuvent être intégrées à l'entente de service pour le CSP à gérer le compte de clients. Détails de ce que les données seront saisies et ce seront faits à la disposition du client devra

Client et CSP



être défini.

11: Tester régulièrement les processus et les systèmes de sécurité

IaaS et PaaS: Généralement Testing est géré par celui qui a le contrôle du particulier aspect de l'environnement. Cependant, les CSP peut interdire les tests de client, dans ce cas, peuvent avoir besoin les clients de compter sur le CSP. Si le CSP effectue des balayages, le client doit vérifier quelles instances / VM sont couverts. IDS / IPS ne peut être fourni par le CSP. En général, le client peut utiliser FIM pour surveiller leurs propres environnements virtuels (y compris données, les applications et les journaux), tandis que la surveillance des fichiers système / de l'appareil est géré par le CSP.

Client et CSP

12 Maintenir une politique qui adresse les informations de sécurité pour l’ensemble du personnel

Tous les modèles de service: Bien que le CSP et le client peut définir de procédures convenues (pour par exemple, dans le SLA), chaque partie conserve leurs propres politiques de sécurité et interne procédures. Rôles et responsabilités définis, la formation et la sécurité des personnelles exigences sont de la responsabilité de chaque partie pour leur personnel respectif. Les clients doivent veiller à ce que les politiques et procédures CSP sont appropriées pour le Les besoins en matière de risque et de sécurité du client. réponse à l'incident en particulier nécessite une sensibilisation et la coordination entre les deux parties.

Client et CSP



Tableau 6 : Exemple de partage de responsabilité pour chaque exigence.

Responsa

bilité

Couverture spécifique

Couverture spécifique

Comment et quand le CSP

Exigence PCI DSS

(CSP seul, client

In-scope client In-scope CSP

fournira la preuve de la

seul, ou partagé)

Responsabilité

Responsabilité

conformité à la clientèle

1.1 Inspecter les normes de configuration de pare-feu et de routeurs et autres documents spécifiés ci-dessous pour vérifier que les normes sont complètes et mises en œuvre comme suit :

1.1.1 Processus formel d’approbation et de test de toutes les connexions réseau et des modifications in-scopes aux configurations des pare-feu et des routeurs

1.1.1 Processus formel d’approbation et de test de toutes les connexions réseau et des modifications in-scopes aux configurations des pare-feu et des routeurs

1.1.2 Diagramme du réseau actuel qui identifie toutes les connexions entre l’environnement de



données du titulaire et les autres réseaux, y compris tout réseau sans fil

3.7 Défis de conformité :

Le stockage, le traitement ou la transmission de données de titulaire de carte dans le Cloud signifie que cet environnement de Cloud est dans-le-champs pour la norme PCI DSS, et il peut être difficile de valider la conformité PCI DSS pour une infrastructure dynamique et distribuée: comme un Cloud public ou autre partagé.

• Les architectures distribuées des environnements de Cloud ajoutent des couches de technologie et de complexité qui remettent en question les méthodes d'évaluation traditionnelles :

• Des exemples de défis de conformité comprennent, mais ne sont pas limités à: � Les clients peuvent avoir ou pas de visibilité sur l'infrastructure sous-jacente

du CSP et des contrôles de sécurité liés. � Les clients peuvent avoir le droit à la surveillance ou le contrôle sur le

stockage des données des titulaires de cartes ou ne pas avoir. Les organisations ne peuvent pas savoir où les données des titulaires de cartes sont physiquement stockées car l'emplacement (s) peut changer régulièrement. Pour la redondance ou pour des raisons de haute disponibilité, des données peuvent être stockées dans des emplacements multiples à un moment donné.

� Certains composants virtuels ne possèdent pas le même niveau de contrôle d'accès, les logs d’audit, et de suivi que leurs homologues physiques.

� Les limites de périmètre entre les environnements clients peuvent être fluides. � Les environnements de Cloud public sont généralement conçus pour permettre

l'accès à partir de n'importe où sur Internet. � Il peut être difficile de vérifier qui a accédé aux données des titulaires de

cartes, traitées, transmises ou stockées dans la environnement de Cloud. � Il peut être difficile de recueillir, corréler, et / ou archiver tous les journaux

nécessaires pour répondre aux exigences PCI DSS. � Les organisations qui utilisent des outils de découverte de données pour

identifier les données des titulaires de cartes dans leur environnement, et d'assurer que ces données ne sont pas stockées dans des endroits inattendus, peuvent trouver que l'exécution de ces outils dans un environnement de Cloud Computing peut être difficile et entraîne des résultats incomplets. Il peut être difficile pour les organismes de vérifier que les données de titulaire carte ne sont pas "fuites" dans le Cloud.

� De nombreux grands fournisseurs peuvent ne pas soutenir le droit à la vérification par leurs clients. Les clients doivent discuter leurs besoins avec le



fournisseur afin de déterminer comment le CSP peut fournir l'assurance que les contrôles nécessaires sont en place.

• L’utilisation d'un CSP compatible PCI DSS ne résulte pas que les clients sont en conformité PCI DSS. et le client est également l'ultime responsable de la sécurité quotidienne de l’externalisation de CHD. En ce qui concerne l'applicabilité de la conformité d'une partie à l'autre, envisager les mesures suivantes: a) Si un CSP est conforme, cela ne signifie pas que leurs clients le sont. b) Si les clients d'un CSP sont conformes, cela ne signifie pas que le CSP l’est. c) Si un CSP et le client sont conformes, cela ne signifie pas que tous les autres clients le sont.

• Le client doit assurer que les services de son côté qui doivent être conformes aux exigences le sont vraiment : Par exemple le client doit assurer que l’antivirus est installé et est mis à jour dans les systèmes de son côté utilisés pour se connecter au Cloud.

3.8 Définir d'utilisation appropriée des outils de gestion :

Les outils de gestion permettent aux administrateurs d'effectuer des fonctions telles que :

• Les outils de système de sauvegarde, de restauration, la connectivité à distance, la migration et des changements de configuration des systèmes virtuels.

• Les outils de gestion pour les composants faisant partie du champ seraient également considérés in-scope : Il faut définir les outils in-scope.

• Séparer les rôles et responsabilités pour les outils de gestion. • Surveiller et enregistrer l'utilisation des outils de gestion.

Ces outils doivent être inventoriés et on doit étudier leurs impacts sur la sécurité si elles sont compromises.

3.9 Etablir des politiques et des procédures pour chaque exigence de sécurité PCI DSS, ainsi que la gestion des rapports.

3.10 Considérations et recommandations pour l’environnement Cloud déployé : • Elaborer un scénario de déploiement de deux sites e-commerce qui respectent les

éléments suivants :-Veiller à ce que ces deux environnements CDE des deux clients seront séparés par des moyens technologiques, comme s’ils l’étaient physiquement. Et qu’ils soient séparés pour isoler les composants CDE des composants non CDE afin de réduire le scope PCI DSS.

• Isolement des données qui sont stockées. • Tous les systèmes ou composants partagées par les environnements clients, y compris

les systèmes d'hyperviseurs sous-jacents, ne doivent pas fournir un chemin d'accès entre les environnements.



• Une fois qu’une couche de l'architecture en nuage est partagée par les environnements CDE et non-CDE, la segmentation devient de plus en plus complexe : Les données non-CDE doivent être dans des hyperviseurs séparés. Cette complexité ne se limite pas aux hyperviseurs partagés; toutes les couches de l'infrastructure qui peuvent fournir un point d'entrée à un environnement CDE doivent être incluses lors de la vérification segmentation.

• Il faut déterminer les couches partagées. • Il faut dresser un tableau qui regroupe les composants de l’environnement virtuels, et

comment le client ou le CSP responsable assure son rôle de segmentation.

3.10.1 Considérations de segmentation : En dehors d'un environnement de Cloud Computing, les environnements clients particuliers doivent normalement être physiquement séparés l'un de l'autre, sur le plan organisationnel, et sur le plan administratif. Les clients qui utilisent un Cloud public ou partagé doivent autrement compter sur le CSP à veiller à ce que leur environnement est suffisamment isolé des autres environnements clients. Exemples de contrôles à considérer lors de l'évaluation des options de segmentation comprennent, mais ne sont pas limités à:

• Les firewalls physiques et la segmentation du réseau au niveau de l'infrastructure. • Les firewalls au niveau de l'hyperviseur et de VM. • Le zonage VLAN, en plus de pare-feu. • Des IPS au niveau de l'hyperviseur et / ou au niveau des VM qui détectent et bloquent

le trafic indésirable. • Outils informatiques de prévention des pertes de données au niveau de l'hyperviseur et

/ ou au niveau VM. • Des contrôles pour empêcher les communications hors-bande qui se produisent via

l'infrastructure sous-jacente. • L'isolement des processus communs et des ressources du milieu des clients. • Magasins de données segmentés pour chaque client. • L'authentification forte à deux facteurs. • La séparation des fonctions et la supervision administrative. • Enregistrement continu et surveillance du trafic de périmètre, et réponse en temps réel • Tracer une politique pour faire des frontières entre les clients, et entre le client et le

CSP, et entre le client et le réseau internet. • Il faut demander d’isoler les services compatibles PCI DSS des services non

compatibles. • Remédier au problème de communications-out-of-band

• L'évaluateur PCI DSS doit valider l'efficacité de la segmentation pour garantir qu'il fournit un isolement adéquat.

• Le client doit avoir le droit de tester dans le réseau du CSP que l’isolement des frontières entre les clients, ou entre le client et le CSP, ou entre le client et le réseau internet sont établis. Si le fournisseur n’accepte pas, le client y sera dépendant.



Scénario Description de l'environnement Orientations de in-scope PCI DSS

Cas 1: Tierce-partie CSP hébergeant un Cloud public compatible "PCI DSS" prenant en charge plusieurs clients, avec une segmentation validée pour les environnements clients.

*Les machines virtuelles peuvent être sur un ou plusieurs hyperviseurs, tous les hyperviseurs et les machines virtuelles sont configurés par CSP pour soutenir les exigences PCI DSS. *Plusieurs clients hébergés sur chaque hyperviseur. *Une segmentation validée des environnements clients utilisant une combinaison de contrôles physiques et logiques.

Le CSP est responsable de la conformité de tous les éléments du service de Cloud fourni. La in-scope de chaque client inclurait leur propre environnement (par exemple, les machines virtuelles, applications, etc.) et tous les autres éléments qui ne sont pas gérés par le CSP. La segmentation doit être validée comme offrant une isolation efficace entre les clients dans le cadre de la validation de la CSP, et peut nécessiter une validation supplémentaire dans le cadre de la validation de chaque client.

Cas 2: Tierce-partie CSP hébergeant un Cloud public compatible "PCI DSS" prenant en charge plusieurs clients, pas de segmentation client.

*Les machines virtuelles peuvent être sur un ou plusieurs hyperviseurs, tous les hyperviseurs sont configurés par le CSP pour soutenir les exigences PCI DSS. *Plusieurs clients hébergés sur chaque hyperviseur, la configuration VM gérée par chaque client. *Segmentation entre les environnements des clients ne sont pas vérifiées.

Le service Cloud en entier et tous les Environnements clients sont in-scope. Notez que la validation de la conformité PCI DSS peut être intraitable et infaisable quand chaque environnement client aurait besoin d'être inclus dans l'évaluation.

3.10.2 Recommandations pour les environnements en mode mixte

Il est fortement recommandé (et un principe de sécurité de base) que les machines virtuelles de différents niveaux de sécurité ne soient pas hébergées sur le même hyperviseur ou même hôte physique; la préoccupation principale étant qu'une VM avec des exigences de sécurité inférieurs auront des contrôles de sécurité moindre, et peuvent être utilisées pour lancer une attaque ou donner accès à des machines virtuelles plus sensibles sur le même système.



• Il est fortement recommandé que les machines virtuelles dans-le-champ et hors-du-champ ne soient pas hébergées sur le même hyperviseur ou même hôte physique;

• Pour que les machines virtuelles en in-scope et hors de in-scope coexistent sur le même hôte ou hyperviseur, les machines virtuelles doivent être isolées les unes des autres de telle sorte qu'ils peuvent effectivement être considérées comme un matériel distinct sur les différents segments de réseau sans la connectivité de l’une à l'autre.

3.10.3 Considérations de scoping : • Les recommandations pour réduire et simplifier les normes PCI DSS à in-scope dans

un environnement de Cloud Computing comprennent: � Ne pas stocker, traiter ou transmettre des données de cartes de paiement dans le

Cloud. Ceci est le moyen le plus efficace pour maintenir un environnement Cloud hors de in-scope, car les contrôles PCI DSS ne seront pas nécessaires s’il n'y a pas de données de cartes de paiement à protéger.

� Mettre en œuvre une infrastructure physique dédiée qui est utilisée seulement pour l'environnement Cloud dans la in-scope.

• Veiller à ce que les données du compte en texte clair ne sont jamais accessibles dans le Cloud peut également aider à réduire le nombre d’exigences PCI DSS applicables à l'environnement de Cloud.

• Il faut déterminer les exigences PCI DSS qui sont in-scope pour le CSP. • Identifier les composants virtuels qui sont in scope pour PCI DSS dans notre cas ? • Dresser un tableau qui décrit :

� Les composants qui sont in-scope validés et non validés. � L’exigence qui concerne le composant. � La date d’obtention de validation

3.10.4 Composants systèmes virtuels et le scoping :

Hyperviseur : Orientation in-scope: Si un composant virtuel connecté à (ou hébergé sur) l'hyperviseur est à in-scope pour la norme PCI DSS, l'hyperviseur lui-même sera toujours à in-scope. Machine virtuelle : Orientation in-scope: Un ensemble de VM sera à in-scope si elle stocke, traite ou transmet des données de titulaire, ou si elle se connecte ou fournit un point d'entrée au CDE. Si une machine virtuelle n’est dans la in-scope, à la fois le système hôte sous-jacent et l'hyperviseur seraient également considérés in-scope, car ils sont directement reliés à et ont un impact fondamental sur le fonctionnement et la sécurité de la machine virtuelle. Application virtuelle : Orientation in-scope: Les applications virtuelles utilisées pour se connecter ou fournir des services à un système in-scope des composants ou des réseaux seraient considérés dans le champ. Toute VSA / SVA qui pourraient influer sur la sécurité du CDE serait également considérée comme in-scope.



Switch ou routeur virtuel :

Orientation in-scope: Réseaux provisionnés sur un commutateur virtuel basé sur l'hyperviseur sera in-scope si approvisionné avec un composant dans le champ ou si elles fournissent des services ou se connecter à un dans le champ composant. Les dispositifs physiques d'hébergement commutateurs virtuels ou des routeurs seraient considérés dans le champ si l'un des composants hébergés se connecte à un réseau dans le champ.

3.11 Planning des documents que le client doit demander au CSP :

La liste des documents que le client doit avoir de son CSP :

• Le client doit envoyer un document qui demande au CSP les exigences qui ont été validées et celles non validées. (Il faut envoyer une lettre)

• Les Clients doivent demander à leurs CSP de leur fournir une assurance continue que les exigences sont toujours respectées,

• Demander les documents applicables pour- par exemple, les journaux d'audit montrant tous les accès aux données des clients.

• Le Client doit savoir les détails précis applicables aux méthodes de maintien en cours de la conformité PCI DSS. Par exemple, selon le service fourni, le CSP peut avoir besoin de produire des copies de fichiers journaux, les dossiers de mise à jour de patch, ou l’ensemble de règles pare-feu applicables spécifiquement à un l'environnement de chaque client. (Il faut trouver d’autres choses à ajouter)

• Il faut que le CSP donne tous les documents nécessaires qui expliquent clairement les parties des services qui ont été validées et celle qui n’ont pas été validées.

• Si le CSP fournit au client les documents qui justifient que son QSA l’a certifié PCI DSS pour les composants systèmes qui rentrent dans son périmètre (IaaS), le QSA du client doit s’appuyer sur les documents du CSP et compléter la validation des autres composants virtuels qui rentrent dans le périmètre du client, vérifier que la validation CSP est encore valable à partir de la date.

• Les CSP qui ont subi une évaluation PCI DSS indépendante pour valider leur conformité auront les résultats résumés dans une attestation de conformité (AOC) et détaillés dans un rapport sur la conformité (ROC).

• Citer tous les accords et documents qui doivent être établis entre le client et le CSP.

• Preuve de la documentation de conformité (comme l'AOC et les articles applicables de la ROC), y compris la date de l'évaluation de la conformité

• Des preuves documentées des composants systèmes et des services qui ont été inclus dans l’évaluation de la norme PCI DSS

• Des preuves documentées de composants système et des services qui ont été exclus de la norme PCI DSS l'évaluation, le cas échéant au service

• Etudier les rapports PCI DSS du CSP: quels services et composants du système sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et



6.2 portent sur la nécessité que les vulnérabilités doivent être identifiées, selon leur indice et selon le risque, et corrigées en un temps minime. Si pas correctement défini, un client pourrait supposer que le CSP gère ce processus pour tout l'environnement Cloud, alors que le CSP pourrait gérer uniquement les vulnérabilités de son infrastructure sous-jacente, en supposant que le client gère des vulnérabilités des systèmes d'exploitation, des applications et des sites web (pour e-commerce)).

3.12 Considérations de sécurité :

Bien que l'utilisation des services de Cloud Computing peut fournir une opportunité intéressante pour les organisations de toutes tailles, les organisations doivent également être conscientes des risques et défis associés à un choix de Cloud particulier avant de passer leurs données ou services sensibles dans l’environnement de Cloud. Cette section explore certaines de ces considérations de sécurité supplémentaires.

• Le client est responsable de la bonne configuration de tout contrôle de segmentation mis en œuvre au sein de leur propre environnement (par exemple, en utilisant des pare-feu virtuels pour séparer le dans-le-champ VM de l'extérieur-du-champ VM), et pour veiller à ce qu’une isolation efficace est maintenue entre dans les composants in-scope et hors-champ.

• Considérations pour le client peuvent inclure: � Combien de temps le CSP a été conforme PCI DSS? Quand est ce qu’était leur

dernière validation? � Quels sont les services spécifiques et les exigences PCI DSS ont été incluses

dans la validation? � Quelles sont les installations et les composants systèmes spécifiques qui ont

été inclus dans la validation? � Y a-t-il des composants système que le CSP repose sur pour la prestation du

service qui n’était pas inclus dans la validation PCI DSS? � Comment les CSP garantissent que les clients qui utilisent le service conforme

PCI DSS ne peuvent pas présenter des composants non conformes à l'environnement ou même peuvent contourner des contrôles PCI DSS?

• Bâtir une structure solide de gouvernance et de gestion de risques, qui est partagée entre le client et le CSP.

• Elaborer une stratégie de gouvernance claire (COBIT). • Le CSP doit être conscient des éléments de services côté client qui peuvent impacter

sa compatibilité PCI DSS. • Il faut avoir une stratégie claire de gouvernance partagée entre le client et le CSP.

3.12.1 Gestion de risque : Les services de Cloud externalisés doivent être évalués par rapport aux critères de risque d'une organisation dans le but de l'identification des actifs critiques, analyse les vulnérabilités et les menaces potentielles à ces actifs, et l’élaboration d'une stratégie d'atténuation des risques appropriée (Voir Exigences PCI DSS 12.1.2).



• (Appliquer les consignes du document « Risk acessement for PCI DSS » en utilisant des outils dédiés.)

• Les formes traditionnelles de l'évaluation des risques peuvent notamment ne pas prendre en considération les caractéristiques du Cloud, et peut donc nécessiter des procédures nouvelles ou modifiées.

• Développer un plan de continuité de service BCP et reprise après sinistre DR. • Le client doit avoir la capacité d’effectuer des tests de capacités BCP et DR et / ou

d'observer les résultats des tests effectués par le CSP. • L'évaluation des risques doit identifier si des contrôles supplémentaires sont

nécessaires pour assurer et protéger les données des titulaires de carte et autres informations sensibles dans un environnement virtuel.

3.12.2 Evaluer les risques associés aux technologies de virtualisation :

• Le flux et le stockage des données des titulaires de cartes doivent être correctement documentés dans le cadre du processus d'évaluation des risques pour veiller à ce que toutes les zones de risque sont identifiées et atténuées de manière appropriée.

• Si un composant fonctionnant sur un hyperviseur est dans la in-scope, il est recommandé que tous les composants que l'hyperviseur soient considérés in-scope, ainsi, y compris, mais sans s'y limiter, les machines virtuelles, les applications virtuelles, et plug-ins de l'hyperviseur

• Les vulnérabilités dans l'environnement physique s’appliquent dans l’environnement virtuel et s’y ajoutent d’autres vulnérabilités.

• Les attaques liées à l’hyperviseur : � Lui appliquer une configuration sécurisée, choisir l’hyperviseur avec plus de

choix de contrôles de sécurité. � L'hyperviseur crée une nouvelle surface d'attaque qui n’existe pas dans le

monde physique. � Mettre un plan d’action pour remédier aux problèmes de faiblesses dans la

technologie d'isolation de l'hyperviseur, contrôles d'accès, renforcement de la sécurité, et mises à jours.

� Ne pas garder la configuration out-of-the-box car elle n’est pas la plus sécurisée.

� Il est essentiel que l'accès à l'hyperviseur soit limité en fonction du moindre privilège et la nécessité de savoir, et que la surveillance indépendante de toutes les activités soit appliquée.

� Les hyperviseurs ne sont pas créés égaux, et il est particulièrement important de choisir une solution qui prend en charge les fonctions de sécurité requises pour chaque environnement.

• Empêcher les communications intra-hôtes : Les machines virtuelles peuvent transmettre des données entre eux à travers l'hyperviseur, ainsi que sur des connexions de réseaux virtuels et à travers les applications virtuelles de sécurité de réseau tels que les pare-feu virtuels.



• Le compromis d'une fonction virtuelle du système pourrait conduire à un compromis d'autres fonctions sur le même système physique.

• Imposer la séparation des processus entre les différentes fonctions. • Dans le contexte virtuel, une VM de confiance inférieure aura typiquement moins de

contrôles de sécurité que les machines virtuelles des niveaux de confiance plus élevés. • Théoriquement, les machines virtuelles de différents niveaux de confiance sur le

même hôte ou hyperviseur peuvent réduire la sécurité globale pour tous les composants à celle du composant le moins protégé (également connu sous le nom –la sécurité est aussi forte que la fonction la plus faible).

• Le risque de mélange des données sensibles avec les données de confiance plus faible doit être soigneusement évalué.

• La séparation appropriée des fonctions est cruciale dans un environnement virtuel.

3.12.3 Identifier les menaces :

• Identifier les menaces spécifiques aux technologies de virtualisation : exp ; menaces de l'hyperviseur et communications out-of-band

3.12.4 Identifier les vulnérabilités :

Identifier les vulnérabilités spécifiques aux technologies de virtualisation

• Les vulnérabilités ne sont pas limitées à des questions techniques. Les failles sont dans les processus opérationnels, l’insuffisante de formation du personnel, le manque de control de surveillance, et des lacunes dans la sécurité physique sont des exemples d'autres domaines où les vulnérabilités potentielles peuvent exister et être exploitées.

• Les organisations qui utilisent la virtualisation doivent évaluer leur environnement particulier, évaluer les risques associés et identifier les contrôles appropriés pour régler ce risque.

• Utiliser les méthodologies et outils d'évaluation de risques acceptés par l'industrie disponibles pour aider à guider le processus d'évaluation des risques.

3.13 Installations et accès physique : Les services Cloud ne sont «nuage» que dans le concept. En réalité, les services de Cloud impliquent des ressources physiques situés dans l’environnement CSP qui sont accessibles à distance à partir de l'environnement du client. Les contrôles pauvres de sécurité physique dans une installation de CSP peuvent exposer les données de nombreux clients à des risques inutiles, et les pauvres contrôles environnementaux peuvent influer sur les performances et l'intégrité de la prestation de service.

• Les contraintes pour un Cloud public : 1- Le CSP pourra ne pas donner accès au QSA du client pour accéder à leurs locaux physiques, et il a le droit.



• Lors de l'utilisation d'un Cloud public, différents éléments de l'environnement, tels que les machines virtuelles, les hyperviseurs, et les périphériques réseau virtuels, etc., peuvent être souvent déménagés en fonction de la stratégie d'équilibrage de charge du CSP.

• Utiliser des mécanismes et procédures afin de savoir où se trouvent les données CDE en temps réel, à cause de la mobilité continue des machines virtuelles, des hyperviseurs, et des périphériques réseau virtuels, etc… soit des outils informatiques, soit des rapports rédigés par le CSP.(voir l’offre de AWS et Google concernant les zones géographiques)

• Par exemple, l'infrastructure du CSP peut entraîner le déplacement de données ou son stockage dans des pays politiquement ou économiquement instables.

• Il faut comprendre les juridictions du pays où se trouvent les données dans le temps réel. (Cas du Maroc, loi 09/08)

• Restreindre l'accès physique : l'hébergement de plusieurs composants sur un seul système physique pourrait accroître considérablement l'impact potentiel si un attaquant a eu un accès physique à ce système hôte.

• Veiller à ce que toutes les interfaces physiques inutilisés sont désactivées, et que l’accès physique ou au niveau de la console est restreint et surveillé.

3.14 Considérations sur la sécurité des données : • Il est recommandé que les besoins de sécurité de données soient évalués pour toutes

les informations dans le Cloud et non seulement CHD. Par exemple, les données opérationnelles, les politiques et procédures de sécurité, configurations de système, et documents des normes, les fichiers journaux, les rapports d'audit, les informations d'authentification, clés de chiffrement, les plans de réponse aux incidents, et coordonnées employés sont quelques-uns des types de données avec différents exigences de sécurité qui peuvent avoir besoin d'être pris en considération.

• Il faut documenter où sont situées les données des titulaires de cartes et comment traversent-ils l'infrastructure (voir Exigences PCI DSS 1.1.2).

• Un accès potentiel de l'hyperviseur aux données en mémoire doit également être pris en considération, veiller à ce que les contrôles d'accès définies par le client ne sont pas involontairement contournées par le personnel administrateur du CSP.

3.14.1 Images et clichés instantanés :

Les images et les clichés instantanés des machines virtuelles fournissent un moyen rapide de déployer ou restaurer les systèmes virtuels dans un court laps de temps. Une attention particulière doit être accordée à la préparation d'images et de clichés VM, car ils peuvent capturer des données sensibles présentes sur le système au moment où l’image a été prise, y compris le contenu de la mémoire active.

• Une attention particulière doit être accordée à la préparation d'images et de clichés VM, car un intrus peut capturer des données sensibles présentes sur le système au moment où l’image a été prise, y compris le contenu de la mémoire active.



• Sécuriser les images systèmes contre les modifications par un hacker. • Chercher les bonnes solutions de surveillance et journalisation des composants virtuels

(les réseaux virtuels, les pare-feu virtuels, les applications systèmes virtuelles). • Idéalement, les capacités de virtualisation sur tous les trois plans de l'exploitation de

l'infrastructure réseau doivent fournir des contrôles et des fonctionnalités pour sécuriser l'infrastructure virtuelle à un niveau équivalent à des dispositifs physiques individuels. Quelles sont les mesures et composants à mettre en place pour empêcher les fuites de données entre les segments réseaux?

• Les fuites d'informations entre les composants virtuels peuvent se produire lorsque l'accès aux ressources partagées permet à un composant de collecter des informations sur un autre composant sur le même hôte

• Chercher quelles sont les méthodes de fuites de données entre composants physiques (accès mémoire, CPU, réseau, etc.) et comment y remédier ?

• Des environnements où les clients exécutent leurs applications dans des images systèmes distinctes, le stockage des donnée doit se faire dans des partitions logiques distinctes en utilisant des bases de données séparées, et ne partagent pas le stockage sur le même disque ou autres ressources, deux réseaux distincts, et en utilisant des mesures de sécurité connues.

• En plus de la gamme connue des emplacements de stockage destinés, les données peuvent également être présentes dans d'autres systèmes CSP utilisés pour l'entretien de l'infrastructure Cloud, tels que les images de VM, les sauvegardes, les journaux de surveillance, la mémoire et ainsi de suite.

• Des outils et des processus spécialisés peuvent être nécessaires pour localiser et gérer les données archivées, off-line, les images relocalisées.

3.14.2 Machines dormantes ou inactives :

• Mettre en place un processus de gestion des machines dormantes ou inactives. • Si une machine dormante ou inactive doit être reprise en service, il faut éliminer ses

vulnérabilités, et lui appliquer toutes les politiques de sécurité avant qu’elle soit active de nouveau.

• Utiliser des contrôles de sécurité supplémentaires basés sur l'hôte pour surveiller et contrôler le trafic VM-VM.

• Choisir les meilleures solutions de sécurité qui n’impactent pas la performance des processeurs et mémoires dans le Cloud.

• Planifier les scans et les mises à jour dans des intervalles de temps décalées afin de ne pas entraîner une extrême charge sur le système sous-jacent et réduire la performance globale de toutes les machines virtuelles hébergées.

• Les VM inactives contenant les données de cartes de paiement peuvent devenir inconnus, des magasins de données non garantis, qui sont souvent seulement redécouvert dans le cas d'une violation de données.

• Les clients doivent également examiner comment le CSP gère les VMs déconnectées ou machines virtuelles inactives, et si les VM dans-le-champ et hors-du-champ



probablement peuvent être stockés ensemble par le CSP sans contrôles de segmentation actifs.

• Parce que les machines virtuelles dormantes ne sont pas activement utilisées, elles peuvent facilement être négligées et laissées hors les procédures de sécurité.

• Une VM en sommeil ne sera probablement pas mise à jour avec les derniers patchs de sécurité, résultant que le système sera exposé à des vulnérabilités connues que l'organisation pense les avoir déjà éliminés.

3.14.3 Reconnaître la nature dynamique des VM :

Les VMs sont effectivement juste des données qui peuvent résider dans des états actifs (sur un hyperviseur) ou des états inactifs (N'importe où). Les VMs inactives ou dormantes sont effectivement des données stockées qui peuvent contenir des informations sensibles et les détails de configuration des appareils virtuels. Une personne ayant accès à une VM en sommeil pourrait la copier et l’activer dans un autre endroit, ou ils peuvent analyser les données de carte de paiements et autres informations sensibles.

• L'accès aux machines virtuelles inactives doit donc être limitée, surveillé, et soigneusement contrôlé.

• Le CSP doit communiquer au client toutes les VM qui contiennent des données CDE sensibles, leurs états, leurs emplacement, comment sont-elles protégées ?

• Valider le fournisseur de Cloud (Cloud public, IAAS) avec la norme PCI DSS

• Valider le du client (Cloud public, IAAS) avec la norme PCI DSS • Délivrance d’une attestation de conformité (AOC)

• Délivrance d’un rapport de conformité (ROC). • Le client est maintenant conforme PCI DSS

3.14.4 La gestion du cycle de vie des données : Pour tous les modèles de Cloud Computing, des exigences claires pour la conservation des données, le stockage et l'élimination sécuritaire doivent veiller à ce que les données sensibles sont:

� Conservés aussi longtemps que nécessaire, � Non retenu plus longtemps que nécessaire, � Stockées uniquement dans des endroits appropriés et sécurisés, � Accessibles seulement à ceux avec un besoin de l'entreprise, � Traitées conformément à la politique de sécurité du client

• Il faut sécuriser la transmission des données sensibles par le cryptage. • Dans un environnement de Cloud distribué, vérifier que toutes les instances de

données des titulaires ont été supprimées en toute sécurité conformément à la politique de rétention des données du client.

• L’élimination des données du titulaire de carte doit être effectuée en utilisant des méthodes sûres, conformément aux exigences PCI DSS

• La méthode d'élimination doit veiller à ce que les données ne sont pas récupérables à la fin du processus de cession.

3.14.5 Classification des données :



• Un système informatique de classification définie peut aider les organisations à identifier les données qui sont sensibles ou confidentielles et les données ayant des besoins de sécurité spécifiques.

3.14.6 Chiffrement des données et gestion des clés cryptographiques (HSM ou Cloud HSM) Dans un environnement Cloud public, les données d'un client sont généralement stockées avec des données appartenant à plusieurs autres clients. Ce qui fait de ce Cloud public une cible attrayante pour les attaquants, car le potentiel de gain peut être supérieure qu’en attaquant des organisations individuellement. Un niveau de chiffrement fort de données doit être appliqué sur toutes les données sensibles ou potentiellement sensibles stockées dans un Cloud public. Parce que tout incident sécuritaire d'un CSP pourrait entraîner l'accès non autorisé à de multiples magasins de données.

• Il est recommandé que les clés cryptographiques utilisées pour crypter / décrypter les données sensibles sont stockées et gérées indépendamment du service de Cloud, où se trouvent les données.

• Au minimum, les serveurs de gestion des clés doivent être situés dans un segment de réseau séparé et protégé avec des références d'accès distincts des machines virtuelles qui utilisent les clés et les données cryptées avec eux.

• Elaborer une procédure pour gérer les clés de chiffrement déchiffrement, où sont-elles stockées, comment sont-elles archivées, les logs d’accès à ces clés.

• Seuls les définies, et les dépositaires de clés autorisés doivent avoir accès aux clés cryptographiques.

• Les clients devront vérifier qui a accédé aux clés cryptographiques, qui a accédé aux données chiffrées, et qui a accédé aux deux à la fois.

• Il est préférable que le client ne partage pas les clés de cryptage avec le CSP, ou engage le CSP en tant que gardien de clé, dans un cas pareil, les détails d’autorisations et les processus d'accès des CSP devront être examinés et vérifiés.

• Ne pas stocker ou héberger les clés cryptographiques par un tiers CSP qui accueille aussi les données chiffrées.

• Les clients doivent choisir de conserver toutes les opérations de chiffrement /déchiffrement et de gestion des clés dans leurs propres locaux, et n'utiliser le Cloud public que pour le stockage des données cryptées.

• Mettre en place un processus de gestion de clés dans l’environnement Cloud public. 3.14.7 Elimination des données : En plus de l'élimination des données, les exigences de déclassement de ressources doivent être définies pour soutenir les clients dans les décisions futures de migrer vers un nouveau CSP.

• Mettre en place un processus d’élimination de données : • Le CSP devrait fournir des mécanismes d'élimination des données qui fournissent une

assurance au client que toutes les données ont été correctement retirées et supprimées à partir de l'environnement de Cloud.

• Etre sûr que les données ont été correctement retirées et supprimées à partir de l'environnement de Cloud.



• Il faut considérer que laissant potentiellement des quantités inconnues de données chiffrées sur les systèmes CSP après que leur convention a été résiliée est une violation par le CSP des politiques de conservation des données.

3.14.8 Identité et gestion d’accès: L’identification de l'utilisateur individuel et l'authentification du personnel de CSP et les clients est essentielle pour le contrôle d'accès et la reddition de comptes.

• Mettre en place un processus et une politique de gestion d’accès des CSP et clients à l’infrastructure Cloud IaaS public.

• Utiliser double authentification. • Les comptes des clients et les mots de passe doivent être uniques pour chaque service. • Les CSP doivent être en mesure de séparer les données des journaux applicables pour

chaque client sans exposer les données des journaux d'autres clients aux risques. • Exiger les logs de tous les niveaux de l'infrastructure. • La configuration de l'hyperviseur et l'accès est particulièrement important car il fournit

un point d'entrée unique à tous ses VM. • Choisir un hyperviseur avec les fonctions de sécurité les plus développées dans le

marché de Cloud. 3.14.9 Introspection : L’introspection est la fonctionnalité qui permet à l'hyperviseur de contrôler et de surveiller chaque activité VM de l'extérieur de la VM s’appelle « introspection »

• Il faut bien profiter des fonctionnalités de l’introspection. • Le problème avec l’introspection est qu’il ne laisse pas de traces de vérification

judiciaire au sein de la machine virtuelle elle-même. • Avec l'introspection, les fichiers peuvent être accessibles à partir de l'intérieur de l'état

privilégié de l'hyperviseur sans laisser de traces. • Les CSP utilisant l'introspection doivent être en mesure de fournir à leurs clients tous

les journaux d'introspection applicables pour l'environnement de ce client, y compris, mais sans s'y limiter, les détails d'authentification, et l'accès au disque, à la mémoire, les demandes et les appels API.

• Etablir un processus de gestion sécurisé d’introspection. • Sécuriser les API et les interfaces web. • Définir les systèmes clients utilisés pour accéder à l'environnement de Cloud. • Comment sécuriser les systèmes clients utilisés pour accéder à l'environnement de

Cloud? • Le client devra donc assurer que leurs dispositifs côté client sont fixés de manière

appropriée et protégés de l'accès physique et logique non autorisé. • Les systèmes côté client utilisés pour l'accès aux données de titulaire de carte dans le

Cloud seraient également dans la in-scope de toutes les exigences PCI DSS applicables.

• Les clients doivent également demander au CSP les contrôles qu'ils ont mis en place pour veiller à ce que la posture de sécurité d'un client ne peut pas affecter la posture de sécurité d'un autre client.



• Les clients doivent examiner comment le CSP vérifie que ses clients sont bien ceux qu’ils disent qu'ils sont.

• Comment le CSP détecte un comportement potentiellement suspect une fois que les clients sont à bord.

• Réponse aux incidents et enquêtes • Les clients ont besoin de savoir l'impact sur leur environnement et / ou sur leurs

données quand un problème, un incident ou violation a eu lieu. • Les enjeux, incidents et violations de données doivent être communiquées par le CSP

dans un temps minime. • Les clients doivent savoir si leur CSP exige que tous les clients doivent aviser

immédiatement le CSP des infractions potentielles dans leurs environnements, permettant au CSP de se rattraper plus rapidement pour contenir la violation et minimiser son impact sur d'autres clients.

• Définir un processus et les délais de notification au CSP. • Mettre une politique qui remédie au problème que les données clients soient capturés

par des tiers au cours d'une enquête de violation. • Etablir un document qui répertorie tous les genres d’incidents qui peuvent parvenir et

leurs contremesures, essayer de rassembler le maximum. 3.14.10 Mettre en œuvre la défense en profondeur :

Dans un environnement physique, une approche de défense en profondeur englobe la prévention, la détection, et les contrôles de sécurité adaptés est une pratique commune pour sécuriser les données et autres actifs. Les contrôles de sécurité logiques sont généralement appliqués au niveau du réseau, hôte, application, et couche de données, et les contrôles de sécurité physiques sont mises en œuvre pour protéger les médias, des systèmes et installations d’accès physique non autorisé.

• Le suivi de l'efficacité des contrôles et de la capacité à répondre rapidement et efficacement à une violation potentielle est également d'une importance primordiale.

• Une approche de défense en profondeur comprend également la formation du personnel et leur éducation à la bonne utilisation des actifs sensibles, l'identification des menaces potentielles à la sécurité, et les mesures appropriées à prendre en cas de violation.

• En outre, un environnement de défense en profondeur est bien défini et ses politiques sont documentées, les processus et les procédures sont comprises et respectées par tous le personnel.

• Examiner comment la sécurité peut être appliquée pour protéger chaque couche technique.

3.14.11 Isolation des fonctions de sécurité :

Les fonctions de sécurité fournies par les machines virtuelles doivent être mises en œuvre avec la même séparation nécessaire dans le monde physique. Il est recommandé que cette exigence soit encore très rigoureuse forcée.



• Les fonctions de sécurité fournies par les machines virtuelles doivent être mises en œuvre avec la même séparation des processus nécessaire dans le monde physique.

• Par exemple, les contrôles préventifs tels un pare-feu de réseau ne doit jamais être combiné sur un seul hôte logique avec les données de carte de paiements qu’il est configuré pour protéger.

• Les processus de segmentation du réseau et de la fonction d'agrégation des logs qui permettraient de détecter la falsification des contrôles de segmentation du réseau ne doivent pas être mixtes.

• Si ces fonctions de sécurité doivent être hébergées sur le même hyperviseur ou hôte, le niveau d’isolement entre les fonctions de sécurité devrait être tel qu'ils peuvent être considérés comme étant installé sur des machines distinctes.

3.14.12 Appliquer le moindre privilège et la séparation des fonctions :

Les comptes et informations d'identification pour l'accès administratif à l'hyperviseur doivent être soigneusement contrôlés.

• La mise en œuvre d'authentification à deux facteurs. • Etablir dual ou split-contrôle de mots de passe administratifs entre plusieurs

administrateurs.

• Mettre en place des processus forts de contrôle d’accès pour administration de l’hyperviseur.

• Les contrôles d'accès doivent être évalués à la fois pour l'accès local et à distance au système de gestion et l'hyperviseur

• Mettre en place un RBAC (Role based access controle) pour tous les composants virtuels.

• Comme meilleure pratique, il faut restreindre l’accès administratif par fonction VM spécifique, réseau virtuel, hyperviseur, le matériel, l'application, et stockage des données.

3.14.13 Evaluer les technologies d'hyperviseur :

S’assurer que la sécurité de l'hyperviseur a été soigneusement testée avant le déploiement :

• Tracer une gestion de patch appropriée de l'hyperviseur. • Identifier et mettre en œuvre des technologies qui facilitent des pratiques de sécurité

solides. 3.14.14 Solidifier l’hyperviseur : Plates-formes de Hyperviseur doivent être déployées de manière sécurisée conformément aux meilleures pratiques et directives de sécurité acceptées par l'industrie.



•Restreindre l'utilisation des fonctions administratives à des réseaux finaux et dispositifs définis, tels que les ordinateurs portables ou ordinateurs de bureau spécifiques qui ont été approuvés pour un tel accès. • Exiger l'authentification multi-facteur pour toutes les fonctions administratives. • Veiller à ce que tous les changements sont mis en œuvre et testés correctement. Envisager d'exiger plus de gestion de surveillance, au-dessus et au-delà de ce qui est nécessaire à travers le processus de changement de gestion normale. • Les fonctions administratives distinctes, telles que les administrateurs de l'hyperviseur, ne doivent pas posséder la capacité de modifier, supprimer ou désactiver les journaux d'audit de l'hyperviseur. • Envoyer les journaux d'hyperviseur à des endroits de stockage sécurisés physiquement séparés dans le temps réel le plus possible. • Surveillez les journaux d'audit pour identifier les activités qui peuvent indiquer une brèche dans l'intégrité de segmentation, les contrôles de sécurité, ou les canaux de communication entre les charges de travail. •Séparer les tâches pour les fonctions administratives, de tel façon les informations d'authentification pour l’hyperviseur ne donne pas accès à des applications, des données ou des composants virtuels individuels. •Avant de mettre en œuvre une solution de virtualisation, vérifier quels contrôles de sécurité ces solutions offrent et comment ils minimisent le risque de compromis d'hyperviseur.

3.14.15 Solidifier les machines virtuelles et autres composants :

Il est également essentiel que toutes les machines virtuelles individuelles sont installés et configurés en toute sécurité et selon les meilleures pratiques et directives de sécurité de l'industrie.

• Désactiver ou supprimer tous les interfaces inutiles, les ports, les dispositifs et les services;

• Configurer solidement toutes les interfaces réseau virtuelles et les zones de stockage; � Établir des limites sur l'utilisation des ressources VM; � Assurer que tous les systèmes d'exploitation et applications en cours

d'exécution dans la machine virtuelle sont également solidifiés; � Envoyer les journaux à des zones de stockage séparées et sécurisées aussi

proches du temps réel que possible; � Valider l'intégrité des opérations de gestion de clés cryptographiques; � Solidifier le matériel virtuel individuel et les conteneurs de VM; � Autres contrôles de sécurité le cas échéant.

3.14.16 Meilleures pratiques pour les applications de paiement :

• Utiliser SSL / TLS lors de la transmission des données des titulaires de carte en interne (par exemple, aux points d’entrée des données des titulaires de cartes et points de sortie) au sein du réseau du marchand.



• En raison de la nature dynamique des environnements e-commerce et des changements fréquents vers des sites Web et des applications Web, et comme les pare-feu traditionnels ne peuvent pas inspecter le contenu du trafic réseau crypté, envisager d'appliquer un pare-feu d’application web (WAF) ou une technologie supplémentaire de détection d'intrusion.

• Suivre PA-DSS lors de l'élaboration et la mise en œuvre des applications de paiement / achats pour aider à assurer que l'application supporte la conformité PCI DSS interne.

• Envisager d'utiliser des applications de paiement tiers qui sont en norme PA-DSS et qui sont noté sur la liste des applications de paiement validées comme «acceptable pour les nouveaux déploiements" (voir le site Web du Conseil PCI pour la liste actuelle des applications de paiement validées).

� Notez que certaines marques de paiement nécessitent l'utilisation d'applications de paiement validées PA-DSS où les demandes de paiement tiers-parties sont en cours d'utilisation. Les commerçants devraient consulter leurs acquéreurs ou les marques de paiement pour comprendre les exigences applicables.

� L'installation correcte d'une application de paiement est essentielle à la protection des données de cartes de paiement. Le guide de mise en œuvre PA-DSS des applications de paiement (obtenu à partir de l'éditeur de l'application de paiement) doit être suivi lors de l'installation et la configuration de l'application de paiement afin d'assurer que le produit est mis en œuvre d'une manière qui prend en charge la conformité PCI DSS.

� Examiner régulièrement les liens (tels que les URL, les iFrames, API, etc.) depuis le site du marchand à une passerelle de paiement pour confirmer que les liens ne sont pas modifiés pour rediriger vers des endroits non autorisés.

3.15 Considérations de PCI DSS pour le Cloud:

Exigences PCI DSS v3.0 déjà existantes : Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur













Nouvelles considérations de sécurité de Cloud qui peuvent s’ajouter aux exigences PCI DSS : Condition 1 et 2

Question PCI DSS Tests attendus Réponse

Oui

Oui, avec CCW Non S.O.

Comment est assurée la séparation entre les clients?

• Examiner les politiques et procédures

• Examiner les outils de séparation mis en place.

Comment les limites sont forcées entre les réseaux de confiance (internes au client) et les réseaux non sécurisés (comme les CSP, autre client, ou les réseaux publics)?


• Définir les composants virtuels nécessaires pour séparer les réseaux.

Ya-t-il des pare-feu physiques ou virtuels?

• Examiner la nature des pare-feu.

Qui gère et contrôle la configuration du pare-feu?

• Définir par nom le personnel responsable du contrôle du pare-feu.

Comment sont détectés et gérés les changements de configuration des pare-feu et réseau ?

• Examiner le processus de gestion de changement de configurations.

1 Est-ce que nous avons une liste complète de tous les composants matériels et logiciels dans cet environnement?

• Etablir un inventaire complet des composants physiques et virtuels dans l’environnement Cloud.



2

Peut-on identifier les composants actuels utilisés par un client particulier?

• Etablir une Checklist pour chaque client contenant les composants qu’il utilise en temps réel.

• Détecter tous les changements en temps réel pat des outils précis.

Est-ce que les interfaces API sont standardisées?


• Développer les interfaces API en suivant la norme PA DSS.

Quel processus pour le provisionnement de nouveaux composants?

• Examiner les processus mis en place.

Les images virtuelles ont été solidifiées avant qu’elles soient activées?

• Examiner la procédure de solidifications des images, VMs inactives et dormantes.

Est-ce que les images solidifiées sont protégées contre l’accès non autorisé?

• Appliquer des RBAC sur l’accès aux images

• Créer des alertes suite à un accès non souhaité.

Comment sont séparés les systèmes classifiés hautement sécurisés des systèmes classifiés bas sécurisés ?

• Séparer le réseau, le lieu de stockage et le personnel qui a la main sur les composants hautement sécurisés du réseau, lieu de stockage et personnel qui a la main sur les composants bas sécurisés.

• Définir les outils technologiques, et les processus qui assurent cette séparation.

Comment sont gérées les ressources partagées (comme le processeur, la mémoire, et le stockage) pour assurer qu'elles ne seront pas manipulées-par exemple par surcharge (Buffer Overflow)-dans le but d'accéder à d'autres environnements ou données clients?


• Faire un test d’intrusion par buffer overflow afin de remédier à ce problème.

• S’assurer que les droits d’accès déployés sont efficaces.




Condition 3 : Protéger les données du titulaire stockées

Condition 4 : Crypter la transmission des données du titulaire sur les réseaux publics ouverts


Oui


Où se trouvent les données stockées « connues » ? où se trouvent les centres de données?


• Définir l’endroit en temps réel de stockage des données CHD

• Définir la localisation géographique de tous les centres de données en temps réel.

Quelles lois s’appliquent au client?

• Examiner les lois que le CSP applique sur le client.

• Examiner les législations que le pays qui accueille le Cloud applique sur le client.

Est-ce que le CSP a des affaires, exigences légales ou réglementaires qui peuvent influer sur la conservation des données des clients?


• Définir l’impact du fournisseur sur la conservation des données des clients.

Comment est restreint l’accès aux données clients à seulement les utilisateurs et applications de ce client?


• S’assurer que seuls les utilisateurs et applications autorisés accèdent aux données clients en :

Analysant les logs Réexaminant les RBAC.

Comment sont gérés les images, clichés instantanées et stockages pour empêcher des captures inutiles des données sensibles?


• Définir les endroits où se trouvent les images et clichés instantanées en temps réel.

• S’assurer que les images et clichés instantanées sont sécurisés en temps réel : mises à jour appliquées, politiques de sécurité appliqués.

• Examiner les logs d’accès aux images et clichés instantanées.

Comment les données sont supprimées de la mémoire et des images stockées?

• Examiner les procédures de suppression des données de la



mémoire et des images stockées.

3

Si les clés cryptographiques sont fournies par le CSP, est ce qu’on génère des clés uniques pour chaque client?

• S’assurer qu’on génère des clés cryptographiques uniques pour chaque client.

4

Où sont effectués les processus de cryptage/décryptage? Qui contrôle chaque processus ?


• Le processus de cryptage/décryptage s’effectue chez le client : définir qui contrôle chaque processus

• Le processus de cryptage/décryptage s’effectue chez le CSP : définir qui contrôle chaque processus

Où sont stockées les clés de cryptage et qui contrôle les clés? Est-ce que les données de clés de cryptage sont stockées dans des endroits autres que les données qu’ils chiffrent?


• Le stockage des clés cryptographiques s’effectue chez le client

• Le responsable de contrôle des clés est un personnel du client

• Séparer les clés de chiffrement des données à chiffrer

Où sont stockées les données cryptées, et qui a normalement accès aux clés et données cryptées?


• Le personnel du client est le seul à avoir accès aux clés cryptographiques

• Les données cryptées sont chez le client

• Les données cryptées sont chez le CSP

Comment est traitée la sécurité et l’accès (local ou à distance) aux ressources virtuels pour la génération des clés cryptographiques?


• S’assurer que les méthodes d’accès aux ressources virtuels pour la génération des clés cryptographiques sont sécurisées.

• Définir les moyens d’accès aux ressources virtuels pour la génération des clés cryptographiques.

Quel processus est utilisé dans le cas d’un incident suspect de clé?


• S’assurer que le client est informé de l’incident en temps réel.

• Identifier l’impact de l’incident



sur la confidentialité, intégrité et disponibilité des données CHD.

Est-ce que toutes les données du client sont détruites d’une manière sécurisée lors de suspension de contrat avec CSP ?

• Examiner le processus de destruction des données client lors d’une suspension de contrat.

Comment les communications sont sécurisées entre le client et les autres environnements ? Comment les données sont sécurisées dans le Cloud même ?


• La séparation et la segmentation sont assurées

• Le mot de passe pour l’accès à chaque environnement est unique et non partagé.

Est-ce que les API sont configurées pour renforcer une cryptographie et authentification forte?

• Examiner que la double authentification est appliquée pour les API

• S’assurer qu’une cryptographie forte est déployée.

Est-ce que l’authentification mutuelle est implémentée entre le CSP et les systèmes clients ?


• Ne pas utiliser l’authentification mutuelle entre le CSP et les systèmes clients



Exigences PCI DSS v3.0 déjà existantes : Condition 5 : Protéger tous les systèmes contre les logiciels malveillants et mettre à jour régulièrement les logiciels ou programmes anti-virus

Condition 6 : Développer et gérer des systèmes et des applications sécurisés







Oui


Est-ce que les machines virtuelles sont protégées des autres VM ou de l’hyperviseur?

• Examiner les procédures

Comment assure-t-on que les anti-virus et mises à jour des VM sont à jour (y compris les VM inactives et répliquées) avant qu’elles soient activées pour une utilisation prévue ?

• Définir des tâches planifiées de mises à jour de l’antivirus et VM

5

Quel processus pour chaque couche du service Cloud? Exp : Les périphériques réseau physiques, systèmes d’exploitation hôte, hyperviseurs, composants virtuels (y compris les VM, les périphériques réseaux virtuel), les applications, etc. ?

• Examiner les politiques et processus pour :

Les périphériques réseau physiques Les systèmes d’exploitation hôte Les hyperviseurs Les machines virtuelles Les applications virtuelles

6

Comment les API et services WEB sont protégées des vulnérabilités?


• Définir des tâches planifiées de mises à jour des API et services WEB

• Des tests d’intrusion sont planifiés périodiquement

• Une adresse de contact est fournie aux collaborateurs et pirates blancs pour communiquer une éventuelle vulnérabilité en temps réel.

• Une manière de motivation des pirates blancs et collaborateurs est mise en place.

Comment sont empêchés les systèmes et données de test et développement de migrer vers l’environnement de production? Et vice versa. (exp : à travers les mécanismes de réplication virtuelle, les images et de clichés instantanés)?


• Utiliser un outil informatique de notification qui alerte lors du passage d’un système de test vers un environnement de production et vice versa



Nouvelles considérations de sécurité de Cloud qui peuvent s’ajouter aux exigences PCI DSS : Condition 7, 8, 9

Condition 7 : Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les connaître

Condition 8 : Identifier et authentifier l’accès aux composants du système

Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes


Oui


Comment est appliquée l’authentification de l’utilisateur à travers différents niveaux?


• Associer un mot de passe différent pour chaque niveau de sécurité

Comment sont gérées les contrôles d’accès afin d’assurer que l’accès n’est pas plus qu’attendu?


Quel personnel du CSP a le droit d’accéder aux données client?


• Ne pas autoriser au personnel du CSP à accéder aux données client.

Comment sont revues et contrôlées les attributions de privilèges?


• Revoir les RBAC périodiquement • Examiner les logs d’accès aux

systèmes et les analyser

Est-ce que l’accès administratif aux systèmes et l’hyperviseur est séparé de l’accès aux VMs et données du client?


• S’assurer que l’accès administratif aux systèmes et l’hyperviseur est séparé de l’accès aux VMs et données du client

Est-ce qu’on utilise les mêmes informations d’authentifications pour différents fonctions de sécurité ?

• S’assurer que les informations d’authentifications pour différents fonctions de sécurité ne sont pas identiques

Est-ce que l’accès aux systèmes et hyperviseurs est séparé de l’accès aux VM et données client ?

• S’assurer que l’accès aux systèmes et hyperviseurs est séparé de l’accès aux VM et données client



Est-ce que des informations d’authentification séparées sont utilisées pour différents fonctions de sécurité?


• S’assurer que les informations d’authentifications pour différents fonctions de sécurité sont séparées.

7

Comment est « le moindre privilège » et « le nécessaire à savoir » est affecté pour le personnel du CSP?


• Définir pour chaque personnel du CSP le minimum de privilège et le nécessaire à savoir.

• S’assurer que le personnel du CSP possède uniquement le minimum de privilège et connait juste le nécessaire.

8

Est-ce que l’accès à partir de réseaux non sécurisés est autorisé aux personnel CSP ?


• Ne pas autoriser l’accès à partir de réseaux non sécurisés aux personnel CSP

9

Est-ce qu’il y a des mesures afin d’empêcher la capture d’informations dans la mémoire?


• Se protéger contre les failles Buffer Overflow

• Ne pas autoriser l’accès aux machines virtuelles à partir de l’hyperviseur

• Contrôler et solidifier l’introspection

• Revoir les logs d’introspection et hyperviseur qui concernent le client

Est-ce qu’il y a des mesures qui assurent que les images virtuelles ne contiennent pas des informations d’authentification ?


• S’assurer qu’il y a des mesures qui assurent que les images virtuelles ne contiennent pas des informations d’authentification

Est-ce que la double authentification est requise pour l’accès client?


• Exiger la double authentification pour l’accès client

•

Est-ce que le CSP utilise des mots de passes partagés (exp pour la maintenance) ?


• S’assurer que le CSP n’utilise pas des mots de passes partagés pour le client



Est-ce que le CSP garde une possession et un contrôle total sur toutes ses installations et ses centres de stockage de données ?


• S’assurer que les contrôles de sécurité sur les installations et centres de stockage de données sont appliqués par :

Le CSP Les fournisseurs des CSP

Qui a l’accès physique aux centres de données et les systèmes ?

• Définir les personnes ayant accès physique aux centres de données et les systèmes

Comment sont protégés les systèmes de stockage de données contre l’accès physique ou accès direct par console ?

• Examiner les politiques et procédures d’accès physique ou par console.

• Permettre au client d’auditer les mesures d’accès physique

• Permettre au QSA du client de se déplacer chez le CSP pour appliquer les exigences de contrôles physiques.

Comment sont sécurisés les sauvegardes des données et machines virtuelles ?


Comment les médias physiques sont inventoriés, sécurisés, surveillés, et suivis ?


• Etablir un inventaire des médias physiques

• Sécuriser ces médias : Les lecteurs de disques amovibles USB Ports parallèle et série. Cartes réseaux Disques durs Lecteurs de bande magnétiques Disques optiques

• Contrôler et auditer l’accès aux médias physiques

• Suivre le cycle de vie des médias suivants :

Les disques amovibles de stockage Disques durs Bandes magnétiques Disques optiques

Est-ce que les médias sont réutilisés ? Comment les données sont supprimées en permanence des médias retirées du service ou les médias réutilisables ?


• S’assurer que les données CHD dans les médias suivants sont carrément détruites avant une éventuelle réutilisation :



Les disques amovibles de stockage Disques durs Bandes magnétiques Disques optiques

• Utiliser des outils de destruction physiques des médias de stockage en fin de vie.




Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données du titulaire

Condition 11 : Tester régulièrement les processus et les systèmes de sécurité


Oui


Est-ce que les composants systèmes spécifiques utilisés par un client spécifique peuvent être identifiés à un moment donné ?

• Examiner les politiques et procédures qui permettent d’avoir un tableau mis à jours en temps réel contenant les composants utilisés par chaque client

Quels types d’évènements sont tracés dans les journaux d’audits?

• Les évènements suivants doivent être tracés dans les journaux d’audits :

1. Données 2. Interfaces (APIs, GUIs, Web) 3. Applications 4. Pile de Solution (Languages de

programmation) 5. Système d'exploitation (OS) 6. Machines virtuelles VMs 7. Infrastructure réseau virtuel 8. Hyperviseurs 9. Processeur et mémoire 10. Stockage de données (Disques

durs-disques amovibles-stockage..etc)

11. Réseau (Interfaces et périphériques-

12. infrastructure de communications)

13. Installations physiques/Centre de données

14. Accès par consoles 15. Accès physique 16. Accès à l’introspection 17. Etc …

Comment les logs d’audit sont gérés et surveillés ?


Comment les logs d’audit sont corrélés entre les environnements clients (comme l’image VM) et l’infrastructure CSP (comme l’hyperviseur et les systèmes sous-jacents) ?


• S’assurer que chaque client reçoit uniquement ses logs d’audit



Comment les horloges sont synchronisées entre les instances virtuelles et le système/matériel hôte?

• Déployer un système de synchronisation d’horloges entres les instances virtuelles et le système/matériel hôte

Comment les machines virtuelles sont scannées des vulnérabilités?


• Définir une date périodique de scan de vulnérabilités et tests d’intrusion

• Définir ce que le client doit scanner et ce que le CSP doit scanner

• Définir des tâches planifiées de mises à jour des VMs

• Une adresse de contact est fournie aux collaborateurs et pirates blancs pour communiquer une éventuelle vulnérabilité en temps réel.

• Une manière de motivation des pirates blancs et collaborateurs est mise en place.

Comment sont provisionnées les informations d’authentification ?


10

Est-ce que l’accès à distance du personnel du CSP est autorisé à partir de réseaux non sécurisés?


• Ne pas autoriser l’accès du personnel du CSP à partir de réseaux non confiants

11 Est-ce que double authentification est mise en place pour l’accès client ?

• S’assurer que double authentification est mise en place pour l’accès client

Comment sont gérées et testées les technologies de Wireless ?

• Examiner les politiques et procédures et la conformité avec les exigences PCI DSS

Comment les machines virtuelles (Dans toutes ses états : actives, dormantes, inactives, en maintenance) sont scannées contre les vulnérabilités ?

• Examiner les politiques et procédures qui traitent le scan contre les vulnérabilités des VMs dans toutes ses états.

Quelles défenses sont en place afin de se protéger contre les attaques «internes» (provenant du CSP ou autre réseau client) et les attaques "externes" (provenant de l'Internet ou tout autre réseau public)?


• Implémenter des IPS/IDS contre les trafics intra-VM et externes.

Est-ce que le test d’intrusion est effectué à travers toutes les couches




de l'environnement (par exemple, entre les machines virtuelles et le réseau de gestion du CSP, ou entre des clients sur une infrastructure partagée)?

• Effectuer des tests d’intrusions sur toutes les couches de l’environnement CDE.

Quels tests de sécurité le client est autorisé à faire sur ses interfaces web ?


• Autoriser les tests d’intrusion sur les interfaces API et WEB

• Ne pas autoriser l’exploitation des failles DOS et DDOS

• Autoriser les tests d’intrusion sur les couches qui sont sous la responsabilité des Clients

Comment les clients sont empêchés de faire des tests d’intrusion sur les environnements des autres clients ?


• Le client n’est autorisé à faire un test d’intrusion que suite à un accord écrit et encadré par le CSP



Nouvelles considérations de sécurité de Cloud qui peuvent s’ajouter aux exigences PCI DSS : Condition 12

Condition 12 : Maintenir une politique de sécurité des informations pour l’ensemble du personnel


Oui


Comment le CSP identifie les risques potentiels?

• Effectuer une évaluation de risque périodiquement

Est-ce que les clients sont notifiés lors des changements de la sécurité et/ou des politiques privées ?

• Examiner le processus de notification des clients lors des changements de la sécurité et/ou des politiques privées

Le CSP a-t-il des mécanismes en place pour assurer que des procédures opérationnels sécurisés sont pratiquées ?


Est-ce que différents niveaux de dépistage sont utilisés pour différents rôles ou régions?


Est-ce que le dépistage couvre tout le personnel ayant un accès physique aux centres de données à tous les endroits?

• Etablir une liste du personnel CSP ayant accès physique

Est-ce que le CSP sous traite n’importe quel aspect de son service Cloud à d’autres fournisseurs (ex : stockage de données, services de sécurité, etc.)?


• Etablir une liste des fournisseurs du CSP

12

Quelles mesures sont prises afin d’assurer que les politiques de sécurité du CSP sont maintenues par leurs fournisseurs tierces-parties?


• Exiger des documents du CSP décrivant les mesures de sécurité déployés par ses fournisseurs

Quels mécanismes sont mis en place afin de reporter au CSP une éventuelle menace ?


• Exiger une adresse e-mail de l’équipe de sécurité pour traiter les menaces de sécurité trouvée par une personne étrangère du CSP

Quel mécanisme est utilisé afin de détecter qu'un "incident" ou "une menace" a eu lieu?


• Examiner les journaux d’audit en temps réel possible.

Quelles notifications sont mises en • Examiner les politiques et



place et quand? procédures

Comment une menace (qui a touché un client) peut affecter la sécurité d’un autre client sur la même infrastructure ?


• Lors d’un incident qui a affecté un client, s’assurer qu’il n’a pas touché les autres clients immédiatement.

Comment les preuves sont collectées, gérées et partagées?


Quel était l’impact sur les données du client lors d’une infraction?

• Etudier l’impact d’un incident de sécurité sur les données CHD

Est-ce que les données d'un client peuvent être collectées dans le cadre d’une enquête de violation d'un autre client (ou de CSP) (soit par les autorités les par les enquêteurs d'un tiers-parti)?


• Etablir une liste contenant le nom, prénom, fonction du personnel autorisé à faire une investigation ainsi que la date de l’investigation

• Auditer la nature des investigations relevées dans des documents qui seront fournies aux clients par la suite

Est ce qu’on a des processus implémentés de reprise après sinistres, systèmes et installations avec le même contrôle de sécurité que les environnements de production ?


• Examiner les processus du plan de continuité de service BCP et de reprise après sinistre DR

Technology

Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)