Comment Rédiger un Constat de Risque sur lequel l'Entreprise Agira?

La plupart des constats de sécurité meurent dans une feuille de calcul parce qu'ils sont rédigés pour d'autres spécialistes de la sécurité, pas pour la personne qui approuve le budget. Si votre rapport dit « CVE-2023-XXXX, CVSS 9.8, appliquer le correctif immédiatement », vous avez décrit une vulnérabilité, pas un risque. L'entreprise n'agit pas sur les vulnérabilités. Elle agit sur les conséquences qu'elle peut visualiser.

Pourquoi les scores de sévérité seuls ne convainquent personne

CVSS vous dit à quel point une faille est grave en isolation. Cela ne dit rien sur le fait que la faille soit accessible, sur l'importance de l'actif protégé pour le chiffre d'affaires, ou sur le fait que des contrôles compensatoires l'atténuent déjà. Un 9.8 sur une boîte de développement interne sans chemin Internet et sans données sensibles n'est pas la même conversation qu'un 7.5 sur la passerelle de paiement. Si vous classez les constats uniquement par CVSS, vous allez dépenser votre crédibilité à corriger des choses que personne n'aurait jamais exploitées, et le constat qui importait réellement se perd dans le bruit.

Le risque sur lequel on agit a trois ingrédients : un chemin plausible vers l'impact, un coût en dollars ou opérationnel attaché à cet impact, et un propriétaire qui peut réellement le corriger. Manquer l'un de ces trois éléments et le constat reste dans le backlog.

Construisez le constat autour d'un scénario, pas d'une sortie de scanneur

Au lieu de « Injection SQL détectée sur le endpoint /login », écrivez le scénario : « Un attaquant non authentifié peut extraire la table complète des clients, y compris les mots de passe hachés et les adresses de facturation, via le formulaire de connexion. Cette table supporte 40 000 comptes actifs et la même base de données contient l'historique des commandes lié à la portée PCI. » Maintenant, le lecteur ne parse pas une classe de vulnérabilité, il se représente une lettre de notification de violation et un appel de conformité.

Une structure utile pour chaque constat :

• Ce qui peut se passer — le chemin d'attaque en langage courant, une ou deux phrases.
• Ce qu'il touche — système spécifique, données spécifiques, processus métier spécifique.
• Quel en est le coût — heures d'indisponibilité, exposition réglementaire, confiance des clients, pénalités contractuelles. Utilisez des chiffres réels quand vous les avez (clauses de pénalité SLA, coûts d'incidents passés, franchise d'assurance cyber).
• Ce qu'il faut pour corriger — effort, pas seulement « appliquer le correctif ». Parfois la correction est une règle WAF aujourd'hui et un changement de code au prochain sprint.
• Qui est responsable de la correction — un nom ou une équipe, pas « IT ».

Liez le constat à quelque chose que l'entreprise suit déjà

Chaque entreprise a des métriques que la direction regarde déjà : les SLA de disponibilité, l'attrition, les constats d'audit du dernier cycle SOC 2, les primes d'assurance cyber, un contrat client spécifique avec une clause de sécurité. Si vous pouvez connecter votre constat à l'une de ces lignes existantes — « c'est la même classe de problème que notre assureur a relevée au dernier renouvellement » ou « ce flux de données est dans la portée de l'audit SOC 2 au Q3 » — vous ne leur demandez pas de se soucier de quelque chose de nouveau. Vous leur montrez une menace pour quelque chose dont ils sont déjà responsables.

C'est aussi là où communiquer avec le côté métier avant de finaliser le rapport paie. Une conversation de dix minutes avec la finance ou les opérations sur le coût réel d'une panne de quatre heures sur un système spécifique vaut mieux qu'une ligne générique sur les « dommages à la réputation ». Obtenez le chiffre, citez-le, passez au suivant.

Classez par exploitabilité et rayon d'explosion, pas seulement par CVSS

Une approche de priorisation fonctionnelle :

1. Est-ce accessible depuis Internet ou faut-il d'abord un accès interne?
2. Y a-t-il un exploit public ou est-ce théorique?
3. Touche-t-il des données réglementées (PCI, PHI, PII) ou des systèmes critiques?
4. Quel est le coût réel en temps et en efforts pour remédier par rapport au coût de laisser traîner?

Les constats qui marquent haut sur l'accessibilité et le rayon d'explosion mais seulement moyen sur CVSS méritent souvent de passer avant un bug noté critique enterré trois sauts réseau derrière une boîte de saut avec MFA.

Écrivez la demande, pas seulement le problème

Terminez chaque constat par une demande spécifique : une ligne budgétaire, une fenêtre de changement, une exception de politique à fermer, ou une décision nommée requise à une date. « Nous recommandons la correction » est ignoré. « Nous avons besoin d'une fenêtre de maintenance de quatre heures avant le 15 pour corriger la passerelle de paiement, ou nous acceptons le risque résiduel par écrit » force une décision d'une façon ou de l'autre. Donner à la direction une option explicite d'accepter le risque, par écrit, avec leur nom dessus, est souvent ce qui finit par faire approuver la correction.

Si vous voulez vous entraîner à transformer la sortie brute d'un scanneur en constats comme celui-ci, parcourez ensemble les segments Blue Team et Offensive de Korra Studio — combiner le contexte d'exploitation avec des exercices de rapport, c'est là que cette compétence se développe réellement.