A OCSF é a chave para a democratização dos data lakes de segurança?

Ingerir e analisar dados de segurança consome muito tempo e recursos, mas a Open Cybersecurity Schema Framework (OCSF) vem com o objetivo de mudar isso. Aqui está o que a equipe de DnR da Salesforce encontrou ao testar a OCSF.
A OCSF é a chave para a democratização dos data lakes de segurança?

Detectar e interromper os ciberataques atuais exige coordenação entre muitas ferramentas de segurança diferentes. O tempo e os recursos que as equipes gastam na unificação desses dados de log de segurança é um custo aceito da execução da análise necessária para descobrir ataques potenciais. O projeto Open Cybersecurity Schema Framework (OSCF) tem como objetivo mudar isso para que as equipes possam passar menos tempo analisando e mais tempo protegendo seus ambientes. Mas vamos dar uma olhada no que faz com que essa nova abordagem seja tão importante e oportuna.

Para que os dados de eventos de log de segurança sejam úteis, cada log deve ter um esquema que define os campos disponíveis para pesquisar, agregar ou detectar além do log. Por exemplo, um log de conexão com a rede pode ter um IP de origem que iniciou a conexão e um IP de destino que recebeu e apresentou uma resposta à solicitação. O esquema teria campos como src e dest para que os analistas de segurança soubessem que podem fazer consultas ao redor desses campos.

Entretanto, há pouco consenso em relação a ferramentas ou logtypes para esses esquemas. Usando o mesmo exemplo, o CrowdStrike extrai a origem do IP nos logs da rede como ip e o destino como RemoteAddressIP4. Os firewalls PAN chamam o IP de origem de src e o de destino de dst. Alguns logs são completamente não estruturados, e os IPs de origem e destino somente podem ser determinados com o entendimento do formato do log e a localização do IP de dentro do evento de log. 

Frequentemente, os analistas desejarão fazer consultas em grandes subconjuntos de logs. Por exemplo, eles podem querer saber se os logs de rede contam com hosts que já foram conectados a um endereço IP específico. Para isso, não precisamos apenas de um esquema para cada logtype, precisamos que esses esquemas concordem entre si. Se houvesse um modo melhor de ingerir e analisar dados com menos esforço manual.

Os desafios da normalização de log

Até agora, a Salesforce abordou isso com uma solução interna complexa chamada de "Dicionário de dados de eventos" (DDI), que lista todos os campos em cada log, e definimos as regras de extração de campo de dados (DFEs) que analisam os logs e impõem o dicionário como um esquema. Na arquitetura de detecção e resposta, esse processo acontece em um sistema chamado "Normalizador". 

Após a normalização, todos os logs, incluindo os anteriormente não estruturados, contem com esquemas correspondentes e um conjunto de campos com base nos quais podemos fazer pesquisas. Extraímos RemoteAddressIP4 nos logs do CrowdStrike e o renomeamos para IPDestination. De modo semelhante, o dst dos logs do PAN se transforma em IPDestination, e os analistas simplesmente escrevem consultas se desejam ver se um IP específico foi conectado consultando todos os logs e perguntando onde IPDestination == [...].

Isso é ótimo! Os analistas podem pesquisar. Entretanto, a normalização de log também gera seus próprios desafios:

  1. Há centenas de campos no dicionário de dados, muitos dos quais são NULL, desperdiçando muito espaço.
  2. Quando obtemos um novo logtype, os campos podem não concordar com o que foi definido anteriormente e, assim, gerar casos de borda não usuais (por exemplo, user, username, useremail, dependendo do logtype, têm significados diferentes).
  3. Temos que analisar manualmente todos os novos logtypes ou sublogtypes como parte da integração de uma nova origem de log ao escrever regras de análise ou regex.
  4. Quaisquer alterações na estrutura do log, como adição ou substituição de campos, podem fazer com que as regras existentes não analisem campos relevantes. Esse é um grande problema na qualidade dos dados.
  5. Além disso, não há um bom modo de validar ou acompanhar as regras em escala. Isso acontece muito provavelmente porque as regras estão duplicadas. É desafiador manter ou atualizar o conjunto de regras, pois a deprecação das regras ocasiona riscos substanciais. Isso pode levar a regressões quando novas regras substituem a funcionalidade da regra antiga.

Todo esse trabalha tem um custo crescente associado a ele. Em vez do foco principal na detecção e resposta a eventos, as equipes gastam o tempo normalizando manualmente esses dados como um pré-requisito.

Adoção da OCSF

A Open Cybersecurity Schema Framework (OCSF), publicamente anunciada como um esquema padrão na BlackHat (agosto de 2022), é um projeto exclusivo, um esforço significativo para generalizar dados de várias fontes de cibersegurança. Essa estrutura tem como objetivo entregar uma taxonomia independente de fornecedor e simplificada para ajudar todas as equipes de segurança a obter análise e ingestão de dados melhores e mais rapidamente sem a tarefa inicial de normalização que consome muito tempo. 

A meta é ter um padrão aberto que possa sem adotado em qualquer ambiente, aplicativo ou provedor de solução, e que se adeque aos processos e padrões de segurança existentes. A OCSF é uma estrutura de código aberto similar à nossa abordagem de Dicionário de dados, pois tem como objetivo solucionar o problema inicial descrito acima, além de também lidar com os pontos problemáticos de nossa abordagem ao definir um subconjunto de campos a serem esquematizados com base no uso do analista.

Nosso CTO, Vikram Rao, compartilhou: "Todas as empresas estão enfrentando a demanda de serem digitais e mais rápidas. Entretanto, desenvolver uma postura de segurança para atender os níveis de escala da Internet da confiança digital pode ser um grande desafio. Novos padrões, como a OCSF, reduzem a complexidade das equipes de segurança, capacitando-as a focar em trabalhos mais impactantes, como análise de ameaças e prevenção contra ataques".

O teste

A equipe de engenharia de resposta e detecção da Salesforce avaliou a OCSF considerando a imposição do esquema em logs gerados pelo Salesforce e adaptando nossa abordagem atual em relação à normalização para produzir logs com os esquemas definidos pela OCSF, em vez de usar nossos esquemas definidos e personalizados do Dicionário de dados de eventos.

Para entender melhor a OCSF, primeiramente fizemos um exercício de transformar e avaliar um evento hipotético de detecção de segurança da Salesforce para o formato OCSF. Abaixo estão as capturas de tela do evento em nosso formato DDI atual e no formato OCSF. 

image
Evento de segurança da Salesforce – Esquematizado em DDI
image
Evento de segurança da Salesforce – Esquematizado em OCSF

Ao trabalhar nesse exercício e explorar o esquema OCSF, encontramos campos interessantes que poderiam ser potencialmente usados, por exemplo, o objeto de correção, que é um campo que ajuda a vincular artigos da base de conhecimento, já o campo descrição seria útil para os analistas posteriores enquanto fazem a triagem de incidentes e também os ajudaria a tomar mais ações.

Começamos rapidamente trabalhando em equipes internas e fazendo o protótipo e avaliando a transformação de nossos logs de aplicativos internos, sfdc_applog, que serão, eventualmente, de produtores de log em conformidade com a OCSF. Esperamos ser colaboradores contínuos daqui para frente. Se desejar colaborar e usar esse esquema para padronizar seus logs, você pode começar e bifurcar o OCSF GitHub [aqui].

Um grande destaque

O projeto Open Cybersecurity Schema Framework (OSCF), criado para simplificar a classificação de dados em uma estrutura neutra para o fornecedor a fim de ajudar as equipes de segurança a passar menos tempo normalizando dados e mais tempo trabalhando na proteção, merece muitos aplausos. A OCSF conta com contribuições de: Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro e Zscaler.

Na Salesforce, estamos animados e passamos a usar a OCSF desde o início. Esses exercícios que realizamos para transformar nossos principais eventos de logtype em OCSF foram um grande primeiro passo e nos ajudaram a integrar diferentes equipes internas para que conhecessem a estrutura e seus ambientes. Como a OCSF é um padrão aberto e um esforço colaborativo no setor de segurança, com várias partes interessadas adotando o padrão e ajudando a aprimorá-lo, ela tem o potencial de democratizar os data lakes de segurança em todas as organizações.

Por fim, para que a OCSF tenha mais impacto, precisamos que os provedores de nuvem e de segurança estejam alinhados e forneçam logs no esquema OCSF. Se estiver nesse espaço, ajude a ultrapassar as barreiras e tornar isso um padrão na comunidade de segurança.

Histórias recomendadas