Les types d’audits de cybersécurité expliqués

Dans cet article, nous abordons trois types d’audits de sécurité du code, les différences entre les audits internes et externes, ainsi que les moyens d’auditer la sécurité tout au long du cycle de développement logiciel (SDLC).

Quels sont les types d’audits de cybersécurité ?

Il existe trois types d’audits de cybersécurité :

1. Modélisation des menaces

2. Évaluations des vulnérabilités/tests d’intrusion

3. Audits de conformité de sécurité

Examinons plus en détail chaque type d’audit de sécurité.

1. Modélisation des menaces

Le développement logiciel moderne repose sur la réalisation du « trio gagnant » : des mises en production plus rapides, des cycles plus courts et un code de meilleure qualité. Pour que le code soit de qualité, il doit être sécurisé. La cybersécurité doit donc être intégrée au cycle de développement sans empêcher les développeurs de publier rapidement leur code.

Pour intégrer la sécurité des applications sans perturber les workflows DevOps, il est essentiel d’évaluer les risques dès le départ à l’aide de la modélisation des menaces. Ce processus examine les exigences et la logique métier afin de repérer les éléments susceptibles de présenter des risques de sécurité. 

La modélisation des menaces porte notamment sur quatre aspects :

• La conception des opérations du système et des flux de données

• Les risques et les éléments susceptibles d’être exploités

• Les moyens de se défendre contre chaque exploit

• L’efficacité de la modélisation des menaces et des défenses

La modélisation des menaces est un processus continu qui n’est jamais vraiment terminé. Elle constitue toutefois la première étape pour intégrer la sécurité à votre processus de développement et appliquer les bonnes pratiques d’hygiène en cybersécurité.

2. Évaluations des vulnérabilités/tests d’intrusion

Les évaluations des vulnérabilités reposent sur un principe simple : il est plus facile de corriger les vulnérabilités lorsqu’elles sont découvertes avant d’atteindre un environnement d’exécution. En utilisant des outils d’analyse statique et d’analyse du code source dans le cadre des audits de sécurité du code, les organisations peuvent détecter et corriger les vulnérabilités les plus courantes et les plus risquées, notamment les attaques par injection et les vulnérabilités liées à des tiers. Elles peuvent également s’assurer que le code respecte les exigences de conformité et de licence avant sa mise en production.

Le test d’intrusion est une forme de piratage éthique dans laquelle des testeurs internes ou externes tentent de découvrir des vulnérabilités en simulant une cyberattaque contre un environnement.

Il existe trois types de tests d’intrusion, selon le niveau de visibilité du testeur sur le code : les tests en boîte blanche, en boîte noire et en boîte grise.

Tests en boîte blanche

Les tests en boîte blanche sont des tests d’intrusion lors desquels le testeur ou l’outil connaît le fonctionnement interne du logiciel et comprend son objectif. Grâce à ces connaissances, les testeurs peuvent décomposer le code en composants fonctionnels élémentaires et tester chacun d’eux (« tests unitaires »). Ils peuvent également examiner des parties précises du code pour vérifier l’absence d’erreurs, comme des failles dans la logique métier. Les tests en boîte blanche peuvent être automatisés et exécutés dans le pipeline CI avec des outils tels que Snyk Code.

Tests en boîte noire

Les tests en boîte noire sont des tests d’intrusion lors desquels le testeur ou l’outil ne connaît pas le fonctionnement interne du logiciel. Ils simulent ainsi la manière dont un attaquant tenterait d’exploiter les failles d’un système pour s’y introduire. Parmi les techniques utilisées pour réaliser des tests en boîte noire :

• Le fuzzing, qui teste des services API ou des interfaces web à l’aide de données aléatoires ou personnalisées ;

• Les tests syntaxiques, qui recherchent des entrées ou des sorties non valides, comme une syntaxe incorrecte ou l’exposition de données sensibles ;

• Les tests exploratoires, au cours desquels des analystes découvrent des problèmes de sécurité cachés, les signalent et proposent des correctifs ;

• L’analyse des données, qui examine les journaux ou les réponses du système afin de détecter tout comportement suspect ou problème de sécurité potentiel.

Les tests dynamiques de sécurité des applications (DAST) comptent parmi les méthodes de test en boîte noire les plus répandues. Ils peuvent être réalisés manuellement ou automatiquement. Contrairement aux outils de test statique de sécurité des applications (SAST), qui analysent le code source lui-même, le DAST ne nécessite pas de connaître le fonctionnement interne du logiciel et peut donc être effectué de l’extérieur. Le DAST génère moins de faux positifs que les outils SAST, car il ne détecte que les vulnérabilités exploitables. Toutefois, il est difficile de garantir que l’ensemble du code a été évalué, et les tests DAST nécessitent d’assumer les coûts de déploiement des applications.

Tests en boîte grise

Les tests en boîte blanche et en boîte noire présentant chacun des avantages et des inconvénients, les testeurs ont souvent recours aux tests en boîte grise pour tirer parti des meilleurs aspects de ces deux méthodes. Par exemple, les tests en boîte grise simulent la manière dont un attaquant verrait une application, tout en s’appuyant sur une connaissance de celle-ci pour découvrir des vulnérabilités. Si un testeur connaît le langage dans lequel une application est écrite, il peut utiliser cette connaissance pour repérer les vulnérabilités courantes associées à ce langage. 

3. Audits de conformité de sécurité

Les applications qui traitent des données sensibles protégées par HIPAA, PCI ou d’autres normes peuvent nécessiter des mesures particulières pour garantir leur conformité. Elles doivent notamment être régulièrement testées afin de repérer les vulnérabilités nouvelles ou jusque-là inconnues. Snyk propose un service de conformité PCI qui s’appuie sur la conformité en tant que code et d’autres méthodes pour garantir la conformité et fournir une piste d’audit.

Audits de cybersécurité internes et externes

Les audits de cybersécurité peuvent être internes ou externes. Les audits internes, réalisés par exemple par les développeurs et les équipes de sécurité, se prêtent davantage aux tests en boîte blanche, puisque le code source n’est accessible qu’aux équipes internes. Les auditeurs externes peuvent ensuite effectuer des tests en boîte noire du point de vue d’un attaquant.

De nombreux nouveaux outils sont à la disposition des auditeurs internes et externes. Les auditeurs internes peuvent s’appuyer sur des outils SAST avancés comme Snyk Code pour détecter automatiquement les vulnérabilités du code. Les auditeurs externes peuvent quant à eux tirer parti d’outils de test d’intrusion modernisés, ainsi que d’outils sophistiqués fondés sur l’intelligence artificielle (IA), comme l’analyse de sécurité, qui surveillent les journaux et les requêtes pour repérer les schémas inhabituels susceptibles de révéler une vulnérabilité.

Auditer la sécurité tout au long de votre SDLC

Traditionnellement, la sécurité intervenait à la fin du SDLC, mais les approches DevSecOps l’intègrent dès le départ. En auditant en continu la sécurité tout au long de votre SDLC, vous pouvez découvrir les vulnérabilités et les corriger avant qu’elles n’affectent les environnements de production. Voyons comment les audits couvrent chaque aspect d’une application logicielle moderne :

Audits des composants open source

La majeure partie du code d’une application moderne peut provenir de bibliothèques open source utilisées par l’application principale. Ces bibliothèques doivent elles aussi être auditées, car elles peuvent introduire des vulnérabilités que les développeurs ne connaissent pas. Snyk propose des audits open source pour vous aider à détecter les vulnérabilités et à gérer vos logiciels open source. De plus, Snyk Open Source vous aide à garantir que l’utilisation de composants open source respecte les exigences de licence applicables.

Revues de sécurité du code

Les revues de code jouent un rôle essentiel dans le SDLC, car elles contribuent à repérer les principales causes d’une mauvaise qualité du code, notamment les problèmes de sécurité. Elles diffèrent légèrement des audits : elles sont généralement effectuées par les développeurs eux-mêmes et portent sur tous les aspects de la qualité du code, tandis que les audits se concentrent sur les risques de sécurité et peuvent être réalisés par des équipes de sécurité ou des auditeurs externes. 

Audits des images de conteneurs

Comme les développeurs modernes définissent généralement la configuration des conteneurs en même temps que celle de leur application, ils doivent auditer leurs processus de gestion des conteneurs. Snyk Container aide à sécuriser les conteneurs, notamment en choisissant une image de base sécurisée, en automatisant les mises à niveau des images de base et en surveillant en continu les nouvelles vulnérabilités. Les développeurs peuvent ainsi utiliser des conteneurs en toute confiance, sans avoir besoin d’une expertise avancée des systèmes d’exploitation.

Audits des modèles IaC

Avec l’approche DevOps, les développeurs sont de plus en plus responsables de la configuration de l’infrastructure sur laquelle leurs conteneurs sont déployés. Du point de vue de la sécurité, cela implique d’appliquer les bonnes pratiques IaC, par exemple en respectant le principe du moindre privilège, en segmentant le trafic réseau et en chiffrant les données en transit et au repos. 

Foire aux questions