Les nouvelles directives du PCI Security Standards Council : vont-elles assez loin dans l'intégration de la sécurité dès la conception ?

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

Cette année, le PCI Security Standards Council a publié un tout nouvel ensemble de directives de sécurité logicielle dans le cadre de son PCI Software Security Framework. Cette mise à jour vise à aligner les meilleures pratiques de sécurité logicielle sur le développement moderne. C'est une initiative fantastique qui reconnaît l'évolution de ce processus, nécessitant une remise en question des normes de sécurité établies bien avant que la majeure partie de nos vies ne soit rapidement numérisée.

C'est la preuve évidente que notre industrie s'approprie davantage l'idée de directives adaptables – qui évoluent avec nos besoins changeants – ainsi que les exigences d'un paysage 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é. Naturellement, le PCI Security Standards Council agissant en tant qu'organisme de réglementation au sein du secteur bancaire et financier (c'est-à-dire en définissant les normes de sécurité pour les logiciels auxquels nous confions notre argent, nos cartes de crédit, nos transactions en ligne et nos points de vente), il porte une part de risque importante et a une motivation immense à le réduire.

Bien que ces normes améliorent certainement la version précédente et contribuent à combler les lacunes en matière de développement rapide et innovant de fonctionnalités qui privilégie également la sécurité dans le cadre de son évaluation globale de la qualité, il est quelque peu décevant de constater qu'il reste encore beaucoup à faire.

Non, ce n'est pas une critique négative de ma part envers cette initiative. Le fait est que ces nouvelles directives de sécurité ne nous font tout simplement pas assez avancer vers le « shift left ».

Nous sommes toujours focalisés sur les tests (et nous testons trop tard).

Un problème flagrant que j'ai relevé dans le PCI Security Standards Framework est sa dépendance apparente vis-à-vis des tests. Bien sûr, les logiciels doivent toujours être testés (et les processus SAST/DAST/IAST ont toujours leur place), mais nous retombons dans le même piège en espérant 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 occupe la position peu enviable de tester ce code, que ce soit avec des outils d'analyse ou par une revue de code manuelle ? Les spécialistes de la sécurité applicative (AppSec).

Que continuent de découvrir ces spécialistes ? Les mêmes bugs qui nous tourmentent depuis des décennies. Des choses simples que nous savons corriger depuis des années : injections SQL, cross-site scripting, failles de gestion de session... C'est un éternel recommencement pour eux. Ils passent leur temps à trouver et à corriger des violations de code que les développeurs eux-mêmes auraient pu corriger depuis longtemps, sauf que la sécurité n'a pas été érigée en priorité dans leur processus, surtout à l'ère du développement agile où la livraison de fonctionnalités est reine, et où la sécurité est le Grinch qui vient gâcher le processus créatif et le triomphe de l'achèvement du projet.

Ce n'est pas une évaluation négative de l'une ou l'autre équipe ; les développeurs et les professionnels de l'AppSec ont tous deux des rôles extrêmement importants à jouer, mais ils continuent de se gêner mutuellement. Cette situation ne fait que perpétuer un cycle de vie de développement logiciel (SDLC) défaillant, où des 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 analysé, évalué et corrigé bien après avoir été initialement écrit. L'AppSec a à peine le temps de résoudre les problèmes vraiment complexes, car ils sont trop occupés par les petits problèmes récurrents qui pourraient pourtant entraîner un désastre pour une entreprise s'ils ne sont pas contrôlés.

Nous gaspillons du temps, de l'argent et des ressources en laissant les tests servir de filet de sécurité pour les failles de code. Et avec les violations de données massives qui surviennent tous les deux jours, cette méthode ne fonctionne manifestement pas de manière optimale, voire pas du tout. Ces nouvelles normes évaluent toujours l'état du 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 failles ; c'est comme construire une belle maison neuve et faire venir une équipe de sécurité pour vérifier les risques le jour même de votre emménagement. Si quelque chose ne va pas avec les fondations, imaginez le temps, le coût et le casse-tête total pour accéder à cette zone et commencer à résoudre les problèmes. Il est souvent plus facile et moins coûteux de tout recommencer (et quel processus insatisfaisant pour tous ceux qui ont construit la première version).

Nous devons absolument travailler dès la base : en impliquant l'équipe de développement dans les meilleures pratiques de sécurité, en leur donnant les connaissances nécessaires pour coder efficacement de manière sécurisée, tout en créant et en maintenant une culture de sécurité positive sur chaque lieu de travail.

Est-ce une courbe d'apprentissage ? Absolument. Est-ce impossible ? Certainement pas. Et cela n'a pas besoin d'être une corvée ennuyeuse. Les méthodes de formation qui font appel directement aux traits créatifs et 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'on en croit l'expérience de Russ Wolfe 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 sont destinées, c'est-à-dire que votre produit financier fini et prêt à l'emploi doit suivre 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 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 survient lorsqu'un produit est analysé, examiné manuellement et qu'il en ressort parfait et sans erreur ? Nous sommes toujours à sa recherche. À l'heure actuelle, c'est une licorne.

Pourquoi est-il si insaisissable ? Il y a plusieurs facteurs :

• Les outils d'analyse sont largement utilisés, mais ils ne sont pas toujours efficaces. Les faux positifs sont une perte de temps frustrante, tout comme le fait que, même combinés, les outils DAST/SAST/PCI ne peuvent tout simplement pas identifier toutes les vulnérabilités d'une base de code. Certes, ils peuvent vous donner le feu vert, mais examinent-ils vraiment tout ? Un attaquant n'a besoin que d'une seule faille pour accéder à ce que vous croyez protégé.
• Les développeurs continuent de commettre les mêmes erreurs. Il n'y a pas de partage de connaissances en matière de sécurité, ni de « recettes de code sécurisé » (modèles de code fiables) bien connues et documentées.
• L'accent n'est pas mis sur la création d'une culture de sécurité collaborative et positive.
• Les développeurs doivent disposer des bons outils pour intégrer la sécurité dès la conception, sans entraver leur créativité ni leurs méthodes de développement agile.

Ces directives constituent une liste de contrôle efficace pour les normes de sécurité auxquelles les logiciels doivent se conformer, mais la meilleure méthode pour y parvenir reste sujette à débat.

Nos logiciels ne sont pas vulnérables par manque de scanners, mais parce que les développeurs ne disposent pas d'outils de sécurité simples et intuitifs pour les guider.

Nous vivons une période de transition. Pendant longtemps, la sécurité logicielle était facultative. Aujourd'hui, elle est devenue essentielle, surtout pour les détenteurs d'informations sensibles (finance, santé, sécurité sociale, etc.).

Le PCI Security Standards Council contribue à définir des références, mais j'aimerais qu'il utilise son influence pour promouvoir des directives pratiques destinées aux développeurs, en mettant l'accent sur une formation et des outils adaptés. Actuellement, aucune pression n'est exercée sur les entreprises pour sensibiliser leurs équipes de développement, et beaucoup de développeurs sous-estiment l'impact de petites erreurs facilement corrigibles lorsqu'elles sont exploitées par des acteurs malveillants.

Comme pour tout ce qui en vaut la peine, il faut tout un écosystème pour susciter un véritable changement. Et ce vent de changement va, espérons-le, nous pousser tous vers une approche plus proactive.