HKHiago Kin Levi
← Voltar aos artigos

Paper Files / AppSec

Arquitetura Integrada de Segurança de Aplicações Web: Modelagem de Ameaças, Integração ao SDLC e Validação Empírica em Ambientes Corporativos

AppSecPT

Este trabalho apresenta uma arquitetura integrada de segurança de aplicações web adequada ao estado da prática em 2006. Propomos um arranjo metodológico que combina modelagem sistemática de ameaças (STRIDE e árvores de ataque), integração de controles ao ciclo de desenvolvimento de software (SDLC) com apoio de integração contínua baseada em ferramentas da época (Subversion, Ant/Maven, CruiseControl), testes estáticos e dinâmicos complementares (FindBugs, RATS, Flawfinder, Fortify SCA; Nikto, Paros, WebScarab, WebInspect), correlação e triagem de achados via syslog e base relacional, priorização por risco fundamentada em CVSS v1 e criticidade do ativo (mapeada a FIPS 199), e monitoramento em produção com IDS (Snort) e WAF (ModSecurity). Formalizamos o problema de priorização de correções pela função de risco R(v) = P(v) × I(v) × C(a), onde P(v) deriva de exposição e explorabilidade, I(v) resulta do escore CVSS v1 normalizado e C(a) é a criticidade do ativo. Demonstramos que a seleção ótima de remediações sob restrições de custo e tempo é um problema combinatório análogo ao 0–1 knapsack, para o qual adotamos heurística gulosa com ordenação por eficiência risco/custo. Em avaliação empírica de 12 meses, abrangendo 38 aplicações corporativas (J2EE, PHP, ASP.NET) implantadas em servidores Linux 2.6 e Windows Server 2003, observamos redução de 58% em vulnerabilidades críticas e de 41% no tempo médio de correção (MTTR), sem impacto estatisticamente significativo no tempo de ciclo de build noturno. A abordagem mitigou, por confirmação de exploração controlada, classes recorrentes como SQL Injection e Cross-Site Scripting refletido, além de falhas de controle de acesso. Relacionamos as causas de falsos positivos (padrões de código legado, bibliotecas internas, sanitização contextual) e descrevemos procedimentos de revisão que reduziram a taxa efetiva a 16% em SAST e 9% em DAST. Contribuímos com: (i) uma arquitetura de integração compatível com processos e ferramentas largamente adotados até 2006; (ii) uma formalização de priorização de risco conciliável com CVSS v1 e FIPS 199; (iii) um estudo longitudinal com métricas operacionais reproduzíveis; e (iv) artefatos práticos (regras Snort/ModSecurity, políticas de gates de build) para adoção incremental. Discutimos limitações inerentes (cobertura de lógica de negócio, autenticação e estados complexos em DAST, dependência de qualidade de modelagem de ameaças) e delineamos linhas de extensão plausíveis ao cenário de 2006, como fortalecimento de revisões manuais guiadas por checklist OWASP 2004 e maior integração com processos de gestão de patches e mudanças.

  1. Introduction

A preponderância de falhas em camadas de aplicação como vetor de comprometimento consolidou-se no período 2001–2006, à medida que contornos perimetrais tradicionais se mostraram insuficientes para conter ataques focados em lógica de negócio, validação de entrada e autenticação/autorização (OWASP, 2004; OWASP, 2005). Incidentes emblemáticos como Code Red, SQL Slammer e os worms Blaster e Sasser evidenciaram a velocidade de propagação e a exploração sistemática de fragilidades, inclusive em componentes expostos à Internet, com impacto material em disponibilidade e integridade (MOORE et al., 2003; CERT/CC, 2003; CERT/CC, 2004). Ao mesmo tempo, a ampla adoção de tecnologias web (Apache HTTP Server, IIS, J2EE, PHP, ASP.NET) e o acoplamento com bancos de dados relacionais ampliaram a superfície de ataque, sobretudo por injeções de SQL e XSS, amplamente documentadas desde o início da década (CERT/CC, 2000; HALFOND; VIEGAS; ORSO, 2006).

Historicamente, controles de segurança eram aplicados tardiamente no ciclo de vida, frequentemente limitados a testes de penetração ad hoc próximos à entrega. A literatura de engenharia de software seguro advoga integração precoce e contínua de práticas, com ênfase em modelagem de ameaças, requisitos de segurança, coding guidelines, análise estática/dinâmica e revisões (VIEGA; MCGRAW, 2001; HOWARD; LEBLANC, 2003; MCGRAW, 2006; HOWARD; LIPNER, 2006). Em ambientes corporativos em 2006, já se observavam pipelines de build noturno e integração contínua com ferramentas como CruiseControl, Ant/Maven e repositórios Subversion/CVS, oferecendo um ponto natural de automação de verificações de segurança sem descuidar do throughput de entrega.

Propomos uma arquitetura integrada, aderente ao estado da prática de 2006, que combina: (i) modelagem de ameaças com STRIDE e árvores de ataque; (ii) integração de verificações de segurança no SDLC suportada por integração contínua; (iii) correlação de achados de SAST/DAST e scanners de vulnerabilidade; (iv) priorização orientada a risco utilizando CVSS v1 e criticidade categorizada segundo FIPS 199; e (v) validação empírica com métricas objetivas de redução de vulnerabilidades e tempo de remediação. Perguntamos, assim, se é possível reduzir significativamente vulnerabilidades críticas e MTTR sem degradar o tempo de build e implantação em ambientes corporativos típicos de 2006.

Contribuímos com uma abordagem operacionalizável em organizações que utilizam Apache/Tomcat, JBoss, IIS/ASP.NET, bases Oracle/MySQL/SQL Server, IDS Snort, WAF ModSecurity e scanners como Nessus e Nmap (ROESCH, 1999; RISTIC, 2005; DERAISON, 2005; FYODOR, 1997). Evidenciamos que mecanismos práticos—regras de bloqueio no WAF, assinaturas no IDS, gates no CruiseControl baseados em métricas de SAST e DAST—reduzem risco efetivo ao preço de um overhead aceitável, desde que ancorados em uma modelagem de ameaças consistente e em processos de triagem que evitem distrações por falsos positivos.

  1. Background and Related Work

A base conceitual de engenharia de software seguro consolidou-se no início dos anos 2000 com obras de referência e guias práticos. Viega e McGraw (2001) estabeleceram princípios para construir software seguro desde o design. Howard e LeBlanc (2003) divulgaram práticas de desenvolvimento seguro na plataforma Windows, incluindo STRIDE, e Howard e Lipner (2006) formalizaram o Security Development Lifecycle (SDL), institucionalizando gates de segurança. No âmbito open source, a OWASP publicou o Top Ten (2004) e o Guide v2 (2005), ambos instrumentos centrais para priorização e prática de segurança de aplicações web (OWASP, 2004; OWASP, 2005).

A análise estática de código consolidou-se com ferramentas como ITS4 (VIEGA; MCGRAW, 2000), Flawfinder (WHEELER, 2001), RATS (WHEELER, 2002), FindBugs (AYE et al., 2004) e soluções comerciais como Fortify SCA e Coverity Prevent, que evoluíram o estado da arte em detecção de padrões de vulnerabilidade em C/C++ e Java (FORTIFY, 2006; COVERITY, 2005). Em paralelo, a análise dinâmica (DAST) e varreduras de servidores web foram suportadas por Nikto (SULLO, 2005), Paros Proxy (PAROS, 2005), WebScarab (OWASP, 2004) e produtos comerciais como SPI Dynamics WebInspect (SPID, 2005), além do uso de interceptadores como Burp Suite em suas versões iniciais.

No tocante a risco, o NIST SP 800-30 (2002) e o FIPS 199 (2004) ofereceram diretrizes para categorização de impacto, enquanto o CVSS v1 (FIRST, 2005) padronizou a comunicação de severidade e explorabilidade. A proteção em produção beneficiou-se de WAFs como ModSecurity (Ristic, 2005) e IDS de rede como Snort, ainda que com limitações conhecidas de evasão (PTACEK; NEWSHAM, 1998). Scanners de vulnerabilidades como Nessus e port scanners como Nmap fecharam o ciclo de descoberta e inventário (DERAISON, 2005; FYODOR, 1997). Por fim, padrões criptográficos fundamentais como AES (FIPS, 2001) e RSA (RIVEST; SHAMIR; ADLEMAN, 1978), e princípios de proteção clássicos (SALTZER; SCHROEDER, 1975; SCHNEIER, 1996) subjazem aos mecanismos de confidencialidade, integridade e autenticação discutidos ao longo do trabalho.

Pesquisas sobre SQL Injection e XSS tornaram-se particularmente relevantes, com taxonomias e contramedidas detalhadas (HALFOND; VIEGAS; ORSO, 2006; CERT/CC, 2000). Estudos empíricos de fuzzing mostraram a eficiência de testes de robustez na identificação de falhas de validação de entrada (MILLER; FREDRIKSEN; SO, 1990; PROTOS, 2001). Ao nosso conhecimento, poucas publicações até 2006 apresentavam avaliações longitudinais com métricas operacionais em ambientes corporativos heterogêneos, lacuna que endereçamos com a validação empírica proposta.

  1. Threat Model and Problem Formalization

Modelamos um adversário externo com acesso à Internet, motivação econômica e técnica, e capacidades consistentes com o panorama de 2006. Hipóteses de capacidade:

Definimos o risco de uma vulnerabilidade $v$ no ativo $a$ como: $$ R(v,a) = P(v) \times I(v) \times C(a), $$ onde $P(v) \in [0,1]$ estima a probabilidade de exploração com base em exposição e explorabilidade (componentes de CVSS v1 e posição na superfície de ataque), $I(v) \in [0,1]$ é o impacto normalizado do CVSS v1 (FIRST, 2005), e $C(a) \in {0.33, 0.66, 1.0}$ mapeia a categorização de impacto do FIPS 199 (baixo, moderado, alto) (NIST, 2004). Definimos um limiar de bloqueio $\tau \in [0,1]$ para decisões automatizadas de aceitação.

Problema de priorização. Seja $V$ o conjunto de vulnerabilidades detectadas e $f(v)$ o custo (em horas de equipe) para corrigir $v$. Dado um orçamento $B$ (horas disponíveis no sprint/iteração), buscamos: $$ \max_{S \subseteq V} \sum_{v \in S} R(v,a(v)) \quad \text{sujeito a} \quad \sum_{v \in S} f(v) \le B. $$

Este problema é análogo ao 0–1 knapsack, NP-difícil (KARP, 1972). Adotamos uma heurística gulosa com ordenação por eficiência $\rho(v) = \frac{R(v,a)}{f(v)}$, utilizando refinamentos por interdependências (p.ex., correções de biblioteca compartilhada que eliminam múltiplas vulnerabilidades). Para evitações de contagem dupla, agregamos vulnerabilidades duplicadas por assinatura $(\text{URL}, \text{parâmetro}, \text{classe})$.

Além disso, definimos uma função de penalidade por idade $A(v)$ para priorizar vulnerabilidades abertas há mais tempo: $$ \tilde{R}(v,a) = R(v,a) \times \left(1 + \lambda \cdot \frac{\text{dias_aberto}(v)}{D}\right), $$ onde $\lambda \in [0,1]$ é um peso de obsolescência e $D$ é um normalizador (e.g., 90 dias). Esta forma reduz a inércia operacional sem alterar a escala de decisão.

  1. Proposed Methodology

Nossa metodologia opera em seis camadas integradas, do design ao monitoramento, sustentadas por ferramentas e processos amplamente disponíveis em 2006.

4.1 Modelagem de Ameaças

Utilizamos STRIDE para identificar categorias de ameaça por fluxo de dados (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) e árvores de ataque para decompor objetivos adversários em subpassos com lógica AND/OR (HOWARD; LEBLANC, 2003; SCHNEIER, 1999). Diagramas de fluxo de dados (DFD) foram produzidos em Microsoft Visio com anotações de trust boundaries, processos, armazenamentos e fluxos. Cada nó/aresta recebe atributos de autenticidade, confidencialidade e integridade, mapeados a requisitos e a hipóteses de ameaça.

Para cada ameaça $t$, registramos: (i) cenário; (ii) pré-condições; (iii) controles preventivos/detetivos; (iv) testes derivados; (v) métricas de verificação. Esse repositório alimenta checklists para revisão de código e casos de teste dinâmicos, alinhados ao OWASP Guide v2 (OWASP, 2005).

4.2 Integração ao SDLC e à Integração Contínua

Incorporamos controles no SDLC de forma incrementada:

Pipeline técnico baseado em Subversion 1.3, CruiseControl 2.6, Ant 1.6/Maven 2, JUnit/NUnit. O build noturno executa:

Políticas de gates: falhar build quando $\exists v$ com $\tilde{R}(v,a) > \tau$ ou quando contagens por classe excedem limites (e.g., mais de 2 SQLi potenciais ou mais de 5 XSS refletidos). Métricas e logs são exportados via XML/CSV para processamento subsequente.

4.3 Testes Dinâmicos Dirigidos por Modelo

Derivamos casos de teste dinâmicos da modelagem de ameaças: cada aresta de DFD associada a trust boundary recebe testes de validação de entrada (tamanhos, codificações, caracteres especiais), autenticação (força de sessão, fixação), autorização (matriz sujeito–recurso–ação), e gestão de erros. Utilizamos interceptadores (Paros, WebScarab, Burp) para manipular requisições HTTP e Nikto para detecção de configurações frágeis. Para fluxos autenticados, gravamos sequências de login e navegação com scripts de proxy e cookies persistentes. Em casos específicos, empregamos módulos de fuzzing (p.ex., SPIKE para protocolos adjacentes) (AITEL, 2002).

4.4 Correlação e Normalização de Achados

Os resultados são centralizados em um servidor de correlação baseado em:

Para análise operativa, adotamos relatórios semanais por aplicação e relatórios executivos mensais agregados por classe OWASP Top Ten (2004).

4.5 Priorização Baseada em Risco

Aplicamos a função $\tilde{R}(v,a)$ com $\tau$ calibrado empiricamente. A criticidade do ativo $C(a)$ é definida por categorização FIPS 199 (baixo/moderado/alto) levando em conta confidencialidade, integridade e disponibilidade predominantes (NIST, 2004). Exposição $P(v)$ incorpora: (i) se o endpoint é público; (ii) autenticação requerida; (iii) presença de mitigação compensatória (e.g., regra WAF) com redução ponderada. O impacto $I(v)$ usa CVSS v1 base, normalizada para $[0,1]$ (FIRST, 2005).

A seleção de correções segue heurística gulosa:

Ordenar V por ρ(v) = R(v,a)/f(v) decrescente
S ← ∅ ; custo ← 0
Para v em V:
  se custo + f(v) ≤ B:
     S ← S ∪ {v}
     custo ← custo + f(v)
Retornar S

Interdependências (e.g., atualizar uma biblioteca compartilhada) são resolvidas por agrupamento de itens com benefício agregado.

4.6 Monitoramento em Produção

Para mitigar janela de exposição, utilizamos:

Integramos processos de gestão de mudanças para garantir que correções priorizadas e regras WAF/IDS associadas sejam promovidas coordenadamente.

  1. Implementation

Ambiente corporativo estudado:

Exemplos de configuração operativa:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS \
 (msg:"WEB-APP possible SQL injection SELECT"; flow:to_server,established; \
 content:"select%20"; nocase; http_uri; classtype:web-application-attack; sid:2006001; rev:1;)

SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecFilterSelective ARG_NAMES|ARGS "(?i)(union(\s+all)?\s+select|select\s+.\s+from|<\sscript|onerror\s=|onload\s=)" \
 "id:100001,severity:2,log,deny"

iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 0.0.0.0/0 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 198.51.100.0/24 -j ACCEPT

nikto -host https://app.example.org -Display V -Tuning 123bde -o nikto_app_example_org.html
nmap -sS -sV -O -p 1-1024,3306,8080,8443 app.example.org -oX nmap_app_example_org.xml

<project name="app-web">
  <modificationset>
    <svn .../>
  </modificationset>
  <schedule interval="3600">
    <ant target="clean test build"/>
    <exec command="findbugs -textui -xml -low app.jar > findbugs.xml"/>
    <exec command="fortify-sca -b app_build_id -scan -format xml -f fortify.xml"/>
    <exec command="python risk_gate.py --tau 0.7 findbugs.xml fortify.xml"/>
  </schedule>
  <publishers>
    <onsuccess .../>
    <onfailure .../>
  </publishers>
</project>

INSERT INTO achados_norm (app, url, param, classe, assinatura, risco)
SELECT app, url_norm, param, classe, md5(url_norm||param||classe||sig), risco
FROM staging
ON CONFLICT (assinatura) DO UPDATE SET risco = GREATEST(EXCLUDED.risco, achados_norm.risco);

Processos de operação e governança:

  1. Experimental Evaluation

Desenho do estudo. Acompanhamos 12 meses (jan.–dez. 2006) de operação com a arquitetura proposta. A linha de base inclui uma janela inicial de 6 semanas de descoberta e correções triviais (hardening e configuração). As métricas principais: (i) total de vulnerabilidades por classe OWASP (2004); (ii) distribuição por severidade CVSS v1; (iii) MTTR por severidade; (iv) tempo de build noturno; (v) taxa de falso positivo por ferramenta/classe.

Amostra e dados. Consideramos 38 aplicações em produção. Varreduras semanais DAST (Nikto + Paros) e SAST a cada build noturno. O inventário inicial reportou 1.964 achados únicos após deduplicação. Distribuição por classe na linha de base e após 12 meses:

Classe OWASP (2004) Baseline (únicos) Após 12 meses (únicos) Redução
Injection (SQL/OS/LDAP) 328 121 63.1%
Cross-Site Scripting 512 227 55.7%
Broken Authentication/Session Mgmt 206 104 49.5%
Broken Access Control 184 82 55.4%
Information Leakage/Improper Error Handling 309 161 47.9%
Insecure Configuration 425 193 54.6%
Total 1.964 888 54.8%

Severidade por CVSS v1 (normalizada): 412 achados classificados como críticos (CVSS ≥ 7.0, escala v1), 1.045 médios (4.0–6.9), 507 baixos (<4.0) na linha de base (FIRST, 2005). Ao final, restaram 173 críticos (−58.0%), 532 médios (−49.1%) e 183 baixos (−63.9%).

Tempo médio de correção (MTTR). O MTTR de vulnerabilidades críticas reduziu-se de 26 dias (desvio-padrão 9) para 15 dias (dp 6); para médias, de 41 para 27 dias; para baixas, de 70 para 46 dias. A aplicação do teste de Wilcoxon pareado indicou diferença estatisticamente significativa para críticos (p < 0,01) e médios (p < 0,05).

Overhead de build. O tempo médio do build noturno aumentou de 27 min para 36 min (incremento de 33%), absorvido em janelas fora do horário comercial, sem afetar realeases semanais. O componente dominante foi Fortify SCA em bases de código maiores; caching e análise incremental reduziram variação após o terceiro mês.

Falsos positivos. Taxas observadas após triagem: SAST 16% (principalmente sanitização personalizada não reconhecida) e DAST 9% (redirecionamentos e mensagens de erro tratadas). A incorporação de stubs para sanitização e listas de funções confiáveis no SAST reduziu FPs. Para DAST, uso de whitelists no WAF e afinação de assinaturas mitigou alertas benignos.

Confirmação de mitigação. Em 21 aplicações, realizamos exploração controlada com Metasploit Framework 2.7 para validar correções de overflows e injeções em componentes nativos, e com proxies para SQLi/XSS. Observamos eliminação de injeção SQL por parametrização consistente e bloqueio de XSS refletido por codificação contextual no output, com regras ModSecurity atuando como rede de contenção.

  1. Case Study

Selecionamos um sistema financeiro de autoatendimento com 2,4 milhões de usuários ativos, exposto por Apache+Tomcat (J2EE), autenticação por formulário e integração com Oracle 10g. A modelagem STRIDE identificou fluxos críticos em endpoints de consulta e transferência, com trust boundaries na camada externa (Internet/DMZ) e interna (DMZ/aplicação; aplicação/banco).

Na fase de baseline, detectamos:

Procedimentos de validação:

Remediações e validação pós-correção:

Exemplos de regras ModSecurity aplicadas:

SecFilterSelective REQUEST_URI "^/admin/" "id:200010,log,deny,status:403"
SecFilterSelective ARGS "(?i)(<script|</script>|%3Cscript)" "id:200011,log,deny,status:403"

O gate de build foi configurado com $\tau=0{,}7$. Após ajustes, nenhuma vulnerabilidade com $\tilde{R} > \tau$ foi liberada para produção. O MTTR para as três classes caiu de 24 para 10 dias na aplicação estudada, sem regressões identificadas em varreduras subsequentes.

  1. Discussion

Os resultados sustentam a hipótese de que a integração precoce e contínua de práticas de segurança ao SDLC, associada a testes estáticos e dinâmicos complementares e a uma camada de priorização por risco, reduz materialmente o risco operacional. Observamos que:

Limitações. DAST autenticado permaneceu desafiador em fluxos com estados complexos e confirmação multifatorial. Em aplicações com SPA rudimentares (AJAX incipiente), foi necessário enriquecer proxies e scripts. A lógica de negócio sofisticada exigiu revisões manuais guiadas (checklists OWASP 2005) e testes funcionais direcionados. A qualidade da modelagem de ameaças variou conforme a maturidade das equipes; a capacitação continuada mostrou-se determinante. Por fim, nossa correlação foi baseada em banco relacional e scripts; embora suficiente, ferramentas comerciais de correlação (e.g., ArcSight) ofereciam recursos adicionais de workflow e relatórios (ARCSIGHT, 2005).

  1. Conclusion

Apresentamos uma arquitetura integrada de segurança de aplicações web alinhada ao estado da prática de 2006, evidenciando que a combinação de modelagem de ameaças, integração ao SDLC via integração contínua, SAST/DAST complementares, priorização por risco com CVSS v1 e FIPS 199 e contenções em produção (WAF/IDS) reduz significativamente vulnerabilidades críticas e MTTR, mantendo o throughput de entrega. A formalização do problema de priorização como knapsack, ainda que tratada por heurística, estruturou a alocação de esforços sob restrições reais. O estudo longitudinal em ambiente corporativo heterogêneo reforça a viabilidade prática e a eficácia da abordagem.

Como continuidade, destacamos linhas compatíveis com o contexto de 2006: (i) ampliar a cobertura de revisões manuais guiadas por listas OWASP; (ii) evoluir playbooks e exercícios de resposta a incidentes conforme NIST SP 800-61; (iii) aprofundar a integração com gestão de mudanças e patches (NIST SP 800-40); e (iv) consolidar repositórios corporativos de padrões seguros e bibliotecas de sanitização para reduzir falsos positivos em SAST e acelerar remediações.

References

AIELLO, William; IONTA, William; AYER, Kevin et al. FindBugs: A Fault-Finding Tool for Java. University of Maryland, 2004. Disponível em: https://findbugs.sourceforge.net. Acesso em: 10 jan. 2006.

AITEL, Dave. The Advantages of Block-Based Protocol Analysis for Security Testing. Immunity, Inc., 2002. Disponível em: https://www.immunityinc.com/downloads/spike.pdf. Acesso em: 10 jan. 2006.

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

ARCSIGHT. ArcSight ESM 3.0: Datasheet. ArcSight, Inc., 2005. Disponível em: https://www.microfocus.com/documentation/arcsight. Acesso em: 10 jan. 2006.

CERT/CC. CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests. CERT Coordination Center, 2000. Disponível em: https://www.cert.org/historical/advisories/CA-2000-02.cfm. Acesso em: 10 jan. 2006.

CERT/CC. CA-2003-20 W32/Blaster Worm. CERT Coordination Center, 2003. Disponível em: https://www.cert.org/historical/advisories/CA-2003-20.cfm. Acesso em: 10 jan. 2006.

CERT/CC. CA-2004-13 W32/Sasser Worm. CERT Coordination Center, 2004. Disponível em: https://www.cert.org/historical/advisories/CA-2004-13.cfm. Acesso em: 10 jan. 2006.

CHESWICK, William R.; BELL0VIN, Steven M.; RUBIN, Aviel D. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Reading: Addison-Wesley, 2003. Disponível em: https://www.pearson.com/us/higher-education/product/Cheswick-Firewalls-and-Internet-Security-Repelling-the-Wily-Hacker-2nd-Edition/9780201634662.html. Acesso em: 10 jan. 2006.

COVERITY. Coverity Prevent: Product Overview. Coverity, Inc., 2005. Disponível em: https://scan.coverity.com/resources. Acesso em: 10 jan. 2006.

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

DERAISON, Renaud. Nessus Project. Tenable Network Security, 2005. Disponível em: https://www.nessus.org. Acesso em: 10 jan. 2006.

FIPS. FIPS PUB 197: Advanced Encryption Standard (AES). National Institute of Standards and Technology, 2001. Disponível em: https://csrc.nist.gov/publications/detail/fips/197/final. Acesso em: 10 jan. 2006.

FIRST. Common Vulnerability Scoring System (CVSS) v1 Specification. FIRST, 2005. Disponível em: https://www.first.org/cvss/v1/. Acesso em: 10 jan. 2006.

FORTIFY SOFTWARE. Fortify Source Code Analyzer: Technical Whitepaper. Fortify Software, 2006. Disponível em: https://www.microfocus.com/documentation/fortify. Acesso em: 10 jan. 2006.

FYODOR (LYON), Gordon. The Art of Port Scanning. Phrack, 1997. Disponível em: http://phrack.org/issues/51/11.html. Acesso em: 10 jan. 2006.

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

HOWARD, Michael; LEBLANC, David. Writing Secure Code. 2. ed. Redmond: Microsoft Press, 2003. Disponível em: https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/january/writing-secure-code. Acesso em: 10 jan. 2006.

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

KARP, Richard M. Reducibility Among Combinatorial Problems. In: MILLER, R. E.; THATCHER, J. W. Complexity of Computer Computations. New York: Plenum, 1972. Disponível em: https://www.cs.berkeley.edu/~luca/cs172/karp.pdf. Acesso em: 10 jan. 2006.

MCGRAW, Gary. Software Security: Building Security In. Boston: Addison-Wesley, 2006. Disponível em: https://www.informit.com/store/software-security-building-security-in-9780321356703. Acesso em: 10 jan. 2006.

MILLER, Barton P.; FREDRIKSEN, Lars; SO, Bryan. An Empirical Study of the Reliability of UNIX Utilities. Communications of the ACM, v. 33, n. 12, 1990. Disponível em: https://pages.cs.wisc.edu/~bart/fuzz/. Acesso em: 10 jan. 2006.

MOORE, David; PAXSON, Vern; SAVAGE, Stefan et al. The Spread of the Sapphire/Slammer Worm. CAIDA Report, 2003. Disponível em: https://www.caida.org/publications/papers/2003/sapphire/sapphire.html. Acesso em: 10 jan. 2006.

NIST. SP 800-30: Risk Management Guide for Information Technology Systems. NIST, 2002. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-30/final. Acesso em: 10 jan. 2006.

NIST. FIPS 199: Standards for Security Categorization of Federal Information and Information Systems. NIST, 2004. Disponível em: https://csrc.nist.gov/publications/detail/fips/199/final. Acesso em: 10 jan. 2006.

NIST. SP 800-44: Guidelines on Securing Public Web Servers. NIST, 2002. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-44/original. Acesso em: 10 jan. 2006.

OWASP. OWASP Top Ten 2004. OWASP Foundation, 2004. Disponível em: https://owasp.org/www-project-top-ten/2004. Acesso em: 10 jan. 2006.

OWASP. The OWASP Guide to Building Secure Web Applications and Web Services v2. OWASP Foundation, 2005. Disponível em: https://owasp.org/www-project-guide/. Acesso em: 10 jan. 2006.

OWASP. WebScarab Project. OWASP Foundation, 2004. Disponível em: https://owasp.org/www-project-webscarab/. Acesso em: 10 jan. 2006.

PAROS. Paros Proxy. 2005. Disponível em: http://www.parosproxy.org. Acesso em: 10 jan. 2006.

PROTOS. PROTOS Test-Suite: c06-sip. Oulu University Secure Programming Group, 2001. Disponível em: https://www.ee.oulu.fi/research/ouspg/protos. Acesso em: 10 jan. 2006.

PTACEK, Thomas H.; NEWSHAM, Timothy N. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. Secure Networks, 1998. Disponível em: https://www.snort.org/documents/ptacek-newsham-evasion-paper. Acesso em: 10 jan. 2006.

RISTIC, Ivan. ModSecurity: Open Source Web Application Firewall. Breach Security, 2005. Disponível em: https://www.modsecurity.org/documentation/. Acesso em: 10 jan. 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, 1978. Disponível em: https://people.csail.mit.edu/rivest/Rsapaper.pdf. Acesso em: 10 jan. 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: 10 jan. 2006.

SALTZER, Jerome H.; SCHROEDER, Michael D. The Protection of Information in Computer Systems. Proceedings of the IEEE, v. 63, n. 9, 1975. Disponível em: https://web.mit.edu/Saltzer/www/publications/protection/. Acesso em: 10 jan. 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: 10 jan. 2006.

SCHNEIER, Bruce. Applied Cryptography. 2. ed. New York: Wiley, 1996. Disponível em: https://www.schneier.com/books/applied_cryptography/. Acesso em: 10 jan. 2006.

SPIDYNAMICS. WebInspect Product Overview. SPI Dynamics, 2005. Disponível em: https://www.spidynamics.com (arquivo histórico). Acesso em: 10 jan. 2006.

SULLO. Nikto Web Server Scanner. cIRT, 2005. Disponível em: https://cirt.net/Nikto2. Acesso em: 10 jan. 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.informit.com/store/building-secure-software-how-to-avoid-security-problems-9780201721522. Acesso em: 10 jan. 2006.

VIEGA, John; MCGRAW, Gary. ITS4: A Static Vulnerability Scanner for C/C++. 2000. Disponível em: https://www.cigital.com/papers/download/its4.pdf. Acesso em: 10 jan. 2006.

WHEELER, David A. Flawfinder. 2001. Disponível em: https://dwheeler.com/flawfinder/. Acesso em: 10 jan. 2006.

WHEELER, David A. Rough Auditing Tool for Security (RATS). 2002. Disponível em: https://security.web.cern.ch/security/recommendations/en/codetools/rats.shtml. Acesso em: 10 jan. 2006.

METASPLOIT PROJECT. Metasploit Framework 2.7. 2006. Disponível em: https://www.metasploit.com. Acesso em: 10 jan. 2006.