Un avis ? Un commentaire ?
Cet espace est pour vous.
Bienvenue dans notre deuxième article consacré au défi 30 Days of Security Testing.
Le scan des vulnérabilités est une technique de recherche proactive et automatisée des failles de sécurité d’un système. Une liste de failles est recherchée, puis un reporting est généré pour savoir lesquelles se trouvent effectivement dans le système. Le logiciel ZAP (dont nous parlerons dans un prochain article) est un outil de scan des vulnérabilités.
Même s’ils permettent d’identifier rapidement un certain nombre de problèmes, les scans de vulnérabilité ne sont pas suffisants pour assurer la sécurité d’un système d’information ou d’un applicatif donné. Premièrement, parce que toutes les failles existantes ne peuvent être répertoriées, et a fortiori par un seul outil. Deuxièmement, parce que les scanneurs de vulnérabilités ne permettent pas de simuler une situation d’attaque sophistiquée.
Il est donc nécessaire de mettre en place, en plus des scans de vulnérabilités, des tests d’intrusion mettant en oeuvre une stratégie d’attaque plausible.
L’évaluation des menaces est essentiel si l’on souhaite renforcer la sécurité de son SI. Le modèle STRIDE répond à ce besoin. Cet acronyme signifie :
Un même scénario faire intervenir plusieurs de ces pratiques frauduleuse.
Voici un exemple d’application du modèle STRIDE, publié par le département d’informatique et de recherche opérationnelle de l’université de Montréal.
Un test d’intrusion, ou pentest, est un test où l’on simule une attaque visant à outrepasser la sécurité d’un système afin d’obtenir, corrompre ou rendre indisponibles des informations. Le but est de révéler, par la pratique, les failles de sécurité spécifiques au système testé.
Un test d’intrusion commence par une analyse des traces laissées par le système que l’on veut tester (ses empreintes, ou footprints). Cela passe par des informations directement trouvables sur le web (informations sur les collaborateurs, politiques de confidentialité), ainsi que des informations techniques telles que son adresse IP (en effectuant un simple ping du site concerné), éventuellement les autres sites qui se trouvent sur la même IP, la date d’expiration du nom de domaine (ce que permet Whois), etc. Des informations techniques peuvent être trouvées via une simple requête dans un moteur de recherche. On parle alors de Google dorks.
Viennent ensuite :
L’un des intérêts d’un test d’intrusion est de comprendre quelles informations il serait stratégique de tenir secrètes, et quelles actions interdire au sein du système, afin d’éviter d’être confronté à des attaques similaires.
Comme vu précédemment, il est intéressant de combiner scans de vulnérabilités et tests d’intrusion.
| Scans de vulnérabilité | Tests d’intrusion | |
| Fréquence de lancement | Haute.
Cela peut être fait à chaque itération. |
Relativement basse.
Les investissements en tests d’intrusion dépendent évidemment du niveau de risque associé. |
| Contenu des reportings | Liste des vulnérabilités, comparatif avec les précédents résultats. | Liste des données en danger. |
| Coût | Faible
Les outils de scan demandent généralement peu d’efforts de configuration. Leur coût d’exécution est nul. |
Elevé
Trouver les failles spécifiques demande davantage de temps, et souvent l’intervention d’experts indépendants. |
| ROI | Immédiat. Une liste de défauts est rapidement générée, qui permet de planifier les prochaines corrections. | Garanti, proportionnel à l’expertise de l’équipe de test. Si des failles sont détectées, on anticipe d’éventuelles attaques. Dans le cas contraire, on gagne en confiance dans le produit. |
Inspiré d’un schéma du groupe TNS. EDIT du 21 février 2019 : le schéma n’est malheureusement plus disponible en ligne. Et si on le sait, c’est grâce à JSoup et Gatling 🙂
La plupart du temps, les audits de sécurité sont menés par des entités externes à l’organisation. L’ANSSI, l’agence nationale de la sécurité des systèmes d’information, définit 5 champs d’investigation :
Un référentiel d’exigences définit le cadre méthodologique et réglementaire des audits de sécurité. Il comporte également des notions pratiques, telle qu’une échelle de classification des vulnérabilité.
L’intérêt d’une évaluation de la sécurité (en anglais « security posture assessment ») est de pouvoir prendre une décision en fonction des risques. Cette décision peut être de mettre ou non un applicatif en production.
Pour mener à bien cette activité, nous avons procédé de cette manière :
Dans le cycle de développement logiciel, à quel moment faire intervenir les tests de sécurité ?
Les scans de vulnérabilité sont si rapides qu’ils peuvent être lancés à tout moment. L’intérêt est de pouvoir détecter les failles le plus tôt possible afin de pouvoir y répondre rapidement et adéquatement. Des scans peuvent être directement incorporés dans la chaîne d’intégration continue, par exemple grâce aux plugins Jenkins ZAP (Zed Attack Proxy), VAddy, Walti.
Pour ce qui est des tests d’intrusion, la réponse est moins évidente. En effet, il paraît fructueux de ne pas raisonner en fonction du cycle de développement (approche boîte noire), car une attaque extérieure peut survenir à tout moment. Cela dit, le testeur peut également tirer profit des informations qu’il connaît : la date et l’heure du déploiement en environnement de test, certains mots de passe, ou encore les dates de congés de l’administrateur système. Avec cette approche « boîte grise », il devient capable de trouver d’autres failles de sécurité.
Nous n’avons pas trouvé de ressources répondant à cette question. Si vous avez des pistes, merci de nous laisser un commentaire.
Cette checklist se trouve ici.
En plus d’être d’une aide pratique au moment de se lancer dans des tests de sécurité d’une application, elle montre que la frontière entre tests fonctionnels et tests de sécurité est assez ténue. Les items à tester lors de la validation d’une fonctionnalité d’authentification illustrent bien cette proximité :
Une famille de normes est consacrée à la sécurité de l’information : ce sont les normes ISO 27000. Cette page fournit un schéma qui permet de comprendre leurs liens de parenté.
Un audit de sécurité peut être effectué dans l’optique d’obtenir la certification ISO 27001, qui établit des spécifications de sécurité de l’information. Dans ce cas, le processus dure trois ans. Lors de la première année, un audit complet est effectué et les non-conformités sont résolues. Un suivi est effectué lors des deux années suivantes.
Cette norme est destinée à accompagner la mise en place d’un système de management de la sécurité de l’information (SMSI). Respectant explicitement le principe de la roue de Deming (PDCA : Plan, Do, Check, Act), elle illustre parfaitement la maxime du cryptologue Bruce Schneier : « Security is not a product; it’s a process ». Elle est téléchargeable gratuitement à cette adresse.
La norme ISO 27002, qui se réfère étroitement à la 27001, développe plus en détail les bonnes pratiques, ne représente pas une condition pour obtenir la certification.
Rendez-vous sur notre article suivant, qui porte sur les défis liés aux outils de test de sécurité !
Cet espace est pour vous.