Saiba como automatizar a detecção de ameaças cibernéticas com o GitLab CI/CD

Este post é o segundo de uma série sobre o GitLab Universal Automated Response and Detection (GUARD).

Escrever e implantar detecções de ameaças de segurança na plataforma de gestão de eventos e informações de segurança (SIEM) de uma organização é um passo essencial de todo programa de cibersegurança bem-sucedido. Isto é, sair de uma engenharia de detecção manual e migrar para um processo totalmente automatizado, implementando Detecções como Código (DaC), garante consistência, qualidade, governança e a realização de testes automatizados nas detecções. No GitLab, incorporamos capacidades de DaC ao GUARD, o nosso framework totalmente automatizado de detecção e resposta.

O problema: controle de versão e testes automatizados

Os times de Signals Engineering e SIRT do GitLab dividem a responsabilidade de criar, atualizar e desativar detecções de ameaças no nosso SIEM. Manter uma única fonte confiável para as detecções é fundamental para garantir consistência e atender aos padrões de qualidade. Por isso, nossos times optaram de forma consciente por abstrair o processo de criação de detecções do nosso SIEM, o que melhorou o rastreamento de issues, a consistência, o processo de rollback e as métricas. Além disso, realizar testes de detecção pré-commit fora do SIEM garantiu que as novas detecções não introduzissem alertas com excesso de falsos positivos, que exigiriam ajustes ou desativação enquanto o alerta fosse corrigido.

A solução: usar o GitLab CI/CD para testar e validar detecções

Para enfrentar esses desafios, desenvolvemos um fluxo de trabalho eficiente usando o CI/CD do GitLab, resultando em um processo de implantação de detecções no SIEM mais simples e seguro.

Principais componentes do pipeline de DaC do GUARD

1. Detecções armazenadas em formato JSON em um projeto GitLab

O GitLab usa o formato JSON para as nossas detecções de ameaças. O template inclui informações essenciais, como a lógica de consulta ao SIEM, o título e a descrição da detecção, além do link para a página do runbook, a tática e a técnica MITRE relacionadas à detecção e outros detalhes necessários.

2. Iniciando merge requests

Quando um membro do time do GitLab pretende criar uma nova detecção de ameaça, atualizar uma detecção já existente ou excluir uma detecção atual, o processo começa com o envio de uma merge request - MR no projeto de DaC, contendo o template JSON da detecção. A criação da MR dispara automaticamente um pipeline de CI/CD.

3. Validação automatizada com jobs de CI/CD

Cada MR passa por uma série de verificações automatizadas por meio do GitLab CI/CD:

• A validação do formato da consulta faz uma chamada à API do SIEM para garantir que a consulta de detecção seja válida.
• A validação dos campos JSON da detecção confirma que todos os campos obrigatórios estão presentes e no formato correto.
• Novas detecções e modificações em detecções disparam uma série de chamadas à API do SIEM para garantir que a detecção não tenha erros e que nenhum problema seja introduzido nas nossas regras de detecção em produção.
• MRs de exclusão de detecção disparam o pipeline para fazer uma consulta à API do SIEM, garantindo que a detecção a ser excluída ainda esteja ativa e possa realmente ser removida.

4. Revisão por pares e aprovação

Quando o job de uma MR de detecção é concluído com sucesso, uma revisão por pares é exigida para confirmar que a MR atende aos padrões de qualidade e conteúdo exigidos antes que ela possa ser mesclada. As regras de aprovação de merge request são usadas para disparar o processo de revisão por pares.

5. Merge e implantação final

Depois que a MR é aprovada, ela é mesclada na branch principal. Como parte do pipeline de CI/CD, um job automatizado executa um comando na API do SIEM para realizar duas tarefas:

• Criar a nova detecção ou atualizar/excluir a detecção existente, conforme necessário.
• Extrair as informações de tática e técnica do MITRE ATT&CK relacionadas ao alerta a partir dos arquivos JSON e enviá-las para uma tabela de referência dentro do SIEM. Essa tabela de referência tem um papel importante ao mapear nossos alertas às táticas e técnicas do MITRE, ajudando a melhorar a nossa análise de ameaças e a identificar lacunas nas nossas capacidades de detecção, em alinhamento com o framework MITRE.

Observação: as credenciais necessárias para essas ações ficam armazenadas com segurança em variáveis de CI/CD, o que garante que o processo permaneça confidencial e seguro.

Veja abaixo um arquivo de configuração gitlab-ci.yml de exemplo para um pipeline de DaC no GitLab CI/CD:

      

#
---------------------------------------------------------------------------
#

# GitLab CI/CD Pipeline for SIEM Detection Management

#
---------------------------------------------------------------------------
#


image: python:3.12


#
---------------------------------------------------------------------------
#

# Global Configuration

#
---------------------------------------------------------------------------
#


before_script:
  - apt-get update && apt-get install -y jq
  - pip install --upgrade pip
  - pip install -r requirements.txt

#
---------------------------------------------------------------------------
#


stages:
  - fetch
  - test
  - process
  - upload

#
---------------------------------------------------------------------------
#

# Fetch Stage

#
---------------------------------------------------------------------------
#


fetch_changed_files:
  stage: fetch
  Script:
    - echo "Fetching changed files..."
    - git branch
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        git diff --name-status HEAD^1...HEAD > changed-files-temp.txt
      else
        git fetch origin $CI_COMMIT_BRANCH:$CI_COMMIT_BRANCH --depth 2000
        git diff --name-status ${CI_DEFAULT_BRANCH}...${CI_COMMIT_SHA} > changed-files-temp.txt
      fi
    - grep -E '\.json$' changed-files-temp.txt > changed-files.txt || true
    - flake8 .
    - pytest
  artifacts:
    paths:
      - changed-files.txt
    expose_as: 'changed_files'

#
---------------------------------------------------------------------------
#

# Test Stage

#
---------------------------------------------------------------------------
#


flake8:
  stage: test
  script:
    - echo "Running Flake8 for linting..."
    - flake8 .

pytest:
  stage: test
  script:
    - echo "Running Pytest for unit tests..."
    - pytest
  artifacts:
    when: always
    reports:
      junit: report.xml

#
---------------------------------------------------------------------------
#

# Process Stage

#
---------------------------------------------------------------------------
#


process_files:
  stage: process
  script:
    - echo "Processing changed files..."
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL
    - mkdir -p modified_rules delete_file new_file
    - python3 move-files.py -x changed-files.txt
    - python3 check-alerts-format.py
  artifacts:
    paths:
      - modified_rules
      - delete_file
      - new_file
#
---------------------------------------------------------------------------
#

# Upload Stage

#
---------------------------------------------------------------------------
#


update_rules:
  stage: upload
  script:
    - echo "Uploading updated rules and lookup tables..."
    - git fetch origin $CI_DEFAULT_BRANCH:$CI_DEFAULT_BRANCH --depth 2000
    - git clone --depth 2000 --branch $CI_DEFAULT_BRANCH $CI_REPOSITORY_URL 
    - python3 update-rules.py
    - python3 update-exceptions.py
    - python3 create_ttps_layers.py
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE != "schedule"
      changes:
        - detections/**/*
        - exceptions/**/*

    

O diagrama abaixo ilustra o fluxo de trabalho do processo de CI/CD que foi descrito acima.

graph TD;
    fetch[Etapa de busca: identificar arquivos alterados] --> test[Etapa de teste: executar linting e testes];
    test --> process[Etapa de processamento: categorizar arquivos];
    process --> upload[Etapa de upload: atualizar regras e tabelas de referência];
    fetch --> fetch_details[Detalhes: filtrar arquivos JSON, gerar o arquivo 'changed-files.txt'];
    test --> test_details[Detalhes: executar Flake8 para linting, Pytest para testes];
    process --> process_details[Detalhes: categorizar em 'modified', 'new', 'deleted', preparar para upload];
    upload --> upload_details[Detalhes: atualizar o repositório, atualizar detecções no SIEM e na tabela de referência do SIEM];

Benefícios e resultados

A automatização do ciclo de vida de detecções de ameaças, por meio de um fluxo de trabalho de DaC baseado em CI/CD, traz uma série de benefícios ao nosso processo de implantação:

• Automação: automatizar a criação e a validação das detecções no SIEM reduz a ocorrência de erros manuais e economiza tempo.
• Segurança reforçada: o fluxo de trabalho orientado por CI aplica uma política de "privilégio mínimo", garantindo consistência, revisões por pares e padrões de qualidade na criação, atualização ou exclusão de detecções de ameaças.
• Eficiência: o formato JSON padronizado para detecções e a criação automatizada agilizam o processo de implantação.
• Colaboração: o processo de MR e revisão fomenta a colaboração e o compartilhamento de conhecimento entre os membros do time do GitLab.
• Controle de versão: tratar a detecção de ameaças como código abstrai as detecções da plataforma SIEM em que estão armazenadas. Essa abstração fornece um histórico de alterações, facilita a colaboração e permite fazer rollback para configurações anteriores caso surjam problemas.

Comece a usar o DaC

Usar o GitLab CI/CD ao mesmo tempo em que existe uma política de "privilégio mínimo" tornou o gerenciamento de detecções e alertas do nosso SIEM mais simples e seguro. A automação melhorou a eficiência e reduziu riscos, servindo como um exemplo útil para quem também quer aprimorar sua segurança e conformidade. Faça este tutorial usando um teste gratuito do GitLab Ultimate.