Reporting Considerations

Nous devons prendre en compte un certain nombre d'éléments lors de la rédaction d'un rapport ou d'une documentation similaire après un incident. Nous examinerons les considérations suivantes dans cette leçon :

• Audience du rapport
• Enquête sur un incident
• Captures d'écran et légendes

Audience du rapport

Comme indiqué dans la leçon précédente, les rapports d'incidents s'adressent généralement à différents publics, en particulier aux membres du conseil d'administration, au personnel informatique et à l'ensemble de l'équipe de sécurité. Nous devons nous assurer que chaque section est adaptée au public cible, en nous assurant qu'elle contient le niveau de détail et le jargon technique appropriés.

• Résumé — Ce résumé doit être court, doux et traiter de l'ensemble de l'incident à un niveau élevé. Cela signifie que les termes et expressions techniques doivent être évités et que l'incident doit être expliqué en utilisant les risques commerciaux. Par exemple, si un incident se produit alors que le site Web de l'entreprise a été défiguré, le résumé doit expliquer comment l'incident a été découvert, comment il a été résolu et comment cela aurait pu affecter l'entreprise s'il n'avait pas été traité rapidement (perte de ventes, atteinte à la réputation, perte de confiance des clients, etc.). Il est également important de se rappeler que les dirigeants sont très occupés et qu'ils ne liront probablement que le résumé. Nous devons faire en sorte que cela ait le plus d'impact possible.
• Reste du rapport — Le reste du rapport est généralement destiné au personnel technique. Il doit donc inclure de nombreux détails, des captures d'écran annotées et doit utiliser un langage technique le cas échéant.

Enquête sur un incident

Cette section doit être détaillée. Très détaillé. Tous vos arguments doivent être étayés par des preuves, sinon ce ne sont que des spéculations (essayez de ne pas le faire, s'il n'y a aucune preuve, vous ne pouvez pas prouver que cela s'est réellement produit). Imaginons par exemple que nous enquêtions sur un système compromis par un e-mail de phishing contenant un document Microsoft Word contenant une macro malveillante qui télécharge des logiciels malveillants sur le système. Nous pouvons affirmer qu'un e-mail de phishing a été le vecteur d'accès initial, mais nous devons fournir des preuves. Cela peut inclure une capture d'écran de l'e-mail, une capture d'écran du contenu des macros malveillantes, une capture d'écran des journaux SIEM montrant le balisage sortant et le téléchargement du logiciel malveillant, etc. Essayez de suivre l'approche ci-dessous : Make a Point > Fournissez des preuves.

Pour les équipes de sécurité, il est utile d'inclure également les tactiques MITRE ATT&CK qui ont été utilisées. En continuant avec l'exemple ci-dessus concernant le phishing, ce qui suit serait applicable :

Captures d'écran et légendes

Les captures d'écran sont un excellent moyen de fournir des preuves. Vous vous souvenez du dicton « une image vaut mille mots » ? Eh bien, cela s'applique vraiment aux rapports de sécurité (pas seulement à la gestion des incidents, mais aussi aux tests de pénétration !). Nous avons mentionné cidessus le processus « Make a Point > Provide Evidence », et les captures d'écran sont le moyen idéal pour y parvenir. Si vous parlez d'un scan de port effectué d'un système interne à un autre et que vous avez des PCAP disponibles, alors faites une capture d'écran Wireshark avec un filtre montrant l'activité de numérisation ! Si vous affirmez qu'un adversaire s'est déplacé d'un système à l'autre en réutilisant des mots de passe, fournissez des captures d'écran des événements de connexion provenant du SIEM, des journaux d'accès locaux ou de tout autre élément indiquant cette activité.

Toutes les images doivent également être sous-titrées avec une ou deux phrases courtes, résumant ce qui est affiché sur la capture d'écran. Cela permet aux utilisateurs de digérer rapidement les informations au cas où ils ne comprendraient pas parfaitement ce qu'ils regardent (par exemple, les résultats d'un outil qu'ils n'ont jamais utilisé auparavant).