L'illusion du score d'un pentest

"If you can not measure it, you can not improve it." Cette citation de Lord Kelvin a beaucoup de sens en sécurité et est la base des tableaux de bord. Pourtant j'ai du mal à trouver comment l'appliquer dans le cadre des tests d'intrusion.

J'imagine qu'il faudrait trouver ce qui est quantitatif et qualitatif dans le résultat de l'audit pour pouvoir réaliser une mesure, mais un audit n'est pas et n'a pas vocation à être exhaustif, ce qui implique que la quantité peut varier, notamment avec l'expérience de l'auditeur et le nombre de jours disponibles. L'objectif  d'un test d'intrusion est d'aller le plus en profondeur possible (p0wner le serveur, le réseau, le contrôleur de domaine), alors quand on trouve une injection SQL on va passer du temps dessus. Puis on a autre chose de plus intéressant à mettre dans le rapport que d'indiquer que la méthode TRACE est acceptée. Et pourtant c'est exactement ça qui va biaiser notre calcul car on n'aura pas une base cohérente entre les audits... Au passage, un camembert de répartition des failles par criticité n'a aucune valeur d'une part parce que la base est incohérente et d'autre part une appli avec 4 vuln critiques et 4 faibles ne devrait pas ressortir de la même façon qu'avec 1 critique et une faible.

Ensuite pour le qualitatif si on revient encore sur notre méthode TRACE, on peut trouver des discussions sur le sujet http://www.securityfocus.com/archive/107/533982/30/30/threaded avec des références à rapid7 (CVE à 6). Du côté de Qualys, c'est très inconsistant :

Toutes les failles n'ont pas non plus un CVE et pour régulièrement qualifier des failles avec un score CVE, c'est très dépendant de la personne qui définit les niveaux. Ça ne prend pas non plus en compte le fait qu'il y est 5 ou 1000 utilisateurs.

Bref, donner une note à un audit autrement qu'au pif semble impossible. Récemment j'ai croisé le projet CCWAPSS (Common Criteria Web Application Security Scoring) qui vise à changer la logique de calcul pour s'appuyer sur la chaine "applicative" :

• Authentication
• Authorization
• User’s Input Sanitization
• Error Handling and Information leakage 
• Password/PIN Complexity 
• User’s data confidentiality 
• Session mechanism 
• Communication security 
• Patch management 
• Administration interfaces 
• Third-Party services exposure 

Pour chaque critère on indique s'il y a une faille, si c'est correct ou si c'est au niveau des "best practices". Ce qui nous refait tomber dans un biais : il n'existe pas de liste exhaustive des bonnes pratiques. Ce qui, une nouvelle fois (ou comme toujours), nous ramène à l'expertise de notre auditeur.

Alors quand un client demande "comment on se positionne par rapport à notre secteur d'activité ?", on va rester flou et faire "à dire d'expert". Puis si tous les autres étaient mauvais, est-ce que ça serait une bonne raison pour être mauvais également ?

CVSS ou pas ?

Je suis actuellement sur une campagne de 15 pentests pour un client qui veut que l'on note chaque vulnérabilité avec un niveau CVSS. L'exercice est assez particulier et m'a fait perdre la foi dans cette métrique :)

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 ?

Il n'y a pas de réponse pour les 3 premiers points, mais on peut développer un peu sur le XSS.

• 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 ?

Bref, je finis par faire discrètement à ma sauce pour obtenir le niveau de criticité que j'estime satisfaisant. Mais parfois on tombe sur une vulnérabilité connue qui remonte dans un scan Nessus et là on doit accepter la criticité définie par l'éditeur qui peut être surestimée par précaution (ou le contraire). Par exemple les failles sur HP SMH peuvent aller jusqu'à 9.0 alors qu'il faut déjà avec un compte utilisateur sur un application de management de serveurs... alors qu'un XSS sans authentification sur la même application n'atteint que 4,3 et au passage la complexité est moyenne alors qu'il faut faire de l'ingénieurie sociale et qu'au final on pourrait voler un compte admin et compromettre totalement le serveur.

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.

Comment truquer un tableau de bord !

Pour avoir mis en place un tableau de bord chez un client voici quelques astuces pour mentir à sa direction...

Tout d'abord il est possible de mesurer tout et n'importe quoi, surtout n'importe quoi. La grande question à se poser est "so what?". Que nous apprend cet indicateur ? Le mieux serait qu'il permette de démontrer l'efficacité des moyens de sécurité et pas seulement faire remonter qu'on travaille (dur et même oulalala très dur !).

Je rigole (discrètement) quand je vois mon client demander à plusieurs éditeurs anti-virus quelle est la valeur moyenne de virus éradiqués par mois dans les grandes entreprises françaises. Heureusement personne ne lui répond (étonnant ?).

Ensuite le problème que j'ai rencontré est cette manie de vouloir mettre une note sur tout. Par exemple si on mesure le pourcentage de spam reçu.  Comment dire si 95% c'est bien ou mal ? En fait ni l'un ni l'autre... on n'est pas responsable du spam mondial. Mais il ne faut pas non plus supprimer cet indicateur car un pourcentage vraiment trop faible pourrait impliquer une défaillance de l'équipement. Je classe cet indicateur comme "information" à avoir sous le coude mais pas à utiliser de façon automatique dans des calculs.

Si on continue sur cette lancée, on peut mettre des pourcentages très faibles pour avoir un indicateur au vert.  Cela ne veut pas forcément dire qu'on triche si l'objectif est bas mais que ce n'est pas une priorité. Enfin on évitera quand même d'être satisfait avec 50 patch de sécurité en retard sur les serveurs...

Un des travers à considérer est la réévaluation des objectifs. On va être vert une année avec nos 50 patch mais on va se fixer 20 puis 10. Au final on va à chaque fois repasser à l'orange ou au rouge. Il faut s'attendre à des questions de la direction... et être prêt à y répondre plutôt que de conserver des objectifs de débutants :-)

Pour finir il me semble que la grosse zone d'ombre est la définition du périmètre. On va évidemment pouvoir mesurer ce sur quoi on a travaillé, et donc être pas mauvais, mais on risque d'occulter ce qui reste à faire et qu'on ignore sans doute. L'exemple qui m'a marqué est celui d'un patch management correct pour l'environnement Microsoft et une absence totale d'information sur les serveurs linux... Au final que du vert dans le tableau de bord !

PDCA et sécurité opérationnelle

Je disais dans un post précédent que les phases "prévention, détection, réaction" sont intemporelles. Alors est-ce qu'elles collent avec le fameux plan-do-check-act de la roue de Deming ?

A mon humble avis, la prévention correspond au DO. Ce sont les mesures qu'on met en place qui préviennent des risques. Le firewall va bloquer les connexions, l'antivirus les virus qu'il connaît...

La détection serait le CHECK. Je vérifie les logs, je supervise mon réseau et mes serveurs.Ce sont ces étapes d'hygiènes qui constituent les contrôle interne.

Et logiquement la réaction va avec ACT. On a détecté une intrusion ? On bloque l'attaque, on diagnostique l'impact, on corrige le problème.

Nous sommes sans doute arrivé à la même conclusion. Il y a du PLAN saupoudré dans chacune des phases précédentes. Mais non ! Mon idée est différente. Ces 3 phases sont opérationnelles et j'aimerai ajouter un besoin de gouvernance qui correspondrait au PLAN. En effet on a beau avoir peaufiné son firewall aux petits oignons avec une matrice de flux minimale. On a le dernier antivirus avec console centralisée qui supprime le moindre petit virus connu. Mais la technique ne suffit pas, il faut du recul et de la stratégie sans quoi on finit vite par tourner en rond. C'est ce que Andrew Jaquith appelle "the hamster wheels of pain" dans son livre "Security Metrics".