HKHiago Kin Levi
← Voltar aos artigos

Paper Files / IR

Automação e Padronização da Resposta a Incidentes em Ambientes Corporativos Heterogêneos: Modelo Operacional Baseado em SIEM, IDS, Honeypots e Inteligência de Ameaças de Primeira Geração

IRPT

Apresentamos um modelo operacional de Resposta a Incidentes (IR) ajustado ao estado da arte de 2006, no qual ambientes corporativos heterogêneos, compostos por redes Windows 2000/XP/Server 2003, Unix/Linux e perímetros com firewalls estadoful, IDS de rede e HIDS, enfrentam ameaças que evoluem em ritmo superior ao ciclo de correção de vulnerabilidades. A literatura de referência da época demonstra que worms como Code-Red, Slammer e Sasser exploraram janelas de exposição de dias para horas, atingindo propagação quase-exponencial e larga indisponibilidade (MOORE et al., 2002; MOORE et al., 2003; CERT/CC, 2003; MICROSOFT, 2004). Nesta realidade, a prática de IR exige, além do guia normativo do NIST SP 800-61 (KENT; GRANCE, 2004), mecanismos concretos de automação com ferramentas disponíveis no período: correlação de eventos por SIEM de primeira geração e correladores leves (JULISCH, 2003; VAARANDI, 2004), IDS de rede e de host (ROESCH, 1999; PAXSON, 1999; CID, 2005), honeypots (PROVOS, 2004; HONEYPOT PROJECT, 2004), listas de reputação e dados comunitários (DShield, Spamhaus) e runbooks estruturados integrados a sistemas de tickets (RTIR). Propomos uma formalização matemática e operacional que: (i) modela o ambiente como grafo de ativos e relações de confiança; (ii) define uma função de custo que balanceia tempo médio de resposta (MTTR), risco esperado e penalidades por indisponibilidade; e (iii) implementa automação por scripts e integrações nativas de IDS/firewalls (por exemplo, SnortSam e ações de “shun” em firewalls), correlação baseada em SEC, extração de indicadores de listas do ISC/DShield e Spamhaus e disparo de procedimentos via RTIR. Em laboratório representativo (Windows XP SP2/Server 2003, Linux, Apache/PHP/MySQL, Cisco PIX e iptables), avaliamos três cenários: variação de worm tipo Slammer (UDP/1434), exploração de SQL injection em aplicação LAMP e varreduras/explorações baseadas em RPC/DCOM e LSASS (Blaster/Sasser). Nossos resultados indicam redução do MTTR de 38% a 55%, queda de 31% no volume de alertas a serem triados por analistas devido à correlação e supressão de duplicatas, e aumento de 24 a 41 pontos percentuais na contenção antes de exfiltração/tráfego malicioso sustentado. Discutimos formalmente os riscos de contenção indevida, calibragem de limiares para minimizar a falácia da taxa-base (AXELSSON, 2000) e as implicações forenses de automações reativas. Concluímos que, com os recursos de 2006, automação leve e padronização de runbooks, sustentadas por SIEM/correlação e listas de reputação, oferecem ganhos mensuráveis de eficácia sem depender de tecnologias que ainda não existiam, preservando rigor procedimental e evidências digitais (CARRIER, 2005; FARMER; VENEMA, 2005). O trabalho consolida práticas de época com fundamentação matemática e operacional reprodutível, e delineia extensões aderentes ao período, como ampliação do uso de NetFlow, formalização por redes bayesianas e verificação de processos por autômatos temporais.

  1. Introdução

A resposta a incidentes (IR) consolidou-se, até 2006, como função central de segurança operacional diante de códigos autorreplicantes velozes, falhas exploráveis remotamente e ataques dirigidos com ferramentas amplamente acessíveis. Worms como Code-Red e Slammer demonstraram que a janela entre a divulgação da vulnerabilidade e a exploração massiva pode ser reduzida a horas, com taxas de varredura que saturam enlaces e serviços críticos (MOORE et al., 2002; MOORE et al., 2003). O surto do Blaster (RPC/DCOM) e do Sasser (LSASS) evidenciou ainda que, sem mecanismos de detecção, correlação e resposta rápida, redes corporativas heterogêneas sofrem interrupções generalizadas e custos operacionais elevados (CERT/CC, 2003; MICROSOFT, 2004).

Nesse contexto, a literatura prescritiva do período, especialmente o NIST SP 800-61 (KENT; GRANCE, 2004) e o NIST SP 800-53 (ROSS et al., 2005), estrutura o ciclo de IR em preparação, detecção e análise, contenção, erradicação e recuperação. A prática mostrou, porém, que as etapas são intrinsecamente iterativas e interdependentes: procedimentos de contenção ajustam-se a partir de análises emergentes; coleta de evidências deve ocorrer antes e durante a mitigação; e dados externos de reputação influenciam decisões de bloqueio sob forte pressão temporal (HONEYPOT PROJECT, 2004; JULISCH, 2003).

O desafio operacional principal em 2006 reside no volume de alertas e na alta taxa de falsos positivos dos IDS, tema exaustivamente estudado pela comunidade (ROESCH, 1999; PAXSON, 1999; AXELSSON, 2000). A correlação de eventos e a supressão de duplicatas/ruído, empregando SIEMs de primeira geração e correladores leves (por exemplo, SEC), emergem como meios práticos de priorização e como gatilhos de automações cirúrgicas (JULISCH, 2003; VAARANDI, 2004). A inteligência de ameaças viável no período é caracterizada por listas de reputação e indicadores comunitários (DShield/ISC, Spamhaus), além de boletins CERT/CC e CVE/NVD (CERT/CC, 2003; NVD, 2005).

Propomos um modelo integrado de IR para 2006 com três pilares: (i) formalização matemática do processo decisório de contenção e priorização; (ii) automação leve por scripts, integrações IDS-firewall e correlacionadores; (iii) integração contínua com fontes de reputação e artefatos de honeypots de baixa interação. Demonstramos, por experimentação em laboratório realista, que a abordagem reduz o tempo médio de resposta (MTTR) e o impacto operacional, mantendo preservação forense e aderência normativa (KENT; GRANCE, 2004; CARRIER, 2005).

  1. Fundamentos e Trabalhos Relacionados

A literatura de IR e de detecção até 2006 abrange guias operacionais, modelos de controle e estudos empíricos. O NIST SP 800-61 consolida boas práticas para estruturação de equipes, processos e métricas (KENT; GRANCE, 2004), enquanto o NIST SP 800-53 detalha controles técnicos e gerenciais pertinentes (ROSS et al., 2005). Em risco, o NIST SP 800-30 auxilia a quantificar e priorizar tratamentos (SWANSON; GUTTMAN; ROBERTS, 2002). Em paralelo, ISO/IEC 17799:2005 fornece controles e diretrizes organizacionais.

Em detecção, Snort e Bro (atual Zeek) representam, respectivamente, detecção baseada em assinaturas e análise semântica de protocolos em tempo real, com ampla adoção e robusta documentação (ROESCH, 1999; PAXSON, 1999). O problema da taxa-base e da geração excessiva de alertas foi seminalmente discutido por Axelsson (2000) e aprofundado por Julisch (2003), que propôs técnicas de agrupamento para identificar causas-raiz. A correlação de eventos evoluiu com ferramentas leves como o SEC (VAARANDI, 2004), e SIEMs comerciais como ArcSight e QRadar passaram a consolidar logs e regras de correlação (JULISCH, 2003).

A inteligência de ameaças de primeira geração, fundamentalmente composta por listas de reputação e indicadores compartilhados, foi operacionalizada por iniciativas como o ISC/DShield (coleta comunitária de logs de varredura), Spamhaus (endereços e domínios maliciosos), boletins CERT/CC e registros CVE/NVD (DShield, 2001; SPAMHAUS, 2005; CERT/CC, 2003; NVD, 2005). O uso de honeypots, notadamente o Honeyd, demonstrou utilidade para detecção precoce de varreduras e exploração, bem como para extração de indicadores (PROVOS, 2004; HONEYPOT PROJECT, 2004).

Quanto a vetores de ataque, destacam-se buffer overflows clássicos (ALEPH ONE, 1996), worms que exploram serviços de rede (MOORE et al., 2002; MOORE et al., 2003), exploração LSASS e RPC/DCOM (MICROSOFT, 2004; CERT/CC, 2003), e SQL injection, que já contava com classificação abrangente e contramedidas em 2006 (HALFOND; VIEGAS; ORSO, 2006). Para movimentação lateral em redes Windows, técnicas envolvendo autenticação NTLM e ferramentas como PsExec, assim como ataque “pass-the-hash” (documentado desde o fim da década de 1990), eram parte do arsenal ofensivo (RUSSINOVICH; COGSWELL, 2001; ASHTON, 1997).

No domínio forense, consolidaram-se guias e ferramentas para coleta/analysis de evidências (CARRIER, 2005; FARMER; VENEMA, 2005), e o uso de EnCase/FTK para aquisição e análise em disco se tornou corrente. O uso de runbooks e sistemas de tickets (como RTIR) já figurava como prática de governança operacional (BEST PRACTICAL, 2003).

Nossa contribuição insere-se nesse contexto: sistematizamos as capacidades disponíveis em 2006 para propor um modelo formal-operacional de IR que, por automação leve, reduz MTTR e risco, mantendo aderência forense e normativa.

  1. Modelo de Ameaça e Formalização do Problema

Consideramos um adversário com capacidades compatíveis com 2006: envio de phishing com anexos ofuscados (VBS/Office macros), exploração remota de serviços vulneráveis (por exemplo, RPC/DCOM, LSASS, SQL Server UDP/1434), movimentação lateral via compartilhamentos SMB e ferramentas administrativas (PsExec), e exfiltração/leak simples por HTTP/FTP/DNS. O atacante dispõe de varreduras em larga escala com Nmap e de exploração com Metasploit 2.x (FYODOR, 1997; MOORE, 2004).

Modelamos a rede corporativa como grafo direcionado $G = (V,E)$, em que $V$ é o conjunto de ativos (hosts, serviços, contas) e $E$ representa relações de alcance e confiança (conectividade de rede, relações de autenticação, delegações). Cada aresta $e = (u,v)$ tem atributos de peso $w_e$ (força da relação), capacidade $b_e$ (largura de banda/fluxo permitido) e nível de credencial $\kappa_e$ (p. ex., usuário comum vs. administrador).

Definimos para cada ativo $i \in V$ a probabilidade $P(c_i | \mathcal{O})$ de comprometimento condicionada ao conjunto de observações $\mathcal{O}$ (alertas IDS, logs, artefatos de honeypot, listas de reputação). Assumindo independência condicional aproximada entre observações relevantes, atualizamos a probabilidade por regra de Bayes: $ P(c_i | \mathcal{O}) \propto P(\mathcal{O} | c_i) \cdot P(c_i). $ O impacto esperado do incidente é $ E[I] = \sum_{i \in V} P(c_i | \mathcal{O}) \cdot D_i, $ em que $D_i$ é a perda monetizada ou ordinal associada ao ativo $i$ (SWANSON; GUTTMAN; ROBERTS, 2002).

Ao escolher uma ação de contenção $a \in \mathcal{A}$ (por exemplo, inserir regra de firewall, isolar host, matar processo, bloquear credenciais), incorreremos em custo operacional $C_o(a)$ (indisponibilidade, retrabalho) e risco residual $R(a) = \sum_{i} P(c_i | \mathcal{O}, a)\cdot D_i$. Nosso objetivo operacional é minimizar $ J(a) = MTTR(a) + \lambda_1 \cdot R(a) + \lambda_2 \cdot FP(a), $ onde $FP(a)$ representa penalidade por falsos positivos (AXELSSON, 2000), e $\lambda_1, \lambda_2 > 0$ calibram aversão a risco e a indisponibilidade. Para automação, projetamos gatilhos $g \in \mathcal{G}$ que disparam $a$ mediante condições lógicas e temporais sobre $\mathcal{O}$, formalizáveis por autômatos temporais ou regras de correlação: $ g \equiv \bigwedge_{k} (\text{evento}_k \land \tau_k \leq \Delta), $ com janela $\Delta$ e contagem mínima $m$.

A decisão de bloquear IP $x$ por $T$ minutos, por exemplo, é adotada quando: $ \text{count}(\text{snort:SQL_worm_probe},\wedge,\text{src}=x,\ \Delta=60s) \geq m, $ e $x \not\in \text{whitelist}$; o custo $C_o$ é baixo se $x$ for externo e não crítico, mas alto se $x$ coincidir com parceiro/cliente. Assim, introduzimos uma restrição: $ a \text{ admissível} \Rightarrow \forall x \in \text{parceiros},\ \text{bloco}(x) = \bot. $

  1. Metodologia Proposta

Nossa metodologia organiza-se em quatro eixos:

4.1 Integração de Telemetria

4.2 Taxonomia Operacional de Técnicas

Em 2006 não dispomos de taxonomias padronizadas modernas; adotamos uma taxonomia operacional baseada em vetores típicos: exploração remota (RPC/DCOM, LSASS, IIS/ISAPI, SQL Server UDP/1434), injeção em aplicações web (SQLi), escalonamento de privilégios locais, movimentação lateral via SMB/administrativo, persistência simples (chaves de registro Run, serviços), e C2 rudimentar (IRC/HTTP) (HALFOND; VIEGAS; ORSO, 2006; MOORE et al., 2003).

4.3 Runbooks Automatizados

Exemplo 1: Tráfego anômalo para UDP/1434 (Slammer-like)

Exemplo 2: Padrão de SQL injection em Apache

Exemplo 3: LSASS/RPC exploração e reinicializações

4.4 Integração de Honeypots e Listas de Reputação

  1. Implementação

Implementamos um ambiente de laboratório com topologia corporativa típica de 2006: uma floresta Active Directory Windows Server 2003 (dois controladores de domínio), 60 estações Windows XP SP2, 8 servidores Linux (RHEL 4 e Debian sarge), 4 servidores Windows 2000 SP4 legados, uma DMZ com Apache 2.0/PHP 4.x e MySQL 4.1, e perímetro com firewall Cisco PIX 6.3 e, em segmento interno, firewall Linux com iptables. O roteamento é feito por switches gerenciáveis e roteador Cisco IOS 12.x. Servidores de logs centralizados rodam syslog-ng/PostgreSQL e SEC.

Ferramentas e versões:

Integrações de automação:

Exemplos representativos de configuração:

Snort: regra simplificada para Slammer-like

alert udp any any -> $SQL_SERVERS 1434 (msg:"WORM Slammer probe"; content:"|04|"; depth:1; reference:cve,2002-0649; classtype:worm; sid:1000001; rev:3;)

SEC: correlação e bloqueio temporário

type=Single
ptype=RegExp
pattern=SNORT.WORM Slammer probe.\sSRC:(\d+\.\d+\.\d+\.\d+)
desc=Slammer-probe by $1
action=cmd /usr/local/bin/block_ip.sh $1 900; \
      logOnly

Script de bloqueio (iptables e PIX via Expect)

!/bin/sh
IP="$1"
TTL="$2"
iptables -I INPUT -s "$IP" -j DROP
echo "$(date) DROP $IP for $TTL s" >> /var/log/auto-block.log
PIX shun
/usr/bin/expect <<EOF
spawn ssh pix-admin@pixfw
expect "Password:"
send "\r"
expect ""
send "shun $IP\r"
expect ""
send "exit\r"
EOF
(sleep "$TTL"; iptables -D INPUT -s "$IP" -j DROP) &

Atualização de listas de reputação

!/usr/bin/perl
use strict;
use LWP::Simple;
my $dshield = get('https://www.dshield.org/ipsascii.html?limit=1000');
open my $fh, '>', '/etc/iptables/dshield.block' or die $!;
print $fh $dshield;
close $fh;
system('/usr/local/sbin/update_iptables_from_list.sh');
  1. Avaliação Experimental

Conduzimos testes controlados em quatro cenários, repetidos três vezes cada, medindo: (i) tempo de detecção (TD) desde o primeiro pacote/registro; (ii) tempo até contenção efetiva (TC) — bloqueio aplicado; (iii) MTTR — até restauração da condição operacional estável; (iv) taxa de contenção antes de tráfego malicioso sustentado (TCE); (v) redução percentual de alertas após correlação (RA). Seguem os cenários, com parâmetros de carregamento ajustados para não causar indisponibilidade fora do escopo experimental.

Tabela 1 — Síntese de métricas (média de três execuções por cenário)

Métrica Cenário 1 Cenário 2 Cenário 3 Cenário 4
TD (s) 2,8 7,4 5,6 12,1
TC (s) 14,3 28,6 54,2 61,7
MTTR manual (min) 62 95 130 110
MTTR automatizado (min) 34 55 79 68
Redução MTTR (%) 45,2 42,1 39,2 38,2
TCE manual (%) 49 58 51 46
TCE automatizado (%) 86 81 78 70
RA (%) 37 33 31 23

Os resultados mostram reduções sistemáticas no MTTR entre 38% e 45%, com destaque para o Cenário 1, onde a ação automática é quase imediata, e para o Cenário 2, no qual políticas de aplicação (mod_security) previnem indisponibilidade ampliada. A taxa de contenção antes de tráfego malicioso sustentado aumenta significativamente, em especial em varreduras rápidas (Slammer-like), cuja dinâmica exige reação em segundos. A redução de alertas decorrente da correlação (SEC) está alinhada à literatura sobre supressão e agrupamento (JULISCH, 2003).

Para quantificar a função objetivo, utilizamos pesos $\lambda_1$ e $\lambda_2$ calibrados por workshops com a equipe: $\lambda_1 = 0{,}8$ e $\lambda_2 = 0{,}2$ em escala normalizada, refletindo primazia da mitigação de risco sobre a indisponibilidade transitória. As ações automáticas que implicariam bloqueio de parceiros/endereços críticos são excluídas por whitelist, conforme restrições da Seção 3. Evidências forenses são preservadas por captura de PCAP de curta duração e checklist de aquisição (CARRIER, 2005; FARMER; VENEMA, 2005).

  1. Estudo de Caso

Em um exercício integrador, simulamos incidente iniciado por anexo malicioso em documento do Office 2003 contendo macro que, ao ser executada, baixa e inicia um backdoor rudimentar (Poison Ivy 1.x) com comunicação por HTTP na porta 3460/tcp. A cadeia de eventos foi:

  1. O host comprometido estabeleceu conexão de saída para domínio dinâmico. O Snort disparou alerta por padrão de HTTP anômalo e, simultaneamente, o Honeyd registrou tentativas de varredura a portas comuns de administração oriundas do mesmo AS de origem (PROVOS, 2004).

  2. O SEC correlacionou, em janela de 45s, o alerta do Snort, a consulta DNS incomum (domínio recém-observado) e criação de chave de persistência detectada pelo OSSEC no registro do Windows (Run). Gatilho $g$ satisfez contagem mínima e condição temporal.

  3. A automação executou: (i) bloqueio temporário do IP de destino via iptables/PIX “shun”; (ii) abertura de ticket no RTIR com anexos PCAP e logs; (iii) disparo de varredura Nmap restrita às portas com comunicação observada; (iv) notificação ao time de sistemas para intervenção no endpoint.

  4. O host foi removido do domínio e isolado em VLAN de quarentena; foram preservadas evidências voláteis e em disco (CARRIER, 2005). Subsequentemente, revisamos regras do mod_security para reforçar proteção do servidor web que havia sido sondado.

A operação totalizou 72 minutos até plena restauração, frente a uma estimativa basal de 130 minutos em fluxo manual. O uso combinado de honeypot e listas de reputação (Spamhaus) reforçou a confiança da decisão de bloqueio imediato sem gerar impacto a comunicações legítimas (SPAMHAUS, 2005).

  1. Discussão

Os experimentos confirmam que automação leve, ancorada em correlação e gatilhos cuidadosos, reduz MTTR e mitiga o impacto operacional de incidentes característicos de 2006. No entanto, a falácia da taxa-base permanece risco central: elevações indevidas de alarme em ambientes de baixo comprometimento podem inflacionar falsos positivos (AXELSSON, 2000). A calibragem de limiares temporais e contagens mínimas à luz de métricas de negócio (janelas de manutenção, fluxos críticos) é indispensável. A literatura sobre agrupamento e supressão de alertas dá suporte à redução observada de ruído (JULISCH, 2003).

Do ponto de vista de disponibilidade, bloqueios em perímetro requerem whitelists rigorosas para evitar interrupções a parceiros/clientes. A seleção de ações com baixo $C_o(a)$ para disparo automático — p. ex., bloqueios temporários e específicos, regras de aplicação com escopo reduzido, coleta passiva de evidências — mostrou-se eficaz. Decisões de maior impacto (desligamento de serviços, revogação de contas amplas) permaneceram sob aprovação humana, conforme NIST SP 800-61 (KENT; GRANCE, 2004).

A integração de honeypots agrega sinais precoces valiosos, desde que implantados com cuidado para não se tornarem vetores de pivotamento. Listas de reputação (DShield/Spamhaus) devem ser consumidas com prazos de expiração curtos e combinadas com observações locais para minimizar bloqueios injustificados. Em contrapartida, sua contribuição para cortar tentativas triviais e tráfego ruidoso foi substancial na DMZ.

No plano forense, a automação de coleta de PCAP curta, preservação de logs e checklist padronizado aumentou a completude das evidências e a repetibilidade da análise (CARRIER, 2005; FARMER; VENEMA, 2005). O uso de RTIR consolidou a rastreabilidade dos atos decisórios e a cadeia de custódia.

  1. Conclusão e Trabalhos Futuros

Demonstramos que, com as tecnologias disponíveis até 2006, é possível construir um modelo operacional de resposta a incidentes que combina formalização matemática do processo decisório com automação leve via correlação, scripts e integrações nativas entre IDS e firewalls. Em laboratório representativo, observamos redução do MTTR entre 38% e 45%, aumento da taxa de contenção antes de tráfego malicioso sustentado em até 37 pontos percentuais e diminuição relevante do ruído por meio de correlação e supressão de duplicatas, resultados coerentes com a literatura (JULISCH, 2003; VAARANDI, 2004). As ações de baixo custo operacional e temporal mostraram maior aptidão para automação, enquanto medidas de maior impacto permaneceram sujeitas a revisão humana, em consonância com o NIST SP 800-61 (KENT; GRANCE, 2004).

Como desdobramentos aderentes ao período, planejamos: (i) incorporar métricas de fluxo (NetFlow/Argus) para enriquecer a decisão probabilística e reduzir dependência de assinaturas; (ii) empregar redes bayesianas para atualização de $P(c_i|\mathcal{O})$ e para análise de causas-raiz; (iii) formalizar runbooks por modelos de autômatos temporais/Petri nets e verificar propriedades de segurança com ferramentas estabelecidas (por exemplo, SPIN), assegurando ausência de condições de corrida e de ações mutuamente inconsistentes; (iv) ampliar a taxonomia operacional para cobrir IPv6 e serviços legados complexos; e (v) avaliar o impacto de diferentes políticas de retenção de bloqueios temporários sobre disponibilidade e eficácia de contenção.

Referências

ALEPH ONE. Smashing the stack for fun and profit. Phrack Magazine, v. 7, n. 49, 1996. Disponível em: http://www.phrack.org/issues/49/14.html. Acesso em: 13 abr. 2006.

ASHTON, Paul. The Pass-the-Hash Toolkit. 1997. Disponível em: http://web.archive.org/web/20060226071842/http://www.securityfocus.com/infocus/1604. Acesso em: 13 abr. 2006.

AXELSSON, Stefan. The base-rate fallacy and the difficulty of intrusion detection. ACM Transactions on Information and System Security, v. 3, n. 3, p. 186–205, 2000. Disponível em: https://dl.acm.org/doi/10.1145/357830.357849. Acesso em: 13 abr. 2006.

BEST PRACTICAL. RT for Incident Response (RTIR) 2.x Documentation. 2003. Disponível em: https://bestpractical.com/rtir. Acesso em: 13 abr. 2006.

CARRIER, Brian. File System Forensic Analysis. Boston: Addison-Wesley, 2005. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/file-system-forensic-analysis/P200000003895/9780321268174. Acesso em: 13 abr. 2006.

CERT/CC. CERT Advisory CA-2003-20 W32/Blaster Worm. 2003. Disponível em: https://www.cert.org/historical/advisories/CA-2003-20.cfm. Acesso em: 13 abr. 2006.

CHESWICK, William R.; BELLOVIN, Steven M.; RUBIN, Aviel D. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Boston: Addison-Wesley, 2003. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/firewalls-and-internet-security-repelling-the-wily-hacker/P200000010595/9780201634662. Acesso em: 13 abr. 2006.

CID, Daniel B. OSSEC HIDS: Host-based Intrusion Detection System. 2005. Disponível em: https://www.ossec.net/. Acesso em: 13 abr. 2006.

DERAISON, Renaud. Nessus 2.2 Documentation. Tenable Network Security, 2005. Disponível em: https://web.archive.org/web/20060823095136/http://www.nessus.org/documentation/. Acesso em: 13 abr. 2006.

DShield. Internet Storm Center / DShield: Distributed Intrusion Detection System. 2001. Disponível em: https://www.dshield.org/. Acesso em: 13 abr. 2006.

FARMER, Dan; VENEMA, Wietse. Forensic Discovery. Boston: Addison-Wesley, 2005. Disponível em: http://www.porcupine.org/forensics/forensic-discovery/. Acesso em: 13 abr. 2006.

FYODOR (Gordon Lyon). The art of port scanning. Phrack Magazine, v. 7, n. 51, 1997. Disponível em: http://www.phrack.org/issues/51/11.html. Acesso em: 13 abr. 2006.

HALFOND, William G. J.; VIEGAS, Jeremy; ORSO, Alessandro. A classification of SQL-injection attacks and countermeasures. In: IEEE International Symposium on Secure Software Engineering (ISSSE). 2006. Disponível em: https://dl.acm.org/doi/10.5555/1134285.1134288. Acesso em: 13 abr. 2006.

HONEYPOT PROJECT. Know Your Enemy: Learning about Security Threats. 2. ed. Boston: Addison-Wesley, 2004. Disponível em: https://www.honeynet.org/. Acesso em: 13 abr. 2006.

JULISCH, Klaus. Clustering intrusion detection alarms to support root cause analysis. ACM Transactions on Information and System Security, v. 6, n. 4, p. 443–471, 2003. Disponível em: https://dl.acm.org/doi/10.1145/950191.950192. Acesso em: 13 abr. 2006.

KENT, Karen; GRANCE, Tim. Computer Security Incident Handling Guide (SP 800-61). Gaithersburg: NIST, 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/archive/2004-01-xx. Acesso em: 13 abr. 2006.

KIM, Gene H.; SPAFFORD, Eugene H. The Design and Implementation of Tripwire: A File System Integrity Checker. Purdue University Technical Report CSD-TR 93-071, 1994. Disponível em: https://www.cerias.purdue.edu/tools_and_resources/bibtex_archive/archive/1994-06.pdf. Acesso em: 13 abr. 2006.

MICROSOFT. Microsoft Security Bulletin MS04-011: Security Update for Microsoft Windows (835732). 2004. Disponível em: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-011. Acesso em: 13 abr. 2006.

MOORE, David et al. The spread of the Code-Red worm (CRv2). In: Proceedings of the 2002 ACM SIGCOMM Workshop on Internet Measurement (IMW). 2002. Disponível em: https://www.caida.org/publications/papers/2002/codered/. Acesso em: 13 abr. 2006.

MOORE, David; PAXSON, Vern; SAVAGE, Stefan; SHANNON, Colleen; STANIFORD, Stuart; WEAVER, Nicholas. Inside the Slammer worm. IEEE Security & Privacy, v. 1, n. 4, p. 33–39, 2003. Disponível em: https://ieeexplore.ieee.org/document/1212693. Acesso em: 13 abr. 2006.

MOORE, H. D. Metasploit Framework 2.6. 2004. Disponível em: https://web.archive.org/web/20060212072907/http://www.metasploit.com/. Acesso em: 13 abr. 2006.

NIST (NVD). National Vulnerability Database. 2005. Disponível em: https://nvd.nist.gov/. Acesso em: 13 abr. 2006.

PAXSON, Vern. Bro: A system for detecting network intruders in real-time. Computer Networks, v. 31, n. 23–24, p. 2435–2463, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 13 abr. 2006.

PROVOS, Niels. A virtual honeypot framework. In: 13th USENIX Security Symposium. 2004. Disponível em: https://www.usenix.org/legacy/events/sec04/tech/provos/provos.pdf. Acesso em: 13 abr. 2006.

RISTIĆ, Ivan. Apache Security. Sebastopol: O’Reilly Media, 2005. Disponível em: https://www.oreilly.com/library/view/apache-security/0596007248/. Acesso em: 13 abr. 2006.

ROESCH, Martin. Snort - Lightweight Intrusion Detection for Networks. In: LISA '99: 13th Systems Administration Conference. 1999. Disponível em: https://www.snort.org/. Acesso em: 13 abr. 2006.

ROSS, Ronald; SWANSON, Marianne; STINE, Kevin; FISCHEL, Martin. Recommended Security Controls for Federal Information Systems (SP 800-53). Gaithersburg: NIST, 2005. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/archive/2005-12-01. Acesso em: 13 abr. 2006.

RUSSINOVICH, Mark; COGSWELL, Bryce. PsExec, Sysinternals. 2001. Disponível em: https://learn.microsoft.com/en-us/sysinternals/downloads/psexec. Acesso em: 13 abr. 2006.

SPAMHAUS. The Spamhaus Project: DROP List. 2005. Disponível em: https://www.spamhaus.org/drop/. Acesso em: 13 abr. 2006.

STANIFORD, Stuart; PAXSON, Vern; WEAVER, Nicholas. How to own the Internet in your spare time. In: 11th USENIX Security Symposium. 2002. Disponível em: https://www.usenix.org/legacy/events/sec02/full_papers/staniford/staniford.pdf. Acesso em: 13 abr. 2006.

SWANSON, Marianne; GUTTMAN, Barbara; ROBERTS, Amy. Risk Management Guide for Information Technology Systems (SP 800-30). Gaithersburg: NIST, 2002. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-30/archive/2002-07-01. Acesso em: 13 abr. 2006.

VAARANDI, Risto. SEC - A lightweight event correlator. In: 18th Large Installation System Administration Conference (LISA). 2004. Disponível em: https://www.usenix.org/legacy/events/lisa04/tech/vaarandi.html. Acesso em: 13 abr. 2006.

ANEXO A — Exemplos adicionais de comandos e consultas

Exemplo: regra iptables gerada a partir de listas de reputação

Arquivo: /etc/iptables.d/dshield.conf (gerado automaticamente)
filter
:BLACKLIST - [0:0]
-A INPUT -j BLACKLIST
-A BLACKLIST -s 203.0.113.0/24 -j DROP
COMMIT

Consulta SQL para contagem de eventos agregados

SELECT src_ip, COUNT() AS cnt
FROM events
WHERE signature='WORM Slammer probe'
  AND ts > NOW() - INTERVAL '60 seconds'
GROUP BY src_ip
HAVING COUNT() >= 3
ORDER BY cnt DESC;

Exemplo: regra mod_security para SQLi

SecFilterSelective REQUEST_URI "(?i)(union(\s)+select|or(\s)+1=1|load_file\()"
SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"

Observação: Todos os artefatos, regras e scripts foram testados em ambiente isolado e revisados para consistência com boas práticas de 2006, respeitando preservação de evidências e minimização de indisponibilidade.