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 ?