Au premier abord, la cybersécurité et l’agilité semblent être en contradiction, la première imposant des contraintes qui peuvent freiner l’élan créatif et productif des équipes de développement. L’agilité, reconnue pour son efficacité à accélérer la livraison de produits de qualité, se heurte à la rigueur de la cybersécurité, perçue comme un obstacle au rythme de développement et, par extension, à la rapidité de mise sur le marché.
Cette vision est largement répandue dans le secteur, mais l’augmentation des risques cyber et l’insuffisance des dispositifs de protection actuels obligent le Responsable de la Sécurité des Systèmes d’Information (RSSI) à revoir sa stratégie. Les anciennes approches de sécurité, fondées sur la solidité des infrastructures – à l’image d’une forteresse – sont désormais obsolètes face aux nouvelles applications et à la diversification des usages des données. Ainsi, la cybersécurité se voit contrainte d’intégrer le processus de conception des produits dès leur genèse, adoptant ainsi une posture agile pour rester pertinente. Reste à savoir si elle peut réellement s’adapter à cette exigence…
« Shift Left » : anticiper la sécurité dans le cycle de développement
Traditionnellement, le développement d’un produit informatique traverse quatre étapes clés : la conception, le développement, les tests — incluant les essentiels tests de sécurité — et enfin la livraison. Historiquement, l’intégration des tests de sécurité se fait en aval du processus, souvent révélant des vulnérabilités tardivement, ce qui entraîne une réévaluation des coûts et des délais de mise sur le marché.
L’approche « Shift Left » propose un changement de paradigme en intégrant la sécurité dès les premiers jalons du cycle de développement. Cette stratégie vise à inclure de manière proactive les analyses et contrôles de sécurité au sein des routines quotidiennes des équipes projets. Des experts en sécurité collaborent dès l’étape de conception, afin d’identifier les risques potentiels et de définir les mesures préventives adéquates, poursuivant leur accompagnement tout au long du processus pour veiller à l’application des meilleures pratiques de sécurité.
Dans l’ère du DevSecOps, l’automatisation des tests de sécurité se fait grâce à l’intégration d’outils spécifiques au sein de l’écosystème DevOps, tels que des systèmes d’audit de code (analyses statique et dynamique), de gestion des dépendances externes, de détection de vulnérabilités, ou encore de systèmes d’alerte en lien avec un SOC (Security Operations Center). Cela dit, l’adoption de ces outils ne saurait éliminer le besoin d’audits manuels et de tests d’intrusion, essentiels pour évaluer l’aspect fonctionnel de la sécurité mise en œuvre. Par ailleurs, l’organisation de campagnes de bug bounty s’avère être une méthode efficace pour garantir une sécurité optimale de l’application en continu.
« Evil User Story », ou l’art de prévoir le pire dans un cadre agile
Pour s’harmoniser avec l’esprit agile des équipes de développement, certaines organisations adoptent une approche novatrice en matière de sécurité dès le lancement du projet. Ce rituel spécifique, mené en présence de l’équipe projet, du Security Champion et parfois d’un membre de l’équipe de sécurité (ce dernier devenant optionnel au fur et à mesure que l’équipe gagne en maturité), vise à anticiper les scénarios d’attaques potentielles pour chaque User Story en conceptualisant une Evil User Story correspondante, qui consiste à envisager un scénario d’exploitation malveillante du produit.
Pour garantir une compréhension optimale par les développeurs, ces Evil User Stories sont formulées selon un modèle clair et direct : « En tant que (source de risque), je souhaite (exploiter une vulnérabilité) dans le but de (générer un impact métier) ». Suite à l’identification de chaque Evil User Story, des stratégies de sécurité adéquates sont élaborées et intégrées au backlog de l’équipe, assurant ainsi une prise en compte systématique des risques de sécurité dès les premières étapes du développement.
« Security Gates » : vers une sécurité infaillible grâce à l’automatisation
Dans l’univers DevOps, l’utilisation des « quality gates » est une pratique courante pour interrompre ou rejeter la compilation du code lorsque des anomalies sont identifiées. Initialement dédiée à la qualité, cette méthode trouve désormais sa place dans le domaine de la sécurité… En dotant l’usine logicielle d’outils avancés d’analyse statique et dynamique du code, tels que CheckMarx ou Fortify, l’équipe de sécurité est en mesure de déterminer précisément les critères qui définiront le succès ou l’échec des audits de sécurité. L’avantage évident de cette démarche proactive est qu’elle permet une détection précoce des vulnérabilités.
« Security Champion », le bras droit du RSSI dans la démocratisation de la cybersécurité
Face à l’ampleur des enjeux de sécurité informatique, l’équipe du RSSI se retrouve souvent en sous-effectif, incapable de traiter toutes les problématiques de sécurité ni d’accompagner chaque projet dans l’identification et la mitigation des risques cyber. Pour pallier cette limitation et éviter les embouteillages qui pourraient freiner l’innovation et le déploiement des solutions, la décentralisation de l’expertise en sécurité devient impérative.
Dans cette optique, l’OWASP (Open Web Application Security Project) préconise la nomination de « Security Champions » au cœur des équipes de développement. Plus qu’un simple expert en sécurité, le Security Champion est un développeur qui se distingue par son intérêt pour les questions de sécurité et qui consacre une partie de son activité à intégrer les exigences sécuritaires dans le processus de développement. En servant de pont entre les équipes techniques et la cellule sécurité, l’instauration d’un réseau de Security Champions est une stratégie clé pour étendre la culture de la cybersécurité à l’ensemble de l’organisation.
Attention : pour que cette transformation prenne forme, elle exige une révision en profondeur des structures organisationnelles et culturelles, appuyée par un engagement sans faille de la direction. Adopter ces pratiques de manière graduelle et s’appuyer sur la figure du Security Champion est vivement recommandé pour insuffler un renouveau durable dans la gestion de la cybersécurité.
La CISA victime de failles Ivanti
Ironie du sort pour la Cybersecurity and Infrastructure Security Agency (CISA), gardienne de la cybersécurité américaine, qui s’est trouvée compromise par des vulnérabilités déjà bien établies dans les solutions Ivanti, un éditeur dont les produits ont été marqués par de multiples failles critiques.
En février, des cyberattaquants ont réussi à infiltrer les systèmes de la CISA. L’agence a rapidement confirmé l’incident à The Record, révélant une activité malicieuse exploitant des faiblesses dans des logiciels Ivanti utilisés par l’agence. « Seuls deux systèmes ont été touchés, que nous avons immédiatement déconnectés. Nos efforts continus pour renforcer et moderniser nos systèmes nous permettent d’affirmer qu’il n’y a eu aucun impact sur nos opérations », a expliqué un représentant de la CISA. Curieusement, le 29 février, la CISA avait elle-même lancé une alerte concernant l’exploitation de failles Ivanti déjà connues, touchant spécifiquement les solutions Connect et Policy Secure (CVE-2023-46805, CVE-2024-21887 et CVE-2024-21893).
