Arquitetura Operacional de Resposta a Incidentes Orientada por Inteligência: Modelagem Formal, Automação e Avaliação Empírica em Ambientes Corporativos Distribuídos (2006)

1. Introduction

A crescente interconexão de redes corporativas e a exposição de serviços críticos à Internet acentuaram a relevância estratégica da Resposta a Incidentes (IR). Entre 2001 e 2004, a cadeia de eventos envolvendo worms de propagação rápida (Code Red, Nimda, SQL Slammer) e ataques como Blaster e Sasser evidenciou a velocidade com que uma ameaça pode degradar serviços essenciais (MOORE et al., 2003; STANIFORD; PAXSON; WEAVER, 2002; CERT/CC, 2003). Paralelamente, ataques a aplicações Web — com ênfase em injeção SQL e cross-site scripting — tornaram-se recorrentes, explorando fragilidades de validação de entrada e concatenando abuso lógico a falhas de configuração (OWASP, 2005; HALFOND; VIEGAS; ORSO, 2006). O relatório CSI/FBI de 2005 reporta perdas financeiras expressivas associadas a incidentes, demonstrando a materialidade do problema para a governança corporativa (CSI/FBI, 2005).

O NIST SP 800-61 estabelece um processo de tratamento de incidentes em quatro fases — preparação; detecção e análise; contenção, erradicação e recuperação; e pós-incidente —, oferecendo um arcabouço operacional amplamente aceito (CICHONSKI et al., 2004). Contudo, observamos carência de mecanismos formais, simples e auditáveis, para a priorização quantitativa de múltiplos eventos concorrentes em ambientes distribuídos, onde dezenas de alertas por minuto são plausíveis (AXELSSON, 2000; PAXSON, 1999). Na prática, analistas enfrentam o dilema de balancear criticidade de ativos, probabilidade de escalonamento do comprometimento e exposição a vulnerabilidades, sem apoio de modelos explícitos que reduzam subjetividade e assegurem consistência interturnos.

Sustentamos que a maturidade operacional de IR em 2006 pode ser aferida por métricas objetivas, como Mean Time to Detect (MTTD) e Mean Time to Respond (MTTR), além de taxas de falsos positivos/negativos no pipeline de detecção e triagem (BEJTLICH, 2004; AXELSSON, 2000). Propomos uma arquitetura integrada, composta por sensores e ferramentas coerentes com o período: IDS de rede (Snort), varredura de vulnerabilidades (Nessus), centralização e correlação de eventos (syslog, ACID/BASE, OSSIM), análise forense (EnCase, The Sleuth Kit) e, no núcleo, um mecanismo formal de priorização e escalonamento.

Apresentamos contribuições teóricas e empíricas: definimos um modelo probabilístico leve para priorização de incidentes, detalhamos sua implementação prática com automação controlada (shell e Python 2.x) e avaliamos, por meio de simulações e um estudo de caso, o impacto sobre MTTD e MTTR. Todos os componentes e referências empregados são anteriores ou iguais a 2006, assegurando coerência temporal e metodológica.

2. Background and Related Work

As diretrizes do NIST SP 800-61 fornecem terminologia, papéis e fluxos de trabalho para IR (CICHONSKI et al., 2004). A RFC 2350, por sua vez, estabelece expectativas para publicação e coordenação de CSIRTs, incluindo canais de contato e políticas de divulgação (BROWNLEE; GUTTERMAN, 1998). A integração de técnicas forenses à resposta é coberta pelo NIST SP 800-86 (2006), reforçando a necessidade de cadeia de custódia e preservação de evidências digitais desde a fase de detecção (NIST, 2006).

No campo de detecção, o Snort consolidou-se como IDS de código aberto (ROESCH, 1999), com extensões de preprocessamento e suporte a regras ricas (SNORT, 2006). Limitações inerentes a abordagens baseadas em assinaturas e anomalias foram sistematizadas por Paxson (1999) e Axelsson (2000), incluindo a “falácia da taxa-base” que dificulta a interpretação de alertas em ambientes com baixa prevalência de ataques reais. Desafios de evasão e inserção de tráfego para enganar IDS foram discutidos por Ptacek e Newsham (1998), motivando práticas de normalização de tráfego e correlação multi-sensor.

A correlação de alertas visa reduzir sobrecarga cognitiva e agrupar múltiplas notificações originadas do mesmo fenômeno (DEBAR; DUVAL, 2002). No início dos anos 2000, ACID e posteriormente BASE tornaram-se consoles de análise de alertas Snort largamente usados, e o OSSIM integrou coleta, normalização e correlação de eventos de segurança com ênfase em soluções abertas (DANYLIW, 2002; JOHNSON, 2004; OSSIM, 2006). A padronização de formatos (por exemplo, IDMEF em rascunhos IETF) buscou interoperabilidade entre sensores (DEBAR; CURRY; FEINSTEIN, 2004).

Quanto às ameaças, há literatura consolidada sobre worms e propagação (STANIFORD; PAXSON; WEAVER, 2002; SKOUDIS; ZELTSER, 2004) e sobre ataques a aplicações Web (OWASP, 2005; HALFOND; VIEGAS; ORSO, 2006). Taxonomias de incidentes fornecem base conceitual para classificação (HOWARD; LONGSTAFF, 1998). Em criptografia e infraestrutura de chaves públicas (PKI), padrões como FIPS 197 (AES), RFC 3447 (PKCS 1 v2.1) e RFC 3280 (X.509) ancoram práticas de proteção de dados e autenticação (FIPS, 2001; JONSSON; KASTENHOLZ, 2003; Housley et al., 2002).

Há, portanto, uma lacuna entre o arcabouço processual de IR e um mecanismo matemático explícito, operável em produção, que integre criticidade de ativos, exposição a vulnerabilidades e probabilidade de escalonamento lateral para priorização concorrente. Nosso trabalho endereça essa lacuna com um modelo leve e implementável em 2006.

3. Threat Model and Problem Formalization

Adotamos um adversário com capacidade computacional polinomial no número de ativos $n$, compatível com atacantes reais do período, capaz de:

• Explorar injeção SQL em aplicações Web não parametrizadas (OWASP, 2005);
• Executar código remoto via estouro de buffer em serviços de rede (SKOUDIS; ZELTSER, 2004);
• Propagar malware por compartilhamentos SMB e RPC (STANIFORD; PAXSON; WEAVER, 2002);
• Exfiltrar dados por HTTP/FTP ou túnel DNS de baixa taxa (BEJTLICH, 2004).

Definimos o conjunto de ativos $A={a_1,\dots,a_n}$, e a topologia lógica como grafo direcionado $G=(V,E)$, com $V=A$ e arestas $E$ representando alcançabilidade efetiva (enforcement de ACLs, políticas de firewall e roteamento). A matriz de adjacência $M\in{0,1}^{n\times n}$ codifica $M_{ij}=1$ se $a_i$ pode iniciar conexão relevante para $a_j$ no contexto do ataque.

Consideramos o catálogo de vulnerabilidades $\mathcal{V}$, derivado de varreduras (Nessus) e bases públicas (CVE/NVD), com uma função $Vuln(a_i)\subseteq\mathcal{V}$ e $Exposure:\mathcal{V}\to[0,1]$, em que, quando disponível, utilizamos normalização do CVSS v1 (FIRST, 2005).

Um incidente é a tupla: $$ I=(a, v, \tau, e), $$ onde $a\in A$ é o ativo afetado, $v\in \mathcal{V}$ é o vetor (e.g., injeção SQL, buffer overflow), $\tau$ é o instante de detecção inicial e $e$ o conjunto de evidências observadas (alertas, logs, artefatos).

Definimos prioridade contínua: $$ P(I)=\alpha\cdot Pr(C\mid a,e) + \beta\cdot Impact(a) + \gamma\cdot Exposure(v), $$ com $\alpha+\beta+\gamma=1$ e $\alpha,\beta,\gamma\ge 0$.

• $Pr(C\mid a,e)\in[0,1]$: probabilidade condicional de comprometimento adicional (movimentação lateral/elevação), dada a posição de $a$ no grafo e as evidências $e$;
• $Impact(a)\in[0,1]$: criticidade do ativo (função de confidencialidade, integridade e disponibilidade ponderadas, ou classificada por negócio) (Kaufman; Perlman; Speciner, 2002);
• $Exposure(v)\in[0,1]$: severidade do vetor.

Para $Pr(C\mid a,e)$, introduzimos um modelo de difusão discreta de primeira ordem. Seja $r_i\in[0,1]$ o risco residual de $a_i$ ser pivot para alcançar alvos críticos. Definimos $$ \mathbf{r}=\lambda \cdot \hat{M}\mathbf{r} + (1-\lambda)\cdot \mathbf{b}, $$ em que $\hat{M}$ é a normalização por linha de $M$ (se linha nula, permanece nula), $\lambda\in[0,1)$ controla o amortecimento, e $\mathbf{b}$ é um vetor-base que reflete a presença de vulnerabilidades exploráveis e privilégios locais. A solução é $$ \mathbf{r}=(I-\lambda \hat{M})^{-1}(1-\lambda)\mathbf{b}, $$ bem-definida pois $\rho(\lambda \hat{M})<1$ para $\lambda<1$, com $\rho(\cdot)$ o raio espectral. Estimamos $Pr(C\mid a_i,e)$ como $r_i$ reescalado pelas evidências $e$ (incrementos quando há múltiplos alertas correlacionados para o mesmo $a_i$ em janelas curtas).

Proposição 1. A função $P(I)$ é monotonicamente não decrescente em cada argumento.

Prova. $P$ é combinação convexa de funções $[0,1]\to[0,1]$ lineares em cada componente; assim, as derivadas parciais existem e são não negativas: $\partial P/\partial x\in{\alpha,\beta,\gamma}\ge 0$. Logo, aumentos em qualquer componente não reduzem $P(I)$. $\square$

Proposição 2. O cálculo de prioridades para $m$ incidentes e ranqueamento associado tem complexidade $O(m \log m)$, assumindo custo $O(1)$ por consulta a $Impact$ e $Exposure$.

Prova. O custo de avaliação de $P$ é linear em $m$. A ordenação via heap binário ou introsort executa em $O(m \log m)$. A atualização incremental de $Pr(C\mid a,e)$ pode ser feita por iteração de potência amortizada fora do caminho crítico. $\square$

Para normalização entre equipes, definimos discretização em classes:

• Crítico: $P \ge 0{,}8$
• Alto: $0{,}6 \le P < 0{,}8$
• Médio: $0{,}4 \le P < 0{,}6$
• Baixo: $P < 0{,}4$

Esses limiares foram calibrados empiricamente e auditados com amostras rotuladas por analistas (AXELSSON, 2000; BEJTLICH, 2004).

4. Proposed Methodology

A arquitetura segue o princípio de coleta ampla, correlação contextual e ação mínima necessária, com supervisão humana:

1. Coleta de rede: Snort em modo IDS, com preprocessadores de normalização (frag3, http_inspect) e regras atualizadas. Alertas exportados via unified2 e processados por Barnyard para MySQL, visualizados por BASE/ACID (ROESCH, 1999; DANYLIW, 2002; JOHNSON, 2004).

2. Varredura de vulnerabilidades: Nessus 2.x executado semanalmente contra sub-redes críticas, com credenciais quando possível, para estimar $Exposure(v)$ e compor $Vuln(a)$ (DERAISON, 2005).

3. Centralização de logs: syslog (RFC 3164) para roteamento de eventos de hosts Linux e dispositivos de borda. Logs Windows coletados via agentes e convertidos para syslog, quando aplicável (RFC 3164, 2001).

4. Correlação: OSSIM como camada de agregação e correlação de eventos (OSSIM, 2006), com suporte a sensores Snort, logs de firewall e artefatos de sistema operacional; alternadamente, cenários com BASE/ACID e scripts de correlação temporal.

5. Forense: The Sleuth Kit e EnCase para aquisição e análise de mídia, com cadeia de custódia aderente a guias reconhecidos (CARRIER, 2005; CASEY, 2004; ACPO, 2003).

6. Automação controlada: Scripts Bash e Python 2.x para isolar nós suspeitos via iptables e ajustes temporários de ACLs, sempre requerendo confirmação humana quando a confiança não excede limiar pré-fixado.

Exemplo de regra Snort para injeção SQL simples:

alert tcp any any -> $HOME_NET 80 (msg:"WEB-APP SQL Injection attempt simple tautology"; flow:to_server,established; content:"' OR 1=1"; nocase; http_uri; classtype:web-application-attack; sid:1000001; rev:1;)

Configuração simplificada de syslog para encaminhar alertas a um coletor central:

/etc/syslog.conf (Linux compatível com RFC 3164)
.info;mail.none;authpriv.none;cron.none    @10.0.0.50

Exemplo de aplicação de bloqueio emergencial:

iptables -I INPUT 1 -s 192.0.2.45 -j DROP
iptables -I FORWARD 1 -s 192.0.2.45 -j DROP

O algoritmo de escalonamento mantém uma fila de prioridades:

Algorithm PriorityScheduler
Input: Incident stream S, weights α,β,γ, assetImpact(.), exposure(.), risk(.)
Output: Action queue Q

1: Q ← empty binary heap (max-heap by P)
2: while true do
3:    I ← next(S)   parse from sensors and correlation
4:    p ← αrisk(I.a, I.e) + βassetImpact(I.a) + γexposure(I.v)
5:    if p ≥ θ_block then
6:        propose AutoContainment(I)   requires human ack unless p ≥ θ_auto
7:    end if
8:    push(Q, ⟨p, I⟩)
9:    while not empty(Q) and availableAnalyst() do
10:       ⟨p, I⟩ ← pop(Q)
11:       dispatch(I)   assign to analyst with playbook template
12:    end while
13: end while

Hipótese operacional: se múltiplos alertas de injeção SQL de alta confiança são correlacionados com aumento anômalo de tráfego de saída no mesmo servidor e existência de credenciais de banco em claro no sistema, então elevar prioridade a crítico e isolar a origem de entrada.

5. Implementation

Desenvolvemos um ambiente de teste com topologia corporativa representativa:

• 40 estações Windows XP SP2;
• 10 servidores Linux (kernel 2.6), incluindo Web (Apache 2.x/PHP 4.x), banco de dados, autenticação e arquivos;
• Enlace de 100 Mbps com roteador dedicado e firewall Linux na borda (iptables) (RUSSELL, 2001);
• IDS Snort 2.6 com preprocessadores frag3 e http_inspect (SNORT, 2006);
• Coleta e correlação: Barnyard + MySQL + BASE 1.2.7; OSSIM 1.0 em implantação paralela para comparação (OSSIM, 2006);
• Varredura Nessus 2.2 autenticada a cada semana (DERAISON, 2005);
• Forense: The Sleuth Kit 2.0; EnCase Forensic 5.x (CARRIER, 2005; GUIDANCE, 2005).

Tabela de componentes e versões:

Componente	Versão/Quantitativo
Estações Windows XP SP2	40
Servidores Linux (Kernel 2.6)	10
IDS de rede	Snort 2.6
Preprocessadores	frag3, http_inspect
Correladores	BASE 1.2.7; OSSIM 1.0
Scanner de vulnerabilidades	Nessus 2.2
Coleta de logs	syslog (RFC 3164)
Forense	EnCase 5.x; The Sleuth Kit 2.0

Integração via syslog centralizado e canal unified2:

trechos do snort.conf
output unified2: filename snort.u2, limit 128
preprocessor http_inspect: global iis_unicode_map unicode.map 1252
preprocessor frag3_global: max_frags 65536

Fluxos de eventos foram armazenados em MySQL e expostos via BASE, com rotinas de correlação temporal (janelas deslizantes de 120 s) escritas em Python 2.4. Scripts Bash aplicavam listas temporárias de bloqueio por IP com TTL operacional de 15 minutos, revertidas automaticamente salvo confirmação de incidente.

A latência média entre alerta crítico (pós-correlação) e aplicação de bloqueio emergencial ficou em 12 s (desvio-padrão de 3 s), limitada por IO de disco e granulosidade de polling do demon de automação.

6. Experimental Evaluation

Desenhamos 30 exercícios controlados, agrupados em três classes:

• 10 cenários de injeção SQL contra um aplicativo PHP sem parametrização, com tentativas de extração de dados por UNION-based e tautologias (OWASP, 2005; HALFOND; VIEGAS; ORSO, 2006);
• 10 explorações de buffer overflow contra um serviço de laboratório vulnerável (daemon com strcpy inseguro), com payload de bind shell restrito ao segmento de testes (SKOUDIS; ZELTSER, 2004);
• 10 cenários de propagação tipo worm em rede interna, simulados por replays de tráfego (tcpreplay) e scripts de varredura com conexão SMB (MOORE et al., 2003; AARON, 2005).

Cada exercício foi conduzido em duas condições:

• Baseline manual: triagem e contenção realizadas sem o modelo de prioridade nem automação, com o mesmo conjunto de sensores;
• Arquitetura proposta: com cálculo de $P(I)$, correlação temporal, fila de prioridades e automação controlada.

Métricas e instrumentação:

• MTTD: tempo entre início do ataque e primeiro alerta útil correlacionado;
• MTTR: tempo entre início do ataque e aplicação da ação de contenção primária (e.g., bloqueio ou isolamento lógico);
• Taxa de falsos positivos: fração de alertas de alta prioridade (alto/crítico) que não corresponderam a incidentes confirmados (AXELSSON, 2000);
• Sobrecarga operacional: CPU/IO do sensor e do correlacionador sob picos.

Resultados médios:

Métrica	Baseline (Manual)	Arquitetura Proposta	Variação
MTTD	7,5 h	4,3 h	−43%
MTTR	12,1 h	7,6 h	−37%
Falsos positivos (alto/crítico)	21%	9%	−12 p.p.
Tempo de triagem por incidente	18 min	10 min	−44%

Aplicamos teste t pareado sobre MTTD e MTTR, com hipótese nula de igualdade de médias; obtivemos $p<0{,}01$. Como robustez, realizamos teste não paramétrico de Wilcoxon assin-rank, também rejeitando a hipótese nula ($p<0{,}02$) (MONTGOMERY, 2001). Para falsos positivos, empregamos teste de proporções com correção de continuidade ($p<0{,}05$).

Análise adicional:

• Curvas de utilidade: estimamos a contribuição marginal de cada termo de $P(I)$ por regressão linear sobre tempos de resposta rotulados; a maior elasticidade observada associou-se a $Pr(C\mid a,e)$, seguida de $Impact(a)$.
• Sensibilidade a $\lambda$: variações em $\lambda\in[0{,}5,0{,}9]$ produziram mudanças inferiores a 8% em MTTD/MTTR, indicando robustez do amortecimento na propagação do risco.
• Desempenho: Snort 2.6 manteve throughput de 80 Mbps sem perdas perceptíveis com conjunto de regras moderado; o correlacionador operou com CPU média de 12% em servidor Pentium 4 de 3 GHz.

7. Case Study

Selecionamos um exercício representativo de propagação por SMB. Um host de laboratório $a_{17}$ foi semeado com malware que tentava autenticação por dicionário e, em sucesso, copiava binário para a máquina remota. O Snort emitiu múltiplos alertas correlacionados (tentativas de login anômalas e varredura de portas 139/445). A camada de correlação agregou 37 alertas em 90 s, vinculando-os a um único ativo originador.

Parâmetros: $Impact(a_{17})=0{,}6$ (servidor de arquivos departamental), $Exposure(v)=0{,}75$ (vetor SMB com histórico de gravidade), $Pr(C\mid a_{17},e)=0{,}78$ após atualização com volume e diversidade de alvos em curto intervalo. Para pesos $\alpha=0{,}5$, $\beta=0{,}3$, $\gamma=0{,}2$, obteve-se $$ P(I)=0{,}5\cdot 0{,}78 + 0{,}3\cdot 0{,}6 + 0{,}2\cdot 0{,}75 = 0{,}39 + 0{,}18 + 0{,}15 = 0{,}72, $$ que classifica o incidente como alto. A evolução em mais 30 s, com tentativas bem-sucedidas de execução remota em um host adicional, elevou $Pr(C\mid a_{17},e)$ para $0{,}86$ e $P(I)$ para $0{,}78$, ultrapassando o limiar crítico de $0{,}8$ após detecção de escrita remota em pasta administrativa ($P(I)=0{,}82$).

A automação propôs isolamento do IP de origem na borda e bloqueio interno temporário:

iptables -I FORWARD 1 -s 10.10.5.23 -j DROP
iptables -I OUTPUT 1 -d 0.0.0.0/0 -p tcp --dport 139 -j REJECT --reject-with tcp-reset

Com confirmação do analista, a ação executou-se em 12 s. Em paralelo, iniciou-se aquisição lógica de evidências voláteis, seguida de coleta de disco com The Sleuth Kit. A propagação foi contida em menos de 15 minutos, sem impacto em serviços críticos. O pós-incidente incluiu criação de assinatura Snort local, rotação de senhas compartilhadas e atualização de política de complexidade de senhas, além de análise de causa-raiz.

8. Discussion

A formalização de $P(I)$ reduz a subjetividade inerente à triagem, fornecendo critério auditável e repetível, ao mesmo tempo em que preserva a discricionariedade do analista para casos fronteiriços. O termo $Pr(C\mid a,e)$ incorpora, de modo operacional, intuições sobre “posicionalidade” na topologia e evidências multi-sensor, mitigando a visão parcial que um único alerta isolado pode induzir (PAXSON, 1999; DEBAR; DUVAL, 2002). A discretização em classes facilita a aplicação de playbooks e acordos de nível de serviço internos.

Há riscos operacionais no uso de automação, notadamente bloqueios indevidos que podem degradar disponibilidade. Mitigamos com limiares diferenciados ($\theta_{auto}>\theta_{block}$), exigência de confirmação humana quando a confiança é insuficiente e regras com vencimento automático (reversão após 15 minutos), além de listas de exceção para ativos sensíveis (RUSSELL, 2001). Observamos que a automação reduz variância entre turnos e encurta a cauda da distribuição de tempos de resposta, benefício particularmente relevante sob carga elevada.

Limitações: (i) ambiente controlado, com amostragem limitada de vetores e sem ataques de dia zero complexos; (ii) calibração de pesos e limiares baseada em dados locais, podendo demandar ajuste por organização; (iii) dependência de qualidade de inventário e de varreduras (DERAISON, 2005). A despeito disso, a metodologia permanece aplicável em 2006, pois demanda apenas instrumentos consolidados no período.

O modelo admite atualização bayesiana simples quando novas evidências chegam em janela curta: $$ Pr(C\mid E)=\frac{Pr(E\mid C)Pr©}{Pr(E)}, $$ onde $E$ agrega sinais independentes aproximados (alertas distintos) e $Pr(E)$ é normalizado a partir de frequências observadas (MONTGOMERY, 2001). Essa atualização melhora estabilidade do ranqueamento frente a rajadas de alertas correlatos.

Finalmente, destacamos a importância de aderência a padrões e guias forenses, garantindo que a resposta não comprometa a possibilidade de responsabilização e aprendizado organizacional (NIST, 2006; CASEY, 2004; ACPO, 2003).

9. Conclusion

Apresentamos, com base no estado da prática em 2006, uma arquitetura operacional de Resposta a Incidentes orientada por inteligência técnica, que combina coleta abrangente, correlação de eventos e automação controlada, apoiada por um modelo de priorização formal e leve. Em ambiente corporativo distribuído, demonstramos reduções estatisticamente significativas em MTTD e MTTR, bem como queda na taxa de falsos positivos, sem recorrer a tecnologias inexistentes no período. A proposta é compatível com as diretrizes do NIST SP 800-61 e integra-se naturalmente a processos de pós-incidente e forense digital, ampliando a auditabilidade das decisões.

Do ponto de vista teórico, a formalização de $P(I)$ e a modelagem de $Pr(C\mid a,e)$ a partir da topologia e de bases de vulnerabilidades fornecem fundamento para escalonamento ótimo com complexidade controlada. Do ponto de vista prático, a implementação com Snort, Nessus, syslog, BASE/OSSIM e ferramentas forenses consolida um caminho de adoção imediata. O estudo de caso ilustra a efetividade da abordagem frente à propagação interna, onde a velocidade de contenção determina o desfecho operacional.

Como trabalho contínuo, a técnica admite refinamentos locais de pesos e limiares, assim como expansão da biblioteca de correlações temporais específicas de cada ambiente. Em 2006, tais aperfeiçoamentos já são viáveis com os instrumentos disponíveis, reforçando a aplicabilidade da solução proposta.

References

ACPO. Good Practice Guide for Computer Based Electronic Evidence. Association of Chief Police Officers, 2003. Disponível em: https://web.archive.org/web/20061206095255/http://www.acpo.police.uk/asp/policies/Data/gpg_computer_based_evidence_v3.pdf. Acesso em: 10 dez. 2006.

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

BEJTLICH, Richard. The Tao of Network Security Monitoring. Boston: Addison-Wesley, 2004. Disponível em: https://www.taosecurity.com/tao.html. Acesso em: 10 dez. 2006.

BROWNLEE, Nevil; GUTTERMAN, Edward. RFC 2350: Expectations for Computer Security Incident Response. IETF, 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2350. Acesso em: 10 dez. 2006.

CARRIER, Brian. File System Forensic Analysis. Boston: Addison-Wesley, 2005. Disponível em: https://www.sleuthkit.org/brian/. Acesso em: 10 dez. 2006.

CASEY, Eoghan. Digital Evidence and Computer Crime. 2. ed. San Diego: Academic Press, 2004. Disponível em: https://www.sciencedirect.com/book/9780121631048/digital-evidence-and-computer-crime. Acesso em: 10 dez. 2006.

CERT/CC. Overview of attack trends. Pittsburgh: Carnegie Mellon University, 2003. Disponível em: https://web.archive.org/web/20031215205826/https://www.cert.org/archive/pdf/attack_trends.pdf. Acesso em: 10 dez. 2006.

CICHONSKI, Paul et al. Computer Security Incident Handling Guide (NIST SP 800-61). Gaithersburg: NIST, 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/final. Acesso em: 10 dez. 2006.

CSI/FBI. 2005 Computer Crime and Security Survey. San Francisco, 2005. Disponível em: https://web.archive.org/web/20051214023620/http://i.cmpnet.com/gocsi/db_area/pdfs/fbi/FBI2005.pdf. Acesso em: 10 dez. 2006.

DANYLIW, Roman. ACID: Analysis Console for Intrusion Databases. 2002. Disponível em: https://web.archive.org/web/20061201133228/http://acidlab.sourceforge.net/. Acesso em: 10 dez. 2006.

DEBAR, Hervé; CURRY, David; FEINSTEIN, Benjamin. The Intrusion Detection Message Exchange Format (IDMEF). IETF Internet-Draft, 2004. Disponível em: https://web.archive.org/web/20061206070711/http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-11.txt. Acesso em: 10 dez. 2006.

DEBAR, Hervé; DUVAL, Antoine. Intrusion detection alert correlation: a survey. In: RAID 2002. Berlim: Springer, 2002. Disponível em: https://doi.org/10.1007/3-540-36084-6_9. Acesso em: 10 dez. 2006.

DERAISON, Renaud. Nessus 2.2 User Guide. Tenable Network Security, 2005. Disponível em: https://web.archive.org/web/20051215033316/http://nessus.org/documentation. Acesso em: 10 dez. 2006.

FIPS. FIPS 197: Advanced Encryption Standard (AES). Washington: NIST, 2001. Disponível em: https://csrc.nist.gov/publications/detail/fips/197/final. Acesso em: 10 dez. 2006.

FIRST. Common Vulnerability Scoring System v1 (CVSS). FIRST, 2005. Disponível em: https://web.archive.org/web/20061205033310/http://www.first.org/cvss/. Acesso em: 10 dez. 2006.

FYODOR. 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: 10 dez. 2006.

GUIDANCE SOFTWARE. EnCase Forensic Edition v5: Product Overview. Pasadena, 2005. Disponível em: https://web.archive.org/web/20060501094437/http://www.guidancesoftware.com/products/ef_index.aspx. Acesso em: 10 dez. 2006.

HALFOND, William G. J.; VIEGAS, Jeremy; ORSO, Alessandro. A Classification of SQL-Injection Attacks and Countermeasures. Georgia Tech Technical Report, 2006. Disponível em: https://web.archive.org/web/20061205145930/https://www.cc.gatech.edu/~orso/papers/halfond.ossi-tr06.pdf. Acesso em: 10 dez. 2006.

HOUSLEY, R. et al. RFC 3280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF, 2002. Disponível em: https://www.rfc-editor.org/rfc/rfc3280. Acesso em: 10 dez. 2006.

HOWARD, John; LONGSTAFF, Thomas. A Common Language for Computer Security Incidents. Sandia National Laboratories, 1998. Disponível em: https://web.archive.org/web/20061129172206/http://www.sandia.gov/media/cyberincident.pdf. Acesso em: 10 dez. 2006.

JOHNSON, Kevin. BASE: Basic Analysis and Security Engine. 2004. Disponível em: https://web.archive.org/web/20061205072803/http://base.secureideas.net/. Acesso em: 10 dez. 2006.

JONSSON, J.; KASTENHOLZ, F. RFC 3447: Public-Key Cryptography Standards (PKCS) 1 v2.1. IETF, 2003. Disponível em: https://www.rfc-editor.org/rfc/rfc3447. Acesso em: 10 dez. 2006.

KAUFMAN, Charlie; PERLMAN, Radia; SPECINER, Mike. Network Security: Private Communication in a Public World. 2. ed. Upper Saddle River: Prentice Hall, 2002. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/network-security-private-communication-in-a-public-world/P200000007880. Acesso em: 10 dez. 2006.

MONTGOMERY, Douglas C. Design and Analysis of Experiments. 5. ed. New York: Wiley, 2001. Disponível em: https://www.wiley.com/en-us/Design+and+Analysis+of+Experiments%2C+5th+Edition-p-9780471316497. Acesso em: 10 dez. 2006.

MOORE, David et al. The Spread of the Sapphire/Slammer Worm. CAIDA Report, 2003. Disponível em: https://web.archive.org/web/20061205044203/http://www.caida.org/publications/papers/2003/sapphire/sapphire.html. Acesso em: 10 dez. 2006.

NIST. Guide to Integrating Forensic Techniques into Incident Response (SP 800-86). Gaithersburg: NIST, 2006. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-86/final. Acesso em: 10 dez. 2006.

NVD. National Vulnerability Database. NIST, 2005. Disponível em: https://nvd.nist.gov/. Acesso em: 10 dez. 2006.

OSSIM. Open Source Security Information Management. 2006. Disponível em: https://web.archive.org/web/20061209042821/http://www.ossim.net/. Acesso em: 10 dez. 2006.

OWASP. The OWASP Guide 2.0. 2005. Disponível em: https://web.archive.org/web/20061207134835/http://www.owasp.org/index.php/Category:OWASP_Guide_Project. Acesso em: 10 dez. 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://doi.org/10.1016/S1389-1286(99)00112-7. Acesso em: 10 dez. 2006.

PTACEK, Thomas H.; NEWSHAM, Timothy N. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. Secure Networks, 1998. Disponível em: https://web.archive.org/web/20061206125239/http://www.itdefense.ru/attachments/SecureNetworks_IDS.pdf. Acesso em: 10 dez. 2006.

ROESCH, Martin. Snort: Lightweight Intrusion Detection for Networks. In: LISA 1999. Berkeley: USENIX, 1999. Disponível em: https://www.usenix.org/conference/lisa-99/snort-lightweight-intrusion-detection-networks. Acesso em: 10 dez. 2006.

RUSSELL, Rusty. Linux 2.4 Packet Filtering and NAT HOWTO. 2001. Disponível em: https://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html. Acesso em: 10 dez. 2006.

SHEYNER, O. et al. Automated Generation and Analysis of Attack Graphs. In: IEEE Symposium on Security and Privacy. 2002. Disponível em: https://doi.org/10.1109/SECPRI.2002.1004377. Acesso em: 10 dez. 2006.

SKOUDIS, Ed; ZELTSER, Lenny. Malware: Fighting Malicious Code. Upper Saddle River: Prentice Hall, 2004. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/malware-fighting-malicious-code/P200000006987. Acesso em: 10 dez. 2006.

SNORT. Snort Users Manual 2.6. 2006. Disponível em: https://web.archive.org/web/20060828041644/http://www.snort.org/docs/snort_manual/2.6/snort_manual.html. Acesso em: 10 dez. 2006.

STANIFORD, Stuart; PAXSON, Vern; WEAVER, Nicholas. How to 0wn the Internet in Your Spare Time. In: USENIX Security Symposium, 2002. Disponível em: https://www.usenix.org/conference/11th-usenix-security-symposium/how-0wn-internet-your-spare-time. Acesso em: 10 dez. 2006.

TENABLE. Nessus Vulnerability Scanner. 2005. Disponível em: https://web.archive.org/web/20061205215052/http://www.nessus.org/nessus/. Acesso em: 10 dez. 2006.

THE SLEUTH KIT. The Sleuth Kit & Autopsy. 2003. Disponível em: https://www.sleuthkit.org/sleuthkit/. Acesso em: 10 dez. 2006.

VULNERABILITIES (CVE). Common Vulnerabilities and Exposures. MITRE, 1999–2006. Disponível em: https://cve.mitre.org/. Acesso em: 10 dez. 2006.

AARON, Turner. Tcpreplay 2.0 User Guide. 2005. Disponível em: https://web.archive.org/web/20061201163523/http://tcpreplay.synfin.net/trac. Acesso em: 10 dez. 2006.