Incident Response Metrics

Les métriques sont des valeurs numériques utilisées à des fins d'évaluation quantitative, qui nous permettent d'évaluer, de comparer et de suivre les performances. En ce qui concerne la réponse aux incidents, elle peut mettre en évidence les domaines dans lesquels l'équipe a réagi de manière efficace ou inefficace. Ces indicateurs peuvent également aider à identifier les tendances des incidents auxquels l'organisation est confrontée afin d'y remédier, en utilisant des indicateurs pour étayer une analyse de rentabilisation visant à obtenir davantage de budget ou de personnel.

Il existe de nombreuses options différentes pour utiliser des métriques afin de résumer la réponse à un incident et de la comparer aux incidents précédents et futurs. Dans cette leçon, nous aborderons

plusieurs indicateurs courants pouvant être utilisés à des fins de reporting, permettant aux équipes de sécurité de mettre en évidence leurs forces et leurs faiblesses et de les utiliser pour prendre des décisions commerciales telles que l'augmentation des effectifs ou du budget.

Veuillez noter que différentes organisations utiliseront des métriques différentes. Ceci a pour but de vous donner une idée générale des métriques qui peuvent être enregistrées.

Métriques d'impact

• Contrat de niveau de service (SLA) — Les SLA sont un accord entre une organisation et son client qui détermine les attentes en matière de disponibilité, de réactivité et de responsabilités des deux parties. Ceci est souvent calculé à l'aide de pourcentages, deux des plus courants étant 99 % et 99,9 %.
• Objectif de niveau de service (SLO) : les SLO sont un accord qui existe au sein du SLA et qui détermine l'indicateur spécifique à mesurer, tel que le temps de disponibilité d'une machine virtuelle critique. La mesure de ces objectifs peut engager la responsabilité à la fois de l'organisation et potentiellement du client dans le cas où l'objectif n'est pas atteint.
• Taux d'escalade : cet indicateur mesurera la fréquence à laquelle les alertes de votre SIEM sont attribuées au bon membre de l'équipe de sécurité. Cela permet d'empêcher un tout nouvel analyste de recevoir une alerte concernant une attaque sophistiquée par rançongiciel et de l'ignorer ou de s'en charger lui-même, au lieu de transmettre l'alerte à un analyste de niveau supérieur qui a déjà traité ce ransomware et connaît les signes d'une violation.

Métriques basées sur le temps

• Temps moyen de détection (MTTD) : également connu sous le nom de délai de réception (MTTA), il s'agit du temps moyen nécessaire à l'équipe de sécurité pour remarquer qu'un incident de sécurité s'est produit. Il est important de mesurer cette métrique car elle peut contribuer à accroître l'efficacité des alertes envoyées à un SIEM ou à une autre plateforme de journalisation.
• Temps moyen de réponse (MTTR) : également appelé délai de réparation, de résolution ou de restauration, il s'agit du délai entre la détection d'un problème et le moment où l'équipe de sécurité peut prendre des mesures pour y remédier. Il s'agit souvent de l'un des indicateurs les plus importants à suivre, car il peut montrer l'efficacité de l'équipe lorsqu'elle a répondu à l'incident et peut aider à identifier les principaux domaines dans lesquels le temps de réponse pourrait être amélioré.
• Incidents au fil du temps : cet indicateur examine le nombre moyen d'incidents sur une période donnée afin de déterminer s'il y a une augmentation ou une diminution du nombre d'incidents. Cette métrique permet de déterminer si des modifications doivent être apportées pour renforcer la sécurité afin de prévenir les incidents ou pour déterminer si la baisse du nombre d'incidents est liée à un autre événement.
• Délai de correction : combien de temps a-t-il fallu aux équipes d'intervention en cas d'incident et aux parties prenantes concernées pour remédier à la situation (restauration de tous les systèmes affectés et retour à l'état de production) ?

Métriques des types d'incidents

• Nombre cumulé d'incidents par type : en classant les incidents en fonction de leur type et en comparant le nombre total de chaque catégorie d'incidents, cela peut fournir aux équipes de sécurité une vue d'ensemble des domaines dans lesquels des améliorations doivent être apportées. Par exemple, si une entreprise est confrontée à un grand nombre d'incidents provoqués par des attaquants exploitant les vulnérabilités de systèmes connectés à Internet, elle devra exécuter le processus de gestion des vulnérabilités pour corriger ces systèmes et appliquer des contrôles d'atténuation tels que des pare-feux pour applications Web et des proxys.
• Alertes créées par incident : cette métrique permet d'analyser le nombre d'alertes créées pour un incident spécifique. Par exemple, lors d'un incident, l'EDR a-t-il envoyé une alerte indiquant qu'un fichier malveillant avait été téléchargé, mais votre environnement O365 n'at-il pas généré d'alerte également ? Cette métrique peut vous aider à déterminer à quel stade du processus de la Cyber Kill Chain vous pouvez améliorer vos défenses et, dans cet exemple, empêcher le téléchargement du logiciel malveillant.
• Coût par incident (CPI) : cet indicateur analyse le coût perçu de l'incident au sein de l'entreprise concernée et peut être analysé de différentes manières. L'une des méthodes consiste à analyser la durée de l'incident et à la multiplier par le coût de l'équipe de sécurité et/ou des membres de l'équipe qui ont travaillé sur le dossier et l'ont résolu. Une autre méthode est calculée en analysant l'impact de l'incident sur l'entreprise, tel qu'une perte de ventes, une perte de productivité ou la destruction d'équipements ou d'ordinateurs. Cette métrique peut s'avérer particulièrement utile lorsqu'une analyse d'impact commercial (BIA) a déjà été réalisée avec le client afin d'établir les coûts de base de son organisation.