Test de cas d'utilisation
Préparation
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.
Mise en œuvre
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 :
- Domaine de sécurité (réseau, point d'accès, etc.)
- Horodatage
- possibilité de supprimer les incidents non pertinents
- Drilldowns pour l'analyse des lignes de log brutes
- Lien avec les tableaux de bord existants
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.
Sources d'erreurs dans l'exploitation
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 :
- Modification du format du journal : après une mise à jour du logiciel, les événements sont enregistrés dans un autre format. Une petite différence peut entraîner l'extraction incorrecte de certains contenus de champs.
- Nouvelle source de logs : après le passage à un nouveau logiciel (par ex. nouvelle solution antivirus), les logs sont livrés dans un nouveau format que la solution SIEM ne comprend pas encore et qui doit être normalisé.
- Le logforwarding ne fonctionne pas correctement : le volume de logs peut être trop important ou certains systèmes livrent les logs avec du retard. Cela peut avoir pour conséquence que les logs ne peuvent pas être recherchés et mis en corrélation au bon moment.
- Limites : nous avons même observé à plusieurs reprises que le nombre de résultats de recherche était limité dans le SIEM Splunk en raison de limites internes.
- Champs sans valeurs : lors d'agrégations par champs individuels, il peut arriver que des événements contenant des champs vides soient exclus de la recherche.
- Les add-ons disponibles auprès du fabricant normalisent souvent de manière erronée.
- L'un des processus entre la création des logs et l'alerte est gelé.
Conclusion
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.
Informations complémentaires
a) Un environnement hybride, dans lequel les données brutes des logs sont d'abord filtrées dans un propre système central de gestion des logs, puis normalisées et envoyées à la solution SIEM.
b) Et un environnement purement Splunk, dans lequel les logs bruts sont normalisés dans des apps Splunk.
Glossaire
Cas d'utilisation
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.
Cas d'utilisation d'urgence
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.
Cas d'utilisation client
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.
Cas d'utilisation opérationnel
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.
