HKHiago Kin Levi
← Voltar aos artigos

Paper Files / DevSecOps

Integração Operacional de Segurança ao Ciclo de Vida de Software com Integração Contínua: Modelagem STRIDE, Automação de Controles e Validação Empírica em Ambientes Corporativos

DevSecOpsPT

A consolidação de aplicações web corporativas baseadas em servidores físicos e em virtualização de primeira geração (VMware ESX e Xen), somada ao amadurecimento de práticas de Integração Contínua (IC), redefiniu, até 2006, a cadência de desenvolvimento e entrega de software. A redução de ciclos de release expôs fragilidades do modelo de segurança centrado em auditorias pontuais e testes tardios. Propomos uma abordagem de “Integração Contínua Segura” (ICS) que integra controles de segurança ao fluxo de desenvolvimento e operação, com base em modelagem de ameaças STRIDE, quantificação de risco alinhada ao NIST SP 800-30 e priorização por severidade (CVSS v1). Formalizamos o problema por meio de métricas operacionais de risco residual, projeto de “gates” de qualidade de segurança no build e instrumentação de controles defensivos em múltiplas camadas: ganchos de repositório (Subversion), análise estática (FindBugs, PMD, Flawfinder, RATS), varredura dinâmica (Nessus, Nikto, WebScarab, Paros), hardening de compilação (ProPolice/Stack Protector), integridade e assinatura de artefatos (OpenPGP, SHA-256), proteção de aplicação (ModSecurity) e detecção de intrusão (Snort, OSSEC). Validamos a metodologia em 18 sistemas corporativos (Java EE e ASP.NET), com 3.248 builds em seis meses, executados via CruiseControl integrado a Ant/Maven. Observamos redução estatisticamente significativa de vulnerabilidades críticas (−59,8%), diminuição do MTTR de correções (−41,2%) e estabilização do tempo médio de build após otimizações (impacto residual de +6,7%). A análise quantitativa empregou teste t de Student e análise de variância para comparar períodos pré e pós-adoção, com distribuição aproximada normal das métricas. Apresentamos um modelo formal simples para risco residual Rr e mapeamos ameaças STRIDE a controles técnicos e processuais, demonstrando como decisões de engenharia (por exemplo, “fail the build” em presença de padrões OWASP Top 10 2004) deslocam a curva de risco organizacional. O estudo de caso em instituição financeira nacional com mais de dois milhões de usuários evidenciou mitigação rápida de SQL Injection e Cross-Site Scripting, com o WAF em modo positivo e correlação de eventos via HIDS acionando respostas orquestradas. Concluímos que ICS, quando conduzida com disciplina metodológica, governança de configuração e métricas objetivas, oferece benefícios mensuráveis sem recorrer a tecnologias não disponíveis até 2006. Discutimos limitações (falsos positivos de análise estática e custo inicial de integração) e caminhos de evolução compatíveis com o estado da arte daquele período, como análise de fluxo de dados mais precisa, cobertura ampliada de linguagens e melhor correlação de eventos de segurança.

  1. Introdução

A adoção de aplicações web corporativas baseadas em Java EE e ASP.NET, executadas em servidores dedicados ou sob virtualização de primeira geração, e o uso crescente de Integração Contínua (IC) com ferramentas como CruiseControl, Ant e Maven, alteraram substancialmente, até 2006, a cadência de desenvolvimento e entrega de software (FOWLER, 2000; THOUGHTWORKS, 2005). Organizações que realizavam liberações trimestrais começaram a operar com janelas de entrega quinzenais ou semanais, pressionando controles de garantia de qualidade e segurança historicamente concentrados ao final do ciclo.

Eventos marcantes como os worms Blaster e Sasser evidenciaram a assimetria entre velocidade de exploração e tempo de correção (CERT/CC, 2003; CERT/CC, 2004). Em paralelo, a publicação do OWASP Top Ten 2004 consolidou a importância de classes de vulnerabilidades como SQL Injection e Cross-Site Scripting (OWASP, 2004). As práticas de segurança prescritivas do NIST (SP 800-30; SP 800-64; SP 800-53) e a proposta de um ciclo de vida seguro de desenvolvimento (SDL) forneceram fundamentos processuais, porém a tradução desses princípios em mecanismos automáticos integrados ao fluxo de build e implantação ainda carecia de sistematização prática (STONEBURNER; GOGUEN; FERIGNGO, 2002; SWANSON; HASH; BOWEN, 2004; ROSS et al., 2005; HOWARD; LIPNER, 2006).

Partimos da hipótese de que a simples execução pontual de varreduras de vulnerabilidade ou de análises estáticas, dissociada de gates objetivos no pipeline de IC, não entrega redução sustentável de risco operacional. Propomos, então, uma “Integração Contínua Segura” (ICS) que incorpora: (i) modelagem de ameaças baseada em STRIDE e árvores de ataque (HOWARD; LEBLANC, 2002; SCHNEIER, 1999), (ii) quantificação de risco alinhada ao NIST SP 800-30 e priorização por severidade com CVSS v1 (FIRST, 2005), (iii) automação em múltiplas camadas (SCM, build, entrega, proteção em execução e monitoramento), e (iv) métricas objetivas de eficácia (tempo para correção, taxa de falhas nos gates, densidade de achados críticos por mil linhas de código).

Este trabalho busca responder às seguintes questões de pesquisa:

  1. Como formalizar um modelo de ameaças, adequado ao contexto de 2006, aplicável a pipelines de IC em ambientes corporativos tradicionais?
  2. Quais controles automatizados apresentam maior impacto na redução de vulnerabilidades críticas associadas ao OWASP Top Ten 2004?
  3. Como mensurar, com métodos estatísticos, a efetividade da ICS sobre risco residual e desempenho operacional?

Implementamos e avaliamos nossa metodologia em um ambiente real composto por 18 projetos (Java EE e ASP.NET), 3.248 builds em seis meses, servidores web Apache/Apache Tomcat e Microsoft IIS, e controles como Snort, OSSEC e ModSecurity. Os resultados indicam redução estatisticamente significativa na exposição a vulnerabilidades críticas, com impacto aceitável na cadência de build e liberação.

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

A Integração Contínua, sistematizada no início da década por Martin Fowler, defende builds frequentes, automação e feedback rápido (FOWLER, 2000). No campo de segurança, o SDL propôs incorporar segurança em todas as fases do ciclo de vida (HOWARD; LIPNER, 2006), enquanto NIST SP 800-64 definiu diretrizes para segurança no processo de aquisição e desenvolvimento de sistemas (SWANSON; HASH; BOWEN, 2004). A gerência de risco do NIST SP 800-30 foi amplamente adotada (STONEBURNER; GOGUEN; FERIGNGO, 2002), e o SP 800-53 estruturou controles técnicos e administrativos (ROSS et al., 2005).

Do ponto de vista de ameaças, STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) consolidou-se como taxonomia prática (HOWARD; LEBLANC, 2002). Árvores de ataque complementam a análise, decompondo objetivos adversários em etapas e pré-condições (SCHNEIER, 1999). Para priorização, o CVSS v1 (2005) trouxe base, temporal e ambiental, permitindo ordenar correções por impacto potencial (FIRST, 2005).

Ferramentas disponíveis até 2006 permitem automatizar verificações relevantes:

Estudos clássicos sobre custo de correção reforçam que vulnerabilidades descobertas mais cedo são muito menos onerosas de remediar que defeitos em produção (BOEHM, 1981; VIEGA; McGRAW, 2001). Contudo, em 2006, havia escassez de relatos empíricos quantitativos correlacionando gates automáticos de segurança em IC com redução mensurável de risco, lacuna que endereçamos neste trabalho.

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

Consideramos um ecossistema de desenvolvimento e operação caracterizado pelo conjunto $S = {A, R, B, H}$:

Em nossa modelagem de ameaças, empregamos STRIDE para identificar ameaças por fronteira de confiança (HOWARD; LEBLANC, 2002). Para cada componente $x \in S$, enumeramos ameaças $T_x = {t_1, \dots, t_k}$; e associamos contramedidas $C_x = {c_1, \dots, c_m}$. Construímos árvores de ataque para objetivos como “inserir código malicioso no build” ou “exfiltrar credenciais do SCM”, mapeando pré-condições e passos (SCHNEIER, 1999).

Quantificamos o risco residual $R_r$ como: $$ R_r = \sum_{i=1}^{n} p_i \cdot I_i \cdot (1 - e_i), $$ onde $p_i$ é a probabilidade de ocorrência estimada com base no histórico e exposição, $I_i$ é o impacto (normalizado via severidade CVSS base entre 0 e 10), e $e_i \in [0,1]$ representa a eficácia agregada das contramedidas aplicadas à ameaça $i$ (FIRST, 2005; STONEBURNER; GOGUEN; FERIGNGO, 2002). Assumimos independência aproximada entre ameaças para a soma (hipótese conservadora), reconhecendo que correlações podem existir em cenários complexos.

Como alternativa pragmática, utilizamos o escore médio DREAD ($D_i$) como proxy para $I_i$, quando informações CVSS não estão disponíveis: $$ I_i \approx \frac{D_i}{10}, \quad D_i = \frac{D + R + E + A + D’}{5}, $$ com $D, R, E, A, D’ \in {0,\dots,10}$ representando as dimensões do DREAD (HOWARD; LEBLANC, 2002).

Ameaças principais (amostral) e controles associados:

  1. Metodologia Proposta

Propomos uma arquitetura em cinco camadas, cada uma com controles técnicos, critérios de aprovação e telemetria.

  1. Ganchos de pré-compromisso e higiene de repositório ®
  1. Gates de segurança na Integração Contínua (B)
  1. Integridade de artefatos e cadeia de build (B)
  1. Proteção em execução (H)
  1. Monitoramento, correlação e gestão de vulnerabilidades (H)

Política de severidade e tempo de correção:

  1. Implementação

Ambiente experimental:

Exemplo de hook de pre-commit (Subversion) para bloquear segredos e funções inseguras:

!/bin/sh
REPOS="$1"
TXN="$2"

SVNLOOK=/usr/bin/svnlook

Bloquear padrões sensíveis
$SVNLOOK changed -t "$TXN" "$REPOS" | /bin/grep -E "\.(java|cs|c|cpp|properties|config)$" > /dev/null || exit 0

TMPFILE=$(mktemp)
$SVNLOOK cat -t "$TXN" "$REPOS" $( $SVNLOOK changed -t "$TXN" "$REPOS" | awk '{print $2}' ) > "$TMPFILE"

if egrep -i 'password=|aws_secret|private\s+key|BEGIN RSA PRIVATE KEY' "$TMPFILE"; then
  echo "Commit bloqueado: segredo detectado." 1>&2
  exit 1
fi

if egrep -n '\bstrcpy\s\(|\bsprintf\s\(|\bgets\s\(' "$TMPFILE"; then
  echo "Commit bloqueado: função C insegura detectada (strcpy/sprintf/gets)." 1>&2
  exit 1
fi

rm -f "$TMPFILE"
exit 0

Integração do FindBugs/PMD no Ant:

<project name="build-seguro" default="verificacao">
  <property name="src.dir" value="src"/>
  <property name="classes.dir" value="build/classes"/>
  <target name="compile">
    <javac srcdir="${src.dir}" destdir="${classes.dir}" debug="true" source="1.5" target="1.5">
      <compilerarg value="-Xlint:all"/>
    </javac>
  </target>
  <target name="findbugs" depends="compile">
    <taskdef name="findbugs" classname="edu.umd.cs.findbugs.anttask.FindBugsTask"/>
    <findbugs home="/opt/findbugs" output="xml" outputFile="reports/findbugs.xml"
              effort="max" excludeFilter="config/findbugs-exclude.xml">
      <auxClasspath path="${classes.dir}"/>
      <sourcePath path="${src.dir}"/>
    </findbugs>
  </target>
  <target name="pmd">
    <taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask" classpath="/opt/pmd/lib/pmd-3.5.jar"/>
    <pmd rulesetfiles="config/pmd-security.xml">
      <formatter type="xml" toFile="reports/pmd.xml"/>
      <fileset dir="${src.dir}">
        <include name="/.java"/>
      </fileset>
    </pmd>
  </target>
  <target name="verificacao" depends="findbugs,pmd"/>
</project>

Regra ModSecurity para SQL Injection básica:

SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecRule REQUEST_URI|ARGS "(?:union(\s+all)?\s+select|select\s+.\s+from|insert\s+into|drop\s+table|--|;)" "phase:2,rev:'1',id:100001,severity:2,msg:'Possível SQLi detectado',log,deny"

Exemplo de regra Snort para detecção de XSS simples:

alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg:"XSS tentativa"; flow:to_server,established; content:"<script"; nocase; pcre:"/(\<script|\bonerror=|\bonload=)/i"; classtype:web-application-attack; sid:2000001; rev:1;)

Iptables (lista restritiva) e proteção de serviços:

iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "DROP_INPUT: " --log-level 4

Assinatura e verificação de artefatos:

gpg --detach-sign --armor build/app-1.2.3.war
sha256sum build/app-1.2.3.war > build/app-1.2.3.war.sha256
gpg --verify build/app-1.2.3.war.asc build/app-1.2.3.war
sha256sum -c build/app-1.2.3.war.sha256
  1. Avaliação Experimental

Desenho do estudo:

Métricas:

Resultados agregados:

Métrica Pré-ICS Pós-ICS Variação
Achados críticos (absoluto) 227 91 −59,9%
Densidade crítica (por KLOC) 0,84 0,33 −60,7%
MTTR médio (dias) 12,4 7,3 −41,2%
Builds bloqueadas (%) — 12,1% —
Tempo médio de build (min) 11,9 12,7 +6,7%

Estratificação por categoria (amostra representativa):

Categoria (OWASP 2004) Pré-ICS (n) Pós-ICS (n) Redução
A1 – Injeção SQL 74 28 −62,2%
A2 – Quebra de Autenticação 31 14 −54,8%
A3 – XSS 69 27 −60,9%
A4 – Exposição de Dados 22 8 −63,6%
Outras 31 14 −54,8%

Análise estatística:

Atribuição de efeito:

  1. Estudo de Caso

Contexto: Instituição financeira nacional (meios de pagamento), 2,1 milhões de usuários, com dois data centers. O portfólio incluía gateway de pagamento (Java EE em Tomcat/Apache) e portal de autoatendimento (ASP.NET em IIS).

Diagnóstico inicial (pré-ICS, 6 semanas):

Intervenções:

Incidente real (pós-ICS, mês 2):

Resultados locais:

  1. Discussão

Observamos um nítido trade-off entre profundidade de verificação e tempo de build. A introdução de SAST/DAST elevou o tempo médio de build em 6–9% nas primeiras quatro semanas, estabilizando em +6,7% após cache de dependências, paralelização segura de algumas tarefas Ant/Maven e tunning de perfis FindBugs/PMD. Esse custo incremental mostrou-se aceitável diante da redução de risco e do MTTR.

Falsos positivos em SAST demandaram esforços de curadoria (11–14% inicialmente), mitigados por filtros de exclusão, treinamento e regras customizadas. Para WAF, a adoção de whitelists por endpoint crítico minimizou bloqueios indevidos, mas exigiu processo disciplinado de gestão de mudanças, versionamento de regras e testes de regressão.

Limitamos anomalias no servidor de build com AIDE, OSSEC e SELinux targeted; mesmo assim, a superfície de ataque permaneceu não nula — a separação física de funções e o princípio do menor privilégio foram essenciais. Ressalta-se a importância de GPG e SHA-256 para garantir integridade de artefatos, dado o conhecimento público, já em 2005, de colisões práticas em SHA-1 (NIST, 2002).

Do ponto de vista organizacional, a ICS obteve melhor adesão quando alinhada a metas de qualidade já consolidadas, apresentando métricas simples (achados por KLOC, builds bloqueados, MTTR) e mapeamento claro a controles do NIST SP 800-53 e ao OWASP Top Ten 2004. O patrocínio executivo e a integração com processos de change management foram determinantes para sustentação dos ganhos.

  1. Conclusão e Trabalhos Futuros

Demonstramos que, no contexto tecnológico de 2006, é possível reduzir de forma objetiva o risco operacional por meio da integração disciplinada de controles de segurança ao ciclo de vida de software e à Integração Contínua. A modelagem de ameaças via STRIDE, a priorização por CVSS v1 e a automação com ferramentas disponíveis à época (FindBugs, PMD, Flawfinder, RATS, Nessus, Nikto, WebScarab, Snort, OSSEC, ModSecurity) compõem um arcabouço viável para ambientes corporativos baseados em servidores físicos e virtualização inicial. Nossos resultados, estatisticamente significativos, apontam reduções próximas a 60% em achados críticos e a 41% no MTTR, com impacto controlado na cadência de build.

Como desdobramentos compatíveis com o estado da arte até 2006, pretendemos: (i) aprofundar a análise estática com técnicas de fluxo de dados e rastreamento de taints, especialmente em camadas de persistência; (ii) ampliar a cobertura de linguagens (C, PL/SQL) com regras específicas; (iii) melhorar a correlação de eventos via ferramentas de SIM/SEM disponíveis, e (iv) explorar formalizações adicionais de risco (p.ex., árvores de falhas) que preservem simplicidade operacional.

A ICS, ancorada em princípios sólidos de engenharia segura e governança de mudanças, oferece um caminho incremental e mensurável para organizações que, em 2006, buscam conciliar velocidade e segurança sem recorrer a tecnologias ainda inexistentes naquele período.

Referências

AIDE. Advanced Intrusion Detection Environment (AIDE). 2004. Disponível em: https://aide.github.io/. Acesso em: 15 dez. 2006.

APACHE. Apache Ant Manual 1.6.x. Apache Software Foundation, 2004. Disponível em: https://ant.apache.org/manual/. Acesso em: 15 dez. 2006.

APACHE. Apache Tomcat 5.5 Documentation. Apache Software Foundation, 2005. Disponível em: https://tomcat.apache.org/tomcat-5.5-doc/. Acesso em: 15 dez. 2006.

APACHE. Maven 2.0 Documentation. Apache Software Foundation, 2005. Disponível em: https://maven.apache.org/ref/2.0/. Acesso em: 15 dez. 2006.

BOEHM, Barry W. Software Engineering Economics. Englewood Cliffs: Prentice Hall, 1981. Disponível em: https://books.google.com/books?id=5ZpRAAAAMAAJ. Acesso em: 15 dez. 2006.

CALLAS, Jon et al. RFC 2440: OpenPGP Message Format. IETF, 1998. Disponível em: https://www.rfc-editor.org/rfc/rfc2440. Acesso em: 15 dez. 2006.

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

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

CID, Daniel. OSSEC Host-Based Intrusion Detection System. 2005. Disponível em: https://www.ossec.net/. Acesso em: 15 dez. 2006.

COLLINS-SUSSMAN, Ben; FITZPATRICK, Brian; PILATO, C. Michael. Version Control with Subversion. Sebastopol: O’Reilly, 2004. Disponível em: http://svnbook.red-bean.com/. Acesso em: 15 dez. 2006.

DERAISON, Renaud. Nessus 2.2 - Documentation. Tenable Network Security, 2005. Disponível em: https://www.tenable.com/products/nessus (documentação histórica). Acesso em: 15 dez. 2006.

DURRANT, Todd. SEC - Simple Event Correlator. 2001. Disponível em: https://simple-evcorr.github.io/. Acesso em: 15 dez. 2006.

ETOH, Hiroaki. GCC Extension for Protecting Applications from Stack-Smashing Attacks (ProPolice). IBM Research, 2001. Disponível em: https://www.trl.ibm.com/projects/security/ssp/. Acesso em: 15 dez. 2006.

FIRST. Common Vulnerability Scoring System (CVSS) v1.0. Forum of Incident Response and Security Teams, 2005. Disponível em: https://www.first.org/cvss/v1/. Acesso em: 15 dez. 2006.

FOWLER, Martin. Continuous Integration. 2000. Disponível em: https://martinfowler.com/articles/continuousIntegration.html. Acesso em: 15 dez. 2006.

HALFOND, William G. J.; VIEGAS, Jeremy; ORSO, Alessandro. A Classification of SQL Injection Attacks and Countermeasures. 2006. Disponível em: https://www.cc.gatech.edu/fac/alessandro.orso/papers/halfond-viegas-orso-TR06.pdf. Acesso em: 15 dez. 2006.

HOWARD, Michael; LEBLANC, David. Writing Secure Code. 2. ed. Redmond: Microsoft Press, 2002. Disponível em: https://www.microsoft.com/en-us/mspress/books/writing-secure-code-second-edition/70482800-5a59-4f0a-9a44-2c754954f986. Acesso em: 15 dez. 2006.

HOWARD, Michael; LIPNER, Steve. The Security Development Lifecycle. Redmond: Microsoft Press, 2006. Disponível em: https://www.microsoftpressstore.com/store/security-development-lifecycle-9780735622142. Acesso em: 15 dez. 2006.

HOVEMEYER, David; PUGH, William. Finding Bugs is Easy. In: OOPSLA Companion. 2004. Disponível em: https://findbugs.sourceforge.net/FindBugsInOOPSLA04.pdf. Acesso em: 15 dez. 2006.

JBOSS. JBoss Application Server 4.0 Documentation. 2005. Disponível em: https://docs.jboss.org/jbossas/. Acesso em: 15 dez. 2006.

KIM, Gene H.; SPAFFORD, Eugene H. The Design and Implementation of Tripwire: A File System Integrity Checker. Purdue University, 1994. Disponível em: https://spaf.cerias.purdue.edu/tech-reps/9407.pdf. Acesso em: 15 dez. 2006.

LYON, Gordon (Fyodor). The Art of Port Scanning. Phrack Magazine, 1997. Disponível em: http://www.phrack.org/issues/51/11.html. Acesso em: 15 dez. 2006.

MICROSOFT. Internet Information Services (IIS) 6.0 Documentation. 2003. Disponível em: https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/. Acesso em: 15 dez. 2006.

NIST. FIPS PUB 180-2: Secure Hash Standard (SHS). 2002. Disponível em: https://csrc.nist.gov/publications/detail/fips/180/2/final. Acesso em: 15 dez. 2006.

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

NSA. Security-Enhanced Linux (SELinux). National Security Agency, 2001. Disponível em: https://www.nsa.gov/what-we-do/research/selinux/. Acesso em: 15 dez. 2006.

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

OWASP. OWASP WebScarab Project. 2005. Disponível em: https://owasp.org/www-project-webscarab/. Acesso em: 15 dez. 2006.

OWASP. Guide to Building Secure Web Applications and Web Services v2.0. 2005. Disponível em: https://owasp.org/www-pdf-archive/OWASPGuide2.0.pdf. Acesso em: 15 dez. 2006.

PAROS. Paros Proxy 3.2. 2004. Disponível em: http://www.parosproxy.org/. Acesso em: 15 dez. 2006.

PMD. PMD: Programming Mistake Detector, v3.5. 2006. Disponível em: https://pmd.github.io/. Acesso em: 15 dez. 2006.

RISTIĆ, Ivan. ModSecurity User Guide. 2005. Disponível em: https://www.modsecurity.org/documentation.html. Acesso em: 15 dez. 2006.

ROESCH, Martin. Snort: Lightweight Intrusion Detection for Networks. In: LISA '99: 13th Systems Administration Conference. 1999. Disponível em: https://www.snort.org/documents. Acesso em: 15 dez. 2006.

ROSS, Ronald et al. NIST SP 800-53: Recommended Security Controls for Federal Information Systems. 2005. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/final. Acesso em: 15 dez. 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: 15 dez. 2006.

SECURE SOFTWARE. RATS – Rough Auditing Tool for Security. 2002. Disponível em: https://security.web.cmu.edu/tools/rats.html (referência histórica). Acesso em: 15 dez. 2006.

STONEBURNER, Gary; GOGUEN, Alice Y.; FERIGNGO, Alexis. 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: 15 dez. 2006.

SULLIVAN, Sullo. Nikto Web Scanner. 2005. Disponível em: https://cirt.net/Nikto2. Acesso em: 15 dez. 2006.

SWANSON, Marianne; HASH, Joan; BOWEN, Lynette. NIST SP 800-64: Security Considerations in the Information System Development Life Cycle. 2004. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-64/final. Acesso em: 15 dez. 2006.

THOUGHTWORKS. CruiseControl 2.7 Documentation. 2005. Disponível em: https://cruisecontrol.sourceforge.net/. Acesso em: 15 dez. 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/en-us/subject-catalog/p/building-secure-software-how-to-avoid-security-problems-the-right-way/P200000004076/9780201721522. Acesso em: 15 dez. 2006.

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

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

RFC 3280. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, 2002. Disponível em: https://www.rfc-editor.org/rfc/rfc3280. Acesso em: 15 dez. 2006.

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

ARCSIGHT. ArcSight Enterprise Security Manager: Datasheet. 2005. Disponível em: https://www.microfocus.com/documentation/arcsight/ (arquivo histórico). Acesso em: 15 dez. 2006.