Cybersécurité : AWS et Splunk veulent rationaliser le partage de données

L’Open Cybersecurity Schema Framework est déjà opérationnel

Bien que le projet n’ait que quelques mois d’existence, la spécification est prête à l'emploi pour les fournisseurs souhaitant créer des connecteurs dans leurs produits. AWS prévoit d’ajouter des connecteurs OCSF dans plusieurs services SecOps, notamment GuardDuty, Security Hub et Inspector.

« Beaucoup de clients avec lesquels nous discutons utilisent de nombreux outils de sécurité différents. Personne ne s’attend à ce que cela s’arrête un jour – il n’y aura jamais un seul outil pour les gouverner tous ».

« Beaucoup de clients avec lesquels nous discutons utilisent de nombreux outils de sécurité différents. Personne ne s’attend à ce que cela s’arrête un jour – il n’y aura jamais un seul outil pour les gouverner tous », déclare Mark Ryland, directeur du bureau du CISO chez AWS.

« En même temps, cela provoque des problèmes de gestion des données parce que les outils communiquent difficilement entre eux. Et [les clients] veulent passer plus de temps sur les résultats de la sécurité et moins de temps à rassembler les données ».

À travers des fichiers JSON, l’OCSF spécifie les éléments de gestion des données standard tels que des classes d’événements, des types de données, des catégories et des attributs. Les éditeurs de logiciels d’analyse de la cybersécurité peuvent les exploiter pour normaliser les données au moment de leur intégration. La normalisation des bases de données est le processus d’organisation des données en tables pour un usage efficace et sans ambiguïté par les systèmes de bases de données relationnelles.

Selon IDC, les équipes IT sont de plus en plus confrontées à la prolifération des outils SecOps. C’est particulièrement vrai lorsque les entreprises se développent par le biais d’acquisitions et que les filiales apportent leurs propres outils, qui peuvent être redondants par rapport à ceux déjà déployés par la société mère.

« Selon la taille de l’organisation, l’on peut compter plus de 20 outils », relate Michelle Abraham, analyste chez IDC. « Certains évoquent parfois l’utilisation d’une centaine d’outils ».

Les SI d'entreprises telles que Zoom deviennent également plus grands et plus complexes. Cela entraîne une dépendance accrue à l’égard de l’automatisation. Dès lors, les flux de données vers les plateformes analytiques consacrées à la cybersécurité gagnent en importance dans les opérations de sécurité, selon Michelle Abraham.

« Si vous voulez automatiser [les analyses], vous avez besoin que les données affluent, et pas uniquement au moment de déployer un système », signale-t-elle. « La technologie évolue rapidement – si l’un de vos systèmes change et que quelque chose modifie le flux de données, cela peut affecter tout ce qui y est connecté. S’il existe une norme, ces changements n’auront idéalement pas autant d’impact sur les systèmes en aval. »

Prochaines étapes : adoption et chevauchement

Bien que techniquement différent, OCSF rappelle OpenTelemetry, une initiative de la Cloud Native Computing Foundation (CNCF). Cette dernière cherche à normaliser les méthodes de collecte de données télémétriques parmi les outils de traçage distribués. Le succès d’OpenTelemetry a également inspiré le projet CDEvents au sein de la Continuous Delivery Foundation cette année.

Techniquement, le projet OCSF ne se limite pas nécessairement aux données relatives aux événements de cybersécurité, mais c’est son objectif initial. Il n’est pas prévu pour l’instant de se lancer dans un domaine plus large de la télémétrie, indique Mark Ryland.

Cependant, d’autres frameworks consacrés au partage des données de cybersécurité ont déjà leurs propres formats de normalisation. D’ailleurs, ils sont soutenus par des alliances d’interopérabilité multifournisseurs. Par exemple, ArcSight, une filiale de Micro Focus spécialisée dans la sécurité, dispose d’un format d’événement appelé CEF. Le framework ATT&CK² de MITRE est un autre format largement utilisé parmi les outils de cybersécurité.

Selon la documentation du projet, OCSF est « complémentaire » d’ATT&CK². Il se différencie par le fait que les classes d’événements (similaires aux techniques dans ATT&CK²) sont associées à une seule catégorie, l’équivalent des tactiques au sein du framework de MITRE. ATT&CK² permet d’associer plusieurs techniques et sous-techniques à plusieurs tactiques, alors qu’OCSF ne dispose pas de sous-classes d’événements.

CEF et ATT&CK² sont également extensibles par des tiers, mais aucun n’est disponible sous une licence open source, contrairement à OCSF qui est estampillé Apache v2.

De plus, les responsables du projet assurent qu’OCSF est « agnostique des formats de stockage, des processus ETL et de collections de données ».

« Il existe non seulement de nombreux produits, mais aussi beaucoup d’outils maison pour traiter les données de sécurité », répète Mark Ryland. « Nous pensons que cela peut réduire les frictions et fournir des expériences et des compétences communes – même un ingénieur en sécurité qui est habitué à ce format peut l’utiliser à large échelle. »

Si OCSF est porté par plusieurs fournisseurs IT de renom, tous les éditeurs ou utilisateurs de services analytiques de cybersécurité ne seront pas intéressés par le remplacement de ce qu’ils utilisent déjà pour normaliser les données d’événements de sécurité.

« Ils ont une liste de contributeurs assez importants », note Carlos Casanova, analyste chez Forrester Research. « Nous devrons surveiller l’évolution [d’OCSF] et si l’initiative donne lieu à une norme ouverte supplémentaire, à une norme réelle ou à rien du tout. »