SecBI veut soulager le travail des analystes SOC

Eviter un travail usant

Début 2015, Alex Vaystikh résumait la situation : « c’est un problème lié au manque d’outils pour nous aider. Nous sommes très bons à détecter des motifs et, en conséquence, très mauvais à remarquer des détails, en particulier lorsque l’on est submergé par des données similaires ».  

Gilad Peleg explique donc l’approche de SecBI : « on ne veut pas bombarder les analystes avec des alertes sporadiques, ni l’envoyer à la poursuite d’alertes distinctes pour comprendre l’ensemble d’un incident. Nous voulons l’aider en lui présentant des incidents recouvrant plusieurs alertes, et lui permettre de les appréhender dans leur globalité, depuis leur point de départ ».

Et la logique semble fonctionner. Gilad Peleg évoque l’exemple d’une institution financière de 5000 collaborateurs avec laquelle SecBI a réalisé un pilote : « nous avons collecté 3,5 milliards de journaux syslog représentant un mois d’activité » dont l’analyse a permis d’identifier trois utilisateurs dont les machines avaient été compromises par Dridex. Leurs machines « communiquaient avec une dizaine de domaines sporadiques, sans qu’un réel motif n’apparaisse. Elles échangeaient aussi avec 20 adresses IP différentes pour lesquelles aucune information de threat intelligence n’était disponible. Cinq mégaoctets de données avaient été exfiltrés, mais sur 14 points de dépôt différents, et le tout chiffré ». Mais les indices de cet incident étaient disséminés au travers de 200 journaux : « une vingtaine d’entre eux avaient généré des alertes […] Pour un analyste, cela veut dire fouiller parmi 180 journaux d’événement apparemment anodins. Et faire ça vingt fois parce qu’il n’y a personne pour vous indiquer que ces alertes sont liées ».

Recouvrir à l’apprentissage machine

Pour fonctionner, la plateforme de SecBI s’alimente auprès des équipements réseau, rappelant ainsi l’approche de Darktrace. La première étape consiste donc à « extraire les informations des logs. Beaucoup de choses peuvent être collectées ». Mais l’une des principales difficultés consiste à replacer ces données dans un contexte, pour notamment reconstruire les sessions des utilisateurs – et pas sous un angle strictement technique bas niveau.

Ce travail permet aux algorithmes d’apprentissage automatique – machine learning – d’associer les événements à des clusters. Car contrairement à d’autres comme PatternEx, SecBI a fait le choix de l’apprentissage automatique non supervisé : il n’est pas question de pointer des exemples à la machine pour apprendre comment classifier des événements ; c’est à elle d’en découvrir la structure cachée en constituant des groupes plus ou moins homogènes. Les clusters ainsi construits « représentent l’activité d’un ou plusieurs utilisateurs sur une période données ».  

Gilad Peleg indique de SecBI développe en interne ses propres algorithmes et insiste sur le fait que les clusters comportementaux établis par ceux-ci peuvent concerner plusieurs utilisateurs : « avec un seul, le rapport signal/bruit est très bas. Plus le cluster concerne d’utilisateurs, plus ce rapport est élevé ». Et plus le sont aussi les chances de trouver des anomalies.

Les incidents détectés sont ensuite présentés aux analystes de manière consolidée, avec pour chaque attaque des éléments de chronologie, la liste des indicateurs découverts, les systèmes compromis ou encore la nature de l’attaque.

C’est fin septembre qu’Orange Digital Ventures a annoncé avoir pris une participation dans SecBI. Et l’on imagine bien l’intérêt du groupe par cette jeune pousse alors que sa division Cyberdéfense vient de présenter une offre de SOC managé qui aucune 120 personnes réparties entre la France et l’Inde.