Un CISO d'une entreprise pesant plusieurs milliards de dollars, avec qui nous nous sommes récemment entretenus, a fait une observation qui m'a marqué. La capacité de sécurité qu'il valorisait le plus n'était pas un autre outil ou framework de détection. C'était la vitesse.
Pour eux, la vitesse d'identification des problèmes, de validation des correctifs et de réponse au changement était une priorité absolue. Avec tant de problèmes à gérer, cela suggère également que le temps devient une contrainte opérationnelle.
L'expert en cybersécurité Phil Venables a récemment suggéré que les programmes de sécurité réussiront ou échoueront de plus en plus en fonction de leur vitesse.
« La vitesse est primordiale. En particulier, la capacité des défenseurs à exécuter leur boucle OODA (observer, orienter, décider, agir) plus rapidement que les attaquants ne peuvent s'adapter ».
Il ne s'agit pas d'un autre article sur « l'IA est à l'origine de ce désordre », confrontons plutôt la réalité plus large. Dans notre étude auprès de 200 CISOs et 200 leaders en ingénierie (y compris des CTOs), 76 % des organisations déploient des mises à jour significatives chaque semaine ou plus rapidement, et 39 % déploient quotidiennement. Les équipes d'ingénierie modernes déploient des changements en continu.
Mais la validation de la sécurité n'opère pas à cette cadence ; seulement 21 % valident la sécurité à chaque release. C'est plus qu'un désalignement, c'est une défaillance structurelle.
Pace Layers
Venables fait référence au framework « Pace Layers » de Stewart Brand pour expliquer comment les systèmes complexes évoluent.
« Les couches rapides apportent la nouveauté et l'expérimentation, et les couches lentes assurent la stabilité et la mémoire. »
La livraison logicielle constitue la couche rapide, tandis que la gouvernance et la validation représentent la couche lente. Les environnements logiciels modernes accentuent l'écart entre ces couches. Les équipes d'ingénierie accélèrent leur rythme de travail, tandis que la validation de la sécurité opère toujours sur des cycles trimestriels ou annuels.
Les résultats de sécurité arrivent après que le système a changé, alors à quoi bon ?
Ce qui se produit en raison de ce décalage est inévitable ; 85 % déclarent que les conclusions de sécurité sont obsolètes au moment où les rapports arrivent, du moins parfois, et près de la moitié (48 %) d'entre eux affirment que cela se produit très souvent ou 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à changé. En effet, les équipes prennent des décisions de sécurité basées sur un état passé du système. Même de petits changements peuvent modifier la posture de sécurité d'un système. Un nouveau point d'accès, une modification de la logique d'autorisation ou une dépendance mise à jour peuvent ouvrir des chemins d'attaque entièrement nouveaux. Le pentesting valide souvent une version du système qui n'existe plus.
En conséquence, les correctifs suggérés et les retests peuvent bien débusquer d'anciens problèmes de sécurité, mais comme le logiciel a évolué, les équipes commencent à perdre confiance dans le signal que le test leur a fourni, car ce signal est tardif.
Le résultat est un peu comme les mécaniques temporelles superposées dans Inception : différentes parties du système opèrent désormais à des vitesses très différentes, et les actions prises trop tard dans une couche peuvent avoir peu d'effet sur ce qui se déroule déjà dans une autre.
La vitesse ne doit pas se faire au détriment de la profondeur.
Pour les organisations cherchant à améliorer leur posture de sécurité, la validation nécessite un raisonnement, une exploration, une confirmation d'exploit et une analyse des workflows. Elle doit être approfondie (mais vous le saviez déjà).
« L'analyse statique a ses limites. Si vous ne pouvez pas valider le problème par rapport à l'application en cours d'exécution, ce n'est qu'une hypothèse », déclare Philippe Dourrasov, responsable du pentest IA chez Aikido Security.
C'est pourquoi les tests de sécurité significatifs ont historiquement pris du temps.
Ainsi, le défi n'est pas d'augmenter le nombre de tests, mais de préserver la profondeur des tests offensifs réels tout en opérant à un rythme beaucoup plus élevé.
Cependant, les limites des tests périodiques en termes de profondeur sont évidentes. Selon notre étude, 51 % des répondants estiment que les vulnérabilités plus profondes, telles que les failles logiques, les contrôles d’accès défaillants ou les chemins d'attaque en plusieurs étapes, sont toujours ou souvent manquées.
Ce n'est pas un manque d'expertise des équipes de sécurité. Au contraire, les pentesters et les équipes rouges sont confrontés à de nombreuses contraintes : des tests à durée limitée, des systèmes en expansion, une complexité croissante et l'interconnexion des systèmes. Mais au fond, le dilemme entre l'étendue et la profondeur est avant tout un problème de temps.
La validation doit suivre les changements significatifs
Les organisations ne sont pas aveugles au déséquilibre croissant entre la vitesse de livraison et la validation de la sécurité. Nombre d'entre elles ont tenté de combler le fossé en réalisant plus de pentests tout au long de l'année, en scannant en continu ou en compressant les engagements manuels pour s'adapter à des cycles de publication plus courts. En théorie, ces approches augmentent la vitesse. En pratique, elles déplacent souvent le compromis ailleurs.
Le meilleur changement à opérer est d'aligner la validation sur la manière dont le logiciel évolue réellement. Cela ne signifie pas tester tout constamment ou en continu, mais permettre à la validation de réagir lorsque des changements significatifs se produisent. En d'autres termes, valider les changements qui introduisent réellement un risque. Le défi est que la plupart des approches de test existantes ne peuvent pas fonctionner à ce niveau de réactivité. Les pentests traditionnels prennent des jours, voire des semaines, à planifier, exécuter et rapporter. Même les engagements les plus rapides ne peuvent pas, de manière réaliste, suivre le rythme des changements quotidiens ou plusieurs fois par jour. Les changements ne sont pas seulement cosmétiques, mais concernent des éléments tels que de nouveaux points d'API, des modifications de la logique d'autorisation, des flux de travail d'agents ou de nouvelles intégrations tierces.
Ce que cela signifie opérationnellement pour les équipes de sécurité, c'est que la validation doit faire partie du pipeline de livraison, et non être un événement ajouté a posteriori. Cela déplace l'attention des tests périodiques de systèmes entiers vers la validation incrémentale des systèmes.
{{cta}}
Le besoin de rapidité
Depuis des décennies, les organisations se sont concentrées sur l'augmentation de la production : plus de code, plus de fonctionnalités, plus d'applications. Les équipes qui livrent plus rapidement obtiennent un avantage concurrentiel. Venables soutient que le même principe s'applique de plus en plus à la sécurité.
Pour réellement bénéficier de la vitesse 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 réagir plus rapidement aux changements obtiennent un avantage, non seulement sur les attaquants, mais aussi sur les concurrents évoluant dans le même secteur. Celles qui n'y parviennent pas se retrouveront de plus en plus à fonctionner sur des hypothèses obsolètes concernant leurs propres systèmes.
Lorsque différentes couches d'un système évoluent à des vitesses différentes, une sécurité qui réagit trop tard peut déjà opérer dans le mauvais laps de temps, un peu comme dans Inception, où les actions prises trop tard dans une couche ont peu d'effet sur ce qui se déroule déjà dans une autre.
