HKHiago Kin Levi
← Voltar aos artigos

Paper Files / DevSecOps

Segurança Orientada a Ameaças para Integração Contínua: Modelagem Formal, Telemetria e Resposta Automatizada em Ambientes Corporativos (2006)

DevSecOpsPT

A consolidação de aplicações web corporativas baseadas em J2EE e .NET, a difusão de serviços expostos à Internet e a adoção crescente de práticas de integração contínua (via ferramentas como CruiseControl e Hudson) intensificaram, até 2006, a necessidade de incorporar segurança ao ciclo de desenvolvimento e de operação de modo sistemático e automatizado. Ao mesmo tempo, o predomínio de arquiteturas perimetrais com firewalls e IDS baseados em assinaturas mostrou-se insuficiente diante de classes de ataques amplamente observadas, como injeção de SQL, execuções arbitrárias por estouro de buffer e worms auto-propagáveis (Code Red, Slammer, Blaster, Sasser). Propomos uma abordagem de segurança orientada a ameaças, adequada ao estado da prática em 2006, que integra: (i) modelagem formal de ameaças com STRIDE e árvores de ataque; (ii) verificação automática de propriedades de segurança com auxílio de notações formais (ataque-grafos e Alloy); (iii) análise estática leve no ciclo de build (Splint, Flawfinder, FindBugs/PMD) e testes dinâmicos (Nikto, Paros/WebScarab); (iv) telemetria operacional baseada em syslog, NetFlow e IDS (Snort/Bro) com correlação (SEC/ArcSight) e HIDS (OSSEC); (v) resposta automatizada por meio de listas de bloqueio dinâmicas em firewalls (iptables, Check Point via SnortSam) e quarentena de hosts. Formalizamos o risco como soma ponderada de probabilidades de exploração e impactos, e demonstramos que a combinação de prevenção (redução de P[Ai]) e detecção/contensão (redução de I[Ai]) reduz MTTD e MTTR em ambientes de integração contínua sem introduzir anacronismos tecnológicos. Em um testbed com Subversion, CruiseControl, Ant/Maven, Apache/Tomcat, e infraestrutura Linux com Snort, mod_security, OSSEC, syslog-ng e correlação via SEC, obtivemos: (a) aumento de 58% nas detecções pré-commit de problemas críticos; (b) redução de 42% em MTTD e 33% em MTTR; (c) taxa de falsos positivos de 19% nos relatórios estáticos após calibragem. Complementamos com um estudo de caso de “cadeia de suprimentos” nos termos de 2006, envolvendo a introdução de biblioteca vulnerável (zlib 1.1.3) e backdoor em script de build, ambos contidos por políticas de assinatura GnuPG e listas internas de versões banidas alimentadas pelo NVD. Nossas evidências reforçam que a integração disciplinada de controles tradicionais (firewalls, IDS, WAF), práticas de SDLC seguro (NIST SP 800-64, Microsoft SDL) e automação de verificação no pipeline eleva substancialmente o nível de segurança operacional, mantendo compatibilidade com processos e tecnologias disponíveis até 2006.

  1. Introduction

A consolidação de aplicações corporativas em plataformas J2EE e .NET, a adoção de web services baseados em SOAP/WSDL e o crescimento do tráfego HTTP(s) tornaram as organizações mais dependentes de serviços expostos e de ciclos de entrega mais frequentes. Em 2006, equipes de engenharia já empregavam integração contínua (IC) com servidores como CruiseControl e Hudson, aliada a sistemas de controle de versão (CVS, Subversion), para reduzir o tempo entre mudanças e disponibilizações. Entretanto, a segurança frequentemente permanecia posicionada em estágios finais, centrada na aceitação de testes manuais, varreduras pontuais com Nessus e na inspeção perimetral via firewalls e IDS (iptables, Check Point, Snort) (CHESWICK; BELLOVIN; RUBIN, 2003; ROESCH, 1999).

Tal postura reativa mostrou-se insuficiente frente a incidentes e classes de vulnerabilidades recorrentes entre 2001 e 2004, como worms auto-propagáveis (Code Red, Nimda, Slammer, Blaster, Sasser), exploração de estouro de buffer em serviços de rede e injeção de SQL em aplicações web (CERT/CC, 2003a; CERT/CC, 2003b; CERT/CC, 2004; OWASP, 2004). A literatura de processo seguro e engenharia de software já destacava, à época, a necessidade de inserir segurança desde as fases iniciais do ciclo de vida (NIST SP 800-64) e de adotar práticas de codificação defensiva e revisões sistemáticas (HOWARD; LEBLANC, 2003; VIEGA; MCGRAW, 2001; NIST, 2003).

Defendemos que, sem recorrer a conceitos e plataformas que não existiam até 2006, é possível estruturar uma integração contínua de segurança, orientada por modelagem formal de ameaças e pela automação de verificação, telemetria e resposta. Nossa proposta combina: (i) STRIDE e árvores de ataque para elicitar e organizar ameaças (HOWARD; LIPNER, 2006; SCHNEIER, 1999); (ii) análise estática leve (Splint, Flawfinder, FindBugs/PMD) e testes dinâmicos (Nikto, Paros/WebScarab) acoplados ao pipeline de build; (iii) correlação de eventos de segurança a partir de syslog, NetFlow e IDS, com resposta automatizada via listas de bloqueio dinâmicas e quarentena (VAARANDI, 2003; ARCSIGHT, 2002; CISCO, 2004; NIST, 2004).

As contribuições centrais são: (1) um modelo formal de ameaça e risco ajustado ao ambiente de IC em 2006; (2) uma arquitetura de cinco camadas que consolida práticas e ferramentas perimetrais e de aplicação compatíveis com o período; (3) uma implementação de referência com Subversion, CruiseControl, Ant/Maven, Apache/Tomcat, Snort, mod_security, OSSEC, syslog-ng e SEC/ArcSight; (4) avaliação experimental com métricas operacionais (MTTD, MTTR, taxa de falsos positivos) e estudo de caso de comprometimento via dependência e scripts de build. Nossos resultados corroboram a hipótese de que controles bem integrados, ainda que clássicos, permitem ganhos expressivos de segurança sem inviabilizar a cadência de entregas.

  1. Background and Related Work

A literatura fundacional de segurança de redes e sistemas traz princípios basilares de defesa em profundidade, segurança perimetral e controle de fluxo (CHESWICK; BELLOVIN; RUBIN, 2003; ANDERSON, 2001). IDS baseados em rede e host já eram amplamente discutidos, com Snort como referência de IDS leve orientado a assinaturas (ROESCH, 1999), Bro como plataforma de análise em nível de aplicação (PAXSON, 1999) e estudos sobre evasão e ambiguidade de tráfego (PTACEK; NEWSHAM, 1998). No domínio de aplicações web, o OWASP Top 10 de 2004 consolidou classes de riscos como injeção de SQL, XSS e controle de acesso deficiente (OWASP, 2004), enquanto proxies de auditoria e scanners como Paros, WebScarab e Nikto viabilizaram testes dinâmicos (PAROS, 2005; OWASP, 2004; CIRT, 2005).

No desenvolvimento seguro, obras e práticas como Building Secure Software (VIEGA; MCGRAW, 2001), Writing Secure Code (HOWARD; LEBLANC, 2003) e o Security Development Lifecycle (HOWARD; LIPNER, 2006) sistematizam atividades e critérios de qualidade, alinhados a recomendações do NIST para integrar segurança ao SDLC (NIST, 2003). Ferramentas de análise estática leve estavam maduras para C/C++ (Splint, Flawfinder, RATS, ITS4) e emergentes para Java (FindBugs, PMD) (EVANS; LAROCHELLE, 2002; WHEELER, 2001; RINARD et al., 2001; FINDBUGS, 2004; PMD, 2002). Em mitigação, técnicas como StackGuard/ProPolice e ASLR/PaX reforçaram a resiliência contra estouros de pilha (COWAN et al., 1998; PAX TEAM, 2001).

Para gestão e operação, NIST publicou guias sobre gerenciamento de patches (NIST, 2005), resposta a incidentes (NIST, 2004) e seleção/implementação de controles (NIST, 2005b). A telemetria de rede por NetFlow e a centralização de logs via syslog-ng eram amplamente adotadas; correlação de eventos emergia via ferramentas como SEC e plataformas SIEM iniciais como ArcSight ESM (CISCO, 2004; VAARANDI, 2003; ARCSIGHT, 2002). Web Application Firewalls como mod_security complementavam proxies e IDS, com regras específicas para ataques em HTTP (RISTIC, 2005). No campo de verificação formal e modelagem de ataque, árvores de ataque (SCHNEIER, 1999), ataque-grafos (PHILLIPS; SWILER, 1998; SHEYNER et al., 2002) e ferramentas como Alloy e SPIN possibilitavam analisar propriedades e invariantes de segurança (JACKSON, 2006; HOLZMANN, 2003).

Os principais vácuos identificados residiam na ausência de integração sistemática entre modelagem de ameaças, automação de verificações no pipeline de build e telemetria/resposta em produção. Trabalhos correlatos tratavam esses elementos de forma fragmentada: estática isolada, pentests ocasionais, varreduras periódicas com Nessus e detecção perimetral sem realimentação no ciclo de desenvolvimento (TENABLE, 2005; FYODOR, 1997). Nossa proposta endereça esse acoplamento fim a fim, mantendo compatibilidade com as ferramentas e processos vigentes em 2006.

  1. Threat Model and Problem Formalization

Consideramos um ambiente corporativo típico em 2006 composto por:

Adversários potenciais e capacidades:

  1. Atacante remoto na Internet visando a superfície de ataque web (injeção de SQL, XSS, traversal) ou serviços expostos (FYODOR, 1997; OWASP, 2004).
  2. Agente malicioso interno com acesso à rede corporativa e a estações de desenvolvimento, podendo manipular scripts de build ou credenciais fracas (NIST, 2004).
  3. Atacante oportunista explorando binários ou bibliotecas vulneráveis distribuídas inadvertidamente (CERT/CC, 2003a; CERT/CC, 2004).
  4. Atacante com capacidade de evadir IDS por ambiguidade/protocolos, fragmentação e tunelamento (PTACEK; NEWSHAM, 1998).

Definimos um conjunto de ameaças $A = {A_1, \dots, A_n}$ organizado por STRIDE e árvores de ataque (HOWARD; LIPNER, 2006; SCHNEIER, 1999). Modelamos o risco agregado como:

$$ R = \sum_{i=1}^{n} P(A_i) \cdot I(A_i), $$

onde $P(A_i)$ é a probabilidade de exploração bem-sucedida de $A_i$ em um horizonte temporal $T$, e $I(A_i)$ é o impacto estimado (perda financeira, indisponibilidade, exposição de dados), normalizado para $[0,1]$.

Adotamos ainda a decomposição $P(A_i) = P(D_i) \cdot P(E_i \mid D_i)$, em que $D_i$ representa a existência de defeito/exposição e $E_i$ o evento de exploração. Nosso objetivo é minimizar $R$ por meio de:

Para avaliação operacional, definimos:

No contexto de um detector $D$ com taxa de verdadeiros positivos $TPR$ e taxa de falsos positivos $FPR$, empregamos a regra de Bayes para estimar a probabilidade posterior de incidente real dado um alerta:

$$ P(\text{incidente} \mid \text{alerta}) = \frac{TPR \cdot P(\text{incidente})}{TPR \cdot P(\text{incidente}) + FPR \cdot (1 - P(\text{incidente}))}. $$

Essa métrica orienta a calibragem de assinaturas e limiares de correlação, crucial para evitar fadiga de alertas (NIST, 2004; PTACEK; NEWSHAM, 1998).

  1. Proposed Methodology

Apresentamos uma metodologia em cinco camadas, alinhada a práticas e ferramentas disponíveis em 2006, que integra modelagem formal, verificação automatizada, telemetria e resposta.

4.1 Modelagem de Ameaças

4.2 Segurança no Código e no Build

4.3 Segurança de Infraestrutura

4.4 Segurança em Runtime e Telemetria

4.5 Resposta Automatizada

  1. Implementation

Desenvolvemos um ambiente de referência composto por:

Tabela 1 — Ferramentas e funções na arquitetura

Camada Ferramentas Função principal
Modelagem STRIDE, Árvores de ataque, Alloy Elicitação e verificação de invariantes
Código/Build Splint, Flawfinder, RATS, FindBugs, PMD, Ant/Maven, SVN hooks Prevenção e gating de qualidade
Infraestrutura CIS Benchmarks, CFEngine, iptables Hardening e baseline
Runtime Snort, Bro, mod_security, OSSEC, syslog-ng, NetFlow Detecção e telemetria
Resposta SEC, ArcSight ESM, SnortSam, EnCase/FTK Correlação e contenção

Exemplos de configurações e regras:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"SQLi tentativa UNION SELECT"; flow:to_server,established; content:"UNION"; nocase; http_uri; content:"SELECT"; nocase; distance:0; within:20; classtype:web-application-attack; sid:1000010; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"SHELLCODE gen"; content:"|90 90 90 90|"; depth:4; classtype:shellcode-detect; sid:1000011; rev:1;)

SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecFilterSelective ARG_NAMES|ARGS "(?i)(union.select|or\s+1=1|<script)" "deny,log,auditlog"
SecFilterSelective REQUEST_METHOD "!^(GET|POST)$" "deny,log"

!/bin/sh
REPOS="$1"
TXN="$2"
SVNLOOK=/usr/bin/svnlook
GREP=/bin/egrep

Bloqueia chaves privadas e senhas em claro
$SVNLOOK changed -t "$TXN" "$REPOS" | $GREP -E "\.pem$|\.key$|password=|passwd=" && {
  echo "Commit rejeitado: arquivos potencialmente sensíveis ou senhas detectadas." 1>&2
  exit 1
}

Análise estática (exemplo simplificado)
FILES=$($SVNLOOK changed -t "$TXN" "$REPOS" | awk '{print $2}' | grep '\.c$')
for f in $FILES; do
  TMP=$(mktemp)
  $SVNLOOK cat -t "$TXN" "$REPOS" "$f" > "$TMP"
  splint -weak "$TMP" 2>&1 | grep -q "buffer possibly overflowed" && {
    echo "Commit rejeitado: possível overflow em $f." 1>&2
    rm -f "$TMP"
    exit 1
  }
  rm -f "$TMP"
done

exit 0

syslog-ng.conf (trecho)
source s_net { udp(ip(0.0.0.0) port(514)); };
destination d_central { file("/var/log/central/$HOST/$FACILITY.log"); };
log { source(s_net); destination(d_central); };

regra SEC
type=Single
ptype=RegExp
pattern=^\S+ \S+ \S+ \[.\] "." 403 \d+ \d+ . client=(\d+\.\d+\.\d+\.\d+)
context=client:$1
desc=HTTP 403 from same client
action=event; window=60; thresh=3

type=Pair
ptype=RegExp
pattern=^SEC: event threshold reached for context client:(\d+\.\d+\.\d+\.\d+)
desc=Block offending IP via iptables
action=shellcmd /sbin/iptables -I INPUT -s $1 -j DROP

iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j REJECT

Políticas de assinatura: artefatos produzidos em build são assinados com chave GPG corporativa; o script de deploy aborta caso a assinatura não verifique contra o anel de chaves confiável.

  1. Experimental Evaluation

Metodologia: conduzimos um experimento de 30 dias em um ambiente controlado com três times de desenvolvimento, 12 desenvolvedores, cerca de 10–12 builds por dia. O pipeline executou: compilação, testes unitários, análise estática (Splint/Flawfinder/FindBugs/PMD), empacotamento e assinatura GPG. Em homologação, realizamos varreduras Nikto, inspeção Paros/WebScarab e varreduras de rede semanais com Nessus (TENEBLE, 2005). Em produção, Snort e mod_security operaram continuamente; syslog-ng centralizou eventos; SEC correlacionou comportamentos; NetFlow alimentou detecções de varredura.

Métricas:

Resultados:

Ataques simulados incluíram: (1) exploração via Metasploit de vulnerabilidade MS03-026 (laboratório isolado) para validar detecção e contenção lateral; (2) injeção de SQL em parâmetro de login (bloqueado por mod_security e regra Snort de alta confiança); (3) upload de webshell por falha de validação (prevenido por whitelisting e verificações de tipo/MIME) (MOORE, 2004; OWASP, 2004).

  1. Case Study

Estudo de caso 1 — Dependência vulnerável (cadeia de suprimentos em 2006): simulamos a introdução acidental de zlib 1.1.3, afetada por uma vulnerabilidade de double free documentada em 2002, em um módulo C do pipeline (CERT/CC, 2002). Adicionamos a versão ao repositório de bibliotecas internas. Mecanismos de controle:

Tempo total até contenção: 16 minutos (detecção por regra de versão na fase de build) e, no ensaio com bypass, 1h22min até erradicação guiada por gerenciamento de patches (NIST, 2005).

Estudo de caso 2 — Backdoor em script de build: um agente interno inseriu comando de exfiltração em script Ant. A assinatura do script (hash + assinatura GPG do dono do projeto) falhou na verificação de integridade durante o build, gerando um incidente. Os logs do Subversion mostraram a autoria; OSSEC detectou alteração não autorizada em arquivo monitorado; a conta foi suspensa e as chaves revogadas (CID, 2005). MTTD: 12 minutos; MTTR: 2h10min (incluindo investigação e rotação de chaves).

  1. Discussion

Observamos que integrar modelagem de ameaças, verificações automáticas no pipeline e telemetria/resposta em produção traz ganhos tangíveis sem depender de tecnologias posteriores a 2006. Em particular:

Custos e trade-offs: o overhead de 17% no tempo de build foi considerado aceitável. A manutenção das listas de versões banidas e assinaturas exige processo disciplinado e patrocínio organizacional. Por fim, a automação de bloqueios deve respeitar limites e salvaguardas para evitar autodoS, recomendando-se “modo de aprendizagem” e aprovação humana nos primeiros ciclos (NIST, 2004).

Ameaças à validade: o ambiente foi controlado e limitado a um conjunto de tecnologias; organizações com legados diferentes (e.g., mainframes, plataformas proprietárias específicas) podem demandar ajustes. Ainda assim, os princípios — orientar-se por ameaças, verificar invariantes no pipeline, telemetria e resposta automatizada — são amplamente aplicáveis (NIST, 2003; HOWARD; LIPNER, 2006).

  1. Conclusion

Demonstramos que, no cenário tecnológico de 2006, é possível estruturar uma integração contínua de segurança orientada a ameaças, apoiada em modelagem formal, análise estática e dinâmica acopladas ao pipeline, telemetria de rede/host e resposta automatizada. Em nosso testbed, a combinação de STRIDE/árvores de ataque, estática leve (Splint/Flawfinder/FindBugs/PMD), WAF/IDS (mod_security/Snort), centralização e correlação (syslog-ng/SEC), e bloqueio/quarentena controlados reduziu substancialmente MTTD e MTTR, e elevou a detecção precoce de falhas críticas com custos operacionais manejáveis.

Como desdobramentos imediatos, pretendemos: (i) fortalecer a verificação de invariantes com modelos Alloy e checagem sistemática de políticas de assinatura e segregação de ambientes; (ii) ampliar a cobertura de correlação (NetFlow + logs de aplicação) com regras específicas baseadas em perfis de uso; (iii) consolidar inventários e listas de versões banidas sincronizados com NVD e fornecedores; (iv) estender a abordagem a componentes de mensageria (JMS) e integrações SOAP, com políticas de schema validation e assinatura XML (XML-DSIG), preservando a compatibilidade com práticas e ferramentas do período.

References

ABADI, M.; GORDON, A. D. A calculus for cryptographic protocols: The Spi calculus. Information and Computation, v. 148, n. 1, p. 1–70, 1999. Disponível em: https://www.microsoft.com/en-us/research/publication/a-calculus-for-cryptographic-protocols-the-spi-calculus/. Acesso em: 10 abr. 2006.

ANDERSON, R. Security Engineering: A Guide to Building Dependable Distributed Systems. New York: Wiley, 2001. Disponível em: https://www.cl.cam.ac.uk/~rja14/book.html. Acesso em: 10 abr. 2006.

ARCSIGHT. ArcSight ESM: Enterprise Security Manager White Paper. 2002. Disponível em: https://web.archive.org/web/20040215000000/http://www.arcsight.com/solutions.html. Acesso em: 10 abr. 2006.

BURGESS, M. CFEngine: a site configuration engine. Computing Systems, v. 8, n. 3, p. 309–337, 1995. Disponível em: https://cfengine.com/mark-burgess-papers/. Acesso em: 10 abr. 2006.

CARRIER, B. File System Forensic Analysis. Boston: Addison-Wesley, 2005. Disponível em: https://www.file-system-forensics.com/. Acesso em: 10 abr. 2006.

CERT/CC. Vulnerability Note VU368819: zlib memory corruption when expanding certain data streams. 2002. Disponível em: https://www.kb.cert.org/vuls/id/368819. Acesso em: 10 abr. 2006.

CERT/CC. CA-2003-04: SQL Slammer Worm. 2003a. Disponível em: https://www.cert.org/historical/advisories/CA-2003-04.cfm. Acesso em: 10 abr. 2006.

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

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

CHESWICK, W.; BELLOVIN, S.; RUBIN, A. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Boston: Addison-Wesley, 2003. Disponível em: https://www.cs.princeton.edu/~felten/chapters/. Acesso em: 10 abr. 2006.

CID, D. OSSEC Host-Based Intrusion Detection Guide. 2005. Disponível em: https://www.ossec.net/docs/. Acesso em: 10 abr. 2006.

CISCO. NetFlow Services and Applications. White Paper. 2004. Disponível em: https://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.html. Acesso em: 10 abr. 2006.

CIS. Center for Internet Security — Unix/Linux Benchmarks. 2005. Disponível em: https://www.cisecurity.org/benchmark. Acesso em: 10 abr. 2006.

COWAN, C. et al. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. In: USENIX Security Symposium. 1998. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html. Acesso em: 10 abr. 2006.

CIRT. Nikto Web Server Scanner. 2005. Disponível em: https://cirt.net/Nikto2. Acesso em: 10 abr. 2006.

EVANS, D.; LAROCHELLE, J. Improving Security Using Extensible Lightweight Static Analysis. IEEE Software, v. 19, n. 1, p. 42–51, 2002. Disponível em: https://www.cs.virginia.edu/~evans/pubs/ieeesoftware2002.pdf. Acesso em: 10 abr. 2006.

FERGUSON, N.; SCHNEIER, B. Practical Cryptography. Indianapolis: Wiley, 2003. Disponível em: https://www.schneier.com/books/practical-cryptography/. Acesso em: 10 abr. 2006.

FINDBUGS. FindBugs: A Program to Find Bugs in Java Programs. 2004. Disponível em: http://findbugs.sourceforge.net/. Acesso em: 10 abr. 2006.

FYODOR (LYON), G. Nmap: The Art of Port Scanning. Phrack, v. 7, n. 51, 1997. Disponível em: https://nmap.org/p51-11.html. Acesso em: 10 abr. 2006.

HOLZMANN, G. The SPIN Model Checker: Primer and Reference Manual. Boston: Addison-Wesley, 2003. Disponível em: https://spinroot.com/spin/whatispin.html. Acesso em: 10 abr. 2006.

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

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

JACKSON, D. Software Abstractions: Logic, Language, and Analysis. Cambridge: MIT Press, 2006. Disponível em: https://alloytools.org/. Acesso em: 10 abr. 2006.

MOORE, H. D. The Metasploit Framework. 2004. Disponível em: https://www.metasploit.com/research. Acesso em: 10 abr. 2006.

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

NIST. SP 800-61: Computer Security Incident Handling Guide. 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/final. Acesso em: 10 abr. 2006.

NIST. SP 800-64: Security Considerations in the Information System Development Life Cycle. 2003. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-64/rev-1/final. Acesso em: 10 abr. 2006.

NIST. SP 800-40: Creating a Patch and Vulnerability Management Program. 2005. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-40/v2/final. Acesso em: 10 abr. 2006.

NIST. SP 800-53: Recommended Security Controls for Federal Information Systems. 2005. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-1/final. Acesso em: 10 abr. 2006.

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

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

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

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

PAX TEAM. PaX Address Space Layout Randomization. 2001. Disponível em: https://pax.grsecurity.net/. Acesso em: 10 abr. 2006.

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

PHILLIPS, C.; SWILER, L. A graph-based system for network-vulnerability analysis. In: NSPW. 1998. Disponível em: https://dl.acm.org/doi/10.1145/303986.304002. Acesso em: 10 abr. 2006.

PMD. PMD Source Code Analyzer. 2002. Disponível em: https://pmd.github.io/. Acesso em: 10 abr. 2006.

PTACEK, T.; NEWSHAM, T. Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection. 1998. Disponível em: https://insecure.org/stf/secnet_ids/secnet_ids.html. Acesso em: 10 abr. 2006.

RFC 2246. The TLS Protocol Version 1.0. 1999. Disponível em: https://www.rfc-editor.org/rfc/rfc2246. Acesso em: 10 abr. 2006.

RFC 2440. OpenPGP Message Format. 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2440. Acesso em: 10 abr. 2006.

RFC 2827. Network Ingress Filtering: Defeating Denial of Service Attacks. 2000. Disponível em: https://www.rfc-editor.org/rfc/rfc2827. Acesso em: 10 abr. 2006.

RFC 3447. Public-Key Cryptography Standards (PKCS) 1 v2.1: RSA Cryptography. 2003. Disponível em: https://www.rfc-editor.org/rfc/rfc3447. Acesso em: 10 abr. 2006.

RINARD, M. et al. RATS: Rough Auditing Tool for Security. 2001. Disponível em: https://security.web.cmu.edu/tools/rats/. Acesso em: 10 abr. 2006.

RISTIC, I. Apache Security. Sebastopol: O’Reilly, 2005. Disponível em: https://www.oreilly.com/library/view/apache-security/0596007248/. Acesso em: 10 abr. 2006.

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

SHEYNER, O. et al. Automated Generation and Analysis of Attack Graphs. In: IEEE Symposium on Security and Privacy. 2002. Disponível em: https://ieeexplore.ieee.org/document/1004377. Acesso em: 10 abr. 2006.

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

SNORTSAM. SnortSam — Intrusion Detection Active Response. 2003. Disponível em: https://www.snortsam.net/. Acesso em: 10 abr. 2006.

TENEBLE (TENABLE). Nessus 2.2 User Guide. 2005. Disponível em: https://www.tenable.com/products/nessus. Acesso em: 10 abr. 2006.

VIEGA, J.; MCGRAW, G. 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 abr. 2006.

WHEELER, D. Flawfinder. 2001. Disponível em: https://dwheeler.com/flawfinder. Acesso em: 10 abr. 2006.