Comment répondre à l'exigence 6.6 de la norme PCI DSS – Une solution deux pour un de Threat Stack

La version actuelle de la norme PCI DSS est la 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, pas de problème. C'est totalement 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 le reste d’entre nous, c’est une tâche difficile. 

Mais le document énumère ensuite un certain nombre d’exigences assez simples, qui font déjà partie de la plupart des cycles de vie de développement de logiciels sécurisés. Vous devez établir un processus pour identifier les vulnérabilités de sécurité, traiter les vulnérabilités connues, employer les meilleures pratiques en matière de codage, séparer de manière sécurisée les environnements et les comptes de développement et de test de la production, effectuer des revues de code, avoir un processus de contrôle des modifications, former les développeurs aux techniques de codage sécurisées, etc. Tout à fait raisonnable. 

Un peu plus en profondeur, sous cette exigence de niveau supérieur (dans l’exigence 6.5), un certain nombre de vulnérabilités spécifiques contre lesquelles les applications doivent être protégées sont répertoriées. Il s'agit en quelque sorte des « plus grands succès » de l'OWASP TOP 10, du SANS CWE Top 25, du CERT Secure Coding, etc., et ils correspondent à ce à quoi on peut s'attendre : injection SQL, cryptographie faible, XSS, dépassements de tampon, etc. Encore une fois, c'est raisonnable. Les attaquants ciblent systématiquement ces types de vulnérabilités comme point initial d’attaque. 

Ensuite, dans l’exigence 6.6, le plus important : « Pour les applications Web destinées au public, traitez en permanence les nouvelles menaces et vulnérabilités et assurez-vous que ces applications sont protégées contre les attaques connues. » Quelles attaques ? Il répond « au minimum à toutes les vulnérabilités de l’exigence 6.5 ». Pensez-y un instant. Cette seule exigence — 6.6 — enfouie au plus profond du document, à la page 64, a un impact majeur sur la façon dont nous construisons et exploitons les logiciels ! Comment proposent-ils de répondre à cette exigence ? La réponse comporte deux parties :

• En examinant les applications chaque année et après toute modification, en utilisant « des outils ou méthodes d’évaluation de la vulnérabilité de la sécurité, manuels ou automatisés »
• En utilisant « une solution technique automatisée qui détecte et prévient les attaques basées sur le Web » 

Cela a donc un impact à la fois sur le temps de création et sur le temps d'exécution des applications Web et implique en réalité deux activités complètement différentes :

1. Examiner les applications pour détecter de manière proactive la présence de vulnérabilités (et s'assurer ensuite qu'elles sont corrigées)

- Et - 

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

Ce n’est pas du tout une mauvaise exigence. Comme l’indiquent les directives, « les applications Web publiques sont les principales cibles des attaquants, et les applications Web mal codées offrent aux attaquants un moyen facile d’accéder aux données et aux systèmes sensibles ». Je ne pourrais pas être plus d’accord. Le défi réside dans la mise en œuvre pratique de cette exigence. 

Il n’y a pas beaucoup de conseils fournis sur la manière d’accomplir la première partie : l’évaluation des applications. Les applications doivent être examinées « à l’aide d’outils ou de méthodes d’évaluation de la vulnérabilité de la sécurité, manuels ou automatisés. » C’est assez large. 

La deuxième partie contient une recommandation un peu plus spécifique. Vous devez installer « une solution technique automatisée qui détecte et empêche les attaques Web (par exemple, un pare-feu d’application Web) devant les applications Web publiques, afin de vérifier en permanence tout le trafic. » Cela a été une aubaine pour les fournisseurs de WAF qui se sont soudainement retrouvés devant un achat « case à cocher » pour les équipes cherchant à satisfaire à l’exigence 6.6. Mais un WAF n’aide pas à répondre à la première partie de l’exigence. Un WAF n’est pas un outil d’évaluation de la sécurité : Il n'a aucune idée de ce que fait une application ou comment elle le fait. Il comprend uniquement ce qui est envoyé à une application , et non ce que l' application peut (ou ne peut pas) faire avec ces informations.

Tout cela laisse de nombreuses équipes en difficulté pour traiter la totalité de la version 6.6. Dans cette petite exigence se cachent deux besoins importants et bien différents. La plupart tenteront de satisfaire la deuxième partie avec un WAF et assembleront un certain nombre d’autres techniques pour répondre à la première (revues de code manuelles, analyse automatisée du code source , etc.). 

Mais il existe une alternative qui peut satisfaire l’exigence 6.6 avec une solution unique. Vous remarquerez que la norme PCI inclut l'expression « par exemple » lorsqu'elle mentionne WAF. C'est important (et cela n'était pas inclus dans les versions précédentes de la norme). Il reconnaît qu’il existe d’autres technologies capables de protéger les applications à condition qu’elles soient « configurées pour bloquer les attaques Web ou pour générer une alerte qui fait immédiatement l’objet d’une enquête ».  Application Security Monitoring, la solution de sécurité des application unifiée que Threat Stack a ajoutée à sa Cloud Security Platform® sans frais supplémentaires, répond à la fois aux aspects de création et d'exécution de l'exigence 6.6. Une solution à ces deux grands défis. 

Au moment de la création, vous ajoutez le microagent Threat Stack à vos applications comme n’importe quelle autre bibliothèque de code tierce. Les développeurs trouvent cela très similaire à l’instrumentation de leurs applications avec une solution APM. Une fois le microagent ajouté, l' application est évaluée à chaque exécution, que ce soit via des tests manuels locaux, des tests automatisés dans une version nocturne, des tests d'acceptation utilisateur, etc. La norme PCI précise que l’application doit être revue « au moins une fois par an et après toute modification ». Threat Stack va bien au-delà de cela pour identifier les vulnérabilités de sécurité de manière continue, le tout sans que le développeur n'ait besoin d'effectuer de travail supplémentaire. Il n'y a aucun test à écrire ni de serveur à administrer.

Une fois qu’une vulnérabilité est identifiée, l’exigence 6.6 indique également qu’elle doit être corrigée. 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 conseils pratiques sur tous les risques détectés : en expliquant le risque, en présentant un exemple de code sur la façon de le corriger et en dirigeant le développeur vers le nom exact du module et de la méthode, l'emplacement du fichier et le numéro de ligne où il a été trouvé. Une fois que le développeur a corrigé la vulnérabilité, il n'est pas nécessaire de faire quoi que ce soit de spécial pour « réévaluer » : l' application sera évaluée automatiquement lors de sa prochaine exécution. 

Lors de l’exécution, l’exigence est de « vérifier en permanence tout le trafic » pour protéger l’ application contre les attaques connues. Le même microagent Threat Stack fait également cela. Au fur et à mesure que l' application est déployée du développement à la production, le microagent l'accompagne (il est intégré à l' application en tant que dépendance). À partir de là, il analyse toutes les charges utiles Web envoyées à l’ application pour surveiller les signes d’attaque. Si une charge utile est considérée comme malveillante, la demande peut être arrêtée immédiatement. Les équipes sont informées de l'attaque via le portail Threat Stack ou dans Slack ou d'autres canaux ChatOps. Cela répond clairement à l’exigence PCI de « bloquer les attaques basées sur le Web ou de générer une alerte qui fait immédiatement l’objet d’une enquête ».

PCI 6.6 est important. Le mandat de « répondre en permanence aux nouvelles menaces et vulnérabilités et de garantir que ces applications sont protégées contre les attaques connues » couvre deux phases distinctes du cycle de vie du développement logiciel (développement et production) et implique deux tâches distinctes (évaluation proactive des vulnérabilités et détection et prévention des attaques en temps réel). Les deux sont complexes et impliquent généralement des équipes différentes. Mais vous n’avez pas besoin de deux outils distincts pour y faire face. La surveillance de la sécurité des application de Threat Stack répond à ces deux exigences avec une solution unique qui ne ralentira pas les développeurs. Essayez-le aujourd'hui !   

Si vous souhaitez en savoir plus ou tester Application Security Monitoring, inscrivez-vous pour une démonstration de la plateforme de sécurité cloud Threat Stack. Nos experts en conformité et en sécurité se feront un plaisir de discuter de vos besoins spécifiques.