06/05/2009

PCI DSS 11.4 : Use intrusion detection systems


Tous les experts en sécurité informatique ont forcement un jour ou l'autre participé à un projet IDS. Qu'il s'agisse de Snort ou de sondes commerciales, l'explosion des remontées d'alertes et des falses-positives ont conduit irrémédiablement à la mise au placard de la console IDS. Entre les remontées stupides causées par des scans incessants des worms PHP comme Santy ou les exploits aveugles IIS 4.0 ntdll.dll obsolètes qui attaquent vos serveurs Apache. Il est difficile différencier, parmi ces centaines d'attaques mensuelles remontées par l'IDS, les véritables attaques ciblant l'entreprise. Si l'on rajoute à cela le fait que les messages d'alertes des IDS ne sont jamais suffisamment explicites et ne peuvent servir comme preuve (parce qu'un message de type "WEB PHP Remote File Inclusion" n'est pas assez précis pour déterminer si un hacker est véritablement en train de chercher une faille dans votre application Oracle ou s'il s'agit simplement de remonté due au passage du ver PHP Wordpress. 

Dans le meilleur des cas, les IDS permettent de faire de magnifique reporting avec des camemberts représentant la répartition des attaques PHP Include, des robots de recherche de proxy public et des scans de ports.

Mon sujet n'est pas de critiquer les technologies IDS ou IPS et maintenant les nouveaux Unified Threat Management, mais de faire remarquer l'absurdité de l'intégration des IDS demandé dans le PCI DSS. Les personnes qui ont écrit le standard ne peuvent pas être sans savoir que les IDS ne sont que des générateurs de logs. Et pourtant, le chapitre 11.4 est explicite :

11.4 Use intrusion-detection systems, and/or intrusion-prevention systems to monitor all traffic in the cardholder data environment and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines up-to-date.


Cela part certainement d'un bon sentiment, mais je ne trouve pas cela très pragmatique, surtout si l'on met ce chapitre en perspective avec le chapitre 4.1 :

4.1 Use strong cryptography and security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks. 

Rien à dire sur ce dernier chapitre : l'utilité de SSL/TLS sur tous les protocoles où transitent des numéros de carte de crédit est indiscutable. Mais comment faire avec les IDS ? Le chapitre 11.4 demande de surveiller avec un IDS le trafic où circulent les numéros de carte. Mais si le trafic est chiffré dans un canal SSL, cela me semble impossible.

Les vendeurs de boitiers IDS proposent bien sûr de copier la clé privée SSL dans le dispositif IDS pour que celui-ci puisse déchiffrer et détecter les attaques dans les flux SSL (véridique, entendu à InfoSec cette année). "Gloups", mais admettons. Mais quid du chapitre 3.5 du PCI DSS ? Ce dernier demande que les clés de chiffrement soient stockées de façon sécurisée et dans le moins d'endroits possible. Cela n'est pas compatible avec la copie des clés sur un dispositif qui sera placé en frontal.

3.5 Protect cryptographic keys used for encryption of cardholder data against both disclosure and misuse: Store cryptographic keys securely in the fewest possible locations and forms.

L'intégration d'un IDS sur une plate-forme PCI DSS est donc légèrement capilotractée si l'on s'en tient à la lecture précise du standard.

Il est incontestable que la détection des attaques informatiques sur une plate-forme PCI DSS est très importante. Pour autant, les IDS ne sont pas pour moi une véritable solution pour celui qui veut réellement détecter les attaques.  Heureusement, le PCI SSC n'impose pas de produit. Le marchand soucieux de sa sécurité préférera utiliser les logs de ses serveurs web. Les logs sont bien plus précises et comme c'est elles qui seront présentées lors d'un procès pour piratage informatique, autant travailler directement avec elles.
Il est possible de scripter des recherches de certaines patterns incontournables aux attaques informatiques dans les logs. Et franchement, sur un site de commerce en ligne qui expose uniquement une application web en HTTPS, un pirate tentera forcement à un moment ou un autre des injections SQL et des Directory Transversal. Ce dernier ne va pas coder des O-days pour le firewall frontal ou casser des clés SSL...

Quelques patterns simples comme  : "' or 1=1", "../../", "/admin/" détecteront de façon systématique toutes attaques. Les logs seront là pour comprendre précisément ce qu'il se passe. De quoi convaincre un QSA.

Aucun commentaire:

Enregistrer un commentaire