Intégrer la sécurité dans le cycle de développement logiciel, sans pour autant ralentir le projet

Spiria : La sécurité est souvent mise en œuvre après coup, en fin de cycle de développement du logiciel. Que pensez-vous de cette situation ?

Garett Spencley-Sales : La sécurité mérite une attention prioritaire. Elle doit être traitée en amont, alors que notre secteur a tendance à considérer la sécurité comme un problème technique à traiter. On part également du principe que “s’il y a un problème de sécurité, c’est un bogue parce que les développeurs n’ont pas codé correctement”. C’est une façon désastreuse d’envisager la sécurité. Vous vous exposez à toutes sortes de problèmes. Pour aborder la sécurité de manière adéquate, vous devez en amont effectuer une analyse des risques et identifier vos actifs les plus précieux. Qu’il s’agisse de données et d’informations sur les clients, de systèmes de l’entreprise — tout ce que vous protégez, ou tout ce qui pourrait constituer une responsabilité en cas de piratage — vous devez identifier ces éléments avant même de commencer le développement.

La modélisation des risques doit également être terminée avant de commencer, de sorte que si le développement dérape, vous pourrez dire : “Bon, voici comment nous avons anticipé ces lignes de faille ; ces actifs à haut risque pourraient être attaqués et potentiellement compromis, mais voici les fonctionnalités que nous avons incluses afin de les protéger sur le plan technique”.

Et puis, bien sûr, les organisations doivent être conscientes que le risque technologique n’est qu’un des risques qu’elles encourent. Au fil des décennies, nous avons assisté à de nombreuses attaques qui s’appuyaient sur des vulnérabilités sociales plutôt que techniques. Aujourd’hui encore, les campagnes par hameçonnage, qui sont des attaques sociales et non des attaques techniques, sont l’un des moyens les plus courants de compromettre un système.

Il est clair que le souci de la sécurité commence bien avant l’écriture de la moindre ligne de code. Les considérations vont du choix des outils et des frameworks à la définition des exigences, non ?

Garett : Bien sûr. Vous devez considérer la sécurité comme une fonctionnalité essentielle. Vous ne pouvez pas simplement supposer que le système sera intrinsèquement sûr. Ce que signifie être sûr varie d’un projet à l’autre. Cela dépend des risques et de ce qui doit être protégé. Que signifie la sécurité pour votre système et pour vos données ? Il n’y a pas de recette toute faite, car chaque projet a des exigences différentes. Lorsque vous comprenez quelles sont vos priorités, vous pouvez traiter la sécurité comme une fonctionnalité et vous assurer qu’elle est prise en compte dès le départ. Ensuite, les outils, les processus et les systèmes que vous utiliserez seront les bons pour résoudre ces problèmes particuliers.

Intégrer la sécurité dans le cycle de développement logiciel sans ralentir le projet est une tâche chronophage qui a son propre coût. N’avez-vous pas besoin de renforts pour respecter les délais ? Cela ne représente-t-il pas un investissement plus important ?

Garett : Une bonne sécurité a inévitablement un coût. Développer correctement des fonctionnalités et des logiciels coûte de l’argent. Mais si nous traitons la sécurité comme une réflexion après coup et les problèmes comme des bogues, les coûts seront encore plus élevés.

En matière de sécurité, les bogues sont particulièrement dangereux, car ils représentent une énorme responsabilité pour les entreprises, qui peuvent être confrontées à des amendes réglementaires, à des poursuites pour atteinte à la vie privée si le statut des utilisateurs est compromis, ou à une perte de marché en raison d’une baisse du niveau de confiance dans leur service. La sécurité a de nombreuses implications financières pour une entreprise.

Pour éviter que les projets ne se grippent, la meilleure solution consiste à traiter la sécurité comme une fonctionnalité dès le départ. De cette façon, vous vous assurez que ces types de bogues sont détectés à un stade précoce, lorsqu’ils peuvent être traités à moindre coût, rapidement et de manière efficace, au lieu de développer un système non sécurisé parce que personne n’a estimé que la sécurité était un prérequis. Vous ne voulez pas avoir à dire après coup : “Oh non, nous devons faire quelque chose pour résoudre notre problème de sécurité, mais nous ne pouvons pas le faire parce que le système n’a pas été conçu pour réaliser ce dont nous avons besoin”.

La réponse est donc malheureusement oui, vous devez investir un peu plus au départ. Mais la raison économique pour laquelle vous devez faire cet investissement est que cela vous épargnera potentiellement un montant considérable de responsabilité. Et si vous voulez faire une analyse coûts-avantages, faites cette évaluation des risques dès le départ. Identifiez ce qui a le plus de valeur et ce que pourraient être vos responsabilités, car si vous ne le faites pas, vous prenez un risque énorme sans même savoir que vous êtes en danger. C’est ce que nous constatons actuellement avec toutes ces attaques de rançongiciels, ces intrusions, etc.

Si vous ne vous occupez pas continuellement de l’aspect sécurité, vous accumulez une sorte de dette technique, n’est-ce pas ? Peut-on parler de “dette de sécurité” et des problèmes qu’une telle dette engendre ?

Garett : On peut considérer cela comme un type de dette technique. Mais le hasard entre malheureusement en jeu. Par pure chance, certaines entreprises ne se retrouvent jamais visées. Elles ne souffrent pas de ces responsabilités et ne paient pas le coût de la dette technique. Mais si vous êtes victime d’une intrusion, s’il existe une vulnérabilité au niveau technique et que vous ne la corrigez qu’après coup, d’autres failles de sécurité dans votre système seront également mises en évidence. Il ne serait pas inapproprié de considérer cela comme une forme de dette qui finit par arriver à échéance.

Afin de minimiser cette dette, diriez-vous qu’il est préférable d’avoir plusieurs ralentissements mineurs pendant le développement qu’un seul ralentissement majeur à la toute fin ?

Garett : Eh bien, le sujet des ralentissements est intéressant, car je pense qu’il y a une attente implicite que le système soit sécurisé. Nous nous attendons à la sécurité parce que nous reconnaissons que nous avons affaire à un risque. Qu’il s’agisse d’une entreprise de produits ou d’un client qui passe un contrat avec une agence telle que Spiria, nul n’a l’intention d’acheter un logiciel non sécurisé. Je dirais que la planification de la sécurité n’est pas un ralentissement.

La sécurité est une fonctionnalité, qu’elle soit traitée comme telle ou non. La chose intelligente à faire est de la traiter comme telle, et de l’intégrer dans le coût de développement des fonctionnalités du logiciel. Personne n’a besoin d’un système non sécurisé qui coûtera à l’entreprise en termes de responsabilité, ou aux clients, ce qui se répercute également sur l’entreprise.

Tout cela est bien beau, mais dans la pratique, comment cela fonctionne-t-il ? Vous êtes un développeur senior avec beaucoup d’expérience, vous avez connu de nombreux projets et équipes. Les choses se passent-elles toujours de cette façon ? La sécurité est-elle réellement intégrée dans le processus de développement ?

Garett : Pour être honnête, d’après mes observations et mon expérience, la sécurité est trop souvent ignorée. Elle n’entre tout simplement pas dans les discussions. Les entreprises se pressent pour mettre sur le marché des fonctionnalités brillantes qui devraient leur rapporter beaucoup d’argent, alors que la sécurité n’est jamais mentionnée. Ou si elle l’est, elle a tendance à être soulevée par des développeurs qui comprennent que “Hé, vous avez des risques ici. Cette base de données contient une quantité incroyable de données et d’informations sur les clients, mais il y a en fait très peu de contrôles d’accès et de mesures en place pour les protéger. “La réponse typique est “C’est un très bon point” et “Nous vous assurons que nous le prenons au sérieux”, mais ce n’est pas une priorité du moment. C’est quelque chose qu’ils veulent faire un jour, mais ce jour n’arrive jamais.

Ce n’est pas une surprise pour moi, car nous, les développeurs et ingénieurs, soulevons ces préoccupations depuis que je suis dans le secteur, et maintenant j’en suis à “je vous l’avais dit”. Nous avions prédit qu’il y aurait davantage d’attaques à grande échelle, de fuites de données et de brèches, comme les attaques par rançongiciels qui font l’actualité.

Pardonnez mon franc-parler, mais je ne pense pas que les choses s’amélioreront vraiment tant que les chefs d’entreprise ne seront pas imputables, voire envoyés en prison. Il n’y a tout simplement pas de conséquences. C’est une question d’évaluation des risques. Les managers, les chefs d’entreprise et les cadres qui ne sont pas particulièrement férus de technologie pensent qu’il faut une sorte de génie comme on n’en voit que dans les films pour compromettre un système. Ils pensent : “Cela ne peut pas nous arriver”. Mais toute personne qui ne prend pas cela au sérieux met le système en danger. Tout système peut être violé si quelqu’un est déterminé à y pénétrer. Si vous omettez l’évaluation des risques, vous ne savez pas ce qui est vulnérable et ce que vous devez protéger, et tout est exposé.

Nous constatons donc que l’avantage d’une mise sur le marché rapide pour offrir aux utilisateurs de nouvelles fonctionnalités l’emporte sur le risque de sanctions liées à des intrusions dans les bases de données, par exemple…

Garett : C’est loin des yeux, loin du cœur. Je pense qu’elle n’est même pas prise en compte dès le début, alors que c’est justement là qu’elle devrait être mise en avant. La sécurité devrait être incluse comme une fonctionnalité. Les clients partent du principe qu’ils achètent un système sécurisé, mais la sécurité n’est jamais mentionnée pendant la phase de découverte ou de planification. On ne nous donne jamais de documents qui décrivent l’évaluation des risques et la modélisation des menaces, et on ne nous demande jamais de faire cette modélisation. Je n’ai jamais vu de rapport disant : “Voici la modélisation des menaces, l’évaluation des risques, nos priorités, donc voici ce que nous devons mettre en place.” Les agences de conseil en sécurité sont engagées pour faire cela dans certains cas, et je l’ai fait une fois lorsque j’étais sur un projet pour une grande banque américaine qui avait ses propres systèmes en place.

De plus, j’ai récemment écouté la conférence de quelqu’un qui est engagé par des banques pour faire des évaluations de la sécurité physique. Elles l’engagent pour qu’il essaie délibérément de voler la banque, afin de voir ce que la banque ferait en cas d’attaque. Il a constaté que même la sécurité physique des banques est beaucoup plus faible que ce à quoi on pourrait s’attendre. Il affirme que si elles ne peuvent pas assurer correctement la sécurité physique, elles ne peuvent pas non plus assurer la sécurité numérique. Si la prise en compte de la sécurité n’est pas jugée importante, c’est la seule imputabilité qui devient une incitation.

On suppose que les développeurs écriront un code sécurisé, mais les politiques de contrôle de l’accès aux serveurs de bases de données n’ont pas grand-chose à voir avec le code. Il s’agit là d’un vecteur d’attaque potentiel ; il y a ensuite les vecteurs d’attaque sociaux, les vecteurs d’attaque de l’infrastructure… il existe de nombreuses façons de compromettre les systèmes. Cela varie selon les projets et les systèmes. Vous ne pouvez pas procéder à la planification en vous basant uniquement sur des hypothèses, car vous n’y arriverez pas, vous ne saurez pas quels sont les risques.

Avez-vous des recommandations spécifiques ?

Garett : Cela dépend du projet et du système. Je vais avoir l’air d’un disque rayé, mais la première recommandation est de procéder à la modélisation des menaces et à l’évaluation des risques, car sans cela, vous ne savez pas quelles sont vos exigences en matière de maintenance.

Certaines organisations ont procédé à une évaluation des risques dès le départ pour finalement décider que les systèmes existants ne représentaient pas un grand risque. Le pire des scénarios n’est pas si terrible si quelqu’un les attaque. Ces anciens systèmes peuvent être laissés en l’état, car ils ne risquent pas d’être sérieusement affectés, alors qu’il y a peut-être d’autres systèmes au sein de l’entreprise et du réseau qui sont beaucoup plus prioritaires et qui méritent toute l’attention.

L’évaluation des risques est également une mesure d’économie, car les entreprises peuvent l’utiliser pour définir leurs responsabilités et hiérarchiser ensuite leurs efforts de maintenance en conséquence.

Pour revenir à la question, qui était de savoir comment intégrer la sécurité dans le cycle de développement des logiciels sans ralentir le projet, est-ce un cercle vicieux ? Si cela demande plus de temps, de personnel et de maintenance, est-ce que nous tournons en rond ? Ou la solution est-elle de le faire en amont afin de pouvoir planifier le nombre adéquat de personnes et un calendrier réaliste, pour que tout se passe bien ?

Garett : Si l’on s’attend à ce que ce logiciel soit sécurisé, la question devient “Comment écrire un logiciel pleinement fonctionnel sans ralentir le cycle de développement ?” Et c’est le problème fondamental auquel tout chef de projet est confronté, qu’il s’agisse de sécurité ou d’autre chose. Comment planifier le développement d’un logiciel qui fonctionne correctement, et comment le développer selon un calendrier serré sans introduire de retards ? Vous y parvenez en planifiant la sécurité dès le départ. Si vous la traitez comme n’importe quelle autre fonctionnalité, si vous identifiez les exigences de sécurité importantes, vous pouvez alors planifier leur développement au lieu de revenir en arrière pour réparer un système non sécurisé.

Il est beaucoup plus efficace et rentable de faire ce petit travail en amont et de l’intégrer dans le cadre de la planification et du processus. Si vous le remettez à plus tard, vous ne faites que prendre vos désirs pour des réalités, en espérant que la sécurisation de votre système ne sera pas trop difficile, alors que vous n’avez même pas encore identifié ce que la sécurité signifie pour votre projet et votre système.

Merci beaucoup pour votre temps, Garett. Vos commentaires étaient sans détours et instructifs. Avez-vous quelque chose à ajouter ?

Garett : Je résumerai les principales recommandations et les points à retenir. Faites une évaluation des risques en amont pour identifier vos actifs de grande valeur et vos responsabilités potentielles, considérez la sécurité comme une fonctionnalité et ajoutez-la dans la planification du projet. Cela ne sera pas nécessairement très coûteux. En fait, il est probablement beaucoup moins cher de faire cela en premier. Développez en pensant à la sécurité dès le départ, plutôt que d’essayer de sécuriser un système non sécurisé après coup.

Les organisations devraient commencer à considérer les problèmes de sécurité comme une question de responsabilité potentielle. De deux choses l’une : soit les primes d’assurance élevées feront partie des coûts d’exploitation normaux, soit les entreprises prendront enfin des mesures pour assurer la sécurité en la traitant comme une priorité dès le départ.