Aidez le commanditaire à prendre des décisions
Face aux résultats du test, le commanditaire va immédiatement se poser questions suivantes :
Que dois-je faire faire pour corriger ces vulnérabilités ?
Dans quel ordre ? Lesquelles sont acceptables à court terme ?
Combien vont me coûter les différentes corrections ?
Notre but en réunion de restitution est double :
Accompagner le commanditaire dans ses choix, en lui donnant un maximum d’éléments factuels et chiffrés.
Vulgariser notre expertise pour qu’il ait conscience des enjeux des différentes recommandations.
Si le client effectue déjà un management du risque sur d’autres sujets (sociaux, financiers, environnementaux, etc.), alors vous pouvez lui demander ses échelles pour les appliquer à votre analyse et votre rapport, pour qu’il s’y retrouve plus facilement. C’est son livrable, ne l’oubliez pas.
Si ce n’est pas quelque chose qu’il a l'habitude de faire, alors vous pouvez utiliser les vôtres, que vous aurez définies auparavant. L’important est que les échelles soient cohérentes, factuelles et comparables !
Les recommandations peuvent avoir plusieurs caractéristiques qui permettent de les ordonner, comme la priorité ; le coût ; la complexité ; ou encore la charge de travail nécessaire.
Personnellement, j’utilise court terme (moins d'1 mois) ; moyen terme (1 mois à 6 mois) ; long terme (6 mois et plus). La notion de “court terme” est très relative en fonction des entreprises ! On peut donc rajouter un niveau “très court terme” pour les recommandations très urgentes.
Mais comment décider de la priorité sans le faire au doigt mouillé ?
On décide en fonction de la vulnérabilité qu’elle corrige, et du risque qu’elle réduit ou atténue.
Si par exemple nous avons sur l’application une RCE (Remote Code Execution) pré-authentification (la pire espèce, la championne des vulnérabilités), il y a de fortes chances que ce soit celle-ci qu'on corrige en premier. Et ce, quel que soit le coût ou la complexité de la recommandation.
Ensuite, à priorité égale, comment aiguiller au mieux le commanditaire ?
Le coût, la complexité et la charge peuvent être confus pour ceux qui n'utilisent pas votre échelle sur une base régulière : si en fin de compte je fais intervenir des prestataires externes pour faire le travail, est-ce que c’est un coût ou est-ce que c’est du temps ? Ou les deux ?
Ok alors si ça prend une charge de travail conséquente, c’est que c’est complexe, et donc que c’est coûteux, non ?
Il n’y a à mon sens pas de bonne réponse, c’est pour ça qu’il faut faire un choix et l’expliciter dans les échelles. Mon postulat est le suivant :
Le coût représente les investissements financiers nécessaires (achat de matériel ou de licence pour un outil).
La charge de travail est toujours difficile à évaluer, car elle est très dépendante de l'inertie du commanditaire… On la compte en “charge jour/homme”.
Une modification dans la configuration du serveur, c’est relativement rapide à faire,
corriger toutes les requêtes SQL car vulnérables aux injections, ça va prendre un peu de temps mais ça reste raisonnable,
modifier complètement une cinématique vulnérable par conception risque en revanche de prendre un temps considérable.
La complexité est encore plus difficile à évaluer, car : "qu’est-ce qui est complexe ?" Je vais considérer comme complexe le fait de migrer une application plutôt ancienne vers un nouveau serveur car le serveur a été identifié comme obsolète, alors même que cette version de l’application n’est plus supportée par l’éditeur ou, pire, que l’éditeur n’existe plus. Tout cela va demander du temps, mais aussi, potentiellement, poser beaucoup d’autres problèmes.
Bien sûr ces échelles ne sont qu’indicatives, car pour chaque recommandation il existe parfois plusieurs solutions !
Imaginons par exemple qu’une de vos recommandations soit d’installer une solution de WAF. Cette recommandation en soi est tellement large qu’elle nécessite derrière un projet d'identification des besoins, de benchmark des solutions, de déploiement, puis de maintien en conditions opérationnelles pour être menée correctement ! Ou alors un client peut tout aussi bien décider de mettre en place un reverse proxy Apache avec quelques règles de filtrage, et ça ne lui aura pas coûté grand-chose (mais le résultat ne sera pas le même). Vous voyez un peu toute la difficulté de l’exercice ?
Facilitez l'implémentation de vos recommandations
Plus vous simplifiez la vie de votre commanditaire et de ses équipes, plus la qualité perçue sera élevée et la satisfaction au rendez-vous. J’ai trop entendu de la part de certains clients (en désignant d’autres rapports, bien entendu) ou vu sur Twitter des commentaires du style “Les recommandations ne sont pas claires / pas adaptées / pas réalistes…”.
Dans votre plan d’action, en plus de la priorité et des autres caractéristiques de la recommandation, je trouve pertinent et utile d’ajouter les équipes à qui elles s’adressent : système, réseau, développement, métier, etc.
Parmi les vulnérabilités que nous avons vues sur l'application example.com nous avons trouvé quelques XSS, et nous devons donc dire au client quoi faire.
Il manque, au minimum, le comment et le où.
Une recommandation plus détaillée pourrait être la suivante pour corriger les vulnérabilités XSS :
“Afin de corriger les vulnérabilités de Cross Site Scripting (XSS), il est nécessaire d’encoder les entrées des utilisateurs qui sont réaffichées dans le corps de la page. En PHP, la fonction
htmlspecialchars()permet de réaliser cet encodage automatiquement, par exemple. Les champs vulnérables suivants ont été identifiés :
aaa sur la page bbb ;
ccc sur la page ddd…
Toutefois, il est fortement recommandé d’effectuer une revue complète du code afin de corriger les champs vulnérables qui n'auraient pas été identifiés dans le temps imparti aux tests.“
Avec ça, normalement les différentes personnes ou équipes de notre commanditaire ont tous les éléments pour corriger la vulnérabilité que nous avons trouvée !
À vous de jouer !
Consigne
Je vous ai montré un exemple de recommandation. À vous de faire les autres !
Voici la liste des 16 vulnérabilités (au format Excel ou au format Open Document) que nous avons trouvées lors de notre test d’intrusion sur example.com.
Pouvez-vous rédiger les recommandations associées ?
Solution
En résumé
Le plan d’action que vous formalisez est une proposition à destination du commanditaire pour l’aider à prioriser les actions.
Votre plan d’action n’est pas un livre saint qui détient la vérité absolue.
Le plan d’action doit être directement actionnable pour votre commanditaire : sauf pour certaines recommandations complexes qui peuvent nécessiter des projets à part entière, le client devrait pouvoir immédiatement lancer la plupart des chantiers de correction.
Pour être actionnables, les recommandations doivent être priorisées, et posséder le maximum de caractéristiques utiles au client : coût évalué, temps de travail nécessaire, équipe type responsable, etc.
Les recommandations doivent être le plus détaillées possible pour laisser le minimum de place aux questionnements et à l'interprétation. Si vous pouvez faire référence à une documentation officielle (constructeur, éditeur, du langage, etc.), rajoutez-la !
