Alerting distribué avec la Suite Elastic

Les mains-d'œuvre distribuées et les environnements informatiques actuels posent des défis inédits aux approches de sécurité des informations traditionnelles. Nombre de stratégies traditionnelles de détection des menaces et de réponse se fondent sur des environnements homogènes, des points de comparaison système et des mises en œuvre de contrôles cohérentes. Ces stratégies ont été conçues selon des suppositions concernant les environnements traditionnels qui peuvent ne plus s'avérer exactes au sein de votre environnement face à l'évolution du cloud computing, du travail à distance et de la culture moderne.

Elastic est une entreprise génétiquement distribuée, depuis ses technologies jusqu'à sa main-d'œuvre. Les Elasticiens sont autonomisés afin qu'ils puissent travailler de n'importe quel emplacement, aux horaires de leurs choix et selon leurs méthodes de prédilection. Cette flexibilité comprend les technologies qu'ils utilisent, les configurations dont ils ont besoin et les logiciels qu'ils préfèrent. Cette culture moderne de la productivité pose un nouveau défi en matière de sécurité des informations. 

Comment pouvons-nous sécuriser un environnement au sein duquel des activités à haut risque peuvent être menées, comme la création d'utilisateurs, la configuration de proxys de réseau et l'installation de nouveaux logiciels sans l'aide du service informatique ? Comment pouvons-nous appliquer des détections à un environnement sans point de comparaison pour les activités ? Comment pouvons-nous scaler notre pratique de détection et de réponse au sein d'une entreprise moderne menant des opérations sur différents sites, voire dans plusieurs pays ? Comment pouvons-nous y parvenir sans un centre opérationnel de sécurité traditionnel ?

Rien de plus simple. Nous envoyons une alerte aux personnes qui sont en mesure de confirmer ou de refuser l'activité via notre framework d'alerting distribué. 

Grâce à l'alerting distribué, notre équipe en charge de la détection des menaces et de la réponse identifie automatiquement les activités à risque, envoie un message à notre personnel en langage naturel et demande une confirmation de l'activité. Si l'Elasticien concerné ne reconnaît pas l'activité, l'alerte peut être immédiatement remontée à notre équipe en charge de la réponse aux incidents à des fins de résolution. Voici un exemple d'alerte distribuée envoyée aux membres de notre personnel lorsqu'un nouveau périphérique à authentification multifacteur est enregistré dans leur compte.

Si la personne concernée reconnaît l'activité, elle doit cliquer sur le bouton YES: This Was Me (Oui, c'était moi). Une invite s'affiche et lui demande de fournir des informations supplémentaires qui pourraient être utiles pour expliquer l'activité ou adapter les opportunités.

Sur le back-end, un nouvel incident de sécurité est créé, des alertes y sont associées, les informations connexes sont consignées et l'incident est classé dans la catégorie "No Impact" (Pas d'impact) avec un récapitulatif pour le rapport quotidien.
Si la personne concernée ne reconnaît pas l'activité, elle doit cliquer sur le bouton NO: Escalate to InfoSec (Non, faire remonter au service chargé de la sécurité des informations). Ainsi, un nouvel incident de sécurité est créé, un canal Slack est ouvert, l'équipe chargée de la réponse aux incidents et l'auteur de la notification sont ajoutés au canal, puis toute information supplémentaire est fournie à l'équipe.

En envoyant ces activités directement aux personnes qui sont le mieux à même de confirmer cette activité, nous pouvons conserver les taux de vrais et faux positifs de nos détections. En outre, nous diminuons le temps de résolution pour l'ensemble de ces détections "difficiles" relatives aux activités représentant un risque élevé si elles proviennent d'utilisateurs malveillants, mais surviennent régulièrement dans notre environnement. 

Qu'est-ce qu'une bonne alerte distribuée ?

Il s'agit des activités présentant un risque élevé pour votre niveau de sécurité, mais ne sont inscrites dans aucun contexte ou ne semblent pas être malveillantes. Par exemple, une alerte unique déclenchée par l'enregistrement d'un nouveau périphérique à authentification multifacteur pour un utilisateur ne fournit aucun contexte sur l'intention de l'activité. Les utilisateurs ajoutent régulièrement sur leur compte de nouveaux périphériques à authentification multifacteur. Cependant, s'il s'agit du périphérique d'un utilisateur malveillant, le compte sera considéré comme compromis, car toutes les authentifications suivantes seraient réalisées à l'aide d'un périphérique à authentification multifacteur valide. Ce scénario constitue une situation difficile pour les équipes chargées de la détection des menaces et de la réponse. Comment pouvons-nous valider ces activités dénuées de contexte sans enquêter sur chacun de leurs détails ? Nous distribuons ces alertes.

Pour obtenir davantage de contexte, voici notre stratégie de détection des menaces. Nous avons plusieurs idées qui fournissent une couverture complète des activités système.

Nous classons les événements dans trois catégories différentes.

• Logs : il s'agit de tous les événements survenant sur un système. Les logs sont souvent inclus dans les investigations pour comprendre ce qu'il s'est passé. Un événement de log n'est pas révélateur d'une activité suspicieuse. Il consigne simplement ce qui s'est passé.
• Signaux : nous utilisons l'application Elastic Security pour générer des signaux. Les règles de détection sont conçues pour identifier les activités susceptibles d'indiquer une activité suspicieuse. Toutefois, il peut aussi s'agir d'une activité sans risque. Le contexte de ces événements est difficile à établir à partir d'un événement unique. Par conséquent, il ne s'agit pas d'une alerte immédiate. Les recherches des menaces sont conçues à l'aide de signaux afin d'identifier toute activité connexe pouvant être utilisée pour repérer les contenus malveillants ou sans risque et ainsi adapter la règle de détection grâce au signal d'une alerte.
• Alertes : nous promouvons les signaux d'alerte lorsque nous avons une confiance élevée dans le fait qu'ils indiquent une activité malveillante ("Likelihood of Malicious Activity" ou probabilité d'une activité malveillante). Lorsqu'une activité a un tel impact élevé, tous les événements doivent être validés pour réduire la probabilité de l'impact ("Impact if Malicious" ou "Impact en cas d'activité malveillante).

Les alertes à impact élevé mais peu susceptibles d'indiquer une activité malveillante représentent une formidable opportunité pour la distribution des alertes. Ainsi, nous pouvons valider les activités administratives, inédites, anormales provenant des utilisateurs ou toutes les autres survenant à l'échelle de l'entreprise dans nécessiter le recours à un centre opérationnel de sécurité traditionnel.

Comment distribuons-nous les alertes ?

Dans le cadre de notre approche tout compris des produits Elastic, notre Suite Elastic se situe au centre de notre architecture SIEM et SOAR. Pour en savoir plus la méthode d'ingestion de toutes nos données dans la Suite Elastic, lisez notre article intitulé Elastic sur Elastic : données recueillies dans le SIEM de sécurité des informations.

Nous avons actualisé notre architecture pour garantir la prise en charge de cette nouvelle fonctionnalité d'alerting distribué.

Nous avons créé une plateforme d'automatisation afin de centraliser nos workflows dans la plateforme d'automatisation sans code de Tines. En utilisant les workflows intégrés à Tines, les alertes provenant de la Suite Elastic sont triées et distribuées en fonction de la logique prédéfinie dans les témoignages de Tines.

Lorsque la balise DISTRIBUTE_ALERT est attribuée à une règle de détection à des fins de distribution, Tines redirige l'alerte depuis la file d'attente de tris des alertes vers le workflow d'alerting distribué.

Toutes les alertes dotées de la balise DISTRIBUTE_ALERT seront traitées dans le cadre de notre workflow d'alerting distribué. Le workflow de Tines identifie l'utilisateur concerné dans la base de données des ressources, puis envoie l'alerte à l'utilisateur via Slack à des fins de confirmation.

Lorsque l'utilisateur clique sur le bouton dans l'alerte, il lance le workflow ci-dessous pour demander des informations supplémentaires ou transférer l'alerte à l'équipe chargée de la réponse aux incidents.

Ces alertes créent automatiquement un nouvel incident dans la solution Elastic dédiée qui est doté de toutes les informations pertinentes. Nous utilisons des automatisations supplémentaires pour fournir aux analystes des enrichissements, comme GreyNoise et les alertes Elastic Security connexes. Les 30 derniers jours d'activité pour l'adresse IP sont également fournis dans une chronologie Elastic destinée aux analystes à des fins d'examen.

Lorsque l'utilisateur fournit ses commentaires et confirme l'activité, son avis est enregistré dans l'incident, qui est ensuite classé. 

Comment puis-je me lancer ?

Vous pouvez débuter un essai gratuit de 14 jours d'Elastic Cloud et utiliser l'exemple de témoignage de Tines intitulé Triage Elastic Security alerts and block malicious IPs (Tri des alertes d'Elastic Security et blocage des adresses IP malveillantes) pour commencer à ingérer les alertes d'Elastic Security dans vos workflows d'automatisation. Ensuite, vous devrez les intégrer dans le client de messagerie de votre choix. Tines offre des exemples de témoignages dans sa bibliothèque pour Slack et Microsoft Teams.