L’OCSF, la clé de la démocratisation des lacs de données de sécurité ?
Pour détecter et arrêter les cyberattaques actuelles, il est nécessaire de coordonner l’utilisation de nombreux outils de sécurité différents. Bien que cela soit regrettable, les équipes consentent à consacrer du temps et des ressources à l’unification des données de journaux de sécurité, car ce travail est reconnu comme nécessaire à la réalisation des analyses requises pour identifier les attaques potentielles. Le projet Open Cybersecurity Schema Framework (OCSF) vise à changer cet état de fait de sorte que les équipes puissent passer moins de temps à réaliser des analyses et en consacrer davantage à la protection de leurs environnements. Examinons tout d’abord ce qui rend cette nouvelle approche si importante et pertinente dans le contexte actuel.
Pour que les données d’événement des journaux de sécurité soient utiles, chaque journal doit être associé à un schéma qui définit sur quels champs peuvent porter des opérations de recherche, d’agrégation ou de détection. Par exemple, un journal des connexions à un réseau peut faire mention d’une adresse IP source à l’origine d’une connexion et d’une adresse IP de destination qui a reçu la demande et y a répondu. Le schéma spécifierait alors des champs tels que src et dest afin d’informer les analystes de sécurité de la possibilité d’effectuer des requêtes relatives à ces champs.
Cependant, il existe de grandes disparités dans la structure des schémas associés aux différents outils et types de journaux. En reprenant le même exemple, CrowdStrike extrait dans ses journaux réseau l’adresse IP source dans un champ nommé ip et celle de destination dans un champ intitulé RemoteAddressIP4. Les pare-feu PAN nomment quant à eux l’IP source src et celle de destination dst. Certains journaux ne sont absolument pas structurés, et vous ne pouvez connaître les adresses IP source et de destination qu’en parvenant à comprendre comment le journal est formaté et à quel emplacement figurent les adresses IP dans l’événement de journal.
Les analystes souhaitent souvent effectuer des requêtes portant sur de vastes sous-ensembles de journaux. Par exemple, ils peuvent vouloir rechercher, dans tous les journaux réseau, si un hôte s’est déjà connecté à une adresse IP spécifique. Pour ce faire, il est non seulement nécessaire de disposer d’un schéma pour chaque type de journal, mais il faut également que ces schémas soient cohérents entre eux. Si seulement il existait un moyen plus efficace d’ingérer et d’analyser des données, le tout en effectuant moins d’opérations manuelles.
Les défis de la normalisation des journaux
Jusqu’à présent, Salesforce gérait ce problème en employant une solution interne complexe appelée « Dictionnaire de données des événements » (DDI), qui répertorie chaque champ de chaque journal. Nous avons défini des règles d’extraction des champs de données qui analysent les journaux et appliquent le dictionnaire en tant que schéma. Dans le domaine des architectures de détection et de réponse, ce processus se déroule dans un système appelé « normalisateur ».
Après leur normalisation, tous les journaux, y compris ceux qui n’étaient pas structurés auparavant, disposent de schémas harmonisés et d’un ensemble de champs que nous pouvons interroger. Ainsi, nous extrayons « RemoteAddressIP4 » dans les journaux de CrowdStrike et le renommons en IPDestination. De même, « dst » dans les journaux générés par PAN devient IPDestination, et il suffit alors aux analystes souhaitant déterminer si une connexion à une adresse IP spécifique a eu lieu de saisir une requête portant sur tous les journaux, structurée comme suit : IPDestination == […].
Dans l’idéal, il s’agit d’une technique formidable. Les analystes peuvent effectuer les recherches qu’ils souhaitent. Cependant, la normalisation des journaux n’est pas exempte de son lot de défis :
- Le dictionnaire de données contient des centaines de champs, dont beaucoup ont pour valeur NULL, ce qui fait perdre un espace important.
- Lorsqu’un nouveau type de journal fait son apparition, ses champs peuvent entrer en conflit avec nos paramétrages précédents et donc générer des cas étranges (dans lesquels, par exemple, user, username et useremail font référence à des éléments différents selon le type de journal).
- Lorsque nous procédons à l’intégration d’une nouvelle source de journal, nous devons analyser manuellement chaque nouveau type ou sous-type de journal en écrivant des règles d’analyse ou d’expressions régulières.
- Toute modification de la structure d’un journal, ainsi que tout ajout ou substitution de champs peut conduire les règles existantes à ne pas analyser certains champs pertinents. Cela constitue un problème majeur de qualité des données.
- En outre, il n’existe pas de moyen efficace de valider les règles ou d’en assurer le suivi à grande échelle. Il est très probable que certaines règles soient dupliquées. Par ailleurs, il est difficile de gérer ou de mettre à jour l’ensemble de règles, car le fait de déprécier des règles pose un risque substantiel. Cela peut provoquer des régressions dans le cadre desquelles les effets de nouvelles règles remplacent ceux des anciennes.
Toutes ces tâches sont associées à des coûts croissants. En effet, au lieu de se consacrer à détecter les événements et à y répondre, les équipes passent du temps à normaliser manuellement ces données.
Adoption de l’OCSF
L’Open Cybersecurity Schema Framework (OCSF), annoncé publiquement en tant que norme de schéma ouverte lors de la conférence BlackHat (août 2022), est un projet unique en son genre, qui représente une initiative importante pour standardiser les données provenant de nombreuses solutions de cybersécurité. Ce cadre vise à proposer une taxonomie simplifiée et indépendante de tout fournisseur afin d’aider toutes les équipes de sécurité à améliorer et à accélérer leurs processus d’ingestion et d’analyse de données sans avoir à effectuer un travail de normalisation préalable qui s’avère chronophage.
L’objectif est de pouvoir disposer d’une norme ouverte qui puisse être adoptée dans l’ensemble des environnements et applications et par tous les fournisseurs de solutions, et qui soit en adéquation avec les normes et processus de sécurité existants. L’OCSF est un cadre open-source qui s’apparente sous certains aspects à notre approche employant le dictionnaire de données. En effet, il vise lui aussi à résoudre le problème initial décrit précédemment. Il apporte également une solution aux difficultés posées par notre approche en définissant un sous-ensemble de champs à schématiser en fonction des besoins des analystes.
Voici ce que notre directeur de la confiance, Vikram Rao, a déclaré à ce sujet : « Toutes les entreprises sont confrontées à l’impératif de passer rapidement au numérique. Toutefois, l’élaboration d’une posture de sécurité à même de susciter la confiance sur le plan numérique dans un environnement aussi vaste que celui d’Internet peut constituer un défi majeur. Les nouvelles normes telles que l’OCSF simplifient le travail des équipes de sécurité, ce qui leur permet de se concentrer sur des tâches plus cruciales telles que l’analyse des menaces et la prévention des attaques. »
Réalisation d’essais
L’équipe d’ingénierie du service Détection et réponse de Salesforce a évalué l’OCSF, en envisageant à la fois la possibilité d’appliquer ce schéma à l’ensemble des journaux générés par Salesforce, ainsi que celle d’adapter notre approche actuelle de la normalisation, de sorte à produire des journaux en employant les schémas définis par l’OCSF au lieu de nos schémas personnalisés issus du dictionnaire de données d’événements.
Afin de mieux comprendre l’OCSF, nous avons tout d’abord réalisé un exercice visant à transposer au format OCSF un événement hypothétique de détection de sécurité Salesforce, puis à l’évaluer. Vous trouverez ci-dessous des captures d’écran présentant l’événement dans le format DDl, que nous utilisons actuellement, et dans le format OCSF.
En réalisant cet exercice et en explorant le schéma OCSF, nous avons trouvé des champs intéressants que nous pourrions potentiellement utiliser, comme celui de l’objet de remédiation. Ce champ permet de présenter des liens menant à des articles de la base de connaissances, afin de fournir aux analystes des descriptions qui leur seront utiles en aval lors du triage des incidents et les aideront à prendre d’autres mesures.
Nous avons donné un coup d’accélérateur au démarrage de cette initiative en travaillant avec des équipes internes et en réalisant des prototypes, ce qui nous a permis de tester le processus nécessaire à la transformation de nos journaux d’application internes (sfdc_applog). Suite à cette démarche, nous sommes désormais en mesure de produire des journaux conformes à l’OCSF. Nous souhaitons poursuivre cette collaboration à l’avenir. Si vous souhaitez vous aussi prendre part à cette initiative et utiliser ce schéma pour standardiser vos journaux, vous pouvez vous lancer en dupliquant le référentiel GitHub de l’OCSF [accessible ici].
Remerciements
Le projet OCSF, visant à simplifier la classification des données dans un cadre indépendant de tout fournisseur afin de permettre aux équipes de sécurité de consacrer moins de temps à la normalisation des données et plus de temps à la protection de leurs systèmes, mérite d’être ovationné. L’OCSF a notamment bénéficié des contributions de Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro et Zscaler.
Chez Salesforce, nous sommes très enthousiastes quant à cette initiative et avons été parmi les premiers à adopter l’OCSF. Les premiers exercices que nous avons réalisés pour transposer nos principaux événements de type de journaux au format OCSF ont constitué une première étape importante. Ils ont en effet permis à certaines de nos équipes internes de se familiariser avec le cadre et le contexte s’y rapportant. Étant donné que l’OCSF constitue à la fois une norme ouverte et une initiative collaborative s’adressant à l’ensemble du secteur de la sécurité, si de multiples acteurs l’adoptent et contribuent à son développement, elle a le potentiel de démocratiser les lacs de données de sécurité dans toutes les organisations.
Enfin, pour que l’OCSF ait le plus d’impact possible, il est nécessaire que les fournisseurs de services Cloud et les fournisseurs de solutions de sécurité suivent cette norme et produisent des journaux conformes au schéma OCSF. Si vous travaillez dans ce domaine, nous vous prions de nous aider à convaincre vos pairs pour faire adopter largement cette norme dans le secteur de la sécurité.