Ce que peut apporter l'automatisation de la réponse à incident

Malgré la médiatisation croissante des brèches et autres incidents de sécurité, de nombreuses équipes de réponse à incident restent en sous-effectifs ou peinent à recruter les compétences dont elles ont besoin.

Dès lors, beaucoup cherchent activement des opportunités d’automatisation de processus qui consomment tout simplement trop de temps pour des analystes dont les compétences pourraient être mieux mises à profit ailleurs, où ceux qui s’avèrent hautement répétitifs sans pour autant offrir une forte valeur ajoutée à l’enquête. Dès lors, il est tentant de chercher à automatiser des activités telles que les suivantes :

• identifier et corréler les alertes : de nombreux analystes consacrent un temps trop important à fouiner alertes et alarmes répétitives à partir de sources de logs et d’événements multiples. Ceci peut être très utile plus loin dans l’enquête, mais la nature répétitive de ces tâches appelle à un certain degré d’automatisation.
• identifier et supprimer les faux positifs : ceci peut être lassant lors d’une bonne journée, et tout simplement insupportable lors d’une mauvaise. Identifier les faux positifs peut souvent être industrialisé ou automatisé en utilisant des outils récents de gestion des événements ou d’automatisation de la réponse à incident.
• Investigation initiale et recherche de menaces : les analystes ont besoin de trouver rapidement des indicateurs de compromission ou d’activités inhabituelles. Et souvent, cela doit pouvoir se faire à grande échelle.
• Ouvrir ou mettre à jour un ticket/cas : grâce à l’intégration plus étroite avec les systèmes de gestion de tickets, les outils de gestion des événements et de supervision utilisés par les équipes de réponse à incident peuvent souvent générer des tickets adressés aux bonnes personnes, et les mettre à jour à mesure qu’arrivent les indices.
• Production de rapports et d’indicateurs : une fois que les indices ont été collectés, que les cas sont en traitement ou en voie de résolution, générer des rapports et des indicateurs peut demander beaucoup de temps.

James Carder et Jessica Hebenstreit de Mayo Clinic ont présenté plusieurs exemples tactiques de réponse à incident automatisée lors d’une allocution sur RSA Conference 2015 : automatisation des requêtes DNS sur des noms de domaine non observés antérieurement ; automatisation de recherche autour des indicateurs de compromission détectés ; automatisation de la production d’images disque et mémoire pour l’inspection de systèmes à l’origine d’alertes ; blocage automatique des communications avec des serveurs de commande et de contrôle à partir d’un système suspect.

Il y a bien d’autres domaines où l’automatisation de la réponse à incident peut aider, notamment la collecte d’indices, la recherche de menaces, ou encore la mise en quarantaine de systèmes suspects.

Les fournisseurs de solutions de sécurité pour les points de terminaison ont commencé à insister sur l’automatisation des activités de réponse, et sur l’intégration avec les capacités de détection, réponse et investigation. Les analystes ont besoin de rapidement identifier les indicateurs de compromission et de les chercher sur d’autres systèmes. Automatiser tout cela autant que possible est un objectif poursuivi par tous.

Plusieurs éditeurs proposent des outils et des plateformes aidant à cela : Swimlane, FireEye, CyberSponse, Phantom, IBM Resilient, Hexadite – racheté par Microsoft –, et plus encore. En se penchant sur leurs offres, il est important d’étudier leur maturité, les capacités d’intégration, avec tout son environnement de sécurité, jusqu’à son système de gestion des informations et des événements de sécurité.

La réponse à incident pour le Cloud peut demander plus de scripting, d’automatisation et de supervision en continu que la réponse à incident en interne. Actuellement, nombre des outils de détection et de réponse pour le Cloud sont largement taillés pour l’automatisation. Et cela souvent pour un jeu d’API spécifique à un fournisseur Cloud, largement Amazon Web Services (AWS), pour le moment.

Teri Radichel s’est longuement penché sur l’automatisation de la réponse à incident automatisée pour AWS et propose une trousse à outil pour aider. La boîte à outils ThreatResponse développée par Andrew Krug, Alex McCormack, Joel Ferrier et Jeff Parr peut également être utilisée pour automatiser la collecte d’indices, l’investigation et le reporting d’incidents dans les environnements cloud.

Mais pour implémenter une véritable réponse à incident automatisée pour le Cloud, il est nécessaire de construire des mécanismes déclencheurs qui surveillent l’environnement en continu, comme les filtres AWS CloudWatch. Le mise en place de tels filtres nécessite toutefois une phase préalable d’analyse en profondeur, ne serait-ce que pour déterminer des comportements normaux.