Un responsable de la sécurité informatique (CISO) d'une entreprise pesant plusieurs milliards de dollars, avec lequel nous nous sommes récemment entretenus, a fait une remarque qui m'a marqué. La capacité en matière de sécurité à laquelle ils accordaient le plus d'importance n'était pas un nouvel outil ou cadre de détection. C'était la rapidité.
Pour eux, la rapidité avec laquelle ils pouvaient identifier les problèmes, valider les solutions et s'adapter aux changements était une priorité absolue. Avec tant de problèmes urgents à régler, cela laisse également penser que le temps devient une contrainte opérationnelle.
L'expert en cybersécurité Phil Venables a récemment fait remarquer que le succès ou l'échec des programmes de sécurité dépendra de plus en plus de leur rapidité.
« Tout est une question de rapidité. Plus précisément, il s'agit de savoir comment les défenseurs peuvent exécuter leur cycle OODA (observer, s'orienter, décider, agir) plus rapidement que les attaquants ne peuvent s'adapter. »
Il ne s'agit toutefois pas d'un énième article du genre « c'est l'IA qui est responsable de ce chaos » : regardons la réalité en face. D'après notre enquête menée auprès de 200 RSSI et 200 responsables techniques (dont des directeurs techniques), 76 % des entreprises déploient des mises à jour importantes chaque semaine, voire plus souvent, et 39 % le font quotidiennement. Les équipes techniques modernes déploient des modifications en continu.
Mais la validation de la sécurité ne suit pas ce rythme ; seuls 21 % des acteurs procèdent à une validation de la sécurité à chaque mise à jour. Il ne s'agit pas simplement d'un décalage, mais d'une défaillance structurelle.
Calques de rythme
Venables s'appuie sur le modèledes « Pace Layers »de Stewart Brand pour expliquer comment évoluent les systèmes complexes.
« Les couches rapides apportent de la nouveauté et favorisent l'expérimentation, tandis que les couches lentes assurent la stabilité et la mémoire. »
La livraison des logiciels constitue la couche rapide, tandis que la gouvernance et la validation forment la couche lente. Les environnements logiciels modernes accentuent encore davantage le décalage entre ces deux couches. Les équipes d'ingénierie accélèrent leur rythme de travail, tandis que la validation de la sécurité s'effectue toujours selon des cycles trimestriels ou annuels.
Les résultats en matière de sécurité ne sont connus qu'après que le système a déjà changé ; alors à quoi ça sert ?
Les conséquences de ce décalage sont inévitables : 85 % des personnes interrogées indiquent que les constatations en matière de sécurité sont obsolètes au moment où les rapports leur parviennent, au moins de temps en temps, et près de la moitié (48 %) d'entre elles précisent que cela se produit très souvent, voire tout le temps.
En d'autres termes, au moment où les résultats des tests sont examinés, le système qu'ils décrivent a déjà évolué. En réalité, les équipes prennent des décisions en matière de sécurité en se basant sur un état antérieur du système. Même des modifications mineures peuvent altérer la posture de sécurité d'un système. Un nouveau terminal, une modification de la logique d'autorisation ou une dépendance mise à jour peuvent ouvrir des vecteurs d'attaque totalement inédits. Les tests d'intrusion valident souvent une version du système qui n'existe plus.
En conséquence, les corrections proposées et les nouveaux tests peuvent certes permettre de détecter des failles de sécurité plus anciennes, mais comme le logiciel a évolué, les équipes commencent à perdre confiance dans les résultats fournis par les tests, car ceux-ci arrivent trop tard.
Le résultat s'apparente un peu à la mécanique temporelle en couches d'Inception: différentes parties du système fonctionnent désormais à des vitesses très différentes, et les actions entreprises trop tardivement à un certain niveau peuvent n'avoir que peu d'effet sur ce qui se déroule déjà à un autre.
La rapidité ne doit pas se faire au détriment de la profondeur
Pour les organisations qui souhaitent renforcer leur sécurité, la validation doit s'appuyer sur un raisonnement, une analyse approfondie, la vérification des vulnérabilités et l'examen des processus. Elle doit être rigoureuse (mais vous le saviez déjà).
« L'analyse statique a ses limites. Si l'on ne peut pas vérifier la validité du problème par rapport à l'application en exécution, cela reste une simple hypothèse », explique Philippe Dourrasov, responsable des tests d'intrusion basés sur l'IA chez Aikido .
C'est pourquoi les tests de sécurité rigoureux ont toujours pris du temps.
Le défi ne consiste donc pas à augmenter le nombre de tests, mais à maintenir la rigueur des tests offensifs tout en opérant à un rythme beaucoup plus soutenu.
Cependant, les limites des tests périodiques en termes de profondeur sont évidentes. D'après notre étude, 51 % des personnes interrogées estiment que les vulnérabilités plus complexes, telles que les failles logiques, les contrôles d'accès défaillants ou les chaînes d'attaque en plusieurs étapes, échappent systématiquement ou souvent à ces tests.
Ce n'est pas parce que les équipes de sécurité manquent d'expertise. C'est plutôt parce que les testeurs d'intrusion et les équipes rouges sont confrontés à plusieurs contraintes : des tests soumis à des délais stricts, des systèmes en constante expansion, une complexité croissante et l'interconnexion des systèmes. Mais au fond, le dilemme entre l'étendue et la profondeur est avant tout une question de temps.
La validation doit faire suite à un changement significatif
Les entreprises ne sont pas sans voir le décalage croissant entre la rapidité de mise en production et la validation de la sécurité. Beaucoup ont tenté de combler ce fossé en multipliant les tests d'intrusion tout au long de l'année, en effectuant des analyses en continu ou en condensant les interventions manuelles pour s'adapter à des cycles de publication plus serrés. En théorie, ces approches permettent de gagner en rapidité. Dans la pratique, elles ne font souvent que déplacer le risque ailleurs.
La meilleure approche consiste à adapter la validation à la manière dont les logiciels évoluent réellement. Cela ne signifie pas pour autant de tout tester en permanence ou en continu, mais de permettre à la validation de réagir lorsqu’un changement significatif se produit. En d'autres termes, il s'agit de valider les changements qui introduisent réellement un risque. Le défi réside dans le fait que la plupart des approches de test existantes ne peuvent pas fonctionner avec un tel niveau de réactivité. Les tests d'intrusion traditionnels prennent des jours, voire des semaines, à planifier, à exécuter et à générer un rapport. Même les interventions les plus rapides ne peuvent pas, de manière réaliste, suivre le rythme des changements qui surviennent quotidiennement, voire plusieurs fois par jour. Ces changements ne sont pas simplement cosmétiques, mais concernent des éléments tels que de nouveaux points de terminaison API, des modifications de la logique d'autorisation, des workflows d'agents ou de nouvelles intégrations tierces.
Concrètement, cela signifie pour les équipes de sécurité que la validation doit être intégrée au processus de déploiement, et non plus être une étape ajoutée a posteriori. Cela implique donc de passer d'un test périodique de l'ensemble des systèmes à une validation progressive de ceux-ci.
{{cta}}
Le besoin de vitesse
Depuis des décennies, les entreprises se concentrent sur l'augmentation de la production : plus de code, plus de fonctionnalités, plus d'applications. Les équipes qui livrent plus rapidement acquièrent un avantage concurrentiel. Venables soutient que ce même principe s'applique de plus en plus au domaine de la sécurité.
Pour tirer pleinement parti de la rapidité du développement logiciel moderne, la sécurité doit évoluer au même rythme. Les organisations capables de détecter les problèmes, de valider les correctifs et de s'adapter plus rapidement aux changements prennent l'avantage, non seulement sur les pirates, mais aussi sur leurs concurrents opérant dans le même secteur. Celles qui n'y parviennent pas se retrouveront de plus en plus souvent à fonctionner sur la base d'hypothèses obsolètes concernant leurs propres systèmes.
Lorsque les différentes couches d'un système évoluent à des rythmes différents, un dispositif de sécurité qui réagit trop tard peut déjà se trouver hors de phase, un peu comme dans le film « Inception », où les mesures prises trop tardivement dans une couche n'ont que peu d'effet sur ce qui se déroule déjà dans une autre.
