deadair v0.5.1

Saúde de detecção SIEM de código aberto.
Encontre detecções habilitadas que estão cegas porque sua telemetria está ausente, desatualizada, atrasada ou incompatível com o esquema.

Executa localmente · Somente leitura · Sem agente · Sem upload de telemetria

Leia o artigo técnico · Destaque no Detection Engineering Weekly

_{Exame real de um laboratório Elastic descartável com telemetria deliberadamente ausente, desatualizada, atrasada e não utilizada. Reproduza-o com make record-scan-lab.}

Por que deadair

Uma regra pode estar habilitada, agendada e sem erros enquanto os dados de que precisa desapareceram. O deadair lê o inventário ativo de regras, resolve as entradas de cada regra usando a semântica nativa do backend e verifica as fontes concretas por trás delas.

Ele detecta:

• regras cujos seletores de índice, alias ou data stream não resolvem para nada;
• regras cujas fontes correspondentes estão todas desatualizadas ou vazias;
• regras executando com campos ausentes ou uma janela cega de atraso de ingestão;
• telemetria saudável que nenhuma detecção habilitada lê.

O deadair atualmente funciona com Elastic Security e OpenSearch Security Analytics.

Início rápido

Baixe um binário para macOS, Linux ou Windows em GitHub Releases ou instale com Go:

go install github.com/alephnull-sh/deadair/cmd/deadair@latest

Conecte uma credencial SIEM somente leitura:

deadair setup elastic   # print the least-privilege setup
deadair check           # verify the credential can scan
deadair scan            # assess live rules and telemetry

Os códigos de saída são estáveis: 0 significa saudável, 1 significa achados e 2 significa que o exame falhou.

Como funciona

O deadair comprova se os pré-requisitos observáveis de telemetria de uma detecção estão presentes e saudáveis. Ele não comprova que a lógica da regra está correta ou que um ataque simulado produzirá um alerta. Combine-o com validação estática de regras e testes de detecção de ponta a ponta para essas camadas.

Achados

Cada veredito está limitado ao que a credencial configurada pode ver. Os relatórios JSON incluem as expressões configuradas, fontes resolvidas, método de resolução, status da avaliação, metadados do backend e evidências de capacidade. Consulte o guia de uso para exemplos práticos e triagem.

Conecte um SIEM

Elastic:

export DEADAIR_ES_URL=https://es.example.internal:9200
export DEADAIR_KIBANA_URL=https://kibana.example.internal:5601
export DEADAIR_API_KEY=<read-only-api-key>

deadair check
deadair scan --json-out report.json --html-out report.html

OpenSearch:

export DEADAIR_BACKEND=opensearch
export DEADAIR_OPENSEARCH_URL=https://opensearch.example.internal:9200
export DEADAIR_OPENSEARCH_USERNAME=deadair
export DEADAIR_OPENSEARCH_PASSWORD=<password>

deadair check
deadair scan

Use as funções de privilégio mínimo documentadas para Elastic ou OpenSearch. A suíte de integração confiável também comprova que tentativas de escrita feitas com essas credenciais são rejeitadas.

CI, frotas e monitoramento

# Gate a candidate rule against live source availability.
deadair scan --rule new-rule.json

# Fail only on new regressions between reports.
deadair diff yesterday.json today.json

# Scan multiple SIEM instances from one process.
deadair scan --fleet fleet.json

# Export cached scan results as Prometheus metrics.
deadair serve --interval 5m

scan --rule isola a regra candidata do backlog não relacionado. O diff funciona com relatórios redigidos deterministicamente. A configuração de frota referencia segredos por meio de variáveis de ambiente em vez de armazenar valores secretos.

_{Um gate de regra candidata e um diff de relatório contra uma stack Elastic descartável.}

Consulte comportamento do gate de CI, implantação de frota e MSSP e os exemplos de Prometheus para padrões de produção.

Backends testados

O fluxo de trabalho de integração atualmente testa estas versões exatas:

Outras versões podem funcionar, mas não são cobertas pela matriz de CI atual.

Modelo de segurança

• Todo o acesso ao backend é somente leitura; os testes de integração confiáveis comprovam que as credenciais documentadas não podem gravar.
• Relatórios, HTML, arquivos de estado e saída de frota são gravados com 0600 em sistemas POSIX.
• As credenciais podem vir de variáveis de ambiente ou arquivos, evitando segredos em argumentos de processos.
• --redact substitui nomes de tenant, regra, fonte, padrão e campo por resumos (digests) estáveis.
• O exportador escuta apenas em loopback por padrão.
• O deadair não tem comportamento de phone-home nem telemetria de uso.

Trate os relatórios como artefatos confidenciais do SOC: eles identificam detecções cegas, nomes de fontes, lacunas de esquema e coleta não utilizada.

Documentação

• Guia de uso — primeiros exames, evidências de relatório, achados, gates de CI, estado e frotas
• Validação e dogfooding — o que é comprovado e o que ainda precisa de evidências de campo
• Arquitetura — contrato do backend, modelo de dados, propriedades de segurança e limites
• Boas práticas — ordem de implantação, contexto de alertas e roteamento
• Guia de MSSP — segredos, redação, retenção, dimensionamento e tratamento de falhas de tenant
• Detecções que executam, mas não enxergam — o problema e uma simulação reproduzível

Contribuindo

Relatos de bugs, fixtures sanitizadas, casos de correção, documentação e propostas de backend são bem-vindos. Comece por CONTRIBUTING.md e use o modelo de RFC de backend para trabalhos de adaptador.

Licença

Apache-2.0.