L’OCSF sera-t-il le langage commun des SOC ?
L’été dernier, l’OCSF ouvrait officiellement au public. Où en est ce projet destiné à normaliser les logs et les alertes que produisent les produits et services de cybersécurité ?
Vers un langage commun pour l’échange d’informations entre produits et services de cybersécurité ? En août dernier, le projet OCSF (Open Cybersecurity Schema Framework) ouvrait officiellement au public avec cet objectif.
AWS et Splunk se partageaient alors le comité de pilotage. C’est toujours le cas. La composition de l’équipe de maintenance du dépôt GitHub reste la même, mais les deux développeurs qui représentaient IronNet contribuent désormais officiellement à titre individuel.
Broadcom fait partie des soutiens du projet. Cela se justifie d’autant plus qu’il a repris les activités B2B de Symantec. Et que ce dernier a fourni la brique de base de l’OSCF. À savoir son schéma IDC (Integrated Cyber Defense).
L’OCSF a repris ce schéma, l’a rendu extensible et l’a publié sous licence Apache 2.0. La promesse : les produits et les services qui s’y connecteront généreront des logs et des alertes normalisés.
Reste la question de l’adoption, quand on sait que des formats ouverts comme OSSEM (Open Source Security Events Metadata) et STIX (Structured Threat Information Expression) n’ont pas atteint une « masse critique ».
L’OSCF, comme un air d’ATT&CK
Dans sa dernière version (0.40.0), l’OSCF comporte neuf catégories, chacune composée de classes d’événements. Un système similaire à celui des « techniques » imbriquées dans les « tactiques » au sein du framework ATT&CK. À la différence qu’une classe ne peut faire partie que d’une catégorie. Et qu’il n’y a pas d’équivalent aux sous-techniques.
La catégorie « Activité système » est la plus fournie. Y figurent les événements suivants (réalisés du point de vue des processus) :
– Action sur un fichier ou un dossier
– Chargement ou fermeture d’un pilote/extension noyau
– Création, lecture ou suppression d’une ressource kernel
– Manipulation de mémoire (allocation, lecture, écriture…)
– Chargement ou fermeture d’un module
– Exécution de tâches planifiées
– Lancement, injection, ouverture ou fermeture d’un processus
– Action sur une clé de registre Windows
– Action sur une valeur de clé de registre Windows
– Accès à une ressource gérée par le système d’exploitation
La deuxième catégorie la plus fournie est celle des événements réseau : HTTP, DNS, DHCP, RDP, SMB, SSH, FTP, RFB… Sur la partie « virtualisation », les conteneurs ont leur classe, comme les VM.
Ces dernières semaines, le dépôt s’est enrichi de quelques exemples de traduction d’événements bruts vers le format OSCF. Par exemple pour une alerte Falco, la création d’un processus Windows ou un log de requête sur le DNS Route 53 d’AWS.
