Conformidade Contínua como Código P1: Sigma

Conformidade sempre foi um tipo de processo reativo, já que os padrões são extensos, levam um grande esforço e tempo para serem atualizados, ainda mais tempo para serem implementados, e o processo de auditoria acontece uma vez por ano. Vindo do mundo do SIEM, eu lidava com a conformidade através de um prisma de relatórios pré-concebidos que normalmente retornam resultados vazios ou algo que está muito longe de ser explicável para um auditor externo. Por outro lado, a lógica subjacente dos relatórios e consultas é obscura e requer um grande esforço para ser mantida, para dizer o mínimo. Para fazer isso funcionar, é necessário dominar a engine de regras de correlação ou uma linguagem de consulta de tecnologia SIEM específica e a engine de relatórios que a acompanha, configurar várias listas e exceções de maneira estática, enquanto o ambiente real é dinâmico e apenas reunir todos os dados em um lugar pode levar muitos meses. E, ao terminarmos essas tarefas, a tecnologia SIEM é alterada ou eu passo a trabalhar com outro cliente que usa um sistema de análises de segurança baseado em busca, em vez de um de “correlação em tempo real” de escola antiga. Fica mais fácil se tivermos ferramentas de auditoria de segurança como scanners de VM, que possuem recursos de auditoria de conformidade, como Qualys Policy Compliance, Tripwire e similares. No entanto, essas últimas ferramentas não constroem uma imagem holística nem em tempo real, a menos que estejam conectadas a uma plataforma SIEM ou de Análise de Segurança de algum tipo. Depois vem o trem GRC com produtos massivos e anos/homem de esforço de consultoria. Entediante. Ineficiente em termos de custo. Lacunas garantidas na visibilidade. Muito lento para a era digital em que vivemos. E quão eficazes são todas as opções acima para lidar com o NIST CSF ou o GDPR? IMHO Conformidade é um reflexo da Segurança, então se você está fazendo cibersegurança da maneira certa, a conformidade seguirá. Isso não funciona ao contrário, no entanto. Hora de mudar? Sim. E hoje começaremos uma série de artigos para tornar sua Conformidade um processo ágil, transparente e eficiente em termos de custo, adequado para o negócio digital moderno.

Evolução das regras Sigma e ligação com a Conformidade

Considero a adoção acelerada das regras Sigma para tarefas de SIEM, SOC e Caça a Ameaças uma das mudanças mais positivas na indústria de segurança. E enquanto o Sigma já é um padrão de facto para consultas de caça a ameaças, tivemos essa ideia maluca de aplicá-lo para estabelecer práticas de Conformidade Contínua. Caso você não tenha ouvido falar do Sigma antes, é uma linguagem de fácil compreensão, de curva de aprendizado rápida, agnóstica de plataforma e de código aberto. Exemplos das regras e código-fonte https://github.com/Neo23x0/sigma e tutorial para começar https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Se você tem Elastic stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog: você pode obter valor das regras Sigma para segurança e caça já. É provável que essas plataformas façam parte do seu infosec / SOC e que tenham uma tonelada de dados utilizáveis para conformidade. E é ainda mais provável que você tenha um Elastic stack, versão premium ou comunitária, usado em várias unidades de negócio da sua organização que podem ter dados para controles de conformidade automatizados. Uma das razões importantes para a evolução do Sigma e sua adoção global é seu suporte nativo ao MITRE ATT&CK https://attack.mitre.org. Caso você esteja lendo este artigo e não venha de infosec: MITRE ATT&CK é o blockchain da cibersegurança ou a tabela periódica de elementos da química. Portanto, temos um padrão de código aberto, amplamente adotado, que é mais fácil de aprender do que qualquer linguagem de consulta de qualquer SIEM e suporta a marcação com a metodologia ATT&CK para realizar a atribuição de TTP em tempo real. E se adicionássemos tags relevantes para padrões de Conformidade? Ter uma consulta para controle automatizado de acordo com o CSC 8.2 ou encontrar sistemas que processam dados pessoais para o GDPR? Para o Sigma, isso é apenas mais uma tag, então, tecnicamente, este é o próximo passo lógico da evolução.

Como escrever regras Sigma para Conformidade

Não é segredo que, apesar de pessoalmente ser um grande defensor do Sigma, não escrevo tantas regras eu mesmo neste momento. Para orientações detalhadas de como fazer, capturei Alex Yamposlkyi para uma conversa rápida. Alex, sendo um dos desenvolvedores muito ativos das regras Sigma, em termos de quantidade de regras desenvolvidas, ficando atrás apenas de Florian Roth, forneceu algumas percepções muito práticas.

AB: “Alex, você já desenvolveu alguma regra Sigma para Conformidade?” AY: “Sim, foram alguns meses ocupados. Você pode encontrar alguns exemplos no repositório oficial do Sigma no GitHub: https://github.com/Neo23x0/sigma/tree/master/rules/compliance e no SOC Prime Threat Detection Marketplace: https://tdm.socprime.com/?sigmaTypes[]=Compliance”

AB: “Ótimo. Existe algum algoritmo particular que você segue ao criar regras Sigma de Conformidade?” AY: “Acho que posso descrever isso como um processo de 5 etapas:

1. Aprender sobre o controle CIS inicial em https://www.cisecurity.org/controls/cis-controls-list/
2. Compreender quais fontes de log na sua organização podem ser usadas para atender aos requisitos de controle em particular.
3. Procurar eventos necessários na sua plataforma SIEM.
4. Uma vez que os eventos apropriados são descobertos, decidir sobre a lógica da regra: ter um registro de log corresponde a um evento que é bom ou ruim para conformidade. Pergunte-se: esse registro de log passa ou falha no controle?
5. Codificar o evento resultante na regra Sigma, removendo quaisquer parâmetros de busca específicos da plataforma para mantê-la agnóstica de SIEM. Adicione as tags do item #1 e programe a busca automatizada.”

AB: “Isso soa como uma vitória rápida. Podemos tentar estender isso para uma instrução passo a passo?” AY: “Sim. Aqui está uma anotação rápida.

1. Selecione o domínio específico para o controle que você está criando, por exemplo, “Defesas contra Malware” que corresponde ao domínio CSC #8.
2. Aprofunde-se na descrição desse controle. No nosso caso, 8.2 lê como “Garantir que o software anti-malware da organização atualize regularmente seu mecanismo de varredura e banco de dados de assinaturas.”
3. Pense no que precisa acontecer no sistema para passar ou falhar esse controle. Para 8.2, isso significa que se o serviço AV for interrompido ou houver um erro em sua atualização, falhamos no controle. Assim, precisamos rastrear o registro de eventos do AV, especificamente para eventos de parada de serviço e erro de atualização.
4. É bem fácil rastrear esse controle em particular; temos que instalar um produto AV. No meu caso, este era um produto da Symantec integrado ao Elastic stack usando o Logstash. Após classificar os logs por um tempo, encontrei o evento que estava procurando, responsável pelo download e implantação das atualizações, que contém as seguintes strings “Novo conteúdo baixado”, “Uma atualização para”.
5. Ao verificar quais campos contêm essas palavras-chave, posso fazer uma consulta simples no Elastic: (event.name:(“Novo conteúdo baixado”)) OU (event.name:(“Uma atualização para”))
6. Agora tomamos uma decisão sobre a lógica da regra: ter o evento é bom ou ruim. No nosso caso, ter o registro de log é positivo e significa que o controle foi passado. Para automatizar o processo, codificaremos a regra Sigma e aplicaremos ao mecanismo específico de busca salva da plataforma. No meu caso, agendo um Watcher para rodar no Elastic stack com um intervalo de tempo específico para meu ambiente.
7. Vamos escrever uma regra Sigma
8. Neste exemplo, posso decidir agendar um alerta quando eventos forem perdidos por um determinado período de tempo. Com outros exemplos, a situação pode ser oposta, e podemos precisar de um alerta quando descobrirmos um evento.
9. Agora nossa regra precisa de todas as tags relevantes, então eu irei adicioná-las neste formatoTags:
   – CSC8.2
   – attack.impact
   – attack.t1489

Podemos realmente misturar tags para ATT&CK e Conformidade. No exemplo acima, “CSC8.2” é o número do controle correspondente por domínio CSC; “attack.persistence” é a tática ATT&CK do MITRE e “attack.t1053” é uma técnica específica que o controle foca.

Um código Sigma atualizado ficará assimUma vez que eu publico as regras para o Threat Detection Marketplace, também obtenho metadados gerados para as regras pressionando o botão “Parse Sigma Content tags”.Na lista de “Tags”, posso vincular as regras com quaisquer Padrões de Conformidade, como ISO, PCI, NIST CSF, etc.

Nossa conversa continuou por mais uma hora, com material suficiente para uma entrevista sobre o programa Threat Bounty da SOC Prime. Até lá, qualquer feedback sobre Sigma para Conformidade é muito bem-vindo.
E se você quiser dar uma espiada em como o resultado final se parece no Elastic stack, veja o vídeo em https://my.socprime.com/en/continuous-compliance

/Fique seguro