Notifications et digests OCTI : un nouveau moteur puissant pour le graphe de connaissances

Pour de plus en plus d'organisations, OpenCTI est (ou commence à être) le système nerveux de la connaissance en cyber-renseignement (à la fois pour les menaces et les données opérationnelles). Les données provenant de multiples flux CTI, XDR / EDR, SIEM et systèmes de gestion de logs sont entièrement intégrées, consolidées et enrichies dans la plateforme grâce à toutes les capacités d'OpenCTI (via des connecteurs ou des moteurs intégrés tels que le gestionnaire de règles d'inférence).

Notifications OpenCTI

Ainsi, le volume d'informations devient extrêmement important et difficile à suivre pour un être humain. À un certain moment, chaque utilisateur n'est intéressé que par des parties spécifiques de cette connaissance et souhaite être informé le plus rapidement possible lorsque certains types de données sont créés dans la plateforme :

• Nouvelle vulnérabilité exploitée dans un secteur donné.
• Nouvelle victime dans un pays donné.
• Nouveaux rapports concernant un acteur de menace donné.
• Mise à jour d'un cas de réponse à incident suivi.
• Nouveau lot de signatures pour un logiciel malveillant donné.
• Nouvelles observations ou entrées de logs pour une organisation donnée.

Sur la base de ce besoin tant attendu de notre communauté, nous avons décidé de réécrire complètement le "système d'abonnement" déjà existant pour offrir plus de flexibilité et de puissance aux notifications et digests d'OpenCTI, en nous appuyant sur notre système de streaming.

Un peu de sémantique

Pour être clair sur ce que nous avons conçu, commençons par une définition sémantique des concepts introduits dans ce nouveau système de notification :

• Déclencheur en temps réel (aka Trigger) : Un ensemble de filtres en temps réel qui produira une ou plusieurs notifications.
• Digest régulier (aka Digest) : Un ensemble de déclencheurs en temps réel sur une période de temps (dernières #heures) qui produira une ou plusieurs notifications
• Notification : Le résultat d'un déclencheur/digest qui produit un résultat : entrée dans l'interface utilisateur / cloche, emails, etc. Les webhooks et autres connecteurs pour les résultats seront disponibles très bientôt.

Comment ça fonctionne ?

Tous les utilisateurs de la plateforme peuvent maintenant définir leurs propres déclencheurs en temps réel ou digests réguliers pour surveiller un sous-ensemble de connaissances dans la plateforme. Cela concerne les données directement créées par les connecteurs et/ou les utilisateurs mais aussi les informations inférées / auto-générées : tout est complètement accessible.

Le parcours commence avec la "cloche"

Pour illustrer cela, expliquons différents cas d'usage.

En tant qu'analyste, je souhaite être notifié de tous les rapports contenant la région "Europe". Mais en général, les connecteurs et autres analystes n'ajoutent que les pays concernés dans les rapports et non la région elle-même. De plus, j'aimerais recevoir les notifications à la fois dans l'interface utilisateur et par email.

Pour résoudre ce cas d'usage, vous pouvez simplement définir un déclencheur de cette manière :

Capturer tous les nouveaux rapports concernant l'Europe dans un déclencheur

Avec cette configuration, tous les rapports de la plateforme qui seront liés à l'Europe (directement ou par inférence) généreront une notification à la fois dans l'interface utilisateur et par email.

Notification dans l'interface utilisateur

Notification par email

Bien sûr, il est possible d'adapter la configuration pour écouter également les mises à jour et suppressions, choisir le système de notification approprié, etc. Comme vous pouvez le voir, il est assez simple de configurer un déclencheur en temps réel et de commencer à être notifié des données qui comptent le plus.

Passons maintenant au cas d'usage suivant.

En tant qu'analyste, je souhaite recevoir un digest quotidien de tous les rapports contenant la région "Europe". Mais en général, les connecteurs et autres analystes n'ajoutent que les pays concernés dans les rapports et non la région elle-même. De plus, j'aimerais recevoir ce digest uniquement par email à 9h00.

Cet analyste souhaite également recevoir un digest quotidien pour le déclencheur qu'il vient de créer. Cela peut être réalisé en définissant une configuration de digest régulier comme ceci :

Digest quotidien des rapports sur l'Europe

Comme vous pouvez le voir, un digest est "simplement" une combinaison de déclencheurs en temps réel. Ensuite, l'utilisateur est libre de définir la période et la liste de déclencheurs qui ont du sens pour le cas d'usage souhaité. Dans cette situation, l'utilisateur recevra cet email :

Email du Digest Rapport/Europe

Juste pour compléter les informations sur ces cas d'usage :

• Il est possible de définir des déclencheurs en temps réel sans aucun résultat pour être utilisés uniquement dans les digests réguliers et ne pas recevoir de notifications en temps réel.
• Un utilisateur peut également configurer un digest régulier pour être affiché comme une notification dans l'interface utilisateur.

Voici un exemple d'un digest régulier directement affiché dans l'interface utilisateur :

Interface utilisateur du Digest Rapport/Europe

Bien sûr, toutes les lignes sont cliquables pour permettre à l'utilisateur d' accéder rapidement aux entités / observations / relations concernées.

Liste des déclencheurs et digests

Nous espérons que ces exemples vous ont aidé à comprendre comment nous avons conçu la fonctionnalité de notifications et comment vous pouvez l'utiliser en combinant des filtres pour créer de puissantes notifications en temps réel et les réutiliser pour programmer vos digests réguliers.

Comment est-ce techniquement conçu ?

Parlons un peu de l'aspect technique de ce système de notification. Il est conçu autour de 2 nouveaux gestionnaires, le "gestionnaire de notifications" et le "gestionnaire de publication".

View the design on Figma

Chaque gestionnaire est responsable d'une partie spécifique du système.

Le gestionnaire de notifications

Ce gestionnaire est responsable de l'écoute du flux de données interne de la plateforme et de l'application de tous les déclencheurs définis par les utilisateurs en temps réel. Lorsqu'une "correspondance" se produit, une nouvelle notification sera poussée dans un autre flux interne de la plateforme (c'est-à-dire le flux de notifications). Nous utilisons ce mécanisme pour séparer les préoccupations entre la génération de notifications et la distribution de notifications.

Quelques détails importants sur ce traitement

• Dans le cas d'un déclencheur en temps réel, le flux sera filtré et un message sera généré/poussé dans le flux de notifications
• Dans le cas d'un digest régulier, le gestionnaire consommera périodiquement le flux de notifications pour combiner les événements intéressants dans une notification de type digest qui sera également poussée dans le flux de notifications.

Le gestionnaire de publication

Ce gestionnaire est responsable de la distribution des notifications via plusieurs résultats. Pour l'instant, OpenCTI prend en charge les résultats d'interface utilisateur et d'email prêts à l'emploi (les modèles sont codés en dur). Mais nous prévoyons de publier très bientôt des webhooks intégrés et de nouveaux connecteurs capables de consommer le flux de notifications (à la fois en temps réel et digests) pour étendre les intégrations. De plus, le système de modèles sera ouvert à la configuration.

Ces 2 gestionnaires sont démarrés par défaut mais peuvent évidemment être gérés via des paramètres statiques. Si les paramètres SMTP ne sont pas correctement configurés, la plateforme démarre maintenant normalement mais chaque fois qu'OpenCTI tentera d'envoyer un email, cela se traduira par une nouvelle entrée de log d'erreur.

Conclusion

Nous espérons que le comportement et les mécanismes sous-jacents du nouveau système de notification sont maintenant clairs après la lecture de cet article. Comme indiqué ci-dessus, ce n'est que la première étape d'un travail global sur les notifications dans la plateforme et plusieurs améliorations sont déjà prévues :

• Introduire des webhooks et des connecteurs spécifiques comme résultats.
• Pouvoir personnaliser les modèles pour les emails et webhooks (même si le modèle prend déjà en compte le thème personnalisé).
• Avoir des boutons "S'abonner" partout pour créer rapidement des déclencheurs en temps réel et être mis à jour de toute activité dans des entités spécifiques telles que les incidents, cas, etc.

Comme toujours, nous restons très intéressés par vos retours et idées pour améliorer cette fonctionnalité. N'hésitez pas à créer des demandes de fonctionnalités dans nos dépôts GitHub ou rejoindre le canal Slack de la communauté !