Rastreando a história: a revolução da IA generativa em SIEM

Essa iteração inicial da coleta de registros de segurança foi definida como SEM (gerenciamento de eventos de segurança) ou SIM (gerenciamento de informações de segurança). Era uma coleta de uma combinação de dados de logs, ou os registros digitais da atividade do sistema, juntamente com dados de eventos. Foi um divisor de águas para os analistas, que agora tinham um sistema sob seu controle que continha os dados necessários para solucionar o crime digital. Basicamente, as equipes de segurança agora tinham seu próprio silo de dados. Essa revolução de produtos foi impulsionada principalmente pela necessidade de coletar dados caso algo acontecesse, como manter um registro forense e ser capaz de demonstrar aos auditores e investigadores que, de fato, esses registros estavam sendo coletados. Esse caso de uso de conformidade impulsionou a adoção da coleta central de eventos de segurança.

Houve desafios com esse novo tipo de produto. O SOC agora precisava de engenheiros de segurança para gerenciar grandes quantidades de dados. Eles também precisavam de orçamento para coletar e armazenar essas informações, pois estavam copiando dados de vários outros sistemas em um sistema monolítico e centralizado. Mas os benefícios eram claros: acelerar a detecção e a remediação reduzindo o tempo gasto na coleta e classificação de dados de toda a empresa. Uma vez notificados de um ataque, os responsáveis pela resposta a incidentes podiam começar a trabalhar quase que instantaneamente.

O próximo avanço foi aplicar a lógica de detecção na camada SIEM centralizada. Um SIEM era uma combinação dos dados do evento em um SEM e os dados de informações em um SIM. O poder de conformidade e coleta de evidências do SEM/SIM era forte, mas depois de quase uma década apenas coletando e revisando dados, os analistas perceberam que poderiam fazer muito mais com informações centralizadas. Em vez de simplesmente consolidar alertas de outros sistemas e fornecer um sistema central de registro para registros e eventos coletados, os SIEMs agora permitiam a análise em várias fontes de dados. Os engenheiros de detecção poderiam operar a partir de uma nova perspectiva, identificando ameaças que poderiam ter sido ignoradas em uma solução pontual, analisando apenas uma fonte de dados, como seu antivírus ou firewall de rede. 

Essa evolução veio acompanhada de muitos desafios. Além da maior necessidade de especialistas no assunto e regras pré-criadas, os SIEMs coletavam centralmente alertas de várias soluções pontuais, e cada uma delas produzia muitos falsos positivos por conta própria e exacerbava o problema. Os analistas de SIEM tinham que revisar os alertas coletivos de rede e desktop. Isso resultava em uma pergunta frequente de um analista de SIEM: "Por onde começo?", além de um conjunto totalmente novo de alertas de detecção do próprio SIEM. Seu SIEM agora contém a soma de todos os outros alertas do sistema na rede mais a quantidade de alertas normalmente gerados. Nem é preciso dizer que isso era praticamente insuportável.

O machine learning (ML) prometia melhorar a detecção de ameaças desconhecidas exigindo menos manutenção. O objetivo era identificar comportamentos anormais, em vez de depender de regras codificadas para encontrar todas as ameaças.

Antes do ML, os engenheiros de detecção precisavam analisar um ataque que já havia acontecido ou um que poderia acontecer (cortesia da pesquisa primária) e escrever detecções para essa possível ocorrência. Por exemplo, se fosse descoberto um ataque que aproveitasse alguns argumentos específicos enviados a um processo do Windows, seria possível escrever uma regra para que esses argumentos fossem invocados na execução. Mas o adversário poderia simplesmente mudar a ordem dos argumentos ou invocá-los de forma diferente para evitar essa detecção frágil. E, se houvesse usos legítimos desses argumentos, seriam necessários dias (talvez semanas) de ajuste para remover os falsos positivos da lógica de detecção. 

O machine learning prometia reduzir bastante esse desafio, principalmente de duas maneiras:

• Detecção de anomalias baseada em ML "não supervisionada": os analistas só precisavam decidir em que área procurar comportamentos desconhecidos, como em logins, execuções de processos e acesso a buckets S3. Em seguida, o mecanismo de ML aprendeu o comportamento NORMAL para essas áreas e sinalizou o que era incomum. O SANS DFIR criou um pôster famoso em 2014 que dizia: "Conheça o anormal para encontrar o mal."

• Modelos de ML treinados ou "supervisionados": analistas humanos podem ver algo e seus cérebros podem conectar os pontos e perceber como essa situação se assemelha a um ataque observado anteriormente. Esses especialistas são capazes de aprender como um ataque ocorreu e aplicar esse conhecimento para encontrar ataques desconhecidos que seguem uma progressão semelhante. Tradicionalmente, eles usavam essa experiência na caça a ameaças para ajudar a encontrar ameaças que seus produtos de segurança podiam ter perdido. Agora, com o machine learning, eles eram capazes de criar detecções de modelos treinados com a capacidade de aprender com ataques anteriores e encontrar novos semelhantes na forma como estavam atacando. Concentrar-se no comportamento – e não apenas em indicadores atômicos como hashes, strings em arquivos e URLs – permite detecções com uma vida útil mais longa e uma taxa mais alta de detecção de ataque.

Como vimos, os SIEMs eram relatórios históricos de problemas, em vez de soluções reais de ponta a ponta. Os SIEMs podiam alertar sobre um problema, mas você estava sozinho para resolvê-lo. Isso mudou com a entrada do SOAR: orquestração de segurança, automação e resposta. Essa nova linha de produtos foi criada para preencher uma lacuna de recursos em SIEMs. Eles forneceram um local para coletar e organizar as etapas que um analista queria executar para correção, bem como conectores para o restante do ecossistema para iniciar a resposta. Em nossa analogia com o departamento de polícia, os SOARs eram como policiais de trânsito direcionando todos os outros sistemas para executar comandos. Eles foram a ligação que uniu a descoberta do ataque do SIEM às ações de resposta dos outros sistemas. 

Assim como a UEBA, a capacidade de organizar planos de resposta e iniciar ações a partir de um local central tornou-se uma expectativa dos SIEMs modernos. Agora, no ciclo de vida do SIEM 2.0, espera-se que os SIEMs possam coletar dados em escala em toda a organização (.gen 0), detectar novas ameaças que as soluções pontuais podem não ter detectado e correlacionar sistemas diferentes usando tecnologias baseadas em regras e em machine learning (SIEM 1.0) e permitir o planejamento e a execução dos planos de resposta (2.0). Na verdade, um novo acrônimo – TDIR (detecção, investigação e resposta a ameaças) – foi criado para capturar a capacidade de lidar com o escopo completo de um ataque.

Os SIEMs tornaram-se fundamentais na detecção, triagem e investigação de ameaças de um SOC, apesar de não abordarem um desafio fundamental: a enorme escassez de habilidades em segurança cibernética. Um estudo de março de 2023 encomendado pela IBM e conduzido pela Morning Consult constatou que os membros da equipe do SOC estão "recebendo apenas metade dos alertas que deveriam revisar em um dia de trabalho típico". Isso representa um ponto cego de 50%. Décadas de melhorias incrementais para simplificar fluxos de trabalho, automatizar etapas de rotina, orientar analistas juniores e muito mais ajudaram, mas não o suficiente. Com o advento de modelos de inteligência artificial generativa acessíveis ao consumidor com experiência de domínio em segurança cibernética, esse cenário está mudando rapidamente. 

Tradicionalmente, os SIEMs dependem muito do ser humano por trás da tela: alertas, painéis e caça a ameaças são operações dependentes de humanos. Mesmo os primeiros esforços de IA, como os copilotos de IA, dependiam da capacidade do analista de usar esses copilotos de forma eficaz. Essa revolução acontecerá quando a IA operar em nome do analista, eliminando a necessidade de “conversar”. Imagine que o sistema examina todos os dados, ignora os irrelevantes e identifica o que é crítico, descobre o ataque específico, cria correções específicas e, por sua vez, libera os especialistas para se concentrarem em impedir o impacto nos negócios.

Pela primeira vez, a tecnologia está aprendendo com analistas seniores e transferindo esse conhecimento para membros juniores automaticamente. A IA generativa agora ajuda os profissionais de segurança a desenvolver planos de correção específicos da organização, priorizar ameaças, escrever e selecionar detecções, depurar problemas e lidar com outras tarefas rotineiras e demoradas. A IA generativa promete automatizar o ciclo de feedback de volta ao SOC, permitindo a melhoria contínua dia após dia. Agora podemos fechar o ciclo OODA com esse feedback e aprendizado automatizados. 

Devido à natureza dos grandes modelos de linguagem (a ciência por trás da IA generativa), podemos finalmente aproveitar a tecnologia para raciocinar em vários pontos de dados, assim como um ser humano faria, mas com maior escala, maior velocidade e compreensão mais ampla. Além disso, os usuários podem interagir com grandes modelos de linguagem em linguagem natural, em vez de código ou matemática, e reduzir ainda mais as barreiras à adoção. Nunca antes um analista conseguiu fazer perguntas em linguagem natural, como "Meus dados contêm atividade em alguma área que possa representar riscos para minha organização?". Esse é um avanço sem precedentes nos recursos que agora podem ser incorporados em um SIEM para todos os membros de um SOC. A IA generativa tornou-se um assistente SOC digital poderoso e preciso. 

Os produtos que tiram proveito da revolução da IA nos fluxos de trabalho de operações de segurança fornecerão o SIEM 3.0.

Este post do blog analisou a evolução do SIEM, da coleta centralizada de dados à detecção de ameaças no nível organizacional e, em seguida, à automação e orquestração para acelerar a remediação. Agora, nesta terceira fase das tecnologias SIEM, estamos finalmente lidando com a enorme escassez de habilidades em segurança cibernética. 

Na segunda parte desta série, discutiremos a evolução do Elastic Security de um TDIR para a primeira e única oferta de análise de segurança orientada por IA do mundo. Enquanto isso, você pode aprender mais sobre como os profissionais de segurança reagiram ao surgimento da IA generativa neste e-book: IA generativa para segurança cibernética: um futuro otimista, mas incerto. Não deixe de acompanhar a segunda parte!