Armé de mon petit calculateur de CVSS que j'ai développé en moins de 30 minutes en utilisant le manuel de référence, je m'en vais mettre des notes à mes vulns et là c'est la douche froide.
- Comment noter une fonctionnalité dangeureuse comme le transfert automatique de message dans Exchange ?
- Comment noter une faille dans un système d'authentification forte qui réduit alors l'authentification au seul mot de passe ?
- Comment qualifier le fait qu'un utilisateur puisse accéder aux interfaces d'administration d'un serveur ?
- Comment noter un bête XSS sur une applications interne ?
- Faut-il considérer l'attaque depuis le réseau (Internet) ou depuis un adjacent network ?
- Est-ce que l'Access Complexity est élevé car nécessitant une phase d'ingénieurie sociale (phishing) ou moyenne car c'est un bête XSS sur un moteur de recherche ?
- Avec un XSS on peut voler le cookie d'une personne et accéder à l'application avec ses droits. On peut altérer ses données. Avec le cookie d'un admin on peut supprimer la base de données. Sauf qu'on attaque personne par personne. Comment qualifier l'impact DIC de façon pertinente ?
Un peu comme je l'évoque pour le XSS, il existe des scénarios qui enchaînent les failles. Par exemple une interface admin accessible, un contournement d'authentification, une élévation de privilège et compromission totale du serveur. Et puis quoi ? Avec des si on mettrait Paris en bouteille.
Ce dont il faut bien se souvenir quand on utilise CVSS, c'est qu'on mesure la criticité d'une vulnérabilité, on ne mesure pas le risque. Est-ce que l'entreprise est grande, a beaucoup de concurrence, a une population technophile (SSII), qui aime assez peu sa société (mauvaise rémunération) ? CVSS n'en tient pas compte. C'est à l'auditeur de faire une analyse de risque et de faire ressortir ce qui est réellement critique dans le contexte de l'entreprise.
Aucun commentaire:
Enregistrer un commentaire