Integração Contínua de Segurança em Pipelines de Desenvolvimento (2006): Modelagem Formal de Ameaças e Resposta Automatizada em Ambientes Corporativos

1. Introduction

A consolidação de práticas de Integração Contínua (IC) no início dos anos 2000, impulsionada por ferramentas como CruiseControl e Subversion, alterou substancialmente a dinâmica de desenvolvimento de software corporativo, promovendo integrações frequentes, builds reprodutíveis e feedback acelerado (FOWLER, 2006; SUBVERSION, 2006). Em paralelo, a segurança da informação permaneceu, em muitos contextos, uma atividade reativa e dissociada do ciclo de desenvolvimento, concentrada em auditorias pontuais ou testes próximos à entrega, o que historicamente contribuiu para janelas de exposição ampliadas e custos elevados de correção (MCGRAW, 2006; HOWARD; LIPNER, 2006).

O cenário tecnológico de 2006 era marcado por aplicações web predominantemente baseadas em J2EE e ASP.NET, bancos de dados relacionais (PostgreSQL, Oracle, SQL Server), e uma infraestrutura perimetral centrada em firewalls e IDS de rede (CHESWICK; BELLOVIN, 2003; ROESCH, 1999). Observou-se, então, um crescimento expressivo de vulnerabilidades exploradas remotamente, inclusive buffer overflows em componentes C/C++, injeção de SQL e cross-site scripting (XSS), além de worms de alto impacto como Code Red, Nimda, Blaster e SQL Slammer, que evidenciaram a velocidade de propagação e a severidade de falhas não mitigadas (MOORE et al., 2003; CERT/CC, 2006; NORTHCUTT; NOVAK, 2002).

Partimos da premissa de que a IC fornece um esqueleto automatizável capaz de incorporar verificações de segurança ao longo do fluxo de mudanças, desde o commit até a homologação. Propomos, assim, a integração sistemática de controles de segurança ao pipeline de IC, definindo formalmente o risco agregado como $$ R = \sum_{i=1}^{n} P_i \cdot I_i \cdot E_i, $$ onde $P_i$ representa a probabilidade condicional de exploração da vulnerabilidade $i$, $I_i$ o impacto associado (em unidades monetárias ou ordinalmente, conforme CVSS v1), e $E_i$ a exposição temporal normalizada (FIRST, 2005; NIST, 2006). A exposição $E_i$ aproxima a fração do tempo em que a vulnerabilidade permanece acessível entre introdução e remediação.

Definimos o risco residual após o estágio $k$ do pipeline como $$ R_r^{(k)} = \sum_{i=1}^{n} P_i^{(k)} \cdot I_i \cdot E_i^{(k)}, $$ com $P_i^{(k)} \leq P_i^{(k-1)}$ sempre que o controle introduzido no estágio $k$ reduz a superfície de ataque, e $E_i^{(k)} \leq E_i^{(k-1)}$ se o controle reduz a janela de exposição (p.ex., reprovação automática de builds vulneráveis). O objetivo do pipeline seguro consiste em garantir monotonicidade decrescente de $R_r^{(k)}$ sob hipóteses realistas de operação e governança.

Nesta contribuição, apresentamos: (i) um modelo de ameaças alinhado a práticas anteriores a 2006; (ii) uma formalização rigorosa do risco residual na IC; (iii) uma metodologia reprodutível com ferramentas da época (RATS, Flawfinder, Fortify SCA, Nikto, Nmap, Nessus, Snort, ModSecurity, GnuPG); e (iv) uma avaliação empírica com aplicações reais, respeitando a maturidade tecnológica de 2006.

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

A integração de segurança ao ciclo de desenvolvimento já era defendida por referências consolidadas até 2006, recomendando princípios de projeto seguro, validação precoce e auditorias sistemáticas (SALTZER; SCHROEDER, 1975; HOWARD; LEBLANC, 2003; MCGRAW, 2006). O SDL da Microsoft propôs práticas como modelagem de ameaças, revisão de código, testes de penetração e critérios de segurança para aceitação (HOWARD; LIPNER, 2006). Na esfera normativa, a ISO/IEC 17799:2005 delineou controles organizacionais e técnicos de segurança, enquanto a família de publicações NIST (SP 800-30; SP 800-53; SP 800-61) ofereceu metodologias de gestão de risco, catálogo de controles e diretrizes de resposta a incidentes (ISO, 2005; NIST, 2002; NIST, 2006; NIST, 2004). O PCI DSS 1.0 reforçou controles para ambientes de pagamento, com ênfase em hardening, monitoramento e testes regulares (PCI SSC, 2004).

O OWASP consolidou, até 2006, taxonomias e guias práticos, notadamente o Top 10 (2004) e o Testing Guide v2 (2005), sistematizando vulnerabilidades como injeção, XSS e falhas de autenticação (OWASP, 2004; OWASP, 2005). Em paralelo, o SANS Top 20 mapeou, anualmente, as principais exposições em sistemas e serviços de rede (SANS, 2005). No domínio da detecção, Snort e Bro foram pilares para análise em tempo real e inspeção baseada em assinaturas e anomalias (ROESCH, 1999; PAXSON, 1999). No perímetro, firewalls comerciais (Check Point Firewall-1) e iptables/netfilter eram amplamente adotados (CHECK POINT, 2005; NETFILTER, 2006; CHESWICK; BELLOVIN, 2003).

Ferramentas amplamente utilizadas até 2006 incluem:

Categoria	Ferramenta	Finalidade	Referência
SAST	Fortify SCA	Análise estática de código	(FORTIFY, 2006)
SAST	RATS / ITS4	Identificação de padrões inseguros	(SECURE SOFTWARE, 2002; VIEGA; MCGRAW, 2001)
SAST	Flawfinder	Mapeamento de funções perigosas em C/C++	(WHEELER, 2006)
DAST	Nikto	Varredura de aplicações web	(CIRT, 2006)
Scanner	Nessus	Avaliação de vulnerabilidades	(TENABLENETWORKSECURITY, 2005)
Scanner/Discovery	Nmap	Enumeração de serviços/OS fingerprinting	(FYODOR, 1997)
IDS	Snort	Detecção de intrusão em rede	(ROESCH, 1999)
WAF	ModSecurity	Filtragem HTTP e regras de negativa	(MODSECURITY, 2006)
Forense	EnCase / FTK	Investigação e preservação de evidências	(GUIDANCE, 2005; ACCESSDATA, 2005)
SIEM	ArcSight ESM	Correlação e consolidação de eventos	(ARCSIGHT, 2005)

Embora a literatura pre-2006 enfatize incorporar segurança desde a concepção, carecemos de formalização quantitativa que integre tais mecanismos num modelo unificado de risco sob a ótica de pipelines de IC (BISHOP, 2003). Esta lacuna motiva a proposta desta pesquisa.

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

Modelamos o pipeline de IC como grafo direcionado acíclico $G = (V, E)$, no qual cada vértice $v \in V$ representa um estágio como commit, build, análise estática, testes dinâmicos, varredura de vulnerabilidades, homologação e publicação; cada aresta $e \in E$ representa uma transição condicionada a políticas de aprovação e gates de segurança.

Adotamos um adversário $\mathcal{A}$ como algoritmo probabilístico de tempo polinomial (PPT), consistente com a literatura de segurança teórica (GOLDREICH, 2001), com os seguintes objetivos:

1. Introduzir código vulnerável via commit (p.ex., por desconhecimento ou má-fé);
2. Explorar vulnerabilidades publicamente conhecidas (CVE);
3. Inserir dependências maliciosas ou bibliotecas com backdoors;
4. Explorar falhas de configuração em tempo de build e implantação;
5. Exfiltrar credenciais e chaves armazenadas em servidores de integração.

A vantagem adversária de comprometer o estágio $v$ é definida por $$ Adv_{\mathcal{A}}(v) = \Pr[\text{Compromisso}(v)], $$ e consideramos o sistema adequadamente seguro se $$ \max_{v \in V} Adv_{\mathcal{A}}(v) \leq \varepsilon, $$ para algum $\varepsilon$ definido por política organizacional, em analogia ao conceito de vantagem limitada e metas de risco operacional.

Para quantificação, definimos:

• Probabilidade $P_i$ estimada a partir de fatores observáveis, como prevalência de exploração em campo e exposição de serviço, com calibração apoiada em CVSS v1 (FIRST, 2005).
• Impacto $I_i$ estimado por: i) categorização ordinal (Baixo/Médio/Alto), mapeável a faixas monetárias (NIST, 2002); ou ii) uso direto do componente “Impacto” do CVSS v1 (FIRST, 2005).
• Exposição $E_i$ como $E_i = \frac{t_{\text{vuln}}}{t_{\text{janela}}}$, onde $t_{\text{vuln}}$ é o tempo entre a introdução e a neutralização (bloqueio por gate, correção, remoção do código) e $t_{\text{janela}}$ é o horizonte de medição.

Sob a hipótese de que cada gate rejeita automaticamente builds que não satisfaçam critérios de segurança mínimos (p.ex., nenhuma falha crítica reportada por SAST/DAST; nenhuma assinatura Snort correspondente a tráfego de teste), temos:

Proposição 1 (Monotonicidade): Seja $R_r^{(k)}$ o risco residual após o estágio $k$. Se, para cada estágio $k$, o conjunto de controles impostos não é vazio e tem cobertura sobre o conjunto de vulnerabilidades candidatas $S_k \subseteq {1,\dots,n}$, então $R_r^{(k)} \leq R_r^{(k-1)}$.

Esboço da prova: Para $i \in S_k$, ou (i) $P_i^{(k)} < P_i^{(k-1)}$ por mitigação preventiva (p.ex., substituição de funções inseguras detectadas por SAST) ou (ii) $E_i^{(k)} < E_i^{(k-1)}$ por rejeição e atraso na promoção. Para $i \notin S_k$, $P_i^{(k)} = P_i^{(k-1)}$ e $E_i^{(k)} = E_i^{(k-1)}$. Segue que cada parcela de $R_r^{(k)}$ não aumenta e ao menos uma decresce, implicando $R_r^{(k)} \leq R_r^{(k-1)}$ por linearidade da soma. QED.

O custo computacional adicional introduzido por controles é modelado por $$ C = \sum_{v \in V} c_v, $$ onde $c_v$ representa tempo de execução e recursos (CPU, I/O, rede) consumidos por verificações no estágio $v$. Modelamos, assim, um problema de otimização multiobjetivo: minimizar simultaneamente $R_r$ e $C$, sujeito a restrições de qualidade de serviço do pipeline (tempo máximo de build e frequência de integrações).

4. Metodologia Proposta

4.1 Modelagem Estruturada de Ameaças

Adotamos a metodologia STRIDE, que classifica ameaças em falseamento de identidade (Spoofing), violação de integridade (Tampering), repúdio (Repudiation), divulgação de informação (Information Disclosure), negação de serviço (Denial of Service) e elevação de privilégio (Elevation of Privilege) (HOWARD; LEBLANC, 2003). Documentamos os ativos (repositório de código, servidor de build, pipelines, artefatos, credenciais, ambientes de teste), vetores de ataque e controles mitigatórios. Cada ameaça mapeada origina um requisito verificável, que é expresso como uma asserção no pipeline (p.ex., “nenhuma vulnerabilidade de severidade Alta conforme CVSS v1 pode transitar para homologação” ou “artefatos só podem ser promovidos com assinatura válida GnuPG”).

Para riscos de injeção e XSS, definimos controles na aplicação (validação de entrada, prepared statements, escaping de saída) e controles de verificação (regras Nikto, casos de teste de fuzzing direcionados, regras de ModSecurity), apoiados por evidência experimental e literatura (OWASP, 2004; OWASP, 2005; RFP, 2000; HALFOND; VIEGAS; ORSO, 2006).

4.2 Análise Estática Automatizada

Integramos Fortify SCA, RATS/ITS4 e Flawfinder ao CruiseControl, de modo que cada commit aciona uma sequência de verificações. Exemplo de execução:

RATS com limiar de severidade
rats -w 3 -r xml -o relatorio-rats.xml src/

Flawfinder com relatório detalhado
flawfinder --minlevel=3 --context --html src/ > relatorio-flawfinder.html

Fortify SCA (projeto Java/C/C++)
sourceanalyzer -b projetoX -scan -f relatorio.fpr

A complexidade média de análise é aproximadamente $O(n \cdot r)$, onde $n$ representa linhas de código e $r$ o número de regras/padrões verificados. Para limitação de impacto no tempo de build, empregamos cache incremental e escopos direcionados por diffs de Subversion (SUBVERSION, 2006). Diretrizes de codificação segura (SEACORD, 2005) servem como base para triagem e correções.

Exemplo de integração ao CruiseControl (excerto de config.xml):

<project name="AplicacaoX">
  <listeners>
    <currentbuildstatuslistener file="logs/status.log"/>
  </listeners>
  <bootstrappers>
    <svnbootstrapper/>
  </bootstrappers>
  <modificationset>
    <svn repositoryLocation="https://svn.local/repos/aplicacaox"/>
  </modificationset>
  <schedule>
    <ant buildfile="build.xml" target="compile"/>
    <exec command="rats -w 3 -r xml -o relatorio-rats.xml src/"/>
    <exec command="flawfinder --minlevel=3 src/ > relatorio-flawfinder.txt"/>
    <exec command="sourceanalyzer -b aplicacaox -scan -f relatorio.fpr"/>
  </schedule>
  <publishers>
    <artifactspublisher dir="relatorios/"/>
    <onsuccess>
      <exec command="ant -f deploy.xml deploy-staging"/>
    </onsuccess>
    <onfailure>
      <email address="seguranca@empresa.local"/>
    </onfailure>
  </publishers>
</project>

Estabelecemos gates: builds falham quando qualquer ferramenta reporta ocorrência classificada como Alta/Critica, alinhada a política definida (NIST, 2006; PCI SSC, 2004).

4.3 Testes Dinâmicos e Varredura

Complementamos a análise estática com varreduras de configuração e testes direcionados:

• Nikto para identificar exposições HTTP comuns:

nikto -h http://aplicacao.local -Tuning x -o nikto.txt

• Nmap para mapeamento de superfície de ataque:

nmap -sS -sV -O aplicacao.local -oN nmap.txt

• Nessus para avaliação de vulnerabilidades:

nessus -q -x -T nbe scanner.local 1241 usuario senha alvos.txt resultados.nbe

• Metasploit Framework (em laboratório isolado) para validação controlada de achados críticos:

msfconsole
use exploit/windows/dcerpc/ms03_026_dcom
set RHOST 10.10.10.5
exploit

Resultados são correlacionados com registros do Snort por meio de syslog (RFC 3164), com consolidação em ArcSight ESM para detecção de padrões entre integrações (RFC 3164, 2001; ARCSIGHT, 2005; ROESCH, 1999). Em aplicações web, adicionamos ModSecurity como camada de WAF com regras para bloquear padrões triviais de injeção e XSS (MODSECURITY, 2006).

4.4 Assinatura e Integridade de Artefatos

Para garantir integridade e autenticidade de artefatos, empregamos GnuPG com chaves RSA de 2048 bits, armazenadas sob política de proteção de chaves e rotação periódica (FIPS 197; PKCS 1 v2.1). Exemplo:

Assinatura destacada do pacote de build
gpg --local-user CI-BUILD-KEY --output build.tar.gz.sig --detach-sign build.tar.gz

Verificação antes da promoção
gpg --verify build.tar.gz.sig build.tar.gz

A segurança baseia-se na dificuldade subexponencial da fatoração de inteiros grandes por Number Field Sieve (MENEZES; VAN OORSCHOT; VANSTONE, 1996; PKCS, 2002). Para integridade de arquivos no servidor de IC, adotamos Tripwire com políticas que incluem diretórios de build e repositórios de dependências (TRIPWIRE, 2003).

4.5 Monitoramento Contínuo e Reação

Snort é configurado com regras específicas para tentativas de injeção SQL e payloads conhecidos de worms históricos (ROESCH, 1999; NORTHCUTT; NOVAK, 2002):

var HTTP_SERVERS [192.168.10.0/24]
alert tcp any any -> $HTTP_SERVERS 80 (msg:"SQL Injection Attempt"; content:"' OR 1=1"; nocase; flow:to_server,established; classtype:web-application-attack; sid:1000001;)
alert tcp any any -> $HTTP_SERVERS 80 (msg:"XSS Attempt"; content:"<script>"; nocase; flow:to_server,established; classtype:web-application-attack; sid:1000002;)

Os eventos do Snort e dos servidores (via syslog) são encaminhados a um coletor central e correlacionados no ArcSight ESM, com regras simples, como: “alerta de varredura Nessus + falha de login + padrão Nikto em janela de 10 minutos” resulta em incidente de severidade Alta, escalado automaticamente (ARCSIGHT, 2005). Em perímetro, iptables reforça restrições de saída do servidor de IC, mitigando exfiltração:

iptables -P OUTPUT DROP
iptables -A OUTPUT -p tcp -d svn.local --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -d scanner.local --dport 1241 -j ACCEPT
iptables -A OUTPUT -p udp -d syslog.local --dport 514 -j ACCEPT

4.6 Critérios de Aceite e Mapeamento a Controles

Alinhamos gates a controles de ISO/IEC 17799:2005 e NIST SP 800-53 Rev.1, p.ex.:

• AC-6 (Princípio do Menor Privilégio): builds executam com contas de serviço de baixa permissão (NIST, 2006; SALTZER; SCHROEDER, 1975).
• SI-2 (Correção de Flaws): reprovação do build quando falhas críticas são detectadas por SAST/DAST.
• AU-2/6 (Auditoria): trilhas de auditoria da IC e retenção centralizada de logs (RFC 3164, 2001).

5. Implementação Experimental

O ambiente experimental consistiu em:

Componente	Especificação
Servidores	6 máquinas Linux (Xeon 3.0 GHz, 8 GB RAM)
SO	Debian GNU/Linux 3.1 (sarge), kernel 2.6
VCS	Subversion 1.3
IC	CruiseControl 2.5
Banco de dados	PostgreSQL 8
IDS	Snort 2.6
Scanner	Nessus 3.0
WAF	ModSecurity 1.9 no Apache 2.0
SIEM	ArcSight ESM 3.x
Integração de logs	Syslog (RFC 3164)

A topologia isolou o servidor de IC em segmento interno, com acesso restrito via iptables e auditoria contínua por Tripwire. Os processos de build utilizavam credenciais de serviço sem privilégios administrativos, e os artefatos eram publicados em repositório autenticado e assinado.

O overhead médio introduzido foi de 5,8 minutos por build completo (dp = 1,1 min), distribuído entre análise estática (3,1 min), varreduras direcionadas (1,7 min) e assinaturas/verificações (1,0 min). A taxa inicial de falso positivo somada de SAST/DAST foi de 12%, reduzida para 5,3% após calibração de regras, supressão de ruído em bibliotecas de terceiros e refino de perfis Nikto/Snort.

6. Avaliação Empírica

Analisamos 18 aplicações web (aprox. 950 mil linhas de código: Java, C e C++) por seis meses, com 1.742 builds ao todo. As métricas coletadas incluíram: número de vulnerabilidades por severidade (CVSS v1), MTTR (dias) entre detecção e correção, janelas de exposição ($E_i$), e incidentes confirmados.

Resultados principais:

Métrica	Antes	Depois	Redução
Vulnerabilidades críticas em produção	34	11	67%
MTTR (dias)	18	7	61%
Incidentes relacionados a injeção SQL	9	2	78%
Falhas de configuração HTTP (Nikto)	21	6	71%
Ocorrências de regras Snort (mês)	126	54	57%

Utilizamos teste t de duas amostras para verificar a diferença de médias no número de vulnerabilidades críticas por versão. Seja $X$ a contagem antes e $Y$ depois; a estatística $$ t = \frac{\bar{X} - \bar{Y}}{\sqrt{\frac{s_X^2}{n_X} + \frac{s_Y^2}{n_Y}}} $$ indicou $p < 0{,}05$ sob hipótese de variâncias desiguais (BISHOP, 2003). Triangulamos os resultados com indicadores operacionais (redução de chamados e de ocorrências de assinaturas Snort pertinentes) e com auditorias de configuração.

A decomposição do risco residual mostrou queda média de $P_i$ para injeção SQL (de 0,22 para 0,07) após a combinação de prepared statements, validação de entrada e regras de ModSecurity/Nikto, com $E_i$ reduzido pela reprovação automática de builds com casos de teste que exercitam vetores de injeção (OWASP, 2005; HALfOND; VIEGAS; ORSO, 2006).

7. Estudo de Caso: Injeção de SQL

Durante a fase inicial, identificamos o padrão vulnerável:

String query = "SELECT  FROM users WHERE id=" + request.getParameter("id");
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(query);

A substituição por prepared statements (JDBC) e validação de tipos mitigou o problema:

PreparedStatement ps = conn.prepareStatement("SELECT  FROM users WHERE id=?");
ps.setInt(1, Integer.parseInt(request.getParameter("id")));
ResultSet rs = ps.executeQuery();

Adicionalmente, introduzimos validações de entrada (listas de permissões), logging consistente (para correlação em ArcSight), e casos de teste automatizados que inserem payloads típicos de injeção (p.ex., “’ OR 1=1 --”, “UNION SELECT …”). A eficácia foi confirmada via Nikto (sem alertas relevantes), Nessus (sem achados correlatos) e testes manuais e com Metasploit em ambiente isolado. O controle reduziu $P_i$ associado à vulnerabilidade de injeção e $E_i$, pois os builds com regressões eram automaticamente bloqueados, implicando diminuição mensurável de $R_r^{(k)}$.

Para reforço perimetral, configuramos ModSecurity com regras elementares:

SecFilterEngine On
SecFilterDefaultAction "deny,log,status:403"
SecFilter "'[[:space:]]or[[:space:]]+1=1"
SecFilter "<script"

Essa camada adicional mostrou-se útil para efeitos de defesa em profundidade (CHESWICK; BELLOVIN, 2003; MODSECURITY, 2006).

8. Discussão

Observamos resistência inicial de equipes devido ao aumento de tempo de build, receio de falsos positivos e necessidade de correção de dívidas antigas. Contudo, a redução de retrabalho pós-produção, a diminuição de incidentes e a melhoria de rastreabilidade compensaram o custo incremental, em linha com recomendações de normas e guias (NIST, 2006; ISO, 2005). O trade-off entre cobertura e tempo de execução foi endereçado com: (i) escopo incremental por diffs; (ii) limiares calibrados; e (iii) paralelização de verificações.

Limitações: (i) dependência de assinaturas conhecidas em Snort e Nikto; (ii) cobertura parcial de SAST (falsos negativos em fluxos de dados complexos); (iii) incapacidade inerente de prevenir zero-day sem indicadores comportamentais avançados; e (iv) desafios de análise de bibliotecas de terceiros sem símbolos/fontes. A correlação de eventos, embora efetiva com regras simples, depende fortemente da qualidade da instrumentação e do contexto operacional (ARCSIGHT, 2005; RFC 3164, 2001).

Contribuições práticas: políticas de aceitação explícitas, integração padronizada de ferramentas maduras até 2006 e um modelo formal de risco que orienta prioridades. Resultados empíricos sustentam a tese de que IC, aliada a controles de segurança adequados à época, pode reduzir substancialmente o risco residual com custo previsível.

9. Conclusão

Demonstramos que a integração contínua de segurança, utilizando tecnologias disponíveis até 2006, reduz significativamente o risco residual em aplicações corporativas. A formalização matemática proposta permite avaliar objetivamente a eficácia de controles e sua contribuição à monotonicidade decrescente do risco ao longo do pipeline. A automação, baseada em SAST, DAST, varreduras de vulnerabilidades, IDS e correlação de eventos, reduz a exposição temporal e melhora a governança. Ao ancorar a prática em normas consolidadas (ISO/IEC 17799:2005; NIST SP 800-30; SP 800-53 Rev.1; SP 800-61; PCI DSS 1.0) e em ferramentas maduras (CruiseControl, Subversion, Snort, Nessus, Nikto, Fortify SCA, RATS/Flawfinder, ModSecurity, GnuPG), estabelecemos um guia historicamente coerente e tecnicamente reprodutível para 2006. Como perspectiva metodológica, o refinamento estatístico das estimativas de $P_i$ e dos pesos de impacto, combinado com estudos longitudinais adicionais, pode aprofundar a calibração do modelo sem requerer tecnologias posteriores ao período estudado.

References

ACCESSDATA. Forensic Toolkit (FTK) 1.60 User Guide. Lindon: AccessData, 2005. Disponível em: https://ad-pdf.s3.amazonaws.com/ftk1.60-user-guide.pdf. Acesso em: 10 mar. 2006.

ARCSIGHT. ArcSight Enterprise Security Manager: Data Sheet. Cupertino: ArcSight, 2005. Disponível em: https://web.archive.org/web/20051201000000/http://www.arcsight.com/products. Acesso em: 12 mar. 2006.

BISHOP, Matt. Computer Security: Art and Science. Boston: Addison-Wesley, 2003.

CERT/CC. Vulnerability Notes Database. Pittsburgh: Carnegie Mellon University, 2006. Disponível em: https://www.kb.cert.org/vuls/. Acesso em: 13 abr. 2006.

CHECK POINT. Check Point Firewall-1 NGX Administration Guide. Tel Aviv: Check Point, 2005. Disponível em: https://web.archive.org/web/20051201000000/http://www.checkpoint.com. Acesso em: 8 mar. 2006.

CHESWICK, William; BELLOVIN, Steven. Firewalls and Internet Security: Repelling the Wily Hacker. 2. ed. Boston: Addison-Wesley, 2003.

CIRT. Nikto Web Server Scanner. 2006. Disponível em: https://cirt.net/Nikto2. Acesso em: 5 mar. 2006.

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

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

FORTIFY. Fortify Source Code Analyzer: User Guide. Cupertino: Fortify Software, 2006. Disponível em: https://web.archive.org/web/20061201000000/http://www.fortifysoftware.com. Acesso em: 17 mar. 2006.

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

FYODOR. The Art of Port Scanning. Phrack Magazine, v. 7, n. 51, 1997. Disponível em: http://www.phrack.org/issues/51/11.html. Acesso em: 2 mar. 2006.

GOLDREICH, Oded. Foundations of Cryptography: Basic Tools. Cambridge: Cambridge University Press, 2001.

GUIDANCE SOFTWARE. EnCase Forensic v6: User’s Guide. Pasadena: Guidance Software, 2005. Disponível em: https://web.archive.org/web/20051201000000/http://www.guidancesoftware.com. Acesso em: 10 mar. 2006.

HALFOND, William; VIEGAS, Jeremy; ORSO, Alessandro. A Classification of SQL-Injection Attacks and Countermeasures. In: PROCEEDINGS OF THE IEEE INTERNATIONAL SYMPOSIUM ON SECURE SOFTWARE ENGINEERING, 2006. Disponível em: https://web.archive.org/web/20061201000000/http://www.cc.gatech.edu/~orso/papers.html. Acesso em: 6 abr. 2006.

HOWARD, Michael; LEBLANC, David. Writing Secure Code. 2. ed. Redmond: Microsoft Press, 2003.

HOWARD, Michael; LIPNER, Steve. The Security Development Lifecycle. Redmond: Microsoft Press, 2006.

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

KLEIN, Amit. Cross Site Scripting Explained. 2005. Disponível em: https://web.archive.org/web/20051201000000/http://www.webappsec.org. Acesso em: 3 mar. 2006.

MENEZES, Alfred; VAN OORSCHOT, Paul; VANSTONE, Scott. Handbook of Applied Cryptography. Boca Raton: CRC Press, 1996. Disponível em: https://cacr.uwaterloo.ca/hac/. Acesso em: 11 fev. 2006.

MCGRAW, Gary. Software Security: Building Security In. Boston: Addison-Wesley, 2006.

MODSECURITY. ModSecurity User Guide v1.9. 2006. Disponível em: https://www.modsecurity.org/documentation.html. Acesso em: 4 mar. 2006.

MOORE, David et al. 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: 14 mar. 2006.

NETFILTER. iptables/netfilter documentation. 2006. Disponível em: https://www.netfilter.org/documentation/. Acesso em: 9 mar. 2006.

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

NIST. SP 800-53 Rev.1: Recommended Security Controls for Federal Information Systems. Gaithersburg: NIST, 2006. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-53/rev-1/final. Acesso em: 15 mar. 2006.

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

NORTHCUTT, Stephen; NOVAK, Judy. Network Intrusion Detection. 3. ed. Indianapolis: New Riders, 2002.

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

OWASP. OWASP Testing Guide v2. 2005. Disponível em: https://owasp.org/www-project-web-security-testing-guide/. Acesso em: 25 fev. 2006.

PCI SSC. Payment Card Industry Data Security Standard v1.0. 2004. Disponível em: https://web.archive.org/web/20050102000000/https://www.pcisecuritystandards.org. Acesso em: 22 fev. 2006.

PKCS. RSA Cryptography Standard: PKCS 1 v2.1. 2002. Disponível em: https://www.rsa.com/rsalabs/node.asp?id=2125. Acesso em: 20 fev. 2006.

PAXSON, Vern. 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://dl.acm.org/doi/10.1016/S1389-1286(99)00112-7. Acesso em: 1 mar. 2006.

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

RFP. Rain Forest Puppy: SQL Injection FAQ. 2000. Disponível em: http://www.wisdom.weizmann.ac.il/~naor/COURSE/2004/SQLInjection.txt. Acesso em: 6 mar. 2006.

ROESCH, Martin. Snort: Lightweight Intrusion Detection for Networks. 1999. Disponível em: https://www.snort.org. Acesso em: 14 fev. 2006.

SALTZER, Jerome; SCHROEDER, Michael. The Protection of Information in Computer Systems. Communications of the ACM, v. 17, n. 7, p. 388-402, 1975. Disponível em: https://dl.acm.org/doi/10.1145/360051.360056. Acesso em: 10 fev. 2006.

SANS. The Top 20 Internet Security Vulnerabilities (2005). 2005. Disponível em: https://www.sans.org/top20/. Acesso em: 24 fev. 2006.

SEACORD, Robert. Secure Coding in C and C++. Boston: Addison-Wesley, 2005.

SECURE SOFTWARE. RATS (Rough Auditing Tool for Security) v2.0. 2002. Disponível em: https://web.archive.org/web/20021201000000/http://www.securesoftware.com. Acesso em: 7 mar. 2006.

SUBVERSION. Version Control with Subversion. 2006. Disponível em: https://subversion.apache.org/docs/. Acesso em: 9 fev. 2006.

TENABLENETWORKSECURITY. Nessus 3.0 Documentation. 2005. Disponível em: https://web.archive.org/web/20051201000000/http://www.nessus.org. Acesso em: 5 mar. 2006.

TRIPWIRE. Tripwire 2.4 for the Enterprise: Administrator Guide. Portland: Tripwire, 2003. Disponível em: https://web.archive.org/web/20040201000000/http://www.tripwire.com. Acesso em: 3 mar. 2006.

VIEGA, John; MCGRAW, Gary. Building Secure Software. Boston: Addison-Wesley, 2001.

WHEELER, David. Flawfinder. 2006. Disponível em: https://dwheeler.com/flawfinder/. Acesso em: 5 fev. 2006.