Entrevista com o Desenvolvedor: Adam Swan

Continuamos nossa série de entrevistas com participantes do Programa de Desenvolvedores (https://my.socprime.com/en/tdm-developers), caçadores de ameaças e entusiastas da cibersegurança para apresentá-los a essas pessoas maravilhosas que estão buscando na web ameaças relevantes e criando conteúdo único para sua detecção. Conheça o Engenheiro Sênior de Caça a Ameaças da SOC Prime – Adam Swan.

Adam, conte-nos um pouco sobre você e sobre sua experiência em Caça a Ameaças.

Quando criança, quando as salas de bate-papo do AOL eram populares, lembro-me de ficar fascinado por um truque que encontrei que me permitia enganar outros a mudar sua mensagem de ausência acessando um link criado. Esses tipos de vislumbres de ‘hacking’ acenderam uma faísca que me levou por este caminho de carreira um pouco sem propósito definido. Acabei fazendo todas as aulas de programação disponíveis no ensino médio (para ser honesto, eram as únicas aulas que me interessavam) e depois descobri que poderia fazer da cibersegurança uma carreira enquanto olhava os programas universitários. Acabei entrando em um programa de Garantia da Informação na Pennsylvania College of Technology. O programa era uma mistura de técnica e política e certamente abriu uma porta que eventualmente levou à caça de ameaças.

Depois da faculdade, comecei imediatamente a coletar certificações para me tornar compatível com o 8570 do Departamento de Defesa dos EUA, na esperança de que elas abrissem mais oportunidades técnicas onde eu estava trabalhando. No entanto, mesmo após passar por várias certificações, incluindo a CISSP para ‘marcar todas as caixas’, senti que realmente *não sabia* nada. Foi quando surgiu uma posição de análise de malware, e o gerente disse que eu precisava obter a certificação GREM para ser elegível. Sem nenhum conhecimento prévio de análise de malware, enfrentei a certificação após algumas semanas de estudo intenso. Realmente gostei do material e finalmente senti que um caminho se abriu para trabalhos altamente técnicos. Fui aceito em uma posição júnior e passei alguns anos aprimorando minhas habilidades em análise de malware, resposta a incidentes e forense de máquinas mortas.

No entanto, não foi até Nate (@neu5ron) me convidar para sua equipe que realmente entrei na caça a ameaças. Ele me apresentou ao Elastic, e ficamos viciados no poder de centralizar e pesquisar nos logs de eventos do Windows. Isso culminou em nós entrando em uma espécie de turnê de palestras evangelizando o poder dos logs do Windows. Esse período é quando me tornei um caçador e nunca realmente olhei para trás. Tenho praticado há cerca de dois anos e meio agora. Então, comparado a talvez alguns dos outros analistas que a SOC Prime entrevistou, ainda sou novo.

Como você acha, quais são as tendências mais importantes de caça a ameaças na indústria agora?

Existem três tendências que gostaria de abordar.

Primeiro, mais organizações estão iniciando programas de caça a ameaças ou estão adotando conceitos centrais de caça a ameaças e os adicionando à sua função SOC existente. Isso é enorme, pois os fundamentos da caça a ameaças são, em minha opinião, altamente eficazes para melhorar programas de segurança.

Segundo, outra tendência na caça a ameaças é a dependência de Detecção e Resposta de Endpoint (EDR). Eu prefiro aquelas que fornecem acesso a dados passivos ricos sobre eventos importantes em sistemas nos quais os analistas podem escrever lógica de detecção ou realizar análises manuais. A liderança deve ser cautelosa com qualquer fornecedor que afirme simplificar completamente ou automatizar toda a detecção de ameaças. Os adversários estão cientes e podem contornar essas ferramentas.

Finalmente, a comunidade de caça a ameaças não existiria ou estaria onde está sem compartilhamento. Projetos como o SIGMA, que possibilitam o compartilhamento na caça a ameaças, estabeleceram uma base sólida para sucessos futuros.

Adam, e quanto ao Sigma, qual foi sua primeira experiência com Sigma, quando você começou a usá-lo.

O SIGMA está na minha consciência desde o seu anúncio, mas meu primeiro uso dele em produção foi no início de 2018, quando um cliente coletou logs do Windows de muitos meses atrás, mas não tinha muitas detecções / alertas além das detecções padrão dos fornecedores. Com a ajuda do engenheiro SIEM, implementei as regras SIGMA públicas relevantes.

E como você acha, quais são os principais benefícios do Sigma como uma ferramenta de caça a ameaças? Pode o Sigma mudar a forma como as organizações constroem sua defesa cibernética?

Primeiro, o SIGMA habilita o compartilhamento de lógica de detecção entre organizações com arquiteturas diferentes, mas com fontes de dados e ameaças familiares. Então, se eu tenho Splunk e você tem Elastic e ambos estamos coletando Logs do Windows, podemos usar o SIGMA como uma linguagem comum para compartilhar lógica de detecção contra nossas ameaças comuns, como ransomware.

Segundo, o SIGMA nos permite escrever lógica de detecção e cercá-la com metadados suculentos que podem não ser (facilmente) integrados ao alerting do seu SIEM. Por exemplo, se você está acompanhando sua cobertura do MITRE ATT&CK em alguns SIEMs, não é óbvio ou fácil vincular essas regras à técnica associada. Com o arquivo YAML do SIGMA você tem o poder de marcar as regras como quiser.

Terceiro, se você mantiver sua lógica de detecção escrita em SIGMA, você está se preparando para o sucesso na adoção inevitável de um novo SIEM. Se seu SOC é repentinamente responsável por adotar um novo SIEM (digamos durante uma aquisição) ou sua liderança decide mudar para um novo SIEM com o SIGMA, você está possibilitando a transição ágil ou adoção da nova tecnologia. Isso é especialmente importante se você está oferecendo SOC/caça a ameaças como serviço (MSSP).

O que você acha que é a parte mais complicada e demorada ao escrever novas regras Sigma e quanto tempo, em média, leva para você escrever uma nova regra Sigma? É conveniente para você usar o Sigma como uma ferramenta para escrever novas regras? E como você decide qual regra criar?

As regras mais imediatamente acionáveis são baseadas em observações diretas. No entanto, regras baseadas em uma hipótese educada sobre o comportamento do adversário ou como o comportamento do adversário afeta um sistema determinado são igualmente válidas. A parte mais demorada ao escrever uma regra SIGMA é a pesquisa e verificação de que a lógica que você escreve vai detectar a técnica/ferramenta/ameaça pretendida. Escrever uma regra em SIGMA não deve levar muito mais tempo do que escrever uma consulta contra qualquer SIEM. Isso porque o SIGMA não atrapalha, não é exigente, e a sintaxe se torna familiar rapidamente.

Para garantir qualidade, recomendo fortemente que qualquer um escrevendo alertas SIGMA leve a sério a palestra de Daniel Bohannon sobre assinaturas resilientes (https://www.slideshare.net/DanielBohannon2/signaturesaredead-long-live-resilient-signatures).

E quanto à sua experiência com o Sigma UI, Adam? Você tem alguma ideia de como torná-lo mais útil/conveniente para desenvolvedores?

A interface do SIGMA é ótima, eu uso uncoder.io para verificar se minha regra sigma será convertida, já que copiar e colar uma regra é muito simples. Seria bom se a interface do SIGMA fizesse sugestões/recomendações para compatibilidade com diferentes backends. Por exemplo, confiar fortemente em coringas pode causar problemas com a compatibilidade do Elastic.

Adam, como escritor de conteúdo, você provavelmente tem um laboratório. Como você testa suas regras e quais fontes de logs você prefere trabalhar?

Ter um laboratório para simular ataques e confirmar/testar a resiliência de suas assinaturas é muito importante. Prefiro trabalhar com logs que a organização média tem acesso. Hoje, escrever uma regra para registro de endpoint nativo é a rede mais ampla possível para lançar.

Quais tipos de ameaças cibernéticas você acha que representarão os maiores riscos para as organizações no ano que vem? Alguma sugestão de como melhorar as capacidades de detecção contra essas ameaças?

As ameaças variam significativamente entre as organizações. Eu diria que a maior ameaça para a organização média é a adoção de técnicas/exploits wormáveis em ransomware wormável (ou qualquer tipo de malware destrutivo). Os dias da intrusão de Schrödinger ficaram para trás para a organização média, a maioria das organizações saberá que foi hackeada quando seus dados forem sequestrados. Felizmente, os métodos por trás da prevenção e detecção desses tipos de ataques são relativamente maduros. A execução desses métodos pode variar de ser relativamente simples a extremamente complexa, dependendo do escopo e complexidade das redes/sistemas que alguém está defendendo. Então, minha recomendação é realmente para a liderança. Sempre que possível, busque a simplicidade.

Na SOC Prime lançamos o Programa de Recompensa de Ameaças que incentiva o compartilhamento de conteúdo entre profissionais de cibersegurança. Adam, você gosta da ideia de recompensar desenvolvedores por compartilhar regras Sigma e outros conteúdos de detecção de ameaças?

Sim. Se você está fazendo qualquer tipo de pesquisa de segurança, pense em como você pode compartilhar a detecção. Tudo o que é necessário é aumentar a verbosidade do logging no seu laboratório e então revisar os logs para possíveis detecções após executar uma prova de conceito. Se você não souber como começar, entre em contato comigo @acalarch e prometo a você que é incrivelmente simples.

Adam, qual seria sua recomendação para jovens especialistas em cibersegurança que estão decidindo qual caminho escolher?

Aqui estão as coisas que eu gostaria de ter feito:

1. Aproveite os treinamentos que você pode obter participando de conferências. É mais barato e você estará cercado por colegas e mentores em potencial.
2. Seja seu próprio defensor e seja cético/realista. Torne claras suas intenções de trajetória de carreira para sua gestão, insista nas suas intenções, procure mentores e não tenha medo de seguir em frente.