RESPOSTA        (agir)
      DETECÇÃO          (regras + anomalia)
    VISIBILIDADE        (logs + telemetria)  ← a base de tudo

Sem a base (logs), o topo não existe. Por isso o Pilar 1 é logs.

PARTE B — Os 8 pilares do Blue Team

Pilar 1 — Logs & telemetria (a base) 📋

• O que logar (DOC §6.1): login (sucesso/falha), acesso admin, criação de lead, rate limit acionado, RLS negado, deploy, erro 5xx.
• Regra: registrar o evento, nunca o segredo — nada de senha/token/PII em claro (Ex. 53). Log estruturado (JSON) com timestamp, IP, rota, resultado.

Pilar 2 — SIEM & agregação 🗄️

• O que é: Security Information and Event Management — junta logs de todas as fontes (Cloudflare + VPS + Supabase) num lugar e permite correlacionar.
• Ferramentas (grátis/porte atual): Grafana Loki + Alertmanager, Wazuh (open-source), Better Stack. (DOC §6.4)

Pilar 3 — Detecção (assinatura + anomalia) 🎯

• Baseada em regra/assinatura: "UA = sqlmap", "> 20 404s/min por IP" — o que o CATALOGO §3 já cataloga.
• Baseada em anomalia: desvio do normal (pico de tráfego, resposta grande demais = exfiltração). (DOC §6.6)
• Padrão da indústria: regras Sigma (formato aberto de regra de detecção) + mapeamento MITRE ATT&CK.

Pilar 4 — Alertas (sem fadiga) 🔔

• Gatilhos (DOC §6.3): >10 logins falhos/min, acesso anon a tabela sem RLS, canário disparado, novo admin criado, deploy fora de hora.
• Regra: poucos alertas e acionáveis. Alerta demais = fadiga = ninguém olha. Cada alerta deve ter uma ação clara.

Pilar 5 — Threat Intelligence 🌐

• O que é: saber o que os atacantes estão usando agora — IoCs (indicadores: IPs, hashes, domínios maliciosos) e CVEs em exploração.
• Fontes (CATALOGO §5): AbuseIPDB, FireHOL, Spamhaus, AlienVault OTX (IPs); NIST NVD, CISA KEV (CVEs em exploração ativa); HIBP (vazamentos).

Pilar 6 — IDS/IPS & EDR 🌐💻

• IDS/IPS: Intrusion Detection/Prevention System — detecta/bloqueia tráfego malicioso na rede (ex.: Suricata).
• EDR: Endpoint Detection & Response — detecta comportamento malicioso no host (processo estranho, persistência).
• No seu porte, o WAF da Cloudflare cumpre boa parte do papel de IPS na borda.

Pilar 7 — Deception (honeypots & canários) 🍯

• A ideia: plantar iscas que ninguém legítimo tocaria — se alguém toca, é ataque. Detecção quase sem falso positivo.
• Do seu CATALOGO §6 / DOC §5.6: endpoint falso /api/internal/debug, canary token no bucket de backup, lead-canário no banco, honeypot SSH.

Pilar 8 — Incident Response (o ciclo) 🚑

• O que fazer quando um alerta vira incidente real. Detalhado na Parte D. É a diferença entre um susto e um desastre.

PARTE C — Como reconhecer um ataque nos logs (a habilidade central) 🔎

O Blue Team lê logs e enxerga a assinatura. Use os padrões do seu CATALOGO §3:

O playbook "estão me escaneando agora" (CATALOGO §4): identificar a ferramenta (UA) → bloquear o IP (WAF) → verificar se achou algo (algum 200 suspeito?) → documentar → endurecer.

PARTE D — Incident Response na prática (o ciclo NIST)

Quando um alerta se confirma como incidente real (DOC §7):

1. PREPARAÇÃO → 2. DETECÇÃO & ANÁLISE → 3. CONTENÇÃO → 4. ERRADICAÇÃO
                                                          │
   6. LIÇÕES APRENDIDAS ← 5. RECUPERAÇÃO ←───────────────┘

• Preparação (antes): contatos, acessos MFA offline, backups testados, canários plantados, runbooks impressos.
• Detecção & análise: é incidente ou falso positivo? Classificar severidade (SEV1–4). Iniciar o relógio. Preservar evidência (snapshot antes de desligar — a RAM se perde).
• Contenção: parar o sangramento sem destruir evidência — isolar (não destruir), revogar chave comprometida, bloquear IP, "Under Attack Mode".
• Erradicação: remover a causa raiz (aplicar a correção que faltou), não só o sintoma.
• Recuperação: restaurar de estado limpo (backup verificado), reaplicar RLS, monitorar de perto 72h.
• Lições aprendidas: post-mortem blameless (foca no processo, não na pessoa); adicionar um teste de regressão.

Classificação de severidade (DOC §7.2): SEV1 (breach de PII/RLS quebrado — RTO 1h, aciona ANPD) → SEV4 (recon sem sucesso — monitorar).

Playbooks por tipo (DOC §7.3): data breach, RCE, DoS, account takeover, phishing de marca — cada um com passos prontos.

PARTE E — Labs práticos 🧪

Lab 1 — Caçar um ataque nos logs (🟢)

Pegue um log (do seu Cloudflare/Nginx, ou um exemplo) e rode as buscas do CATALOGO §3:

# 404s por IP (directory brute-force):
awk '$9==404{print $1}' access.log | sort | uniq -c | sort -rn | head
# indícios de SQLi/XSS nos params:
grep -iE "union.*select|sleep\(|<script|onerror=" access.log | head

Lição: você vê a assinatura do ataque (Parte C).

Lab 2 — Escrever uma regra de detecção (🟡)

Crie uma regra que dispare alerta quando um IP passar de N logins falhos por minuto (ou uma regra WAF do CATALOGO §2). Lição: detecção baseada em assinatura (Pilar 3).

Lab 3 — Plantar um canário e testar o disparo (🟡)

Crie um token em canarytokens.org, plante-o num arquivo/.env falso ou num endpoint isca, e acione-o. Lição: deception — detecção quase sem falso positivo (Pilar 7).

Lab 4 — Tabletop de incidente (🟢) — o mais valioso

Rode o tabletop do DOCUMENTACAO §15.5: cenário "RLS de leads removido há 2h; anon lendo PII". A cada 10 min, uma injeção nova. Decida: quem faz o quê? quando aciona a ANPD? Meça MTTD/MTTR. Entregável: 1 Incident Report preenchido.

Lab 5 — Labs de Blue Team (grátis)

LetsDefend, CyberDefenders e Blue Team Labs Online (BTLO) — cenários reais de SOC (investigar um alerta, analisar um phishing, uma máquina comprometida). A prática que forma o analista defensivo.

PARTE F — Autoavaliação ✅

Responda de memória:

1. Descreva o ciclo detecção-resposta (as etapas).
2. O que são MTTD e MTTR, e por que reduzir o MTTD é prioridade?
3. Por que "visibilidade vem primeiro" (a pirâmide)?
4. Diferencie detecção por assinatura de detecção por anomalia.
5. Por que um canário/honeypot é uma detecção com pouquíssimo falso positivo?
6. Cite as 6 fases do ciclo de resposta a incidentes (NIST).
7. Na resposta, por que "isolar, não destruir" e "snapshot antes de desligar"?

1. Ataque → Evento → Log → Detecção → Alerta → Investigação → Resposta → Correção (A.1).
2. MTTD = tempo até detectar; MTTR = tempo até conter. Reduzir MTTD é prioridade porque um atacante não-detectado age livremente — quanto antes você vê, menor o dano (A.2).
3. Você não detecta o que não registra: sem logs (visibilidade), não há detecção nem resposta (A.3).
4. Assinatura: procura um padrão conhecido (UA sqlmap, UNION SELECT). Anomalia: procura desvio do normal (pico de tráfego). Uma pega o conhecido; a outra, o novo (Pilar 3).
5. Porque ninguém legítimo interage com a isca — qualquer toque é, por definição, suspeito (Pilar 7).
6. Preparação → Detecção & Análise → Contenção → Erradicação → Recuperação → Lições Aprendidas (D).
7. Isolar preserva a evidência (destruir apaga o rastro); snapshot antes de desligar captura a memória (RAM), que se perde ao desligar e pode conter a chave do ataque (D).</details>

Checklist prático:

[ ] Cacei ≥ 1 padrão de ataque num log (Parte C / CATALOGO §3)
[ ] Escrevi 1 regra de detecção / alerta
[ ] Plantei um canário e vi o disparo
[ ] Rodei um tabletop de IR e preenchi 1 Incident Report (MTTD/MTTR)
[ ] Sei classificar severidade (SEV1–4)
[ ] Fiz ≥ 1 cenário no LetsDefend/CyberDefenders/BTLO
[ ] Entendo assinatura × anomalia e a base "visibilidade"

Conclusão: 5/7 do quiz + 1 tabletop feito com métricas.