28/11/2010

Scans et audits de vulnérabilités PCI DSS

Je suis régulièrement confronté à des incompréhensions sur les besoins d'audit et de scans dans le cadre du PCI DSS. Je présente donc ici, en détail, toutes les exigences PCI à ce sujet. J'ai choisi d'utiliser la version 2.0 de PCI DSS, car elle ne change à rien à ces besoins, elle les a juste éclaircis.

* Audit des règles firewall bi-annuel (Requirement PCI DSS 1.1.6)

Le ou les firewalls qui isolent l'environnement PCI d'Internet et du réseau interne non-PCI doivent être régulièrement audités : les règles de filtrage doivent être analysées pour détecter d'éventuelles failles ajoutées par des erreurs de configuration.

Par qui : par un expert réseau/sécurité interne ou par une société externe spécialisée.
Quand : Tous les 6 mois.

* Revue sécuritaire du code des applications maison (Requirement PCI DSS 6.3.2)

Pour toutes les applications développées "maison" ou par un fournisseur, de type Web ou de type Client-Serveur, interne ou exposée sur Internet, une revue sécuritaire du code doit être réalisée. Cette revue peut être automatisée ou réalisée manuellement, mais par des personnes indépendantes des personnes qui ont développé le code. En effet, cette revue a pour objectif de détecter des failles de sécurité selon le chapitre 6.5 (OWASP, SANS CWE TOP 25...), mais également de détecter d'éventuelles backdoors ou verrues logicielles visant à la réalisation de fraudes.

Quand : avant chaque mise en production d'une nouvelle version de l'application (avant chaque livraison).
Par Qui : par une personne interne compétente en audit de code (ex: CISSP) ou par une société externe spécialisée.

* Les tests d'intrusion applicatifs (Requirement PCI DSS 6.6)

Pour les applications de type Web exposées sur Internet, un test d'intrusion application doit être réalisé. Ce test peut être réalisé par un outil automatique spécialisé dans les applications web (ex: Acunetix, AppScan) ou manuellement par des experts équipés d'outil (Burp, Zap, WebScarab...).

Quand : au moins 1 fois par an et après chaque changement significatif.
Par Qui : Par une société spécialisée en Audit de sécurité des applications web (tests d'intrusion applicatifs) ou par une équipe interne si l'entreprise dispose d'une équipe spécialisée et véritablement indépendante des développeurs.
Exception: Si un Web Application Firewall (WAF) est installé en frontal des applications web, cette exigence d'audit n'est que recommandation.


* Les scans WiFi (Requirement PCI DSS 11.1)

Un scan de détection d'un point d'accès WiFi non-autorisé doit être mené sur chaque site physique du CDE (le périmètre PCI). Cette exigence s'applique même si le périmètre ne contient pas normalement de réseau WiFi.

Par qui : une personne interne ou une société tierce.
Quand : Trimestriel
Exception : Si un outil de détection automatique de réseau WiFi (wireless IDS/IPS) est en place ou si un Network Access Control (NAC) est en place.

* Scans de vulnérabilités trimestriels internes (Requirement PCI DSS 11.2.1)

Pour les adresses IP du CDE exposé sur le réseau interne de l'entreprise, des scans de vulnérabilités réguliers doivent être effectués. Le scan se déroule depuis le réseau interne de l'entreprise (en dehors du CDE). Le choix du scanner est ici libre (pas besoin que cela soit un boitier d'un ASV).

Par qui : Par une équipe interne, compétente et indépendante, ou par une société externe spécialisée.
Quand : Trimestriel

* Scans de vulnérabilités trimestriels externes (Requirement PCI DSS 11.2.2)

Toutes les adresses IP du CDE exposées sur Internet doivent être scannées avec un scanner de vulnérabilités. Le choix du scanner doit être fait parmi la liste des fournisseurs de scans certifiés PCI ASV. Les rapports de scan doivent être générés selon de la template "PCI" du scanner et le rapport doit indiquer un statut "Réussi" pour le scan de compliance. Le dernier rapport de scan doit être envoyé à la banque d'acquisition (ou aux Compliance Manager de chaque réseaux de cartes) tous les 3 mois.

Par qui : Le logiciel ASV peut être piloté par une personne interne ou par une société externe spécialisée.
Quand : Trimestriel

* Scans de vulnérabilités après tout changement (Requirement PCI DSS 11.2.3)

Toutes les adresses IP, internes et publiques, du CDE doivent être scannées avec un scanner de vulnérabilités après toute modification de l'environnement PCI. Le choix du scanner est ici libre (pas besoin que cela soit un boitier d'un ASV).

Pour les scans externes : toutes les vulnérabilités avec un score CVSS > 4.0 doivent être corrigées immédiatement.
Pour le scans internes : toutes les vulnérabilités avec un score "HIGH", ou équivalent en fonction du logiciel, doivent être corrigées immédiatement.

Par qui : Par une équipe interne, compétente et indépendante, ou par une société externe spécialisée.
Quand : Après toute modification de l'environnement PCI.


* Requirement PCI DSS 11.3 : Tests d'intrusion

Des tests d'intrusion externes (depuis Internet) et internes (depuis le réseau interne de l'entreprise) doivent être réalisés. Ces tests doivent cibler toutes les couches : réseau, système et applicative.

Par qui : Par une société externe spécialisée en tests d'intrusion ou par une équipe interne si l'entreprise dispose d'une équipe spécialisée et véritablement indépendante des développeurs.
Quand : Une fois par an.


Mon conseil : Faites vous accompagner par votre QSA (ca tombe bien, mon entreprise est QSA). La mise en place du processus et la réalisation de tous ces tests sont tout de même un travail d'experts et les logiciels ne font pas tout ! En effet, j'ai vu beaucoup d'entreprises investir des sommes folles dans des scanners commerciaux en pensant qu'elles se débrouilleraient seules et revenir en disant "OK, j'ai le logiciel, mais j'arrive je comprends pas ce qu'il me dit...XSS, CSRF, LFI...." ou encore "J'ai envoyé le rapport de SuperScanner à notre banque, mais on me dit que ce n'est pas ce qui est attendu."



5 commentaires:

  1. "revue de code des applications -> Par Qui : par une personne interne compétente en audit de code (ex: CISSP)."
    pas sur que le CISSP soit la certif la plus orienté audit de code ...

    RépondreSupprimer
  2. Je suis d'accord avec vous, le CISSP n'est pas un gage de compétence en audit de code web. Je voulais donner un exemple de formation. J'avais pensé à CEH, mais c'est pas forcément une bonne formation non plus.

    Je ne suis pas fan du CISSP, qui je trouve ne forme pas de bon expert en sécurité.

    Disons : une personne maitrisant les failles de sécurité web par la pratique manuelle (pas une personne savant lancer Nessus ou Acunetix Free Edition), les backdoors logicielles et ayant une expérience en tests d'intrusion et en revue de code.

    Fred.

    RépondreSupprimer
  3. Bonjour,
    Merci de se concentrer precis pour ls PCI-DSS.
    Je voulais savoir pourriez-vous svp, nous decrire comment devenir QSA?

    RépondreSupprimer
  4. Pour devenir QSA, il faut passer par la formation PCI QSA dispensée par le PCI Council. Pour passer cette formation, il faut justifier d'une certification CISSP ou de 5 ans d'expérience en audit SSI.

    Il faut également être salarié d'une société QSAC (QSA Company). La liste est disponible : https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php

    Il existe également une certification iQSA (internal QSA) destinée aux responsables internes PCI (ex: le RSSI et le CISO). Cette formation permet de mener des audits d'écart en interne avant l'audit de certification.

    RépondreSupprimer
  5. J'ai testé la solution IKare elle simple et efficace à utiliser

    RépondreSupprimer