La première chose à faire est d'analyser quels types de logs existent et avec lesquels le comportement suspect pourrait être détecté. Comment le comportement est-il enregistré ? Existe-t-il différents systèmes sur lesquels la journalisation est différente ? Les systèmes de nos clients peuvent-ils générer les données de log correspondantes ou faut-il un logiciel supplémentaire pour cela ? Un volume de logs supplémentaire est-il généré ?
Dans un deuxième temps, nous analysons comment le comportement peut être représenté avec les modèles de données existants ; cela peut nous aider plus tard lors de la corrélation de différents événements. Les modèles de données ne nous aident pas seulement dans l'analyse, mais nous donnent aussi la possibilité de rechercher efficacement dans les logs et de maintenir ainsi à un bas niveau les exigences en matière d'infrastructure et donc les coûts pour nos clients.
La dernière question qui se pose est de savoir si le comportement suspect peut être simulé. Si c'est le cas, nous prévoyons d'intégrer une procédure permettant de tester quotidiennement le cas d'utilisation de bout en bout.
Il s'agit maintenant de la mise en œuvre ! Celle-ci commence par la normalisation des données log brutes. Les contenus des champs nécessaires sont extraits et attribués aux champs correspondants du modèle de données. Par exemple, UserName='Admin' devient le champ normalisé user='Admin'.
Dès que les données sont disponibles dans le format souhaité, nous nous mettons à écrire la "recherche". Selon le cas d'utilisation, celle-ci peut être très simple (par exemple, recherche de certains contenus de champ) ou très compliquée (lorsque des informations provenant de différents modèles de données doivent être réunies et corrélées). Nous tenons compte du fait que chaque cas d'utilisation contient certains éléments obligatoires :
Dans la mesure du possible, nous écrivons une procédure de test et l'intégrons dans notre framework de test de bout en bout. Celui-ci simule quotidiennement sur un hôte dédié les processus à détecter et nous permet de constater si tous les cas d'utilisation fonctionnent correctement.
Dans le cadre de notre processus de release, les nouveaux cas d'utilisation sont testés de manière approfondie avant d'être déployés chez nos clients.
En raison du grand nombre de systèmes et d'architectures réseau, la liste des sources d'erreurs possibles est également longue. Sans test de bout en bout, il est très difficile d'évaluer le degré de disponibilité d'un SIEM et les défauts peuvent parfois passer inaperçus pendant des années.
Une sélection de sources d'erreurs possibles illustre l'importance d'un contrôle permanent :
Même pour des cas simples, le développement d'un cas d'utilisation est une affaire complexe. Ce n'est qu'en combinaison avec un cadre de test de bout en bout que l'on peut garantir un fonctionnement fiable de la détection des attaques.
Un cas d'utilisation (= cas d'application) définit une attaque. Lorsque nous parlons d'un cas d'utilisation dans le contexte d'une solution SIEM, nous entendons par là la recherche de comportements suspects qui doivent être détectés par un cas d'utilisation. Combiné à la procédure de test, voir aussi Use Case Testing, il permet de garantir que la recherche et l'alerte fonctionnent de manière fiable.
Désormais, nous avons également la possibilité de déployer des cas d'utilisation dans le cadre d'un processus accéléré. Cela est par exemple utile en cas de menace imminente. Par la suite, les Emergency Use Cases sont soit déployés comme des Use Cases normaux, soit supprimés si la menace n'existe plus.
Nombre de nos clients ont leurs propres exigences ou souhaits concernant ce qui doit être observé en plus de nos cas d'utilisation existants. Dans ce cas, nous conseillons et mettons en œuvre des cas d'utilisation spécifiques au client.
Ce cas vérifie l'intégrité de la plateforme SIEM. Par exemple, nous contrôlons si les données log arrivent avec du retard ou si les limites internes sont atteintes.