Elastic Security abre repositório público de regras de detecção
Nós da Elastic acreditamos no poder do open source e entendemos a importância da comunidade. Ao colocar a comunidade em primeiro lugar, nos certificamos de estar criando o melhor produto possível para os nossos usuários. Com o Elastic Security, dois dos nossos objetivos principais são parar as ameaças em escala e dar recursos para todos os analistas. Hoje, estamos abrindo um novo repositório no GitHub, elastic/detection-rules, para trabalhar junto com a comunidade de segurança, parando as ameaças em uma escala maior.
O lançamento do mecanismo de detecção no Elastic Security trouxe a detecção automatizada de ameaças para o Elastic Stack. Desde o lançamento inicial do mecanismo de detecção, a equipe de Elastic Security Intelligence & Analytics adicionou mais de 50 regras, aumentando a visibilidade das técnicas dos invasores nos sistemas operacionais Linux, macOS e Windows. Conforme continuarmos a expandir a cobertura, você verá uma maior amplitude nas detecções, abrangendo novos domínios, como serviços na nuvem e comportamento do usuário.
Nas últimas versões, usamos um repositório interno para gerenciar as regras do mecanismo de detecção. Melhoramos iterativamente nossos procedimentos de teste, adicionando testes automatizados para novas contribuições que validam a sintaxe da Kibana Query Language (KQL), o uso do esquema e outros metadados. Nosso desenvolvimento de regras amadureceu, então, podemos andar mais rápido sem quebrar as coisas.
Com a abertura do nosso repositório do GitHub elastic/detection-rules, o Elastic Security desenvolverá regras abertamente junto com a comunidade, e estamos receptivos às suas detecções orientadas pela comunidade. Esta é uma oportunidade para todos nós compartilharmos nosso conhecimento coletivo, aprendermos uns com os outros e causarmos impacto trabalhando juntos.
O que há nesse novo repositório?
No repositório do GitHub elastic/detection-rules, você pode encontrar regras escritas para o Elastic Security, com cobertura para muitas técnicas do MITRE ATT&CK®. A lógica da nossa regra atual é escrita principalmente em KQL e, aproveitando o Elastic Common Schema (ECS), só precisamos escrever as regras uma vez. Ao usar os campos definidos e as categorias no ECS, as regras funcionam automaticamente com os logs dos Beats e outras fontes de dados que mapeiam corretamente para o ECS.
Na pasta rules/, as regras são armazenadas em arquivos TOML e agrupadas por plataforma. Tentamos manter a simplicidade com uma hierarquia plana para que seja mais fácil encontrar e adicionar novas regras. Se estiver procurando regras somente para Windows, navegue até rules/windows. Se ainda está com dificuldades para encontrar uma regra ou quer pesquisar em todas as regras, você pode usar nossa CLI executando o comando python -m detection_rules rule-search, que mostrará os arquivos com metadados correspondentes.
Cada regra contém vários campos de metadados, além da própria consulta. Isso captura informações como título, descrição, nível de ruído, mapeamentos do ATT&CK, tags e o intervalo de programação. Temos alguns campos adicionais para ajudar os analistas a realizar a triagem, descrevendo falsos positivos conhecidos ou etapas úteis para uma investigação. Para obter mais informações sobre os metadados que dizem respeito às regras, consulte o guia de criação de regras do Kibana ou o resumo dos metadados das regras (ambas as páginas em inglês) no guia de contribuição.
Como essas regras chegam ao meu mecanismo de detecção?
Se estiver usando o nosso serviço gerenciado do Elastic Cloud ou a distribuição padrão do software Elastic Stack que inclui o conjunto completo de recursos gratuitos, você obterá as regras mais recentes na primeira vez que navegar até o mecanismo de detecção. Quando você atualiza, o mecanismo de detecção reconhece que as regras foram adicionadas ou alteradas e solicita que você decida se quer que essas regras sejam atualizadas. Siga as etapas após a atualização, e você obterá a cópia mais recente das regras.
Quem usará esse repositório?
Nesse repositório, a equipe de Elastic Security Intelligence & Analytics desenvolverá regras, criará ocorrências, gerenciará pull requests e direcionará os lançamentos. Ao tornar o repositório público, estamos convidando todos os colaboradores externos para este fluxo de trabalho. Isso dará aos colaboradores visibilidade do nosso processo de desenvolvimento e um caminho claro para as regras a serem lançadas com o mecanismo de detecção.
Quando estiver pronto(a) para contribuir, assine o contributor license agreement (CLA) (acordo de licença do colaborador) da Elastic. Esse é um acordo padrão para todos os repositórios da Elastic no GitHub e significa que podemos distribuir o seu código gratuitamente aos usuários da Elastic.
Como abordamos a detecção de ameaças?
Em geral, tendemos a preferir detecções que se concentrem no comportamento do adversário. Isso geralmente significa que nos concentramos nas técnicas do ATT&CK. Pode significar que mais pesquisas e esforços serão necessários para descobrir como uma técnica funciona antes de criar uma regra. Porém, ao adotar essa abordagem, fazemos um trabalho melhor para detectar e parar os ataques de hoje e amanhã, em vez apenas dos ataques de ontem.
A adoção de uma abordagem comportamental também significa que precisamos de vários tipos de regras. Alguns podem detectar eventos atômicos, outros podem exigir a agregação de vários eventos ou a procura de desvios acima de um limite. Com a Event Query Language (EQL), seremos capazes de escrever regras que procurem sequências de comportamento que abranjam vários eventos.
Naturalmente, entendemos que às vezes uma técnica pode ser difícil para todos os usuários detectarem comportamentalmente. Nesse caso, fique à vontade para adicionar uma regra que seja mais semelhante a uma assinatura por natureza e escrita para um comportamento ou ferramenta específico(a).
Para uma discussão mais longa sobre o que torna uma detecção madura, leia sobre a filosofia do repositório de regras de detecção.
Por que precisamos de um novo repositório?
Se você já compartilhou regras públicas antes, provavelmente conhece outros repositórios do GitHub como o Cyber Analytics Repository (CAR) da MITRE, o Sigma ou mesmo a EQL Analytics Library baseada na EQL da Elastic. Você pode estar se perguntando: Por que precisamos de outro repositório? Por que não usar os que já existem?
Não é nenhuma surpresa que a melhor resposta para essa pergunta comece com outra pergunta: Por que os outros repositórios existem? Tanto o CAR quanto o Sigma são propositadamente agnósticos quanto à linguagem ou à plataforma e, às vezes, à fonte de dados. Já a EQL Analytics Library foi escrita com uma linguagem específica em mente.
Com nosso novo repositório de regras de detecção, estamos tentando servir a um propósito ligeiramente diferente. Nosso objetivo é fornecer aos usuários do Elastic Security as melhores detecções possíveis que funcionem em várias fontes de dados. Usamos o ECS como o grande equalizador de esquemas, tornando possível escrever uma regra uma vez que se aplique a várias fontes de dados.
Como o Elastic Stack dá suporte a várias linguagens, nossas regras devem refletir isso. Normalmente, as linguagens de consulta são desenvolvidas para resolver diferentes tipos de problemas, e não devemos restringir os desenvolvedores de regras a uma única linguagem se existe outra que faz melhor o trabalho. Atualmente, temos regras em KQL e Lucene, junto com regras que usam tarefas de detecção de anomalia com machine learning no repositório. Estamos trabalhando muito para trazer a EQL para o Elastic Stack e para o nosso repositório.
Também podemos garantir que as práticas recomendadas estejam sendo seguidas para o desempenho ideal do Elasticsearch. Por exemplo, pesquisar por process.path:*\\cmd.exe requer a execução de uma verificação curinga, que é mais dispendiosa do que uma simples verificação de palavra-chave. Em vez de pesquisas contendo curingas no início, podemos recomendar o uso de process.name:cmd.exe, o que resultará em melhor desempenho e em resultados mais precisos. De maneira semelhante, o ECS também contém o campo process.args, que é uma versão analisada de process.command_line. Recomendamos usar o campo analisado porque nos dá melhor desempenho. Além disso, ficamos muito menos propensos a ter espaços em branco triviais ou evasões com uso de aspas. Todo mundo sai ganhando.
Posso adicionar regras de outro repositório?
No seu próprio ambiente, você pode adicionar regras ao seu próprio mecanismo de detecção, desde que sua função do Kibana tenha as permissões corretas. Se você quer adicionar regras ao repositório elastic/detection-rules, a resposta é: depende... Contanto que uma regra possa ser sublicenciada sob a licença da Elastic, acho justo. Na maioria das vezes, os requisitos são bastante diretos — manter os autores originais na matriz rule.author e atualizar o arquivo NOTICE.txt para dar o devido crédito aos autores originais. Não queremos receber crédito pelo trabalho de outra pessoa, então, ajude-nos nesse cuidado!
Para obter mais informações sobre como abordamos o licenciamento no repositório, consulte a seção Licensing (Licenciamento) do README.
Como posso contribuir?
Está ansioso(a) para compartilhar sua lógica de regra? Vá para elastic/detection-rules no GitHub. Lá temos instruções detalhadas para navegar no repositório, criar regras, variantes e clones. Incluímos uma ferramenta de linha de comando para edição em massa dos arquivos e para tornar mais fácil a criação de novas regras. Quando estiver pronto(a) para adicionar uma nova regra ao repositório, execute python -m detection_rules create-rule e forneça os metadados necessários. Recomendamos usar a CLI quando possível, porque ela reduz os erros de copiar e colar que acontecem ao reutilizar o conteúdo de um arquivo TOML de outra regra ou modelo.
Quando sua regra estiver em um bom estado, você poderá executar o comando python -m detection_rules test para realizar testes de unidade localmente, que validam a sintaxe, o uso do esquema etc. Em seguida, crie a pull request, e alguém da equipe de Intelligence & Analytics analisará a contribuição. Se solicitarmos alguma alteração, trabalharemos com você para fazer as alterações recomendadas.
Se você tem uma boa ideia para uma regra, mas quer colaborar conosco na ideia ou obter feedback, fique à vontade para criar uma ocorrência de New Rule (nova regra). Estamos ansiosos para ajudar e fazer um brainstorming com você!
Para obter mais informações, consulte o guia de contribuição.
O que vem a seguir?
Bem-vindo(a) ao nosso novo repositório e fluxo de trabalho de regras! Incentivamos você a contribuir e esperamos ver seu nome no campo rule.author. O repositório de regras de detecção continuará a evoluir junto com o resto do Elastic Security, e estamos animados com o que vem por aí.
Se você quer acompanhar o desenvolvimento da EQL na stack, inscreva-se nesta ocorrência do GitHub. Ou dê uma olhada na documentação em andamento para ver o que a equipe do Elasticsearch está fazendo.
Se tiver algum feedback ou dúvida ao escrever regras ou navegar em nosso novo repositório de regras de detecção no GitHub, crie uma ocorrência no GitHub, entre em contato no fórum de discussão com a tag detection-rules ou encontre-nos no canal #detection-rules da comunidade da Elastic no Slack.