Les lignes directrices révisées du Conseil des normes de sécurité PCI : Sont-elles assez à gauche ?

Une version de cet article a été publiée dans Digital Transactions Magazine.

Cette année, le Conseil des normes de sécurité du PCI a publié un tout nouvel ensemble de lignes directrices sur la sécurité des logiciels dans le cadre du PCI Software Security Framework. Cette mise à jour vise à aligner les meilleures pratiques en matière de sécurité des logiciels sur le développement moderne des logiciels. Il s'agit d'une initiative fantastique qui reconnaît la façon dont ce processus a évolué au fil du temps, ce qui nécessite de repenser les normes de sécurité qui ont été établies bien avant que la majorité de nos vies ne deviennent rapidement numérisées.

Il s'agit d'une preuve évidente que notre industrie s'engage plus étroitement dans l'idée de lignes directrices adaptables - qui évoluent avec nos besoins changeants - ainsi qu'avec les exigences d'un paysage de cybersécurité qui pourrait très rapidement échapper à tout contrôle si nous continuons à être laxistes 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 (c'est-à-dire définissant les normes de sécurité des logiciels auxquels nous faisons confiance pour protéger notre argent, nos cartes de crédit, nos transactions en ligne et nos points de vente), il est porteur d'un risque important et a une motivation énorme pour le réduire.

Bien que ces normes améliorent certainement la version précédente et comblent en partie les lacunes en matière de développement rapide et innovant de fonctionnalités, tout en accordant la priorité à la sécurité dans le cadre de la qualité globale assessment, il est quelque peu décevant de constater qu'il reste encore beaucoup de chemin à parcourir.

Non, ce n'est pas moi qui donne un "bah, humbug !" à cette initiative. Le fait est que ces nouvelles lignes directrices en matière de sécurité ne nous rapprochent pas suffisamment de la gauche.

Nous étions toujours obnubilés par les tests (et nous les avons effectués trop tard).

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

Qui écrit ligne après ligne de code pour créer les logiciels que nous connaissons, aimons et auxquels nous faisons confiance ? Les développeurs de logiciels.

À qui incombe la tâche peu enviable de tester ce code, que ce soit à l'aide d'outils d'analyse ou d'un examen manuel du code ? Les spécialistes de l'AppSec.

Que découvrent toujours ces spécialistes ? Les mêmes bogues qui nous affligent depuis des décennies. Des problèmes simples que nous savons corriger depuis des années : Injection SQL, scripts intersites, faiblesses dans la gestion des sessions... C'est un peu le jour de la marmotte pour ces types. Ils ont passé leur temps à trouver et à corriger des violations de code que les développeurs eux-mêmes avaient le pouvoir de corriger depuis des années, sauf que la sécurité n'est pas devenue une priorité dans leur processus " surtout maintenant, à l'ère du développement agile où la livraison de fonctionnalités est reine, et où la sécurité est le Grinch qui vole le processus créatif et le triomphe de l'achèvement du projet ".

Il ne s'agit pas d'une critique de l'une ou l'autre équipe ( assessment ) ; les développeurs et les professionnels de l'AppSec ont tous deux des tâches extrêmement importantes à accomplir, mais ils continuent à se mettre des bâtons dans les roues. Cette situation ne fait que perpétuer un SDLC défectueux, où les développeurs peu sensibilisés à la sécurité opèrent dans une culture de sécurité négative, produisant un code non sécurisé, qui doit ensuite être analysé, évalué et corrigé bien après qu'il a été initialement écrit. L'AppSec a à peine le temps de résoudre les problèmes vraiment complexes, parce qu'il est tellement pris par les petits problèmes récurrents qui pourraient toujours entraîner un désastre pour une entreprise s'ils n'étaient pas contrôlés.

Nous perdons du temps, de l'argent et des ressources en permettant aux tests d'être le fourre-tout des faiblesses de sécurité dans le code. Et avec les violations massives de données qui ont lieu tous les deux jours, il est évident que cette méthode ne fonctionne pas de manière optimale, voire pas du tout. Ces nouvelles normes évaluent toujours l'état d'un produit final (peut-être en supposant que tous les développeurs sont sensibilisés à la sécurité, ce qui n'est pas le cas), c'est-à-dire un produit déjà construit. C'est l'étape la plus coûteuse et la plus difficile pour corriger les défauts ; c'est comme si vous construisiez une belle maison neuve et que vous fassiez venir une équipe de sécurité pour vérifier qu'il n'y a pas de danger le jour même où vous emménagez. Si quelque chose ne va pas au niveau des fondations, imaginez le temps, le coût et le casse-tête que cela représente de se rendre sur place pour commencer à résoudre les problèmes. Il est souvent plus facile et moins coûteux de simplement recommencer (et quel processus insatisfaisant pour tous ceux qui ont construit la première version).

Nous devons absolument travailler à partir de la base : en faisant en sorte que l'équipe de développement s'engage dans les meilleures pratiques de sécurité, en leur donnant les connaissances nécessaires pour coder efficacement en toute sécurité, en plus de créer et de maintenir une culture positive de la sécurité sur chaque lieu de travail.

Est-ce une courbe d'apprentissage ? Oui, c'est vrai. Est-ce impossible ? Certainement pas. Et ce n'est pas forcément une corvée ennuyeuse. Les méthodes de formation qui font directement appel à la créativité des développeurs et à leur capacité à résoudre des problèmes ont déjà connu un immense succès dans le secteur bancaire et financier, si l'on en croit l'expérience de Russ Wolfes chez Capital One.

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

Si vous considérez les normes de sécurité PCI mises à jour dans le contexte pour lequel elles ont été conçues, c'est-à-dire que votre produit financier fini et prêt à l'emploi doit respecter ces meilleures pratiques pour une sécurité et une sûreté optimales, alors elles sont tout à fait correctes. Cependant, à mon avis, chaque entreprise - financière ou autre - aurait les meilleures chances d'atteindre un état final du logiciel qui soit représentatif à la fois de la qualité des fonctionnalités et d'un niveau élevé 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.

L'état final parfait ? Vous savez, celui qui se produit lorsqu'un produit est scanné, contrôlé manuellement et qu'il en ressort parfait et sans erreur ? Nous sommes toujours à sa recherche. Pour l'instant, il s'agit d'une licorne.

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

• On se fie aux outils d'analyse, mais ils ne sont pas toujours efficaces. Les faux positifs sont un sous-produit frustrant et chronophage de leur utilisation, tout comme le fait que même ensemble, les analyses DAST/SAST/PCI ne peuvent tout simplement pas identifier et révéler toutes les vulnérabilités possibles dans la base de code. Certes, ils peuvent vous donner le feu vert, mais cherchent-ils vraiment tout ? Un attaquant n'a besoin que d'une seule vulnérabilité à exploiter pour accéder à quelque chose que vous pensez être protégé.
• Les développeurs continuent de commettre les mêmes erreurs. Il n'y a pas de répartition des connaissances entre les développeurs en matière de sécurité et il n'y a pas de "recettes de code sécurisé" (de bons modèles de code sécurisé) qui soient connues et documentées.
• L'accent n'est pas mis sur la mise en place d'une culture de sécurité positive et collaborative.
• 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 lignes directrices constituent une puissante liste de vérification des normes de sécurité auxquelles les logiciels doivent se conformer, mais le meilleur processus pour amener les logiciels à cet état est sujet à débat.

Ce n'est pas parce que nous manquons de scanners que nos logiciels ne sont pas sûrs, mais parce que les développeurs ne disposent pas d'outils de sécurité faciles à utiliser et à comprendre pour les guider.

Nous vivons actuellement une période d'évolution. Pendant de nombreuses années, la sécurité des logiciels en général était facultative. Aujourd'hui, elle est essentiellement obligatoire - en particulier pour les détenteurs d'informations sensibles (financières, médicales, sécurité sociale... vous voyez l'idée).

Le Conseil des normes de sécurité PCI contribue à établir la référence, mais j'aimerais qu'il s'efforce - avec toute l'estime et l'influence qu'il a dans l'industrie - d'inclure des lignes directrices 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 organisations pour qu'elles veillent à ce que leurs équipes de développement soient sensibilisées à la sécurité et respectent les normes, et de nombreux développeurs ne comprennent pas l'ampleur de ces petites erreurs faciles à corriger lorsqu'elles sont exploitées par ceux qui cherchent à faire du tort à autrui.

Comme c'est le cas pour tout ce qui vaut la peine d'être vécu, il faut vraiment un village pour mettre en œuvre un véritable changement. Et le changement dans l'air va (espérons-le) nous entraîner plus loin vers la gauche.