Reporting Format

La première chose que nous voulons dire est qu'il n'existe pas de format standard pour les rapports d'incidents. Malheureusement, il n'existe pas de modèle magique qui convienne à toutes les équipes de sécurité de toutes les organisations du monde. Cependant, il est courant de voir quatre sections principales d'un rapport, que nous aborderons plus en détail ci-dessous :

• Résumé exécutif
• Chronologie de l'incident
• Enquête sur un incident
• Appendice

Résumé exécutif

C'est généralement là que sera présentée la vue d'ensemble de haut niveau de l'incident, en utilisant des termes non techniques pour indiquer clairement l'impact commercial. Les cadres étant très occupés, il est de notre devoir de veiller à ce que cette section soit facilement lisible et contienne des informations importantes pour ce public spécifique.

Le résumé devrait idéalement comporter une page et se concentrer sur des domaines tels que les risques commerciaux, les coûts financiers et les dommages survenus et évités. C'est l'endroit idéal pour vraiment mettre en lumière le travail de l'équipe de sécurité et la manière dont elle a évité d'autres dommages et coûts (en maîtrisant un incident, en empêchant l'exfiltration de données, en détectant une menace interne, etc.). Cela montrera aux dirigeants que le coût de fonctionnement de l'équipe de sécurité est inférieur à celui des incidents réussis, démontrant ainsi l'intérêt de maintenir (et peut-être même de développer) l'équipe.

Chronologie de l'incident

La chronologie indiquera la date, l'heure et de brèves descriptions de tous les événements clés survenus tout au long de l'incident. Cela peut être soit dans l'ordre dans lequel ces actions ont été entreprises ou découvertes, soit dans un ordre chronologique afin de faciliter la lecture exacte de ce qui s'est passé du début à la fin. Il est fréquent que les équipes de sécurité utilisent leur fuseau horaire local (à condition que l'incident n'ait touché qu'un seul lieu géographique) ou le temps universel coordonné (UTC) si l'incident touche des utilisateurs ou des systèmes sur plusieurs fuseaux horaires. La conversion de plusieurs fuseaux horaires en un seul garantit que la chronologie reste claire et facile à lire et à consulter.

Enquête sur un incident

Il s'agira de la majeure partie du rapport, fournissant une documentation étape par étape des actions menées et des conclusions connexes des intervenants en cas d'incident. Toutes les étapes du cycle de vie de la réponse aux incidents doivent être prises en compte et signalées, à l'exception de la préparation :

• Détection et analyse — Comment l'incident a-t-il été découvert ? S'agissait-il d'une alerte SIEM ? Une chasse aux menaces ? Un utilisateur ou un administrateur système qui a signalé quelque chose d'inhabituel ? Comment cette activité a-t-elle été triée pour s'assurer qu'il

s'agissait d'un incident et non d'un faux positif ? Des contrôles ont-ils été effectués sur le ou les systèmes concernés ou le trafic réseau a-t-il été collecté et analysé ? Des captures d'écran doivent être utilisées pour montrer exactement quelles mesures ont été prises et ce que les intervenants chargés de l'enquête ont vu lors de l'analyse.

• Confinement, éradication et rétablissement : comment l'incident a-t-il été défini ? N'oubliez pas qu'il s'agit sans doute de la partie la plus importante d'une réponse. Nous devons nous assurer d'avoir trouvé tous les systèmes affectés afin d'éviter une réinfection à une date ultérieure. Comment l'équipe de sécurité a-t-elle retiré le ou les acteurs des réseaux ? Les systèmes ont-ils été restaurés à partir de sauvegardes dont la sécurité était connue ? Un antivirus a-t-il été utilisé pour scanner tous les systèmes, parallèlement à des vérifications manuelles via une solution EDR ? Les systèmes ont-ils été complètement mis hors service ? Et quelle en était la cause première ? Une identification correcte de ce problème nous permettrait, en tant que défenseurs, de résoudre le problème et de faire en sorte qu'un incident similaire ne se reproduise pas.
• Activité après l'incident — Qu'est-ce qui aurait pu être amélioré ? L'équipe de sécurité a peut-être besoin de plus de personnel, d'outils supplémentaires ou d'une plus grande visibilité sur les réseaux et les systèmes. Tout cela doit être expliqué ici pour aider à prendre des décisions visant à prévenir les incidents futurs ou à permettre à l'équipe de mieux y répondre. Tout élément important doit être inclus dans le résumé afin de garantir qu'il soit perçu par les décideurs commerciaux de haut niveau.

Annexe du rapport

L'annexe sert de stockage pour le rapport et inclut généralement des images ou des figures (graphiques, tableaux) qui seront référencées dans le corps principal du rapport. Un exemple de contenu pouvant être inclus dans cette section inclut une longue liste d'adresses IP qui ont été analysées pour rechercher des indicateurs malveillants. Cette liste ou ce tableau devrait être inclus ici car cela occuperait beaucoup de place dans le rapport « d'enquête sur l'incident ».

Modèles de rapports

Nous ne le soulignerons jamais assez : un modèle ne convient pas à tout le monde. Cela variera d'une organisation à l'autre, en fonction des informations les plus importantes pour elles. Cependant, les sections que nous avons mentionnées ci-dessus sont les plus courantes susceptibles de figurer dans la plupart des rapports d'incidents.