Introduction
Dans un monde où la nuisance à la sécurité de l’information évolue à un rythme effréné, la sécurité applicative devient pour moi une priorité incontournable pour les entreprises souhaitant protéger leurs données et leurs systèmes d’information. Le principe de Shift-Left, qui consiste à intégrer la sécurité dès les premières étapes du cycle de développement logiciel, offre une approche proactive pour renforcer la sécurité des applications. En adoptant cette stratégie, les organisations peuvent non seulement identifier et corriger les vulnérabilités plus tôt, mais aussi réduire les coûts associés aux failles de sécurité découvertes tardivement. Cet article explore comment le principe de Shift-Left peut transformer votre approche de la sécurité applicative et renforcer votre politique de sécurité globale.
Pour contextualiser notre sujet, revenons aux origines et définissons la sécurité informatique.
L'objectif de l'informatique est la gestion automatique de l'information et la sécurité informatique implique la sécurité de l'information c'est-à-dire le maintien de la confidentialité, intégrité et la disponibilité de ces informations. Ces trois points sont les piliers de la sécurité informatique. Le principe de confidentialité stipule que l’information ne doit être accessible qu’aux personnes autorisées, l’intégrité est la garantie que l’information ne soit pas corrompue, dégradée ou modifiée et la disponibilité est l’assurance que l’information soit accessible aux personnes autorisées au moment où elles en ont besoin.
La sécurité de l’information n’est pas figée, elle est plutôt le résultat d’un processus d’amélioration continue, c’est-à-dire qui évolue à travers différentes phases et se perfectionne tout le long. Il s’agit d’un voyage et pas une destination. Bien qu’il y ait de nombreuses étapes dans ce voyage nous pouvons néanmoins les regrouper dans trois grandes phases : la prévention, la détection et la réponse (incluant la remédiation) (LaPiedra, 2002).
La prévention
La prévention consiste à se préparer en amont pour se prévenir de futurs incidents. Notre objectif est de protéger l’information de toutes dégradations, altération ou accès non autorisé. Pour cela la phase de prévention implique :
La définition de politiques de sécurité : savoir ce qui doit être protégé en décrivant des règles claires, concises et précises.
La mise en place d’un programme de sensibilisation à la sécurité de l’information pour éduquer toute l’équipe aux bonnes pratiques de sécurité et aux risques que court l’organisation
L’implémentation des contrôles d’accès : restreindre l’accès et n’autoriser que les permissions nécessaires à la fonction de l’utilisateur. Identifier correctement les principes d’identification, authentification et autorisation dans chaque processus d’accès.
La détection
Se protéger est idéal mais détecter est indispensable. Tout système d’information est vulnérable et sujet à compromission. Keith Alexander, général de la United States Army et directeur de la National Security Agency (NSA) affirme durant la U.S. Chamber of Commerce Cybersecurity Summit en 2012 :
Either you know you’ve been hacked, or you’ve been hacked and you don’t know you’ve been hacked
que nous pouvons traduire par : soit vous savez que vous avez été attaqué soit vous avez été attaqué mais vous ne le savez pas encore. En effet, peu importe le niveau de protection d’un système d’information, ce n’est qu’une question de temps avant qu’il ne soit compromis par un acteur ayant assez de compétences et de motivation. D’où l’importance d’un système de détection de d’intrusion et de compromission (IDS). Le facteur le plus crucial dans une stratégie de détection est le temps moyen entre l'infection et la détection ajoutée à la précision de la notification en cas de compromission : une détection plus rapide et une notification plus précise amélioreront l'efficacité du processus d'investigation et de réponse en cas d'incident.
La réponse
La réponse consiste à réagir face à l’annonce d’un nouvel incident ou d’une compromission. La phase de réponse donne toute sa valeur à une détection de qualité. Néanmoins, une bonne réponse ne s’improvise pas. Le stress que nous ressentons lors d’une attaque ne permet pas de prendre de bonnes décisions. Il existe des méthodologies de réponse à incident permettant d’adapter son plan de réponse à son métier et à l’incident subit. Celui du NIST (National Institute of Standards and Technology) et du SANS se distingue dans le schéma suivant.
Nous commençons toujours par l’étape de préparation qui se déroule en général avant l’arrivée de l’incident. La détection arrive ensuite, nous devons identifier et analyser le type d’attaque que nous subissons, son origine et idéalement l’auteur de l’attaque. Après cela le confinement vise à réduire l’impact de l’incident, l’éradication à supprimer la menace du système d’information et la reprise à remettre le système en condition opérationnelle. Enfin la dernière étape consiste toujours à faire une revue de la gestion de l’incident et sert à améliorer le processus de réponse en lui-même.
Une bonne réponse à incident nécessite un processus rapide qui aboutit à une remédiation dans un court laps de temps. Au-delà d’une succession optimale des étapes susmentionnées, nous devons noter que la vitesse de ce processus passe par une remontée efficace des informations nécessaire à l’équipe lors de la détection même l’incident. Le SANS précise que
The process of detecting malicious or accidental misuse of resources is much more than sounding an alarm. Also, responding to an incident is much more than just showing up. An organization to be successful must know what to detect and once alerted know how to effectively coordinate resources for a response.
Pour poursuivre, une bonne détection est de même liée à une préparation et une prévention correcte. Là se trouvent les principaux maux de la sécurité informatique :
Ils prennent du temps
Ils nécessitent beaucoup de bande passante (de charge de travail, de personnes qualifiées)
Ils sont coûteux en ressources et en argent
Cela décourage certaines organisations à entamer le voyage dont nous parlons. Comment donc faire en sorte de corriger ces barrières tout en facilitant l’adoption des pratiques de sécurité ? Cela commence par la définition d’un programme ou et une politique de sécurité établi par un responsable de la sécurité de l’information. Après avoir fait l’état des lieux et défini les politiques nécessaires et les actions à prendre pour commencer notre voyage, ce dernier doit à un certain niveau de maturité inclure une phase d’automatisation des processus de sécurité au sein du cycle de développement mais également dans les tâches quotidiennes de l’équipe en charge de la sécurité.
Les processus de sécurité automatisées
Dans un monde idéal, nous n'aurions pas à répondre à des incidents ou, du moins, nous n'aurions qu'à traiter des incidents dignes de notre attention. L'une des solutions pour parvenir à ce monde idéal serait d'automatiser les processus répétitifs.
Le docteur Brian Carrier définit l’automatisation en disant :
Automation is when the computer does the next step without human intervention1
De ce fait l’automatisation des processus de sécurité permettrait :
Une réduction des tâches manuelles de bas niveau : pour libérer du temps à l'équipe sécurité et lui permettre de se concentrer sur les tâches nécessitant plus d'attention.
Une réponse rapide aux incidents : pour réduire le MTTD (Mean Time To Detect — temps moyen de détection) et le MTTR (Mean Time To Repair — temps moyen de réparation) comme expliqué plus haut.
Une standardisation des processus : car une plateforme automatisée suivra toujours les règles que nous lui donnons, éliminant ainsi les erreurs d'opérations manuelles et apportant de la cohérence.
Un gain de productivité général pour l'équipe.
Cependant, l'automatisation n'est pas l'unique option. Les autres solutions consistent à optimiser la réalisation des processus en améliorant ceux qui en dépendent. Par exemple, nous pouvons limiter le temps de réponse à un incident en maximisant les indicateurs que nous remontent nos systèmes de détection d'intrusion (IDS). Nous pouvons également élever le niveau de notre détection en connaissant profondément notre système d'information. En effet, une connaissance parfaite de son SI et de ses services permet de configurer finement ses outils de détection et de remonter les événements. En continuant avec cette idée, on éviterait le nombre d'événements remontés en prévenant le nombre de vulnérabilités dans nos applications, réduisant ainsi notre surface d'attaque et, par transitivité, le risque auquel nous sommes soumis. D'où l'importance de la phase de prévention.
Une grosse partie de la prévention est de faire en sorte que les applications et logiciels que nous sortons soient sécurisés, nous arrivons donc à la sécurisation du cycle de développement.
Le cycle de développement sécurisé
Tenant ses origines des années 1960, la sécurité dans le SDLC — Software Development Lifecycle — et toutes les méthodologies s’en inspirant, quand elle est incluse, se positionne comme un jalon la gestion de projet entre certaines étapes du SDLC. Une porte à franchir pour passer à l’étape suivante. Nous avons généralement dans les équipes soucieuses de la sécurité de leur produit
La revue des spécifications et de la conception du produit : après l’étape d’identification
La revue de l’architecture : après l’étape de conception
La revue du code : après l’étape de création ou développement
Les tests de sécurité : après l’étape des tests.
Laura Bell précise dans son livre Agile Application Security que l’idée derrière ces jalons soit de réaliser des livrables en lot car
It is predicated on the old rule that the earlier a defect is caught, the cheaper it is to fix; therefore we need to do a security review as early as possible to catch security defects before they get too far. (Bell, Brunton-Spall, Smith, & Bird, 2017, p. 79)
Sauf que notre problématique persiste. Effectivement, les processus et pratiques de sécurité telles que nous les connaissons ont été conçues pour une gestion de projet en cascade où les besoins sont décidés bien avant et pas pour des petites équipes évoluant rapidement et de manière itérative.
En optant pour une approche Agile, la solution ne consisterait pas à résoudre tous les problèmes de sécurité avant la mise en production, mais plutôt à se concentrer sur la réduction du coût de correction, en rendant les futurs changements sans risque et plus facilement réalisables.
We want to reach a fine balance between finding and fixing (or better, preventing) security problems up front where it makes sense to do so, and making sure that we can fix them quickly and cheaply later if something gets by. (Bell, Brunton-Spall, Smith, & Bird, 2017, p. 79)
La première approche pour répondre à cela est l’apparition du principe Shift Left2, c’est-à-dire inclure des tests de sécurité à chaque étape du SDLC. Nous obtenons ce dont les experts appellent le SSDLC — Secure Development Lifecycle — ou SDL pour faire court.
Une approche plus récente avec la montée en charge des pratiques DevOps et l’augmentation exponentielle des menaces de sécurité, permet d’aller encore plus loin et favorise les entreprises à se préparer et à actualiser fréquemment l’ensemble de ses processus de sécurité de la prévention à la réponse : le modèle DevSecOps avec un accent particulier sur l’automatisation.
Shift-Left et DevSecOps
Je définirai le Shift-Left de la même manière que cet article de RedHat sur la perspective du Shift-Left par rapport au Shift-Right.
To shift left is to incorporate security testing as soon as possible to find vulnerabilities and fix defects as early as possible in development.
— Shift-Left vs Shift-Right
DevSecOps est une approche qui intègre la sécurité dans chaque phase du cycle de développement logiciel, ce qui en fait une méthode efficace pour appliquer le principe de Shift-Left. En intégrant les pratiques de sécurité dès le début du processus de développement, DevSecOps permet aux équipes de développement, de sécurité et d'opérations de collaborer de manière transparente. Cela signifie que les tests de sécurité et les évaluations des risques sont effectués en continu, plutôt qu'à la fin du cycle de développement. Cette intégration précoce permet d'identifier et de corriger les vulnérabilités dès leur apparition, réduisant ainsi le risque de failles de sécurité coûteuses et complexes à résoudre une fois le produit en production. De plus, l'automatisation des tests de sécurité dans les pipelines CI/CD (Intégration Continue/Déploiement Continu) assure une détection rapide des problèmes, ce qui accélère le temps de réponse et améliore la qualité globale du logiciel.
En fin de compte, DevSecOps favorise une culture de responsabilité partagée en matière de sécurité, où chaque membre de l'équipe est conscient des enjeux et contribue activement à la sécurisation des applications dès le départ.
Conclusion
En conclusion, l'adoption du principe de Shift-Left et l'intégration de DevSecOps dans le cycle de développement logiciel représentent des avancées significatives pour renforcer la sécurité applicative. En intégrant la sécurité dès les premières étapes du développement, les organisations peuvent non seulement identifier et corriger les vulnérabilités plus tôt, mais aussi réduire les coûts et les risques associés aux failles de sécurité. Cette approche proactive favorise une culture de collaboration et de responsabilité partagée, où chaque membre de l'équipe contribue activement à la sécurisation des applications. Finalement, en plaçant la sécurité au cœur du développement, les entreprises peuvent mieux protéger leurs données et leurs systèmes, tout en assurant la qualité et la fiabilité de leurs produits. Adopter ces pratiques est essentiel pour naviguer efficacement dans le paysage numérique actuel, où les menaces évoluent constamment.
