Comment répondre à l’exigence 6.6 de la norme PCI DSS — Une solution deux-en-un de Threat Stack

F5

Threat Stack est désormais F5 Distributed Cloud App Infrastructure Protection (AIP). Commencez à utiliser Distributed Cloud AIP avec votre équipe dès aujourd’hui.

La version actuelle de la norme PCI DSS est la version 3.2.1, publiée en mai 2018. L’exigence 6 stipule que vous devez « développer et maintenir des systèmes et des applications sécurisés ». Bien sûr, aucun problème. C’est parfaitement clair et simple — du moins pour quiconque n’a jamais essayé de développer et de maintenir des systèmes et des applications sécurisés ! Pour les autres, c’est une tâche ardue.

Mais le document énumère ensuite un certain nombre d’exigences assez simples, qui font déjà partie de la plupart des cycles de développement logiciel sécurisé. Il convient de mettre en place un processus permettant d’identifier les failles de sécurité, de corriger les vulnérabilités connues, d’appliquer les bonnes pratiques de programmation, de séparer de manière sécurisée les environnements et comptes de développement et de test de ceux de production, d’effectuer des revues de code, de disposer d’un processus de gestion des changements, de former les développeurs aux techniques de programmation sécurisée, etc. Tout cela est plutôt raisonnable.

En approfondissant un peu cette exigence de haut niveau — dans l’exigence 6.5 —, on trouve une liste de vulnérabilités spécifiques contre lesquelles les applications doivent être protégées. Il s’agit en quelque sorte d’un « best of » de l’OWASP TOP 10, du SANS CWE Top 25, des recommandations CERT Secure Coding, etc., avec les vulnérabilités auxquelles on pourrait s’attendre : injection SQL, cryptographie faible, XSS, dépassements de mémoire tampon, entre autres. Là encore, rien que de très raisonnable. Les attaquants ciblent régulièrement ces types de vulnérabilités comme point d’entrée initial.

Puis vient le point crucial, à l’exigence 6.6 : « Pour les applications web accessibles au public, traiter en permanence les nouvelles menaces et vulnérabilités, et veiller à ce que ces applications soient protégées contre les attaques connues. » Quelles attaques ? Le texte précise : « au minimum, toutes les vulnérabilités mentionnées dans l’exigence 6.5. » Réfléchissez-y un instant. À elle seule, cette exigence — la 6.6 — enfouie à la page 64 du document, a une incidence majeure sur la façon dont nous développons et exploitons les logiciels ! Comment proposent-ils de satisfaire à cette exigence ? La réponse comporte deux volets :

• En examinant les applications chaque année et après toute modification, à l’aide « d’outils ou de méthodes d’évaluation de la sécurité des vulnérabilités, manuels ou automatisés »
• En utilisant « une solution technique automatisée qui détecte et empêche les attaques Web »

Cela a donc un impact à la fois sur la phase de compilation et sur l’exécution des applications web, et implique en réalité deux activités complètement différentes :

1. Examiner les applications afin de détecter de manière proactive la présence de vulnérabilités (puis veiller à ce qu’elles soient corrigées)

– Et –

2. Détecter et bloquer les attaques en temps réel

Cette exigence est tout à fait pertinente. Comme l’indiquent les recommandations, « les applications web accessibles au public sont des cibles privilégiées pour les attaquants, et les applications web mal codées leur permettent d’accéder facilement aux données et systèmes sensibles ». Je suis tout à fait d’accord. La difficulté réside dans la mise en œuvre concrète de cette exigence.

Il existe peu d’indications sur la manière de réaliser la première partie, à savoir l’examen des applications. Celles-ci doivent être examinées « à l’aide d’outils ou de méthodes d’évaluation de la sécurité et des vulnérabilités, manuels ou automatisés ». C’est assez vague.

La deuxième partie formule une recommandation légèrement plus précise. Vous devez installer « une solution technique automatisée qui détecte et empêche les attaques Web (par exemple, un pare-feu applicatif Web) devant les applications Web accessibles au public, afin de contrôler en permanence l’ensemble du trafic ». Cette disposition a fait le bonheur des fournisseurs de WAF, dont les produits sont soudain devenus un achat permettant aux équipes de « cocher une case » pour satisfaire à l’exigence 6.6. Mais un WAF n’est d’aucune aide pour la première partie de l’exigence. Un WAF n’est pas un outil d’évaluation de la sécurité : il ne sait ni ce que fait une application ni comment elle le fait. Il comprend uniquement ce qui est envoyé à une application, et non ce que celle-ci peut (ou non) faire de ces informations.

Tout cela laisse de nombreuses équipes démunies lorsqu’il s’agit de répondre à l’ensemble de l’exigence 6.6. Cette seule petite exigence recouvre deux besoins importants et très différents. La plupart tenteront de satisfaire à la seconde partie à l’aide d’un WAF et combineront plusieurs autres techniques pour répondre à la première (revues manuelles du code, analyse automatisée du code source, etc.).

Mais il existe une autre approche permettant de satisfaire à l’exigence 6.6 avec une solution unique. Vous remarquerez que la norme PCI emploie l’expression « par exemple » lorsqu’elle mentionne le WAF. Ce détail est important (et cette expression ne figurait pas dans les versions antérieures de la norme). Cela signifie qu’il existe d’autres technologies capables de protéger les applications, à condition qu’elles soient « configurées soit pour bloquer les attaques Web, soit pour générer une alerte faisant immédiatement l’objet d’une investigation ». Application Security Monitoring — la solution unifiée de sécurité des applications que Threat Stack a ajoutée sans frais supplémentaires à sa Cloud Security Platform® — couvre à la fois les aspects liés à la phase de développement et à l’exécution de l’exigence 6.6. Une seule solution pour relever ces deux défis majeurs.

Lors de la phase de développement, vous ajoutez le micro-agent Threat Stack à vos applications comme n’importe quelle autre bibliothèque de code tierce. Pour les développeurs, cela ressemble beaucoup à l’instrumentation de leurs applications à l’aide d’une solution APM. Une fois le micro-agent ajouté, l’application est évaluée à chaque exécution, qu’il s’agisse de tests manuels en local, de tests automatisés dans le cadre d’une compilation nocturne, de tests d’acceptation utilisateur, etc. La norme PCI précise que l’application doit être examinée « au moins une fois par an et après chaque modification ». Threat Stack va bien au-delà en détectant en continu les vulnérabilités de sécurité, sans que le développeur ait à fournir le moindre travail supplémentaire. Il n’y a aucun test à écrire ni aucun serveur à administrer.

Une fois qu’une vulnérabilité a été identifiée, l’exigence 6.6 impose également d’y remédier. Vous devez vous assurer « que toutes les vulnérabilités sont corrigées et que l’application est réévaluée après les corrections ». Threat Stack AppSec Monitoring fournit aux développeurs des recommandations concrètes pour chaque risque détecté : explication du risque, exemple de code permettant de le corriger, ainsi que le module, le nom de la méthode, l’emplacement du fichier et le numéro de ligne exacts où il a été identifié. Une fois la vulnérabilité corrigée par le développeur, aucune action particulière n’est nécessaire pour « réévaluer » l’application : celle-ci sera automatiquement évaluée lors de sa prochaine exécution.

Lors de l’exécution, l’exigence consiste à « contrôler en permanence l’ensemble du trafic » afin de protéger l’application contre les attaques connues. Le même micro-agent Threat Stack s’en charge également. Lorsque l’application passe de l’environnement de développement à la production, le micro-agent l’accompagne (il est intégré à l’application en tant que dépendance). Il analyse alors toutes les charges utiles web envoyées à l’application afin de détecter d’éventuels signes d’attaque. Si une charge utile est jugée malveillante, la requête peut être immédiatement bloquée. Les équipes sont informées de l’attaque via le portail Threat Stack, Slack ou d’autres canaux ChatOps. Cela répond directement à l’exigence PCI qui impose de « bloquer les attaques web ou de générer une alerte faisant immédiatement l’objet d’une investigation ».

La norme PCI 6.6 est exigeante. L’obligation de « traiter en permanence les nouvelles menaces et vulnérabilités et de veiller à ce que ces applications soient protégées contre les attaques connues » couvre deux phases distinctes du cycle de développement logiciel (développement et production) et implique deux tâches différentes (l’évaluation proactive des vulnérabilités, ainsi que la détection et la prévention des attaques en temps réel). Toutes deux sont complexes et font généralement intervenir des équipes différentes. Mais vous n’avez pas besoin de deux outils distincts pour y répondre. La solution Application Security Monitoring de Threat Stack répond à ces deux exigences au moyen d’une solution unique qui ne ralentira pas les développeurs. Essayez-la dès aujourd’hui !

Si vous souhaitez en savoir plus ou tester la solution Application Security Monitoring, inscrivez-vous à une démonstration de la plateforme Threat Stack Cloud Security. Nos experts en conformité et en sécurité se feront un plaisir d’échanger avec vous sur vos besoins spécifiques.

Référence

Exigence 6.6 de la norme PCI DSS, extraite du document « Exigences et procédures d’évaluation de sécurité », version 3.2.1, mai 2018

6.6 Pour les applications web accessibles au public, traitez en permanence les nouvelles menaces et vulnérabilités et veillez à ce que ces applications soient protégées contre les attaques connues au moyen de l’une des méthodes suivantes :

• Examiner les applications web accessibles au public à l’aide d’outils ou de méthodes manuels ou automatisés d’évaluation de la sécurité et des vulnérabilités des applications, au moins une fois par an et après toute modification
• Installer une solution technique automatisée qui détecte et empêche les attaques web (par exemple, un pare-feu applicatif web) en amont des applications web accessibles au public, afin de contrôler en permanence l’ensemble du trafic.

Threat Stack est désormais F5 Distributed Cloud App Infrastructure Protection (AIP). Commencez à utiliser Distributed Cloud AIP avec votre équipe dès aujourd’hui.

À propos de l’auteur

F5

Autres articles de F5