Du moment à tout le temps : Pourquoi les tests de sécurité doivent évoluer

Pendant des années, les tests de pénétration ont été la méthode de référence pour valider la posture de cybersécurité d’une organisation. Mais les cycles de développement évoluent à la vitesse de l’éclair et les menaces évoluent d’heure en heure. Alors, les tests ponctuels sont-ils toujours adaptés à l’objectif?

Très souvent, cela signifie que les équipes de sécurité doivent réagir aux vulnérabilités d’hier au lieu de prévenir les violations de demain.

L’héritage et les limites des tests de pénétration

Les tests de pénétration traditionnels sont nés à une époque où les mises à jour logicielles étaient peu fréquentes et où les cycles de publication s’étendaient sur plusieurs mois. Aujourd’hui, avec les pipelines de livraison continue et les applications natives du cloud, beaucoup se demandent si ce modèle correspond à notre réalité.

Les tests de pénétration ont généralement lieu chaque année, souvent sous la forme d’une case à cocher de conformité ou d’un exercice post-incident. Ces évaluations ponctuelles identifient les vulnérabilités à un moment précis, mais elles ne peuvent pas tenir compte de ce qui se passe dans les semaines et les mois qui suivent. En tant que tel, vous pouvez vous retrouver avec de longues fenêtres d’exposition entre les tests. De nouvelles vulnérabilités peuvent apparaître dès le lendemain, et les attaquants n’attendent pas votre prochain cycle.

Pire encore, les tests trop tard dans le cycle de développement peuvent ralentir les versions ou créer des tensions entre vos équipes de sécurité et de développement. Ce dernier, sous la pression d’expédier rapidement des fonctionnalités, voit souvent la sécurité comme un frein à main. Lorsque les tests de pénétration deviennent un obstacle plutôt qu’un guide, ils risquent de faire dérailler l’innovation même qu’ils sont censés protéger.

Les périodes calmes ne sont pas si calmes

Entre les tests, beaucoup de choses peuvent changer : Le code évolue, les configurations dérivent et de nouvelles interfaces de programmation d’applications (API) sont ajoutées, ce qui signifie que chaque changement introduit des points faibles potentiels qui restent incontrôlés jusqu’au prochain test planifié.

Pour remédier à ces points faibles, vous pouvez effectuer un balayage rapide au niveau de la surface, ce qui peut donner un faux sentiment de sécurité, ou effectuer un test manuel approfondi qui retarde le rythme des affaires. Ni l'idéal.

Cette période dite de « tranquillité » est l’endroit où se cachent les plus grands risques. De nombreuses violations du monde réel se produisent parce que les organisations ne parviennent pas à effectuer des tests en continu, ce qui permet aux attaquants d’exploiter ces lacunes plus facilement, parfois dans les heures qui suivent l’introduction d’une nouvelle vulnérabilité.

Validation continue : Une sécurité qui bouge avec vous

Les responsables de la sécurité avant-gardistes brisent ce cycle réactif en intégrant la validation continue dans leurs processus DevSecOps. Les tests de sécurité ne sont plus considérés comme un événement ponctuel; il s’agit plutôt d’une discipline continue qui évolue en même temps que l’entreprise.

NTT DATA travaille avec un détaillant mondial qui exécute des tests incrémentiels trimestriels alignés sur les nouvelles versions tout en maintenant une base d’exigences de sécurité spécifiques à l’entreprise. Chaque test s’appuie sur le dernier, plutôt que de partir de zéro. Le détaillant exécute également des « validations de surface d’attaque » externes, qui utilisent des flux de renseignements externes pour refléter le comportement réel des attaquants. Cela permet de maintenir les tests pertinents et adaptatifs.

D’autres clients de NTT DATA intègrent la numérisation automatisée et les renseignements sur les menaces directement dans leurs pipelines d’intégration continue et de livraison continue (CI/CD). Au lieu de s’appuyer sur des approbations manuelles, ces tests s’exécutent discrètement en arrière-plan, faisant apparaître les problèmes rapidement et informant les développeurs en temps réel.

L’automatisation a rendu la relation entre la sécurité et les développeurs beaucoup plus saine. Lorsque les tests se déroulent dans le pipeline, ils ne perturbent pas. La sécurité devient un facilitateur, pas un obstacle.

Créer un état d’esprit pour une sécurité continue

La validation continue est également une question de mentalité. Les équipes de sécurité passent progressivement du statut de gardiens à celui de collaborateurs, et les développeurs doivent également considérer la sécurité comme une partie intégrante de la qualité, plutôt que comme une boîte à cocher.

Ce changement culturel commence souvent par de petites choses : Intégrer des outils de numérisation dans le pipeline, planifier des tests plus fréquents ou aligner les calendriers de tests sur les cycles de publication connus. L’objectif n’est pas de tout tester en permanence, mais de construire un rythme où les tests et le développement évoluent ensemble.

Au fil du temps, les avantages deviennent évidents :

• Moins de surprises :Les vulnérabilités sont détectées plus tôt, ce qui réduit les reprises et les retards.
• Une plus grande résilience :Les informations continues aident les organisations à s’adapter à l’évolution des menaces.
• Innovation plus rapide :la sécurité devient une partie du flux, pas un obstacle.

Une approche vivante et respirante de l’assurance

En fin de compte, l’avenir de la sécurité offensive consiste à faire évoluer les tests d’intrusion, et non à les remplacer. Et en adoptant la validation continue, les organisations transforment les tests d’une activité réactive en une capacité proactive.

En fin de compte, nous devons cesser de traiter les tests comme un événement et commencer à les traiter comme un écosystème – un écosystème qui ne dort jamais.

• LIRE AUSSI->  Résilience des entreprises modernes : Un cadre pour une préparation continue

QUE FAIRE ENSUITE

En savoir plus sur les solutions offensives de sécurité en tant que service de NTT DATA.