Jask veut aider les SOC à être plus efficaces malgré des effectifs limités

Greg Martin et Damian Miller ont fondé Jask à l’été 2015. Et tout deux connaissent bien le domaine de la sécurité informatique et en particulier, le travail dans les centres opérationnels de sécurité (SOC), notamment avec les systèmes de gestion des informations et des événements de sécurité (SIEM).

Greg Martin, Pdg de Jask, est ainsi un ancien d’ArcSight, mais également fondateur et ancien directeur technique de ThreatStream, éditeur d’une plateforme de gestion du renseignement sur les menaces rebaptisée depuis Anomali. Damian Millier, directeur stratégie de Jask, est quant à lui passé par McAfee/Intel Security où il a été consultant solutions. C’était après 8 ans passé chez HP, dans le domaine de la sécurité. Avant cela, il était chez ISS, bien avant son rachat par IBM en 2006.

C’est de ces expériences qu’est née l’idée de Jask : une plateforme cloud de gestion des incidents de sécurité mettant à profit des techniques d’intelligence artificielle – dont bien sûr l’apprentissage automatique, mais également l’apprentissage profond – pour aider les analystes de SOC à être plus efficaces, malgré des ressources humaines toujours limitées. Dans un entretien avec la rédaction, Greg Martin rappelle un constat largement partagé : « nous n’avons pas assez de ressources qualifiées disponibles pour faire face à la fréquence et à la sophistication des attaques ». Pire encore, pour lui, le rythme est tout simplement intenable humainement.

Cette ambition revendiquée n’est pas sans rappeler celle qu’affichent des Exabeam, Siemplify, ou encore SecBI. Greg Martin accepte d’ailleurs bien volontiers le parallèle, se revendiquant de « cette poignée de challengers » qui viennent défier des acteurs traditionnels du SIEM comme ArcSight, IBM ou Splunk. Mais le créateur de Jask souligne une exigence : le recours à l’apprentissage automatique, par option à une automatisation à base de scripts, et une approche centrée sur le cloud.

La plateforme de Jask, basée sur Apache Spark, promet tout d’abord de consolider automatiquement les événements de sécurité relatifs à une alerte pour ne présenter que celle-ci, de manière complète et cohérente, quelle que soit l’étendue chronologique considérée. Elle s’appuie pour cela sur un moteur de corrélation qui apprend graduellement et en continu des actions des analystes, à la manière d’algorithmes de machine learning supervisé.

L’alimentation peut se faire via des logs, ou des alertes remontées par des systèmes de détection, sur le réseau ou les hôtes, notamment. Des API sont là pour ça, et les capacités d’intégration sont déjà étendues.

Prudent, mais ambitieux, Greg Martin explique vouloir, avec Jask, et avec le temps, proposer une plateforme capable d’assurer le travail d’un analyste SOC de premier niveau, voire même plus, « en assumant certaines fonctions de niveau deux ou trois ». Et le fait d’avoir adopté un modèle cloud apporte un bénéfice immédiat : tous les analystes travaillant sur la plateforme viennent faire profiter les algorithmes de leur expertise personnelle. Une forme de « crowdsourcing » appliqué aux compétences des analystes SOC, en somme.

Le volet automatisation n’est donc pas oublié. Mais pas en s’appuyant sur des playbooks statiques à la manière des outils de SOAR. Là encore, Greg Martin revendique prudence et progressivité, faisant un parallèle avec l’industrie automobile : « l’automatisation, dans les voitures autonomes, est introduite graduellement, pour des raisons de sécurité bien sûr, mais aussi parce que le public n’est pas forcément prêt aujourd’hui à monter dans une voiture sans volant ni pédales ». Du coup, Jask avance « étape par étape » dans l’intégration de capacités d’automatisation « pour gagner la confiance des analystes ». Car sans celle-ci, il n’y aura pas d’adoption.

A ce stade, Greg Martin indique donc que Jask est dans la phase 2 d’une progression qui en comporte cinq : la plateforme est capable de détecter des anomalies et de lancer automatiquement des requêtes d’investigation comme le ferait un analyste. L’ensemble est consolidé et présenté à l’analyste, assorti de recommandations. A charge pour lui d’étiqueter ces recommandations, les « insights » fournis par la plateforme : c’est là qu’on entre dans la boucle d’apprentissage, pour préparer les phases « trois et quatre » d’évolution de la plateforme. Là, « le système ne sera pas simplement en mesure de recommandation des actions, mais pourra éventuellement les effectuer automatiquement lui-même si besoin ».