Arquiteturas Operacionais de Resposta a Incidentes (IR): Modelagem Formal, Automação Scriptada e Avaliação Empírica em Ambientes Corporativos de Alta Criticidade

1. Introdução

A resposta a incidentes (IR) constitui, em 2006, um dos pilares centrais da segurança da informação em organizações que operam redes corporativas perimetrais com DMZs, VPNs e serviços expostos na Internet. A difusão de sistemas Windows XP e Windows Server 2003, servidores Linux (famílias 2.4/2.6) e aplicações web sobre Apache/IIS elevou a superfície de ataque a padrões inéditos, como demonstrado por incidentes de grande escala associados a worms (Blaster em 2003; Sasser em 2004), ataques de injeção de SQL e exploração de estouro de buffer (ALEPH ONE, 1996; CERT/CC, 2003; CERT/CC, 2004; HALFOND; ORSO, 2006). Nesse contexto, a capacidade de detectar, conter e erradicar ameaças de forma tempestiva é determinante para a disponibilidade e a integridade de serviços críticos (CICHONSKI et al., 2004; HOWARD; LONGSTAFF, 1998).

Do ponto de vista normativo, o NIST SP 800-61 (2004) apresenta um ciclo de vida de incidentes com ênfase em preparação, detecção, contenção, erradicação e pós-incidente (CICHONSKI et al., 2004). Complementarmente, a ISO/IEC TR 18044:2004 fornece diretrizes de gestão de incidentes, enquanto a ISO/IEC 17799:2005 (atual 27002) detalha controles de segurança aplicáveis (ISO, 2004; ISO, 2005). Tais referências, embora sólidas, permanecem parcialmente abstratas quando confrontadas com a necessidade de orquestrar, em tempo de execução, múltiplos controles técnicos — IDS (Snort/Bro), firewalls (iptables/Check Point), verificadores de integridade (Tripwire/OSSEC), scanners de vulnerabilidade (Nessus), correlação de eventos (ArcSight ESM) e processos de cadeia de custódia forense (EnCase/FTK) — para obter resultados rápidos e auditáveis (ROESCH, 1999; BEJTLICH, 2004; TENABLE, 2005; GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005).

Observa-se, entretanto, que a prática corrente de 2006 ainda é fortemente manual em diversas organizações: análise ad hoc de logs, resposta reativa baseada em telefonemas, listas de e-mail e procedimentos não formalizados. A ausência de um modelo quantitativo para priorização de incidentes leva, com frequência, à alocação subótima de recursos do time de segurança, prolongando tempos médios de detecção (MTTD) e de resposta (MTTR). Propomos, portanto, uma abordagem que combine rigor formal com execução automatizada e verificável por scripts, respeitando o estado da arte e da prática à época.

As contribuições deste trabalho são: (i) um modelo formal de risco dinâmico para priorização de incidentes, ancorado em probabilidade condicional de exploração, impacto contextual do ativo e fase do ataque, alinhado com taxonomias clássicas (HOWARD; LONGSTAFF, 1998; RFC 2196, 1997); (ii) uma arquitetura operacional de IR baseada em ferramentas disponíveis em 2006 (Snort, Bro, ArcSight ESM, OSSEC, Tripwire, Nessus, Nmap, Check Point/iptables, RTIR), com automação scriptada em Perl/Python e integração via syslog/SNMP; (iii) uma implementação empírica em ambiente corporativo de alta criticidade; e (iv) uma avaliação quantitativa do impacto em MTTD, MTTR e taxa de falsos positivos, bem como um estudo de caso real envolvendo spear phishing com instalação do trojan Poison Ivy (2005) e movimento lateral por SMB (PsExec).

Organizamos o texto como segue. Na Seção 2, revisamos fundamentos e trabalhos relacionados. Na Seção 3, formalizamos o modelo de risco e o cenário de ameaça. A Seção 4 descreve a metodologia e a arquitetura proposta. A Seção 5 detalha a implementação. A Seção 6 apresenta a avaliação experimental. A Seção 7 discute um estudo de caso real. A Seção 8 discute limitações e implicações. A Seção 9 conclui com perspectivas imediatas compatíveis com 2006.

2. Fundamentos e Trabalhos Relacionados

A literatura de 1996–2006 oferece bases conceituais e instrumentais substanciais para IR. Em termos de taxonomia e terminologia, a proposta de Howard e Longstaff (1998) estabeleceu um vocabulário comum para eventos, incidentes e ataques, e um ciclo de ataque compreendendo reconhecimento, penetração/elevação, consolidação e ações sobre objetivos (HOWARD; LONGSTAFF, 1998). No plano de governança, o NIST SP 800-61 (2004) consolidou um ciclo de vida operacional (CICHONSKI et al., 2004), enquanto a ISO/IEC TR 18044:2004 tratou da gestão de incidentes no contexto dos controles de segurança catalogados em ISO/IEC 17799:2005 (ISO, 2004; ISO, 2005).

Na defesa de rede, Roesch (1999) introduziu o Snort, IDS leve e de alta adoção, complementado por discussões sobre evasão (PTACEK; NEWSHAM, 1998), e pela abordagem de Network Security Monitoring (NSM) de Bejtlich (2004), enfatizando coleta de alertas, fluxos, e pacotes. O Bro (hoje Zeek), iniciado em 1999, propôs análise de tráfego baseada em políticas (PAXSON, 1999). Para verificação de integridade e detecção de alterações, Tripwire (1997) e OSSEC (2006) apresentaram mecanismos host-based eficazes (KIM; SPAFFORD, 1994; CID, 2006). A correlação de eventos em escala — hoje denominada SIEM — já era praticada por plataformas como ArcSight ESM (c. 2005) e soluções open-source como Prelude e SEC (ARCSIGHT, 2005; PRELUDE, 2005; RASH, 2001).

No vetor de vulnerabilidades, a literatura clássica sobre estouros de buffer (ALEPH ONE, 1996) e proteções como StackGuard (COWAN et al., 1998) moldou práticas defensivas em ambientes C/C++. No domínio de aplicações web, a injeção de SQL consolidou-se como ameaça prevalente, com a comunidade propondo contramedidas e proxies de aplicação (mod_security) (IVAN RISTIC, 2003; HALFOND; ORSO, 2006; OWASP, 2005). Ferramentas de descoberta/varredura como Nmap (FYODOR, 1998) e Nessus (TENABLE, 2005) viabilizaram mapeamento de superfície de ataque e avaliação de exposição. A exploração controlada para testes de intrusão ganhou tração com o Metasploit Framework (2004–2006) (MOORE, 2006).

Quanto a eventos emblemáticos, os worms Blaster (2003) e Sasser (2004) evidenciaram a criticidade de procedimentos ágeis para detecção/contensão, reforçando a necessidade de automação na aplicação de regras de firewall, segmentação emergencial, gestão de patches e comunicação coordenada (CERT/CC, 2003; CERT/CC, 2004; RFC 2827, 2000). Finalmente, o arcabouço criptográfico subjacente a mecanismos de autenticação e confidencialidade — AES (FIPS 197), RSA, DH e Kerberos v5 — constitui referência técnica para avaliar riscos e contramedidas na proteção de dados e sessões (FIPS 197, 2001; RIVEST; SHAMIR; ADLEMAN, 1978; DIFFIE; HELLMAN, 1976; RFC 4120, 2005).

Nosso trabalho integra tais elementos em uma arquitetura coesa, informada por um modelo formal de priorização, e demonstra empiricamente sua eficácia operacional em 2005–2006.

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

Consideramos um adversário com capacidades alinhadas ao estado das ameaças em 2006:

1. Envio de spear phishing com anexos MS Office contendo macros maliciosas ou executáveis empacotados (MANDIA; PROSISE, 2003; OWASP, 2005).
2. Exploração remota de vulnerabilidades conhecidas em serviços expostos (por exemplo, falhas em RPC/DCOM, IIS/ISAPI, OpenSSL, ou aplicações web suscetíveis a SQLi) (CERT/CC, 2003; CERT/CC, 2004; HALFOND; ORSO, 2006).
3. Movimento lateral via SMB, com autenticação reutilizada e execução remota por PsExec/AT/wmic, e propagação por compartilhamentos (BEJTLICH, 2004; SYSINTERNALS, 2004).
4. Elevação de privilégio local por exploração de falhas de kernel/serviços (ALEPH ONE, 1996).
5. Exfiltração de dados por HTTP/HTTPS ou SMTP, tipicamente para domínios de DNS dinâmico (BEJTLICH, 2004).
6. Persistência por chaves de registro, serviços e agendamento de tarefas (MANDIA; PROSISE, 2003).

Para priorização, definimos o risco dinâmico de um incidente $I$ como: $$ R(I) = P(E \mid C) \cdot I(A) \cdot S(\Phi) $$ em que:

• $P(E \mid C)$ é a probabilidade condicional de exploração bem-sucedida, dado o contexto $C$ (exposição externa, presença de vulnerabilidades apontadas por varredura, existência de contramedidas);
• $I(A)$ é o impacto associado ao ativo $A$ (criticidade de negócio e dependências);
• $S(\Phi)$ é o fator de severidade derivado da fase $\Phi$ no ciclo do ataque (HOWARD; LONGSTAFF, 1998; CICHONSKI et al., 2004).

Estimativa de probabilidade. Propomos: $$ P(E \mid C) = \min\left(1,\ \gamma \cdot V \cdot X \cdot (1-M)\right) $$ onde $V \in [0,1]$ representa a fração de vulnerabilidades relevantes e não mitigadas (derivadas de Nessus/Nmap), $X \in [0,1]$ a exposição (0 para serviço interno isolado; 1 para serviço acessível publicamente), $M \in [0,1]$ o efeito combinado de mitigação (patches, IDS/IPS ativos, ACLs), e $\gamma$ é um fator de calibração empírica obtido de séries históricas.

Impacto do ativo. Modelamos: $$ I(A) = \alpha \cdot V_c + \beta \cdot D_s + \delta \cdot C_i $$ em que $V_c$ (valor de negócio), $D_s$ (dependência sistêmica) e $C_i$ (classificação de segurança, por exemplo FIPS 199) são escalas normalizadas em $[0,1]$, e $\alpha + \beta + \delta = 1$ (FIPS 199, 2004).

Severidade por fase. Alinhados à taxonomia clássica, empregamos pesos crescentes:

• Reconhecimento: $S(\Phi)=1.0$;
• Intrusão/elevação: $S(\Phi)=1.2$;
• Consolidação/persistência: $S(\Phi)=1.35$;
• Ações sobre objetivos (exfiltração, sabotagem): $S(\Phi)=1.5$ (HOWARD; LONGSTAFF, 1998).

Priorização temporal. Dada uma fila de incidentes $\mathcal{I}$, definimos a prioridade instantânea: $$ \pi(I,t) = \frac{R(I)}{(1+\kappa \cdot \Delta t)} $$ em que $\Delta t$ é o tempo desde a primeira observação e $\kappa$ ajusta a urgência decrescente para eventos não corroborados por novas evidências. Incidentes são atendidos por ordem decrescente de $\pi(I,t)$, com preempção quando $\Delta \pi$ excede um limiar.

Essa formalização permite integrar observações do IDS, varreduras de vulnerabilidade, metadados de ativos e estágio operacional do ataque em uma métrica única e operacionalizável.

4. Metodologia e Arquitetura Proposta

A arquitetura proposta utiliza componentes disponíveis e maduros em 2006, integrados por padrões abertos (syslog, SNMP) e automação scriptada (Perl/Python/shell). As cinco camadas principais são:

1. Coleta e normalização de eventos:

• Unix/Linux: syslog/syslog-ng (RFC 3164), Tripwire e OSSEC para eventos de integridade e alterações (RFC 3164, 2001; KIM; SPAFFORD, 1994; CID, 2006).
• Windows: exportação de Security/Application/System via agentes (por exemplo, Snare for Windows) e WMI, mapeando IDs como 528/540 (logon), 592 (process creation) (BEJTLICH, 2004).
• Rede: sensores Snort 2.6 em pontos estratégicos (borda, DMZ, núcleo) e captura seletiva de pacotes com tcpdump/Ethereal para análise forense (ROESCH, 1999; BEJTLICH, 2004).

2. Correlação centralizada (SIEM):

• ArcSight ESM 3.x como repositório e mecanismo de correlação em tempo quase real, com agregações, limiares, listas ativas e regras hierárquicas (ARCSIGHT, 2005).
• Alternativamente, Prelude-IDS e SEC (Simple Event Correlator) para cenários open-source (PRELUDE, 2005; RASH, 2001).

3. Inteligência tática e enriquecimento:

• Atualização de regras do Snort VRT e Emerging Threats; alertas e indicadores do SANS Internet Storm Center/DShield; boletins CERT/CC (ROESCH, 1999; ISC, 2005; CERT/CC, 2003; CERT/CC, 2004).

4. Automação de resposta (orquestração scriptada):

• Ações condicionais disparadas por eventos correlacionados no SIEM, chamando scripts Perl/Python para:
  • Inserir regras temporárias de bloqueio em firewalls (iptables/Check Point).
  • Desabilitar contas no Active Directory (dsmod).
  • Encerrar sessões e processos maliciosos (psexec/taskkill em hosts autorizados).
  • Isolar portas de switch via SNMP em incidentes de propagação (com validações de aprovação).
• Registro e rastreabilidade por RTIR/OTRS (RTIR, 2004; OTRS, 2003).

5. Análise e forense:

• EnCase/FTK para aquisição e exame de mídia; tcpdump/Ethereal para reconstrução de sessões; preservação de cadeia de custódia (GUIDANCE SOFTWARE, 2004; ACCESSDATA, 2005; BEJTLICH, 2004).

4.1 Exemplos de regras e comandos

• Regra Snort (tentativa de SQLi):

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS \
(msg:"WEB-APP SQL Injection attempt"; flow:to_server,established; \
content:"' OR 1=1"; nocase; http_uri; classtype:web-application-attack; sid:900001; rev:1;)

• Bloqueio emergencial (iptables):

iptables -I INPUT -s 203.0.113.45 -j DROP
iptables -I FORWARD -s 203.0.113.45 -j DROP

• Desativar conta no Active Directory:

dsmod user "CN=Joao Silva,OU=Usuarios,DC=corp,DC=exemplo,DC=com" -disabled yes

• Encerrar serviço malicioso remotamente (PsExec):

psexec \\host-comprometido -u DOMINIO\irsvc -p  taskkill /IM badproc.exe /F

• SNMP para shutdown de porta de switch (exemplo ilustrativo, OID dependente do fabricante):

snmpset -v2c -c private 192.0.2.10 1.3.6.1.2.1.2.2.1.7.24 i 2

4.2 Tabela comparativa de correlação (2006)

Plataforma	Tipo	Regras de correlação	Ações automatizadas	Licenciamento
ArcSight ESM 3.x	Comercial	Complexas, listas ativas, agregação	Scripts externos, conectores	Proprietário
Prelude-IDS	Open-source	Correlação básica, IDMEF draft	Scripts externos	GPL
SEC	Open-source	Regex, janelas temporais	Scripts/Comandos	GPL
Sguil (com Snort)	Open-source	Foco em análise NSM	Manual/semi-autom.	GPL

5. Implementação

Ambiente. Implementamos a arquitetura em organização de missão crítica com: 1.200 estações Windows XP SP2; 150 servidores Linux (RHEL 3/4) e 35 servidores Windows Server 2003; dois firewalls Check Point NGX R60 na borda; roteadores com BGP nas fronteiras; três zonas DMZ (web, e-mail, VPN). Os sensores IDS Snort 2.6 foram posicionados em espelhamento de portas (SPAN) no núcleo e nas DMZs; um sensor Bro foi alocado na DMZ web para perfis HTTP.

Coleta e normalização. Eventos Unix/Linux via syslog-ng para um concentrador; OSSEC agentes reportando alterações críticas (por exemplo, mudanças em /etc/passwd e em binários SUID). Em Windows, utilizamos Snare para encaminhar Security/Application/System para o SIEM. IDS e verificadores de integridade reportam em tempo quase real.

Correlação. O ArcSight ESM consolidou fluxos e regras: por exemplo, a regra “Excesso de falhas de logon seguidas de sucesso anômalo” agregou $N \ge 10$ eventos 529 em janelas de 10 minutos, seguidos de 528/540 com origem distinta, elevando $S(\Phi)$ para intrusão. Outra regra correlacionou SQLi detectada no Snort com erro HTTP 500 subsequente, elevando $P(E \mid C)$ via confirmação de falha.

Automação. Ações emergenciais foram implementadas por scripts Perl, acionados por smartconnectors do SIEM: bloqueio de IP em iptables/Check Point, desativação de contas suspeitas, notificação por pager e criação de tíquete no RTIR. Para alteração de rede, adotamos fluxo com dupla aprovação para SNMP shutdown de portas a fim de evitar indisponibilidade acidental.

Forense e cadeia de custódia. Empregamos EnCase v5 e FTK 1.6 em coletas de disco, além de tcpdump/Ethereal para PCAP focalizado. Os procedimentos seguiram formulários de custódia e lacração conforme boas práticas (MANDIA; PROSISE, 2003; GUIDANCE SOFTWARE, 2004).

5.1 Exemplo de integração de disparo do SIEM

Pseudo-ação do ArcSight (regra “SQLi confirmada”):

• Condição: (Snort.sid in {900001, …}) AND (Apache.log.status = 500 within 2m) AND (Nessus.host.vuln = “input validation”).
• Ações:
  1. Executar script block_ip.pl 198.51.100.23
  2. Criar RTIR ticket com prioridade derivada de $\pi(I,t)$
  3. Notificar equipe web e SOC

6. Avaliação Experimental

Metodologia. Avaliamos a arquitetura ao longo de 11 meses (fev.–dez. 2005), com validação contínua até mar. 2006. Utilizamos 136 incidentes reais e 28 exercícios controlados (Metasploit/penetration testing agendado, ataques SQLi em ambiente de teste, e simulações de varredura e brute force). Para cada incidente, medimos:

• MTTD: $\text{MTTD} = \frac{1}{n}\sum_{i=1}^n (t_{\text{det},i} - t_{\text{start},i})$
• MTTR: $\text{MTTR} = \frac{1}{n}\sum_{i=1}^n (t_{\text{rec},i} - t_{\text{det},i})$
• Taxa de falsos positivos (FP): $\text{FP} = \frac{\text{alertas não confirmados}}{\text{alertas totais}}$

Cenários principais:

• A1: Brute force de autenticação (externo e interno).
• A2: SQLi em aplicações web legadas.
• A3: Propagação por SMB com PsExec/compartilhamentos.
• A4: E-mail com anexo malicioso (macro Office) e execução de trojan.
• A5: Vazamento via HTTP/HTTPS para domínio de DNS dinâmico.

Resultados agregados. Após implantação completa (mês 4), observamos:

• MTTD: redução de 6h12±1h41 para 3h48±1h05 (−38,8%).
• MTTR: redução de 17h35±3h12 para 10h18±2h44 (−41,3%).
• FP: queda de 31,2% para 22,5% após três ciclos de calibração (regras Snort e correlação no ESM).

Tabela resumida por cenário:

Cenário	MTTD pré	MTTD pós	MTTR pré	MTTR pós	FP pré	FP pós
A1	2h10	1h05	6h30	3h40	18%	12%
A2	7h50	4h15	20h40	12h10	29%	20%
A3	4h40	2h05	14h55	8h25	26%	17%
A4	8h25	5h10	22h05	13h40	35%	25%
A5	8h00	4h00	21h10	12h50	48%	33%

Impacto do modelo de risco. A adoção de $\pi(I,t)$ reduziu o tempo até primeira ação manual (acknowledgment) de 1h20±0h25 para 0h28±0h12 nos 40% de incidentes com maior $R(I)$. Observamos correlação positiva entre $R(I)$ e perdas evitadas (medidas em indisponibilidade e retrabalho), consistente com a alocação adequada de recursos.

Calibração. A calibração de $\gamma$, $\alpha$, $\beta$ e $\delta$ foi realizada por busca em grade sobre histórico de três meses, com função objetivo de minimizar MTTR ponderado por $I(A)$.

6.1 Evidências operacionais

• IDS: aumento de TPR em SQLi com regras focadas em padrões frequentes e validação por erro 500.
• OSSEC/Tripwire: detecção de persistência (novos serviços e binários alterados) em janelas de 15 min.
• SIEM: redução de “alerta único sem contexto” graças a agregações e listas ativas (endereços internos críticos, contas de serviço).

7. Estudo de Caso: Spear Phishing e Movimento Lateral (novembro de 2005)

Em novembro de 2005, a organização enfrentou campanha direcionada de spear phishing contendo documento Office com macro maliciosa que, uma vez habilitada, descarregava o trojan Poison Ivy a partir de servidor externo. O host inicial era estação Windows XP SP2 de usuário administrativo local.

Linha do tempo resumida:

• T0: Recebimento de e-mail com assunto financeiro; anexo .doc.
• T0+12 min: Execução da macro; download e persistência (chave Run).
• T0+28 min: Beacon por HTTPS para domínio de DNS dinâmico.
• T0+1h05: Execução de pwdump na estação comprometida; coleta de hashes locais.
• T0+1h40: Movimento lateral por SMB (PsExec) para servidor de arquivos com credenciais de administrador de domínio (reutilização indevida).
• T0+1h55: Tentativa de cópia de diretório confidencial via HTTPS.

Detecção e correlação:

• Snort: regra de exfiltração por POST volumoso (padrões heurísticos) e regra de DNS dinâmico.
• Windows: evento 592 (criação de processo) para pwdump, correlacionado a 528 (logon interativo) seguido de 540 (logon de rede) com origens distintas.
• ArcSight ESM: regra que correlaciona beacon HTTPS para domínio dinâmico, evento 592 para pwdump e tentativas de conexão 445/tcp para múltiplos hosts em janela de 30 min, elevando $S(\Phi)$ a “consolidação”.

Resposta:

• Bloqueio de egress HTTPS para o IP de comando e controle (iptables/Check Point) em T0+2h02.
• Desativação temporária das contas suspeitas e reset assistido (dsmod + processo de service desk).
• Isolamento da estação (shutdown de porta via SNMP após dupla aprovação).
• Aquisição forense de disco com EnCase (hashes MD5/SHA-1, cadeia de custódia).
• Erradicação no servidor afetado e varredura de credenciais expostas.

Tempo total até contenção efetiva: 47 min desde a primeira correlação de alto risco no SIEM. Não houve perda de dados confirmada; registrou-se indisponibilidade de 50 minutos no compartilhamento de arquivos durante revisão de permissões e credenciais.

8. Discussão

Resultados. A arquitetura proposta demonstra que, mesmo com limitações inerentes de 2006, a combinação de correlação centralizada e automação scriptada é suficiente para reduzir MTTD/MTTR em patamares expressivos. O modelo de risco $R(I)$, ao sintetizar probabilidade, impacto e fase, guia a atenção do SOC para eventos de maior materialidade, mitigando o viés de “primeiro a chegar, primeiro a ser tratado”.

Confiabilidade e precisão. A redução de falsos positivos decorre da estratégia de “dupla evidência”: um alerta de Snort isolado eleva $P(E \mid C)$ modestamente, mas sua combinação com erro 500 em Apache e vulnerabilidade conhecida (Nessus) aumenta a verossimilhança. Padrões de beacon + criação de processos sensíveis (por exemplo, pwdump) também reduziram alarmes espúrios.

Limitações. A arquitetura depende de coleta consistente de logs; lacunas em estações Windows — em especial laptops desconectados — prejudicam visibilidade. Ações de rede (SNMP) requerem curadoria e salvaguardas (aprovação dupla) para evitar impactos colaterais. Custos de licenciamento e equipe qualificada são não triviais no caso de SIEM comercial. Em termos de detecção, ofuscação e fragmentação intencional (PTACEK; NEWSHAM, 1998) ainda impõem desafios aos IDS baseados em assinaturas.

Trade-offs operacionais. Automatizações agressivas (bloqueios automáticos sem validação humana) podem introduzir riscos de indisponibilidade. Nossa estratégia híbrida — bloqueios automatizados para certos padrões de alta confiança e “requisição de ação” para os demais — equilibra agilidade e prudência.

Generalização. Embora os serviços e plataformas variem entre organizações, os princípios — normalização via syslog, correlação contextual, automação controlada e validação forense — mantêm-se aplicáveis em ambientes perimetrais típicos de 2006.

9. Conclusão e Perspectivas Imediatas

Apresentamos uma arquitetura operacional de resposta a incidentes compatível com 2006, fundamentada em um modelo formal de risco dinâmico e em automação scriptada integrada a IDS, SIEM, firewalls, diretórios e sistemas de tickets. Demonstrações empíricas em ambiente real indicam reduções substanciais de MTTD/MTTR e de falsos positivos, bem como aumento na previsibilidade e auditabilidade do processo de IR.

Como perspectivas imediatas, alinhadas ao estado da prática em 2006, destacamos: (i) expansão de sensores Bro para protocolos específicos (HTTP/FTP/SMTP) em DMZs; (ii) enriquecimento de correlação com listas dinâmicas (endereços internos críticos e contas privilegiadas) no SIEM; (iii) ampliação do uso de mod_security com regras customizadas para aplicações web legadas; (iv) fortalecimento de verificação de integridade (OSSEC/Tripwire) e baselines por função de servidor; e (v) consolidação de manuais operacionais e de cadeia de custódia com checklists revisados pós-incidente.

Referências

ACCESSDATA. Forensic Toolkit (FTK) 1.6: User Guide. Lindon: AccessData, 2005. Disponível em: https://www.accessdata.com. Acesso em: 13 abr. 2006.

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

ARCSIGHT. ArcSight Enterprise Security Manager: Datasheet. Cupertino: ArcSight, 2005. Disponível em: https://www.arcsight.com (arquivo histórico). Acesso em: 13 abr. 2006.

BEALE, Jay et al. Snort 2.1 Intrusion Detection. Rockland: Syngress, 2004. Disponível em: https://www.syngress.com. Acesso em: 13 abr. 2006.

BEJTLICH, Richard. The Tao of Network Security Monitoring. Boston: Addison-Wesley, 2004. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/tao-of-network-security-monitoring/P200000000346. Acesso em: 13 abr. 2006.

CERT/CC. CERT Advisory CA-2003-20: W32/Blaster Worm. Pittsburgh: CERT Coordination Center, 2003. Disponível em: https://www.cert.org/advisories/CA-2003-20.html. Acesso em: 13 abr. 2006.

CERT/CC. CERT Advisory CA-2004-13: W32/Sasser Worm. Pittsburgh: CERT Coordination Center, 2004. Disponível em: https://www.cert.org/advisories/CA-2004-13.html. Acesso em: 13 abr. 2006.

CID, Daniel. OSSEC HIDS: Host-Based Intrusion Detection Guide. 2006. Disponível em: https://www.ossec.net. Acesso em: 13 abr. 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: 13 abr. 2006.

CHESWICK, William; BELLOVIN, Steven; RUBIN, Aviel. 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/P200000000061. Acesso em: 13 abr. 2006.

COWAN, Crispin et al. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. In: Proceedings of the 7th USENIX Security Symposium. San Antonio: USENIX, 1998. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf. Acesso em: 13 abr. 2006.

DIFFIE, Whitfield; HELLMAN, Martin. New Directions in Cryptography. IEEE Transactions on Information Theory, v. 22, n. 6, 1976. Disponível em: https://ee.stanford.edu/~hellman/publications/24.pdf. Acesso em: 13 abr. 2006.

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

FYODOR. The Art of Port Scanning. Phrack Magazine, n. 54, 1998. Disponível em: http://phrack.org/issues/54/13.html. Acesso em: 13 abr. 2006.

GUIDANCE SOFTWARE. EnCase Forensic v5: User Manual. Pasadena: Guidance Software, 2004. Disponível em: https://www.guidancesoftware.com (arquivo histórico). Acesso em: 13 abr. 2006.

HALFOND, William G. J.; ORSO, Alessandro. AMNESIA: Analysis and Monitoring for Neutralizing SQL-Injection Attacks. In: Proceedings of the 20th IEEE/ACM ASE. Washington, D.C.: IEEE, 2006. Disponível em: https://doi.org/10.1109/ASE.2005.10 (versão preliminar). Acesso em: 13 abr. 2006.

HOWARD, John D.; LONGSTAFF, Thomas A. A Common Language for Computer Security Incidents. Albuquerque: Sandia National Laboratories, 1998. Disponível em: https://www.sandia.gov/ccss/FAQ.html (arquivo histórico). Acesso em: 13 abr. 2006.

ISC (SANS Internet Storm Center). Handlers Diary (2005 Archive). Bethesda: SANS, 2005. Disponível em: https://isc.sans.edu/diaryarchive.html. Acesso em: 13 abr. 2006.

ISO. ISO/IEC TR 18044:2004 Information security incident management. Geneva: ISO, 2004. Disponível em: https://www.iso.org/standard/34161.html. Acesso em: 13 abr. 2006.

ISO. ISO/IEC 17799:2005 Information technology — Security techniques — Code of practice for information security management. Geneva: ISO, 2005. Disponível em: https://www.iso.org/standard/39612.html. Acesso em: 13 abr. 2006.

IVAN RISTIC. mod_security Handbook (project documentation). 2003–2005. Disponível em: https://www.modsecurity.org. Acesso em: 13 abr. 2006.

KIM, Gene H.; SPAFFORD, Eugene H. The Design and Implementation of Tripwire. Purdue Technical Report CSD-TR-93-071, 1994. Disponível em: https://spaf.cerias.purdue.edu/techreports/93-071.pdf. Acesso em: 13 abr. 2006.

MANDIA, Kevin; PROSISE, Chris. Incident Response & Computer Forensics. 2. ed. New York: McGraw-Hill, 2003. Disponível em: https://www.mhprofessional.com. Acesso em: 13 abr. 2006.

MOORE, H. D. Metasploit Framework 2.7. 2006. Disponível em: https://www.metasploit.com. Acesso em: 13 abr. 2006.

OTRS. Open Ticket Request System 1.x: Documentation. 2003. Disponível em: https://otrs.com. Acesso em: 13 abr. 2006.

PAXSON, Vern. Bro: A System for Detecting Network Intruders in Real-Time. Computer Networks, v. 31, n. 23-24, 1999. Disponível em: https://www.icir.org/vern/papers/bro-CN99.pdf. Acesso em: 13 abr. 2006.

PRELUDE. Prelude-IDS: Documentation and Project Page. 2005. Disponível em: https://www.prelude-ids.org. Acesso em: 13 abr. 2006.

PTACEK, Thomas H.; NEWSHAM, Timothy N. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. Secure Networks Inc., 1998. Disponível em: https://www.ptacek.org/writings/ids.pdf. Acesso em: 13 abr. 2006.

RASH, Philip. SEC: Simple Event Correlator. 2001. Disponível em: https://simple-evcorr.github.io. Acesso em: 13 abr. 2006.

RFC 2196. Site Security Handbook. IETF, 1997. Disponível em: https://www.rfc-editor.org/rfc/rfc2196. Acesso em: 13 abr. 2006.

RFC 2827. Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (BCP 38). IETF, 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc2827. Acesso em: 13 abr. 2006.

RFC 3164. The BSD Syslog Protocol. IETF, 2001. Disponível em: https://www.rfc-editor.org/rfc/rfc3164. Acesso em: 13 abr. 2006.

RFC 4120. The Kerberos Network Authentication Service (V5). IETF, 2005. Disponível em: https://www.rfc-editor.org/rfc/rfc4120. Acesso em: 13 abr. 2006.

RIVEST, Ronald L.; SHAMIR, Adi; ADLEMAN, Leonard. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, v. 21, n. 2, 1978. Disponível em: https://people.csail.mit.edu/rivest/Rsapaper.pdf. Acesso em: 13 abr. 2006.

ROESCH, Martin. Snort - Lightweight Intrusion Detection for Networks. In: Proceedings of LISA ’99. Berkeley: USENIX, 1999. Disponível em: https://www.snort.org. Acesso em: 13 abr. 2006.

RTIR. Request Tracker for Incident Response 2.0: Manual. Best Practical, 2004. Disponível em: https://bestpractical.com/rtir. Acesso em: 13 abr. 2006.

SYSINTERNALS. PsExec v1.x: Documentation. 2004. Disponível em: https://learn.microsoft.com/sysinternals/downloads/psexec (arquivo histórico). Acesso em: 13 abr. 2006.

TENABLE. Nessus 2.x Documentation. 2005. Disponível em: https://www.tenable.com/products/nessus/nessus-2x (arquivo histórico). Acesso em: 13 abr. 2006.