Les directives remaniées du Conseil des normes de sécurité PCI : sont-elles suffisamment orientées vers la gauche ?

Une version de cet article a été initialement publiée dans Magazine sur les transactions numériques.

Cette année, le PCI Security Standards Council a publié un tout nouvel ensemble de directives relatives à la sécurité des logiciels dans le cadre de leur cadre de sécurité logicielle PCI. Cette mise à jour vise à aligner les meilleures pratiques en matière de sécurité logicielle sur le développement logiciel moderne. Il s'agit d'une initiative fantastique qui reconnaît l'évolution de ce processus au fil du temps, nécessitant de repenser les normes de sécurité établies bien avant que la majorité de nos vies ne soient rapidement numérisées.

Cela prouve clairement que notre secteur s'intéresse de plus en plus à l'idée de directives adaptables, qui évoluent en fonction de l'évolution de nos besoins, ainsi qu'aux exigences d'un environnement de cybersécurité qui pourrait très rapidement devenir incontrôlable si nous continuons à faire preuve de laxisme dans nos processus de développement sécurisés. Naturellement, le Conseil des normes de sécurité PCI agissant en tant qu'organe directeur du secteur bancaire et financier (en fixant les normes de sécurité pour les logiciels en lesquels nous avons confiance afin de protéger l'ensemble de notre argent, de nos cartes de crédit, de nos transactions en ligne et sur les points de vente), ils comportent de nombreux risques et sont très motivés à les réduire.

Bien que ces normes améliorent certainement la version précédente et contribuent dans une certaine mesure à combler la lacune que nous avons en matière de développement rapide et innovant de fonctionnalités, qui donne également la priorité à la sécurité dans le cadre de l'évaluation globale de la qualité, il est quelque peu décevant de constater que nous avons encore un long chemin à parcourir.

Non, ce n'est pas moi qui dis « ah, crétin ! » à cette initiative. Le fait est que ces nouvelles directives de sécurité ne nous déplacent tout simplement pas assez vers la gauche.

Nous sommes toujours obsédés par les tests (et les tests étaient trop tard).

Un problème flagrant que j'ai découvert avec le cadre des normes de sécurité PCI est sa dépendance apparente à l'égard des tests. Bien entendu, les logiciels doivent encore être testés (et le processus SAST/DAST/IAST a toujours sa place), mais nous tombons toujours dans le même piège et attendons un résultat différent.

Qui écrit ligne après ligne de code pour créer le logiciel que nous connaissons, aimons et en qui nous avons confiance ? Développeurs de logiciels.

Qui a la position peu enviable de tester ce code, que ce soit à l'aide d'outils de numérisation ou d'une révision manuelle du code ? Spécialistes AppSec.

Qu'est-ce que ces spécialistes continuent de découvrir ? Les mêmes bugs qui nous affligent depuis des décennies. Des choses simples que nous savons résoudre depuis des années : Injection SQL, script intersite, faiblesses de la gestion des sessions... c'est comme le jour de la marmotte pour ces gars. Ils ont passé leur temps à trouver et à corriger des violations de code que les développeurs eux-mêmes ont le pouvoir de corriger depuis des années, sauf que la sécurité n'est plus une priorité dans leur processus, surtout à l'ère du développement agile où la fourniture de fonctionnalités est reine et où la sécurité est le Grinch qui vole le processus de création et le triomphe de l'achèvement des projets.

Il ne s'agit pas d'une évaluation négative de l'une ou l'autre des équipes ; les développeurs et les professionnels de la sécurité des applications ont tous deux des tâches extrêmement importantes à accomplir, mais ils continuent de se gêner mutuellement. Cette situation ne fait que perpétuer un SDLC défectueux, dans lequel les développeurs peu sensibilisés à la sécurité opèrent dans une culture de sécurité négative, produisant du code non sécurisé, qui doit ensuite être scanné, évalué et corrigé bien après sa création initiale. AppSec a à peine le temps de résoudre les problèmes réellement complexes, car elle est tellement confrontée à de petits problèmes récurrents qui peuvent tout de même être catastrophiques pour une entreprise si rien n'est fait.

Nous gaspillons du temps, de l'argent et des ressources en permettant aux tests d'être la solution miracle pour détecter les failles de sécurité du code. Et avec des violations de données massives tous les deux jours, cette méthode ne fonctionne évidemment pas de manière optimale, voire pas du tout. Ces nouvelles normes évaluent toujours l'état du produit final (peut-être en partant du principe que tous les développeurs sont conscients de la sécurité, ce qui n'est pas le cas) : un produit déjà créé. Il s'agit de l'étape la plus coûteuse et la plus difficile pour corriger les défauts ; c'est comme si vous construisiez une nouvelle maison de luxe, pour faire appel à une équipe de sécurité chargée de détecter tout danger le jour même de votre emménagement. Si quelque chose ne va pas avec la fondation, imaginez le temps, les coûts et les maux de tête que cela implique de se rendre dans cette zone pour même commencer à résoudre les problèmes. Il est souvent plus facile et moins coûteux de simplement recommencer (et quel processus totalement insatisfaisant pour tous ceux qui ont créé la première version).

Nous devons absolument partir de zéro : en impliquant l'équipe de développement dans les meilleures pratiques de sécurité, en lui donnant les connaissances nécessaires pour coder efficacement et en toute sécurité, tout en créant et en maintenant une culture de sécurité positive dans chaque lieu de travail.

S'agit-il d'une courbe d'apprentissage ? Bon sang oui, ça l'est. Est-ce impossible ? Absolument pas. Et cela ne doit pas être une corvée ennuyeuse. Les méthodes de formation qui font directement appel à la créativité et à la capacité de résolution de problèmes des développeurs ont déjà connu un immense succès dans le secteur bancaire et financier, si L'expérience de Russ Wolfe à Capital One n'est qu'une indication.

Nous sommes toujours à la recherche de l' « état final » parfait.

Si vous examinez les normes de sécurité PCI mises à jour dans le contexte auquel elles sont destinées, par exemple si votre produit financier fini et prêt à être utilisé doit suivre ces meilleures pratiques pour une sécurité et une sûreté optimales, alors elles sont parfaitement correctes. Cependant, à mon avis, chaque entreprise, financière ou autre, aurait les meilleures chances d'atteindre un état final logiciel représentatif à la fois de la qualité des fonctionnalités et d'un haut niveau de sécurité, si seulement elle prenait du recul et réalisait qu'il est beaucoup plus efficace de le faire dès le début du cycle.

Cet état final parfait ? Vous savez, celui qui se produit lorsqu'un produit est scanné, révisé manuellement et qu'il en ressort parfait et sans erreur ? Nous sommes toujours en train de le rechercher. À l'heure actuelle, c'est une licorne.

Pourquoi est-ce si insaisissable ? Il existe un certain nombre de facteurs :

• Les outils de numérisation sont fiables, mais ils ne sont pas toujours efficaces. Les faux positifs sont un sous-produit frustrant et fastidieux de leur utilisation, tout comme le fait que même ensemble, l'analyse DAST/SAST/PCI ne peut tout simplement pas identifier et révéler toutes les vulnérabilités possibles dans la base de code. Bien sûr, ils pourrait vous donnent le feu vert, mais cherchent-ils vraiment tout ? Un attaquant n'a besoin que d'une seule vulnérabilité à exploiter pour accéder à un élément que vous pensez être protégé.
• Les développeurs continuent de commettre les mêmes erreurs. Il n'existe aucune distribution des connaissances entre les développeurs en matière de sécurité et aucune « recette de code sécurisée » (de bons modèles de code sécurisés) bien connue et documentée.
• L'accent n'est pas mis sur la création d'une culture de sécurité positive axée sur la collaboration.
• Les développeurs doivent disposer des bons outils pour intégrer la sécurité dans les produits qu'ils écrivent, sans perturber leurs processus créatifs et leurs méthodologies de développement agiles.

Ces directives constituent une puissante liste de contrôle pour vérifier les normes de sécurité auxquelles les logiciels doivent adhérer, mais le meilleur processus pour amener les logiciels à cet état fait l'objet de débats.

Nous n'avons pas de logiciels non sécurisés parce que nous manquons de scanners, mais nous avons des logiciels non sécurisés parce que les développeurs ne disposent pas d'outils de sécurité faciles à utiliser et à comprendre pour les guider.

Nous sommes dans une période d'évolution en ce moment. La sécurité logicielle en général était facultative pendant de nombreuses années. Aujourd'hui, c'est essentiellement obligatoire, en particulier pour les détenteurs d'informations sensibles (finances, santé, sécurité sociale... vous voyez l'idée).

Le Conseil des normes de sécurité PCI contribue à établir la référence, mais j'adorerais les voir, avec toute l'estime et l'influence qu'ils ont dans le secteur, travailler à l'inclusion de directives pratiques pour les développeurs, en mettant l'accent sur une formation et des outils adéquats et positifs. À l'heure actuelle, aucune pression n'est exercée sur les entreprises pour qu'elles veillent à ce que leurs équipes de développement soient conscientes de la sécurité et de la conformité, et de nombreux développeurs ne comprennent pas l'ampleur de ces petites erreurs faciles à corriger lorsqu'elles sont exploitées par des personnes qui cherchent à nuire.

Comme on peut s'y attendre pour tout ce qui vaut la peine de vivre, il faut vraiment un village pour réellement apporter des changements. Et le changement d'air va (espérons-le) tous nous emporter plus à gauche.