Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Alexandre Fernandez-Toro, Consultant, HSC : Offres intégrées de conformité PCI-DSS : conformité automatique ou semi-automatique ? Complète ou partielle ?

mars 2008 par Alexandre Fernandez-Toro, Consultant, HSC

Les entreprises amenées à traiter, transmettre ou stocker des informations relatives aux cartes bancaires sont de plus en plus poussées à se mettre en conformité avec le référentiel PCI-DSS. Cette pression crée chez ces entreprises un besoin de sécurisation de leurs plateformes de paiement, et ce besoin prend une telle ampleur que certains éditeurs de logiciels ainsi que des constructeurs d’équipements réseau proposent maintenant des offres intégrées réputées « conformes PCI-DSS ». On pouvait récemment lire dans une entrevue avec des représentants d’un éditeur de solutions intégrées que ses clients « n’ont pas besoin de dépenser de l’argent car ils répondent déjà aux douze réglementations de PCI. Ils sont sécurisés de fait. Par nature, les sociétés qui possèdent notre infrastructure sont conformes à cette norme ».

Cette dernière phrase pose toute la question : est-il vraiment possible d’être conforme à tout un référentiel « par nature » ? On peut en douter, surtout lorsqu’on a affaire à un référentiel aussi contraignant que PCI-DSS. Cet article a pour but de comprendre dans quelle mesure une offre intégrée peut aider à être conforme avec les exigences du référentiel PCI-DSS.

Les « offres de conformité » PCI-DSS n’apporte aucune exigence révolutionnaire en matière de sécurité

PCI-DSS n’apporte aucune exigence révolutionnaire en matière de sécurité. C’est une compilation de bonnes pratiques que l’entreprise qui y est soumise se doit d’adopter. Aussi, tous les produits logiciels et matériels nécessaires à la conformité existent déjà : firewals pour cloisonner les réseaux, filtrage applicatif pour protéger les applications (contre les attaques XSS, injections SQL, débordements de buffer), systèmes d’authentification forte, chiffrement des réseaux sans fil, centralisation des journaux, protection des mots de passe, etc. La difficulté n’est donc pas de trouver les produits sur étagère aidant à être conforme. La difficulté est dans l’intégration de tous ces éléments afin qu’ils interagissent de façon efficace et qu’ils garantissent la conformité à PCI-DSS.
Cette situation pousse certains constructeurs d’équipement réseau ou éditeurs de solutions de sécurité à proposer des offres intégrées, centrées autour de leurs produits, éventuellement complétées par les produits de sociétés partenaires. En effet, ces acteurs sentent bien que PCI-DSS est un grand marché ne nécessitant ni recherche ni développement ne nouveaux produits. Seul un effort d’assemblage de l’existant cohérent et bien pensé suffit. Donc de fortes marges en perspective…

Deux grandes approches et un point commun la vitualisation

En regardant les offres qui se dessinent, deux grandes approches se dégagent. Elles ont un point commun, la virtualisation.

• Virtualisation centrée sur les réseaux : c’est une offre proposée par les constructeurs réseau. Le cas de CISCO est intéressant puisqu’il propose une offre centrée sur trois architectures type : une pour les petites structures, une autre pour les commerçants de taille moyenne, puis une dernière pour les grands centres. Cette architecture type a pour but d’être adaptée aux spécificités du client tout en gardant un certain nombre de propriétés. Chacune de ces architectures type est détaillée tant d’un point de vue matériel que logiciel. La liste exacte des équipements est fournie avec leur configuration détaillée, équipement par équipement. Enfin, CISCO a fait auditer ces trois architectures type par un QSA. Tous ces éléments (description d’architecture, liste des équipements et logiciels, configurations détaillées et rapport de conformité du QSA) sont compilés dans un document disponible librement sur Internet (http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a00809464ec.pdf). _ Ces architectures types ont vocation à être adaptées aux spécificités du client. Attention, il faut être bien conscient que le QSA n’a certifié que la conformité PCI-DSS de ces trois architectures type, testées en laboratoire. Le client achetant la solution CISCO devra nécessairement adapter l’architecture à son contexte, et donc faire venir un QSA pour auditer la sienne. En somme, l’offre « conforme à PCI-DSS » n’est donc pas automatiquement conforme une fois implantée chez le client. En revanche elle est structurellement conçue pour que l’effort à faire pour être conformité soit moindre.

• Virtualisation centrée sur les serveurs et des postes clients : une seconde approche consiste à ne pas se centrer sur le réseau mais plutôt sur les serveurs. C’est typiquement l’approche de Citrix, qui a adapté son offre pour tenir compte des exigences de PCI-DSS. Les serveurs ainsi que les postes de travail gérant des données relatives aux cartes bancaires sont isolés grâce à la virtualisation. Cette offre est complétée par des appliances qui, comme pour CISCO, contrôlent les flux et vont même jusqu’au filtrage de niveau applicatif. Tout comme pour CISCO, un whitepaper disponible sur le site de Citrix (http://cms.citrix.de/modules/resource/download/42e116621782a00901179c00642e0003/CitrixSolutionsFor-PCI-Compliance.pdf) présente la solution et recommande au client de se rapprocher d’un auditeur pour vérifier la bonne couverture des exigences.

La couverture des offres intégrées est trop souvent partielle

Il est certain que les produits et services de ces fournisseurs aident grandement à la conformité PCI-DSS. Mais couvrent-ils toutes les exigences du référentiel ? Il y a de bonnes raisons d’en douter.

3 grandes types de familles pour le PCI Security Standard Council

Le PCI Security Standard Council, créateur du référentiel PCI-DSS, n’a pas typé les exigences. Cependant, il est possible de les diviser en trois grandes familles. D’abord, les exigences d’ordre technique, celles relatives à l’exploitation et, enfin, les exigences organisationnelles. Cette approche est un peu artificielle, mais elle nous sera utile pour notre propos.

• Exigences techniques : il s’agit d’actions qui doivent être entreprises lors de la sécurisation de l’infrastructure, au moment de sa mise en place, en vue d’être certifiée PCI. Nous trouvons parmi ces actions la configuration des pare-feu (articles 1.2 et 1.3) ou le réglage des configurations des équipements réseau (2.1 et 2.2) ainsi que toutes les autres actions techniques de sécurisation.

• Exigences d’exploitation : comme la sécurité n’est jamais un acquis, les exigences d’exploitation ont pour but d’assurer le maintient d’un bon niveau de sécurité, en exécutant un certain nombre de tâches récurrentes. Elles empêchent ainsi la dérive du système. Ainsi, l’examen trimestriel des règles applicables aux pare feux (article 1.1.8) permet il de vérifier que les règles en place sont toujours pertinentes. L’étude quotidienne des journaux (article 1.1.8) facilite grandement la détection rapide de tout incident relatif à la sécurité.

• Exigences politiques et organisationnelles : elles consistent à formaliser les politiques et procédures nécessaires au bon usage des ressources (article 12).
Ces exigences sont mélangées dans le référentiel PCI-DSS car elles ne sont pas classées en fonction de leur type mais en fonction du domaine traité (réseau, contrôle, protection des données, contrôle d’accès, surveillance, etc.). Nous notons tout juste une forte concentration d’exigences politiques et organisationnelles dans le chapitre douze.

Si la couverture des exigences techniques est assez bonne, celle de l’exploitation est loin d’être parfaite

Pour étudier l’intérêt des offres intégrées de solutions PCI, il est plus pratique de considérer les exigences selon leur type (technique, d’exploitation ou organisationnel) plutôt que selon leur domaine.

• Couverture des exigences techniques : les exigences de ce type sont largement couvertes par les offres commerciales. Tant CISCO que Citrix les satisfont. Tous proposent des boîtiers de chiffrement SSL, des systèmes d’authentification, filtrage applicatif, ainsi que de la journalisation centralisée. Les choix architecturaux des offres répondent bien aux exigences de cloisonnement de PCI-DSS.

• Couverture des exigences d’exploitation : Elle est moins évidente à prouver. Par exemple, l’article 1.1.2 oblige à tenir un diagramme du réseau à jour. Les solutions intégrées le permettent-elles ? Qu’en est-il de l’examen trimestriel des règles applicables aux pare-feux et aux routeurs (article 1.1.8) ? Ces solutions précisent-elles qui doit surveiller quotidiennement les journaux (article 10.6) ? Le référentiel impose de tester annuellement les contrôles de sécurité, limitations, connexions réseau et restrictions (article 11.1). Ces tests sont-ils effectués automatiquement par la solution ? Si oui, comment ? Des balayages de vulnérabilité réseau internes et externes doivent être réalisés au moins une fois par an. Est-ce prévu ? Enfin, des tests de pénétration doivent être réalisés au moins une fois par an (article 11.3). Ce service est-il compris dans la solution ?

• Couverture des exigences politiques et organisationnelles : elle parait encore plus difficile à satisfaire que les précédentes. En effet, les aspects politiques dépendent tellement du contexte de chaque client qu’ils sont spécifiques à chaque entreprise.

o Par exemple, l’article 8.5.1 demande de contrôler tout ajout d’identités d’utilisateur ou d’identifiants. Par ailleurs, lorsqu’un utilisateur a besoin de faire réinitialiser son mot de passe, l’article 8.5.2 exige que son identité soit préalablement vérifiée. Et lorsqu’il quitte l’entreprise, il doit être mis fin immédiatement à ses accès (article 8.5.4).
o Comment un intégrateur de solution PCI peut-il communiquer les procédures et politiques en matière de mot de passe à tous les utilisateurs ayant accès aux données de titulaires de carte (article 8.5.7) ?
o Comment la solution fait-elle pour édicter, publier, maintenir en vigueur et diffuser une politique de sécurité (article 12.1) ?
o Le fournisseur de solution PCI-DSS a-t-il une telle connaissance du contexte du client pour se charger de l’identification annuelle des menaces et des vulnérabilités (article 12.1.2) ?
o Qui d’autre que le client doit développer des procédures de sécurité opérationnelle (article 12.2). Par exemple : maintenance de compte utilisateur, vérification de journal.
o Qui va s’assurer que ces politiques comportent une liste des dispositifs et des personnels disposant d’un accès (exigence 12.3.3) ?
o Quelle autorité a le fournisseur (exigence 12.4) pour définir les responsabilités en matière de sécurité de l’information chez le client ?
o Qui d’autre que le client est mieux placé pour attribuer à un individu la responsabilité de mettre en place, consigner et diffuser les politiques et procédures en matière de sécurité (exigence 12.5.1) ?
o Les solutions proposées peuvent-elles déployer (à la lace du client) un programme formel de sensibilisation à la sécurité pour que tous les employés soient conscients de l’importance de la sécurité (exigence 12.6) ?
o Enfin, qui a autorité pour soumettre les employés à des vérifications afin de minimiser le risque d’attaques de sources internes (exigences 12.7) ?
Ces exigences d’ordre politique peuvent être satisfaites par les fournisseurs gérant la plate forme à la place du client, mais cela ne dispense nullement ce dernier d’appliquer lui aussi ces exigences.
Il ressort de cette analyse que les solutions proposées répondent de façon très satisfaisante aux exigences purement techniques du référentiel PCI-DSS. Pour ce qui concerne les exigences d’exploitation, tout dépend si elles sont laissées à la charge du client ou si elles font l’objet d’un service d’infogérance. Par exemple, l’analyse quotidienne des journaux peut être prise en charge par un prestataire. Il en va de même pour les autres exigences d’exploitation. Ainsi, une offre qui consisterait à installer l’infrastructure, à la configurer, mais aussi à l’exploiter serait conforme aux exigences d’exploitation PCI. Restent les exigences politiques et organisationnelles qui nécessitent dans tous les cas une certaine implication, voire une implication totale du client. L’analyse que nous venons de faire conduit à penser que les offres auront énormément de mal à satisfaire l’ensemble des exigences PCI-DSS.

Au final, une situation plus complexe que les offreurs de solutions veulent bien le dire

Il ressort de cette approche que la situation est beaucoup plus complexe qu’il n’y parait lorsqu’on lit les propos lénifiants tenus par certains commerciaux. Ces offres répondent sans aucun doute aux exigences purement techniques du référentiel PCI. Pour ce qui est des exigences relatives à l’exploitation, une réflexion doit être faite sur la part d’infogérance proposée par le fournisseur et la part d’exploitation en interne par le client. Enfin, une partie des exigences politiques peut être prise en charge par le fournisseur s’il infogère l’exploitation de la plateforme du client. En revanche, une partie des exigences de politique revient nécessairement au client.
En tout cas, si les solutions intégrées de mise en conformité PCI-DSS aident vraiment, et pour une part importante, à la conformité PCI, il n’y a en aucun cas de conformité « automatique », « par nature ». Face à ces offres, le client doit faire preuve, plus que jamais, de discernement pour choisir l’approche qui lui corresponde le mieux : approche orientée réseau, approche orientée virtualisation, part de l’infogérance, part de l’exploitation en interne. Il ne bénéficiera pas par transitivité du label « conforme à PCI-DSS ».


 Alexandre Fernandez-Toro est l’auteur du livre "Management de la
sécurité de l’information. Implémentation ISO 27001, mise en place d’un
SMSI et audit de certification",aux éditions Eyrolles (ISBN :
978-2-212-12218-3)

Il est consultant en sécurité depuis huit ans et dirige les activités
ISO 27001 au sein d’HSC. Il est auditeur de certification et conseille
ses clients dans la mise en place des Systèmes de Management de la
Sécurité de l’Information (SMSI) et la gouvernance de la sécurité des SI.

Ancien professeur associé à l’Université, il conçoit et assure les
formations HSC relatives aux systèmes de management en sécurité depuis
2004. Alexandre Fernandez-Toro était auparavant responsable de
production dans un environnement mainframe et il est ingénieur CNAM.


Voir les articles précédents

    

Voir les articles suivants