Integração Sistemática de Modelagem de Ameaças, Controles Automatizados e Telemetria de Segurança no Ciclo de Vida de Desenvolvimento de Software

1. Introduction

A segurança de software consolidou-se, ao longo da última década, como preocupação central para organizações dependentes de sistemas distribuídos conectados à Internet. Incidentes de larga escala como o worm Code Red (2001) e o SQL Slammer (2003) evidenciaram que vulnerabilidades exploráveis em serviços expostos podem comprometer milhões de sistemas em poucas horas (CERT/CC, 2001; MOORE et al., 2003; STANIFORD; PAXSON; WEAVER, 2002). A recorrência de falhas clássicas — buffer overflows, injeções SQL, traversal de diretórios — demonstrou limitações de abordagens baseadas exclusivamente em testes manuais tardios (VIEGA; MCGRAW, 2001; SEACORD, 2005). A permanência de deficiências de projeto e implementação contraria princípios estabelecidos de segurança, como privilégio mínimo e separação de funções (SALTZER; SCHROEDER, 1975), e desafia mecanismos aferidos de proteção, como firewalls de perímetro, IDS/IPS e listas de controle de acesso (CHESWICK; BELLOVIN; RUBIN, 2003; ROESCH, 1999).

Tradicionalmente, a segurança era tratada como atividade posterior ao desenvolvimento, frequentemente restrita a auditorias independentes ou testes de intrusão pontuais. Entretanto, estudos empíricos indicam que o custo de correção cresce exponencialmente conforme o defeito é detectado em fases mais avançadas do ciclo de vida (BOEHM; BASILI, 2001). Há, portanto, motivação econômica e técnica para incorporar práticas sistemáticas desde as fases iniciais de especificação e projeto, com ênfase em modelagem explícita de ameaças, automação de verificações e coleta contínua de evidências operacionais.

Propomos estruturar o ciclo de vida de desenvolvimento com base em três pilares: (i) modelagem formal de ameaças; (ii) integração de controles automatizados ao processo de construção e testes; e (iii) telemetria contínua com IDS/IPS de rede e correlação centralizada de eventos. Diferentemente de abordagens fragmentadas, defendemos uma integração quantitativa orientada a risco mensurável, utilizando a versão 1.0 do Common Vulnerability Scoring System (FIRST, 2005) e métricas clássicas de risco (STONEBURNER; GOGUEN; FERINGA, 2002), compatíveis com o estado da prática até 2006.

Contribuímos com: (a) uma formalização matemática de risco residual alinhada ao CVSS v1; (b) um fluxo de integração contínua enriquecido com análise estática, varredura de vulnerabilidades e testes de intrusão controlados; © um arranjo de telemetria baseado em Snort e plataformas de correlação de eventos (ArcSight ESM, Splunk 2.x), consolidando indicadores operacionais; e (d) uma avaliação empírica com resultados estatisticamente estáveis em ambiente corporativo heterogêneo.

2. Fundamentação Teórica e Trabalhos Relacionados

A modelagem de ameaças constitui técnica consolidada para identificação sistemática de vetores de ataque. O modelo STRIDE, proposto pela Microsoft no contexto do Security Development Lifecycle (SDL), classifica ameaças em seis categorias: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service e Elevation of Privilege (HOWARD; LIPNER, 2006). Complementarmente, árvores de ataque formalizam cenários adversariais de forma hierárquica e permitem decomposições AND/OR para raciocínio sistemático (SCHNEIER, 1999).

Quanto à mensuração, o Common Vulnerability Scoring System (CVSS) foi publicado em 2005 pelo FIRST, introduzindo um mecanismo padronizado para mensurar severidade de vulnerabilidades por meio de métricas base, temporais e ambientais (FIRST, 2005). A adoção do CVSS viabiliza priorização racional e comparável de correções entre sistemas e versões (MELL; SCARFONE; ROMANOSKY, 2006).

No tocante a controles, a literatura estabelece a relevância de perímetros robustos (CHESWICK; BELLOVIN; RUBIN, 2003), criptografia adequada (FIPS 197, 2001; RIVEST; SHAMIR; ADLEMAN, 1978; DIERKS; ALLEN, 1999) e práticas de desenvolvimento seguro (VIEGA; MCGRAW, 2001; SEACORD, 2005). Em detecção, destacam-se Snort (ROESCH, 1999) e Bro (PAXSON, 1999). Para automação de segurança operacional, já em 2004-2006 surgiram plataformas de correlação e gestão de eventos, como ArcSight ESM e Splunk 2.x (ARCSIGHT, 2004; SPLUNK, 2004), além de consoles e front-ends para análise de alertas do Snort (ACID/BASE) (ROMAN; SPANGLER, 2003). Em varredura e mapeamento, ferramentas como Nmap (LYON, 2004) e Nessus 2.x (TENEBLE, 2005) consolidaram-se; para exploração controlada, o Metasploit Framework tornou-se referência (METASPLOIT, 2006).

Em aplicações web, referências como o OWASP Top 10 (OWASP, 2004), Nikto (CARTER, 2005), Paros Proxy (PAROS, 2004) e OWASP WebScarab (OWASP, 2004b) orientam mitigação de vulnerabilidades conhecidas. Do ponto de vista científico, trabalhos sistematizam a análise de injeção SQL e contramedidas, como AMNESIA (HALFOND; ORSO, 2005).

Apesar dessas contribuições, observamos lacuna na formalização integrada entre modelagem, automação e telemetria operacional com vinculação explícita a métricas de risco uniformes e restrições práticas de ciclo de build.

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

Consideramos um portfólio de aplicações $S = {s_1, \dots, s_n}$, bancos de dados $B = {b_1, \dots, b_m}$ e serviços de infraestrutura $I = {i_1, \dots, i_k}$. Para cada elemento arquitetural, construímos diagramas de fluxo de dados (DFD) e associamos categorias STRIDE (HOWARD; LIPNER, 2006). Representamos cenários adversariais prioritários por árvores de ataque $\mathcal{T}$ com decomposições lógicas AND/OR (SCHNEIER, 1999).

Adotamos uma noção de risco anualizado compatível com NIST SP 800-30 (STONEBURNER; GOGUEN; FERINGA, 2002). Para um componente $x$, definimos o risco bruto:

$$ R(x) = P_e(x) \times I_m(x), $$

em que $P_e(x) \in [0,1]$ denota a probabilidade de exploração no horizonte anual e $I_m(x) \ge 0$ representa impacto monetário ou operacional convertido em unidades monetárias equivalentes (e.g., $I_m$ em US$). Estimamos $P_e(x)$ a partir da métrica base CVSS v1 $B(x) \in [0,10]$, normalizada:

$$ P_e(x) = \frac{B(x)}{10}. $$

Reconhecemos tratar-se de aproximação conservadora, uma vez que $B(x)$ captura impacto e explorabilidade, mas não inclui fatores ambientais específicos; discutimos ajustes na Seção 8.

Definimos um conjunto de controles $C = {c_1, \dots, c_r}$ que incidem sobre um subconjunto $C_x \subseteq C$ de cada componente $x$. Denotamos a eficácia empírica do controle $c_j$ por $E(c_j) \in [0,1]$, definida como a fração de tentativas de exploração bloqueadas ou neutralizadas, estimada por testes controlados e evidências de telemetria (vide Seção 4.4). Assumindo independência aproximada entre controles quanto ao vetor específico de ataque, obtemos o risco residual:

$$ R_r(x) = R(x) \cdot \prod_{c_j \in C_x} \bigl(1 - E(c_j)\bigr). $$

Apresentamos duas propriedades úteis:

• Monotonicidade: se $E(c_j) \in [0,1]$, então $R_r(x)$ é monotonicamente não crescente em cada $E(c_j)$.
• Limite inferior: $R_r(x) \ge 0$; se $\exists c_j \in C_x$ tal que $E(c_j) = 1$, então $R_r(x) = 0$ para o vetor específico sob hipótese de independência.

O objetivo organizacional consiste em minimizar o risco agregado sob restrições de orçamento e de tempo de ciclo de build:

$$ \min_{C_x \subseteq C} \sum_{x \in S \cup B \cup I} R_r(x) \quad \text{sujeito a} \quad \sum_{c_j \in \cup_x C_x} \text{custo}(c_j) \le \mathcal{B}, $$

e

$$ T_{\text{build}}© \le T_{\max}, $$

com $T_{\max} = 30$ minutos. A seleção ótima de $C$ sob $\mathcal{B}$ é um problema do tipo mochila com efeitos multiplicativos; em prática, adotamos heurísticas gulosa e por densidade de risco reduzido por unidade de custo (BISHOP, 2002).

Para relacionar a métrica de segurança com gestão de conformidade, definimos a perda anualizada esperada:

$$ \text{ALE} = \sum_{x} \lambda_x \cdot R_r(x), $$

onde $\lambda_x$ é a frequência anual estimada de incidentes relevantes para $x$ (STONEBURNER; GOGUEN; FERINGA, 2002). Esta formulação permite alinhamento com requisitos ISO/IEC 17799:2005 e PCI DSS 1.0 (ISO, 2005; PCI SSC, 2004).

4. Metodologia Proposta

4.1 Modelagem de Ameaças

Para cada aplicação, elaboramos DFDs com identificação de trust boundaries, processos, fluxos e armazenamentos. Aplicamos STRIDE a cada elemento e derivamos árvores de ataque para cenários críticos (SCHNEIER, 1999; HOWARD; LIPNER, 2006). Em aplicações web, priorizamos vetores do OWASP Top 10 (OWASP, 2004), com ênfase em injeção SQL, XSS e controle de acesso defeituoso.

Ilustrativamente, para uma aplicação de autenticação, modelamos nós: navegador, proxy reverso, servidor web, lógica de aplicação, banco de dados e diretório LDAP. No canal navegador–proxy, mapeamos spoofing e informação indevida; no processo de aplicação, mapeamos adulteração (tampering) e elevação de privilégio.

4.2 Controles Automatizados no Processo de Build

Integramos verificações automatizadas ao servidor CruiseControl, acionado a cada commit no Subversion. O fluxo inclui:

• Compilação e análise estática:
  • Java: FindBugs (smells de segurança), Fortify SCA quando disponível;
  • C/C++: Flawfinder, RATS, verificações de uso inseguro de funções ($\texttt{strcpy}$, $\texttt{sprintf}$).
• Execução de testes unitários e de integração.
• Varredura com Nessus 2.x contra ambiente de homologação isolado, com políticas segmentadas por perfil (Linux, Windows, middleware).
• Mapeamento de serviços com Nmap (detecção de versão, scripts NSE não eram maduros em 2006, portanto não utilizados).
• Testes de intrusão controlados com Metasploit Framework (vetores clássicos), complementados por testes manuais e semiautomatizados de aplicações web com Nikto, Paros Proxy e OWASP WebScarab.

Exemplo de script de orquestração:

nmap -sS -sV -O -p- servidor_homologacao
nessus -q -x scan_config.nessus
nikto -host http://app-homologacao
java -jar paros.jar &
Uso do Paros/WebScarab como proxy manual para fuzzing de parâmetros
msfconsole -r testes_buffer_overflow.rc

Falhas com pontuação CVSS base $B \ge 7{,}0$ bloqueiam a promoção para produção (FIRST, 2005). Erros classificados como altos por análise estática (e.g., taint propagation para SQL injection) também geram falha de build (HALFOND; ORSO, 2005).

Trecho de configuração do CruiseControl:

<cruisecontrol>
  <project name="app-segura">
    <listeners>
      <currentbuildstatuspublisher file="logs/status.txt"/>
    </listeners>
    <modificationset>
      <svn repositoryLocation="https://svn/repos/app-segura/trunk"/>
    </modificationset>
    <schedule interval="300">
      <ant buildfile="build.xml" target="ci-security"/>
    </schedule>
    <publishers>
      <onsuccess>
        <artifactspublisher dest="artifacts/" srcdir="relatorios/"/>
      </onsuccess>
      <onfailure>
        <artifactspublisher dest="artifacts/" srcdir="relatorios/"/>
      </onfailure>
    </publishers>
  </project>
</cruisecontrol>

4.3 Monitoramento e Telemetria

Implantamos Snort 2.x como IDS de borda, com regras específicas para vetores prevalentes. Quando apropriado, Snort-inline implementa bloqueio ativo sob política conservadora (SNORT-INLINE, 2004). Logs são centralizados via Syslog (RFC 3164) em servidor dedicado, com correlação feita por ArcSight ESM e/ou Splunk 2.x (RFC 3164, 2001; ARCSIGHT, 2004; SPLUNK, 2004). Para análise forense e consolidação de alertas do Snort, recorremos ao BASE (ROMAN; SPANGLER, 2003).

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

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

Exemplo de regra de iptables para mitigação reativa:

iptables -A INPUT -p tcp --dport 80 -m string --string "' OR 1=1" --algo bm -j DROP
iptables -A INPUT -p tcp --dport 80 -m limit --limit 10/s --limit-burst 20 -j ACCEPT

Syslog centralizado (syslog-ng):

source s_all { udp(ip(0.0.0.0) port(514)); };
destination d_loghost { file("/var/log/central/$HOST/$FACILITY-$YEAR$MONTH$DAY.log"); };
log { source(s_all); destination(d_loghost); };

Eventos correlacionados com múltiplas assinaturas aumentam automaticamente a severidade (e.g., detecção simultânea de varredura agressiva por Nmap e payload de exploração por Metasploit).

4.4 Validação Ofensiva Controlada e Estimativa de Eficácia

Executamos campanhas mensais de testes ofensivos controlados em ambiente de homologação. Selecionamos exploits estáveis do Metasploit (e.g., vulnerabilidades conhecidas em serviços desatualizados) e roteiros semiautomatizados para aplicações web (nikto, proxies interceptadores). Para cada controle $c_j$, coletamos o número de tentativas $N_j$ e de bloqueios $B_j$. Estimamos:

$$ \widehat{E}(c_j) = \frac{B_j}{N_j}, \qquad \text{IC}_{95%} \text{ de Wilson}. $$

Esse processo reduz falsos positivos e fornece base quantitativa para decisões de priorização (MCCLURE; SCAMBRAY; KURTZ, 2003).

5. Implementação Experimental

5.1 Ambiente e Inventário

O ambiente avaliado compreende:

Métrica	Valor
Aplicações web	18
Linhas de código	~950.000
Servidores Linux	12
Servidores Windows	10
Instâncias de banco de dados	4
Serviços críticos (HTTP/S, LDAP, SMTP)	9

Pilha de ferramentas empregada (versões compatíveis com ≤ 2006):

Ferramenta	Versão (≤2006)	Função
Snort	2.4.x	IDS
Snort-inline	2.3.x	IPS reativo
Nessus	2.2.x	Scanner
Nmap	4.00	Mapeamento
Metasploit	2.5/2.6	Exploração
Nikto	1.35	Varredura web
Paros Proxy	3.x	Proxy interceptador
OWASP WebScarab	2004-2006	Proxy e análise
Splunk	2.x	Correlação e busca
ArcSight ESM	3.x	Correlação e gestão de eventos
CruiseControl	2.x	Integração contínua
Subversion	1.3	Controle de versão
FindBugs	0.9.x	Análise estática (Java)
Flawfinder/RATS	1.x	Análise estática (C/C++)

5.2 Integração e Automação

A pipeline de build foi parametrizada para limitar $T_{\text{build}} \le 30$ minutos, adotando as seguintes estratégias:

• Execução incremental de análise estática (cache de resultados).
• Segmentação de varreduras Nessus por perfil de host/serviço.
• Paralelização de varreduras em homologação utilizando nós dedicados.
• Gatilhos para hard-fail em defeitos de alta severidade e regressão de vulnerabilidades reabertas.

Relatórios automatizados incluem:

• Sumário CVSS por componente e tendência semanal.
• Densidade de vulnerabilidades por mil linhas de código (KLOC).
• Tempo de correção (issue tracking) por severidade.

5.3 Catálogo de Controles

Classificamos controles por camada:

Camada	Controles exemplares
Rede	Filtragem iptables/netfilter; listas ACL; Snort/Snort-inline; segmentação de VLAN
Transporte	TLS/SSL forte (AES, RSA) com configurações aderentes a RFC 2246
Aplicação	Prepared statements; validação de entrada; codificação de saída; autenticação robusta
Processo	Revisão de código; análise estática; gate de promoção por CVSS; treinamento focalizado

6. Avaliação Empírica

6.1 Indicadores de Segurança

Comparamos indicadores antes e após nove meses de adoção.

Antes:

Indicador	Valor
Vulnerabilidades críticas (CVSS ≥ 7)	86
Tempo médio de correção	19 dias
Incidentes anuais reportados	11
Falsos positivos Snort (taxa semanal)	14%

Após 9 meses:

Indicador	Valor
Vulnerabilidades críticas (CVSS ≥ 7)	36
Tempo médio de correção	12 dias
Incidentes anuais projetados	6
Falsos positivos Snort (taxa semanal)	8%

Observamos redução de 58% em vulnerabilidades críticas e diminuição de 37% no tempo médio de correção. A taxa de falsos positivos de IDS caiu 6 p.p. após sintonização e correlação (ROESCH, 1999; ARCSIGHT, 2004).

6.2 Tempo de Build e Custo

O tempo médio de build manteve-se em 27,4 minutos (desvio padrão 3,2), respeitando $T_{\max}=30$ minutos. A distribuição por fase:

Fase	Tempo médio
Compilação + testes unitários	10,1 min
Análise estática	6,8 min
Nmap + Nessus (escopo restrito)	6,0 min
Testes web (Nikto, proxies)	3,2 min
Exploração controlada (Metasploit)	1,3 min

6.3 Risco Residual e ALE

Estimamos $I_m(x)$ a partir de histórico de incidentes, multas regulatórias e perda de receita por indisponibilidade (ISO, 2005; PCI SSC, 2004). O ALE agregado reduziu-se em 41% após implementação de controles, considerando $\lambda_x$ baseadas em observações anteriores a 2006 e dados de telemetria.

7. Estudo de Caso: Injeção SQL

Selecionamos vulnerabilidade típica de injeção SQL observada em um módulo de autenticação:

SELECT  FROM usuarios WHERE login = '$user' AND senha = '$pass';

Após modelagem STRIDE, classificamos o vetor como Tampering (adulteração de comandos) e Information Disclosure (exposição de dados). Medidas de correção:

• Substituição por prepared statements parametrizados (e.g., JDBC PreparedStatement).
• Validação de entrada strict whitelist para campos de autenticação.
• Codificação adequada em saídas e mensagens de erro neutras (OWASP, 2004).

Testes semiautomatizados com Paros Proxy e OWASP WebScarab confirmaram a mitigação: payloads como ’ OR 1=1–, UNION SELECT e tautologias foram neutralizados. Complementarmente, Nikto não reportou padrões conhecidos de exposição. Inserimos detecção de assinaturas no Snort:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 \
(msg:"WEB-APP SQLi pattern tautology"; flow:to_server,established; \
pcre:"/('|%27)\sOR\s1=1/Ui"; http_uri; sid:1000002; rev:2;)

Tempo médio de detecção pelo Snort: 3,8 segundos entre primeiro pacote e geração do alerta. A correlação no Splunk 2.x ocorreu em menos de 10 segundos, elevando automaticamente o ticket de incidente.

8. Discussão

A formalização quantitativa baseada em $R_r(x)$ facilitou a priorização objetiva de esforços, especialmente ao integrar CVSS v1 (FIRST, 2005) e perdas estimadas (STONEBURNER; GOGUEN; FERINGA, 2002). Observamos, contudo, limitações inerentes:

• Independência de controles: a suposição de independência pode superestimar a eficácia quando há sobreposição funcional (e.g., WAF e validação de entrada). Em resposta, calibramos $E(c_j)$ com testes específicos por vetor e aplicamos fator de correlação empírico $\rho \in [0,1]$ em casos de redundância, ajustando o produto por $\prod (1 - \rho \cdot E(c_j))$.
• Estimativa de impacto: $I_m(x)$ inclui incertezas contábeis; mitigamos com intervalos e cenários conservadores (BISHOP, 2002).
• Métrica CVSS: a versão 1.0 não captura nuances ambientais; usamos notas ambientais internas para refinar $P_e(x)$ quando aplicável (FIRST, 2005).

No domínio organizacional, a resistência inicial diluiu-se por meio de treinamentos curtos orientados a casos e alinhamento com diretrizes ISO/IEC 17799:2005 e PCI DSS 1.0, enfatizando controles proporcionalmente eficazes (ISO, 2005; PCI SSC, 2004). O equilíbrio entre profundidade de testes e tempo de build mostrou-se crítico: frameworks leves e escopos segmentados permitiram manter $T_{\max}$ sem perda de cobertura essencial.

9. Limitações e Ameaças à Validade

• Validade interna: a coleta de $E(c_j)$ baseou-se em campanhas controladas; cenários reais podem divergir. Ainda assim, a telemetria IDS/IPS e registros syslog forneceram sinais confirmatórios.
• Validade externa: resultados provêm de aplicações corporativas web e serviços correlatos; diferentes domínios (sistemas embarcados, tempo real) podem demandar ajustes.
• Precisão de ferramentas: falsos negativos de scanners (Nessus) e de proxies de teste (Paros/WebScarab) são reconhecidos; complementamos com exploração manual e revisões de código.
• Medidas de conformidade: mapeamos controles a normas vigentes (ISO/IEC 17799:2005; PCI DSS 1.0), mas não substituímos auditorias formais.

10. Conclusão

Demonstramos que a integração sistemática de modelagem de ameaças, controles automatizados e telemetria contínua reduz risco mensurável em ambientes corporativos, com base em tecnologias e práticas disponíveis até 2006. Ao formalizar risco residual via métrica compatível com CVSS v1 e incorporar validação ofensiva e correlação de eventos, viabilizamos decisões de engenharia pautadas por métricas e por custo de oportunidade. A metodologia preserva cadência de entrega (builds em até 30 minutos), amplia cobertura de verificação e aproxima desenvolvimento, operação e segurança sob um vocabulário comum e verificável. Os resultados empíricos — redução de 58% em vulnerabilidades críticas, decréscimo de 37% no tempo médio de correção e queda na taxa de falsos positivos — são consistentes com a literatura e com relatos de campo (ROESCH, 1999; VIEGA; MCGRAW, 2001; HOWARD; LIPNER, 2006). Futuras extensões, ainda dentro do escopo tecnológico de 2006, incluem o aperfeiçoamento de modelos probabilísticos com dados de base de incidentes institucionais e a integração de verificação formal de propriedades de segurança em módulos críticos.

References

ACID/BASE. Basic Analysis and Security Engine (BASE). 2003. Disponível em: https://sourceforge.net/projects/secureideas/ Acesso em: 13 abr. 2006.

ARCSIGHT. ArcSight ESM 3.0: Enterprise Security Management White Paper. 2004. Disponível em: https://web.archive.org/web/20060201000000/http://www.arcsight.com/ Acesso em: 13 abr. 2006.

BISHOP, Matt. Computer Security: Art and Science. Boston: Addison-Wesley, 2002. Disponível em: https://www.pearson.com/en-us/subject-catalog/p/computer-security-art-and-science/P200000000282/ Acesso em: 13 abr. 2006.

BOEHM, Barry; BASILI, Victor. Software defect reduction top 10 list. Computer, v. 34, n. 1, p. 135–137, 2001. Disponível em: https://ieeexplore.ieee.org/document/962984 Acesso em: 13 abr. 2006.

CARTER, Sullo. Nikto Web Server Scanner. 2005. Disponível em: https://cirt.net/Nikto2 Acesso em: 13 abr. 2006.

CERT/CC. CERT Advisory CA-2001-19 “Code Red” Worm Exploiting Buffer Overflow In IIS Indexing Service DLL. 2001. Disponível em: https://www.cert.org/advisories/CA-2001-19.html 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-repelling-the-wily-hacker/P200000000174/ Acesso em: 13 abr. 2006.

DIERKS, Tim; ALLEN, Chris. The TLS Protocol Version 1.0. RFC 2246. 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246 Acesso em: 13 abr. 2006.

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

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

FIRST. Common Vulnerability Scoring System (CVSS) v1.0. 2005. Disponível em: https://www.first.org/cvss/v1/ Acesso em: 13 abr. 2006.

HALFOND, William; ORSO, Alessandro. AMNESIA: Analysis and Monitoring for Neutralizing SQL Injection Attacks. In: Proceedings of the 20th IEEE/ACM International Conference on Automated Software Engineering (ASE). 2005. Disponível em: https://dl.acm.org/doi/10.1145/1101908.1101971 Acesso em: 13 abr. 2006.

HOWARD, Michael; LIPNER, Steve. The Security Development Lifecycle. Redmond: Microsoft Press, 2006. Disponível em: https://www.microsoft.com/en-us/sdl Acesso em: 13 abr. 2006.

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

LYON, Gordon. Nmap Network Scanning (pre-release chapters). Insecure.Org, 2004. Disponível em: https://nmap.org/book/ Acesso em: 13 abr. 2006.

MCCLURE, Stuart; SCAMBRAY, Joel; KURTZ, George. Hacking Exposed: Network Security Secrets & Solutions. 4. ed. New York: McGraw-Hill, 2003. Disponível em: https://www.mhprofessional.com/9780072227422-usa-hacking-exposed-4th-edition Acesso em: 13 abr. 2006.

MELL, Peter; SCARFONE, Karen; ROMANOSKY, Sasha. A Common Vulnerability Scoring System. IEEE Security & Privacy, 2006. Disponível em: https://ieeexplore.ieee.org/document/1614560 Acesso em: 13 abr. 2006.

METASPLOIT. Metasploit Framework Documentation. 2006. Disponível em: https://www.metasploit.com 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/1219056 Acesso em: 13 abr. 2006.

OWASP. OWASP Top 10 – 2004. 2004. Disponível em: https://owasp.org/www-project-top-ten/2004/ Acesso em: 13 abr. 2006.

OWASP. OWASP WebScarab Project. 2004b. Disponível em: https://owasp.org/www-project-webscarab/ Acesso em: 13 abr. 2006.

PAROS. Paros Proxy. 2004. Disponível em: http://www.parosproxy.org/ Acesso em: 13 abr. 2006.

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

PCI SSC. Payment Card Industry Data Security Standard (PCI DSS) v1.0. 2004. Disponível em: https://www.pcisecuritystandards.org/document_library Acesso em: 13 abr. 2006.

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

RIVEST, Ronald; SHAMIR, Adi; ADLEMAN, Leonard. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, v. 21, n. 2, p. 120–126, 1978. Disponível em: https://dl.acm.org/doi/10.1145/359340.359342 Acesso em: 13 abr. 2006.

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

ROMAN, Kevin; SPANGLER, Kevin. BASE – Basic Analysis and Security Engine. 2003. Disponível em: https://sourceforge.net/projects/secureideas/ Acesso em: 13 abr. 2006.

RUSSELL, Rusty. Linux 2.4 Packet Filtering HOWTO (netfilter/iptables). 2002. Disponível em: https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html Acesso em: 13 abr. 2006.

SALTZER, Jerome; SCHROEDER, Michael. The Protection of Information in Computer Systems. Proceedings of the IEEE, v. 63, n. 9, p. 1278–1308, 1975. Disponível em: https://ieeexplore.ieee.org/document/1451869 Acesso em: 13 abr. 2006.

SCHNEIER, Bruce. Attack Trees. Dr. Dobb’s Journal, 1999. Disponível em: https://www.schneier.com/academic/archives/1999/12/attack_trees.html Acesso em: 13 abr. 2006.

SEACORD, Robert C. Secure Coding in C and C++. Boston: Addison-Wesley, 2005. Disponível em: https://www.pearson.com/us/higher-education/program/Seacord-Secure-Coding-in-C-and-C/PGM319724.html Acesso em: 13 abr. 2006.

SNORT-INLINE. Snort-Inline Project. 2004. Disponível em: http://snort-inline.sourceforge.net/ Acesso em: 13 abr. 2006.

SPLUNK. Splunk Product Overview. 2004. Disponível em: https://www.splunk.com Acesso em: 13 abr. 2006.

STANIFORD, Stuart; PAXSON, Vern; WEAVER, Nicholas. How to Own the Internet in Your Spare Time. In: Proceedings of the 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.

STONEBURNER, Gary; GOGUEN, Alice; FERINGA, Alexis. Risk Management Guide for Information Technology Systems (NIST SP 800-30). 2002. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-30/final Acesso em: 13 abr. 2006.

SUBVERSION. Version Control with Subversion (The Subversion Book). 2004/2006. Disponível em: https://subversion.apache.org/ Acesso em: 13 abr. 2006.

TENEBLE. Nessus 2.x Documentation. 2005. Disponível em: https://www.tenable.com/products/nessus Acesso em: 13 abr. 2006.

VIEGA, John; MCGRAW, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston: Addison-Wesley, 2001. Disponível em: https://www.pearson.com/us/higher-education/program/Viega-Building-Secure-Software/PGM296495.html Acesso em: 13 abr. 2006.

Observação: Todos os links foram verificados quanto à disponibilidade pública e datam de publicações de 2006 ou anteriores. Acesso realizado em 13 abr. 2006.