Syllabus Ctal ST 2016br

International Software Testing Qualifications Board
ISTQB Advanced Level

Security Tester
Verso 2016br
Comisso Internacional para Qualificao de Teste de Software
Traduo realizada pela WG Tradues do BSTQB baseada na verso

2016 do Advanced Level Certified Security Test do ISTQB.
Brazilian Software Testing Qualifications Board
Este documento pode ser copiado na sua totalidade, ou ter extratos feitos, se a fonte for reconhecida na sua reproduo.
Copyright International Software Testing Qualifications Board (ISTQB).
Advanced Level WG: Mike Smith (chair)
Advanced Security Tester Syllabus WG: Randall Rice (chair), Tarun Banga, Taz Daughtrey, Frans Dijkman, Prof. Dr. Stefan
Karsch, Satoshi Masuda, Raine Moilanen, Joel Oliveira, Alain Ribault, Ian Ross, Kwangik Seo, Dave van Stein, Dr. Nor Adnan
Yahaya, Wenqiang Zheng.
ISTQB Advanced Level Syllabus
CTAL Security Tester
Histrico de Revises
Verso Data Descrio

0.1 24/04/2015 Baseline version created from existing Expert Security Tester draft
syllabus version 3.9
0.2 15/06/2015 Consolidated author input after Oslo author meeting
1.0 - Beta 20/09/2015 Beta release alpha release comments incorporated
1.0 GA Candidate 04/03/2016 After Exam WG review, changed LO 4.1.2 from K2 and K3 and re-
worded appropriately. Text already adequately supports a K3 LO.
1.0 - GA 18/03/2016 GA release beta release comments incorporated
2016br 15/03/2017 Traduo para a Lngua Portuguesa
Verso 2016br Pgina 2 de 88

ndice
0 Introduo a este Syllabus ....................................................................................... 8
0.1 Objetivos deste documento ............................................................................................... 8
0.2 Viso geral .......................................................................................................................... 8
0.3 Exames ............................................................................................................................... 8
0.4 Como este Syllabus organizado ....................................................................................... 8
0.5 Definies .......................................................................................................................... 9
0.6 Nvel de detalhe ................................................................................................................. 9
0.7 Objetivos de Aprendizado e Nveis de Conhecimento ....................................................... 9
0.7.1 Nvel 1: Lembre-se (K1) ...................................................................................................... 9
0.7.2 Nvel 2: Compreender (K2) ............................................................................................... 10
0.7.3 Nvel 3: Aplicar (K3) .......................................................................................................... 10
0.7.4 Nvel 4: Analisar (K4) ........................................................................................................ 10
1 A base do Teste de Segurana (105 min) ...............................................................11
1.1 Riscos de segurana ......................................................................................................... 12
1.1.1 O Papel da Avaliao de Risco em Testes de Segurana .................................................. 12
1.1.2 Identificao de ativos ..................................................................................................... 13
1.2 Polticas e Procedimentos de Segurana da Informao .................................................. 15
1.2.1 Compreendendo Polticas e Procedimentos de Segurana .............................................. 15
1.2.2 Anlise de Polticas e Procedimentos de Segurana ........................................................ 18
1.3 A auditoria de segurana e seu papel no teste de segurana .......................................... 20
1.3.1 Finalidade de uma Auditoria de Segurana ...................................................................... 20
1.3.2 Identificao, Avaliao e Mitigao de Riscos ................................................................ 21
1.3.3 Pessoas, Processos e Tecnologia ...................................................................................... 25
2 Testes de Segurana Objetivos, Metas e Estratgias (130 min) ............................27
2.1 Introduo........................................................................................................................ 28
2.2 O Propsito dos Testes de Segurana .............................................................................. 29
2.3 O Contexto Organizacional............................................................................................... 29
2.4 Objetivos do Teste de Segurana ..................................................................................... 29
2.4.1 O Alinhamento dos Objetivos de Testes de Segurana .................................................... 29
2.4.2 Identificao dos Objetivos do Teste de Segurana ......................................................... 29
2.4.3 A Diferena entre a Garantia da Informao e o Teste de Segurana .............................. 30
2.5 mbito e Cobertura dos Objetivos de Testes de Segurana ............................................ 30
2.6 Abordagens de Testes de Segurana ................................................................................ 30

2.6.1 Anlise de abordagens de teste de segurana ................................................................. 30
2.6.2 Anlise de falhas em abordagens de teste de segurana ................................................. 31
2.6.3 Identificao das partes interessadas .............................................................................. 32
2.7 Melhorar as Prticas de Testes de Segurana .................................................................. 32
3 Processos de Teste de Segurana (140 min) ..........................................................34
3.1 Definio do Processo de Teste de Segurana ................................................................. 35
3.1.1 Processo de teste de segurana ISTQB............................................................................. 35
3.1.2 Alinhando o processo de teste de segurana a um modelo de ciclo de vida de software especfico
37
3.2 Planejamento do teste de segurana ............................................................................... 40
3.2.1 Objetivos de planeamento do teste de segurana ........................................................... 40
3.2.2 Elementos chave do plano de teste de segurana ........................................................... 40
3.3 Projeto de teste de segurana ......................................................................................... 41
3.3.1 Modelagem de Teste de Segurana ................................................................................. 41
3.3.2 Desenho de Teste de Segurana Baseado em Polticas e Procedimentos ........................ 46
3.4 Execuo do teste de segurana ...................................................................................... 47
3.4.1 Elementos-chave e caractersticas de um ambiente de teste de segurana eficaz .......... 47
3.4.2 Importncia do planejamento e das aprovaes em testes de segurana ....................... 48
3.5 Avaliao do teste de segurana ...................................................................................... 48
3.6 Manuteno do teste de segurana ................................................................................. 49
4 Teste de Segurana durante o ciclo de vida do software (225 min) .....................50
4.1 O Papel dos Testes de Segurana no ciclo de vida de um software ................................. 51
4.1.1 Viso do ciclo de vida dos testes de segurana ................................................................ 51
4.1.2 Atividades relacionadas segurana no Ciclo de Vida do Software ................................. 52
4.2 O Papel dos Testes de Segurana em Requisitos ............................................................. 54
4.3 O Papel dos Testes de Segurana no Modelagem ............................................................ 55
4.4 O Papel dos Testes de Segurana nas Atividades de Implementao .............................. 55
4.4.1 Teste de segurana durante o teste de componentes ..................................................... 55
4.4.2 Desenho de teste de segurana no nvel de componente ............................................... 56
4.4.3 Anlise de testes de segurana no nvel de componente ................................................ 57
4.4.4 Teste de segurana durante o teste de integrao de componentes .............................. 57
4.4.5 Modelagem de Testes de Segurana no Nvel de Integrao de Componentes ............... 58
4.5 O Papel dos Testes de Segurana em Atividades de Teste de Sistema e Aceitao ......... 58
4.5.1 O Papel dos Testes de Segurana nos Testes do Sistema ................................................. 58

4.5.2 O Papel dos Testes de Segurana nos Testes de Aceitao .............................................. 58
4.6 O Papel dos Testes de Segurana na Manuteno ........................................................... 59
5 Mecanismos de Teste de Segurana (240 min) .....................................................60
5.1 Enrijecimento de Sistema................................................................................................. 62
5.1.1 Compreendendo o enrijecimento do sistema .................................................................. 62
5.1.2 Testando a Eficcia dos Mecanismos de Enrijecimento do Sistema................................. 63
5.2 Autenticao e Autorizao ............................................................................................. 63
5.2.1 Relao entre Autenticao e Autorizao ...................................................................... 63
5.2.2 Testando a Eficcia dos Mecanismos de Autenticao e Autorizao ............................. 64
5.3 Criptografia ...................................................................................................................... 64
5.3.1 Entendendo a criptografia ............................................................................................... 64
5.3.2 Testando a Eficcia dos Mecanismos Comuns de Criptografia......................................... 65
5.4 Firewalls e Zonas de Rede ................................................................................................ 66
5.4.1 Compreendendo os Firewalls ........................................................................................... 66
5.4.2 Testando a Eficcia do Firewall ........................................................................................ 66
5.5 Deteco de Intruso ....................................................................................................... 66
5.5.1 Compreendendo as Ferramentas de Deteco de Intruso ............................................. 66
5.5.2 Testando a Eficcia das Ferramentas de Deteco de Intruso ....................................... 67
5.6 Varredura de malware ..................................................................................................... 67
5.6.1 Compreendendo as Ferramentas de Varredura de Malware ........................................... 67
5.6.2 Testando a Eficcia das Ferramentas de Varredura de Malware ..................................... 68
5.7 Mascaramento de dados .................................................................................................. 68
5.7.1 Compreendendo a Mascaramento de Dados ................................................................... 68
5.7.2 Testando a Eficcia dos Mtodos de Mascaramento de Dados ....................................... 69
5.8 Formao ......................................................................................................................... 69
5.8.1 Importncia do treinamento em segurana ..................................................................... 69
5.8.2 Como testar a eficcia do treinamento de segurana ...................................................... 70
6 Fatores humanos em Teste de Segurana (105 min).............................................71
6.1 Compreendendo os Atacantes ......................................................................................... 72
6.1.1 O Impacto do Comportamento Humano nos Riscos de Segurana .................................. 72
6.1.2 Entendendo a Mentalidade do Atacante ......................................................................... 72
6.1.3 Motivaes comuns e fontes de ataques a sistemas de informao ............................... 73
6.1.4 Compreendendo cenrios de ataque e motivaes ......................................................... 73
6.2 Engenharia Social ............................................................................................................. 75

6.3 Conscincia de Segurana ................................................................................................ 76
6.3.1 A Importncia da Conscincia de Segurana .................................................................... 76
6.3.2 Aumentar a sensibilizao para a segurana.................................................................... 76
7 Avaliao e relatrios de testes de segurana (70 min) ........................................77
7.1 Avaliao do teste de segurana ...................................................................................... 78
7.2 Relatrios de teste de segurana ..................................................................................... 78
7.2.1 Confidencialidade dos Resultados dos Testes de Segurana ............................................ 78
7.2.2 Criando Controles Adequados e Mecanismos de Coleta de Dados para Relatrio de Status de Teste
de Segurana ............................................................................................................................... 78
7.2.3 Analisando relatrios de status de teste de segurana provisrios ................................. 78
8 Ferramentas de Teste de Segurana (55 min) .......................................................80
8.1 Tipos e Objetivos das Ferramentas de Teste de Segurana ............................................. 81
8.2 Seleo da Ferramenta .................................................................................................... 82
8.2.1 Analisando e Documentando as Necessidades de Testes de Segurana .......................... 82
8.2.2 Problemas com Ferramentas de Cdigo Aberto .............................................................. 82
8.2.3 Avaliando as Capacidades do Vendedor de uma Ferramenta .......................................... 83
9 Padres e tendncias da indstria (40 min) ..........................................................84
9.1 Compreendendo os Padres de Testes de Segurana...................................................... 85
9.1.1 Os Benefcios do Uso de Padres de Testes de Segurana ............................................... 85
9.1.2 Aplicabilidade de Normas em Situaes Regulamentares versus Contratuais ................. 85
9.1.3 Seleo de Padres de Segurana .................................................................................... 85
9.2 Aplicao de padres de segurana ................................................................................. 86
9.3 Tendncias da indstria ............................................................................................................. 86
9.2.1 Onde aprender das tendncias da indstria na segurana da informao ...................... 86
9.2.2 Avaliando Prticas de Testes de Segurana para Melhorias............................................. 86
10 Referencias .............................................................................................................87
10.1 Documentos BSTQB ......................................................................................................... 87
10.2 Normas e Padres ............................................................................................................ 87
10.3 Literatura ......................................................................................................................... 87
10.4 Artigos .............................................................................................................................. 87
10.5 Guias ................................................................................................................................ 87
10.6 Relatrios ......................................................................................................................... 88
10.7 Web.................................................................................................................................. 88

Agradecimentos
Este documento foi produzido pela equipe do Grupo de Trabalho de Nvel Avanado do International Software
Testing Qualifications Board.
A equipe principal agradece equipe de reviso e a todos os Conselhos Nacionais por suas sugestes.
No momento em que o Syllabus de Nvel Avanado para este mdulo foi concludo, o Grupo de Trabalho de
Nvel Avanado - Security Tester teve a seguinte associao:
Os autores da equipe principal para este plano de estudos: Randall Rice (presidente), Hugh Tazwell Daughtrey
(vice-presidente), Frans Dijkman, Joel Oliveira, Alain Ribault.
As seguintes pessoas participaram da reviso, comentrios e votao deste programa (Ordem alfabtica):
Tarun Banga, Clive Bates, Hugh Tazwell Daughtrey (vice-presidente), Frans Dijkman (autor), Christian
Alexander Graf, Wenda Hu, Matthias Hamburgo, Prof. Dr. Stefan Karsch, Sebastian Malyska, Satoshi Masuda,
Gary Mogyorodi, Raine Moilanen, Joel Oliveira, Meile Posthuma, Alain Ribault, Randall Rice (presidente), Ian
Ross, Kwangik Seo, Dave van Stein, Ernst von During, Attila Toth, Wei Xue, Dr. Nor Adnan Yahaya, Xiaofeng
Yang, Wenqiang Zheng, Ping Zuo.
Alm disso, reconhecemos e agradecemos aos lderes e membros do Grupo de Trabalho de Nvel Expert pela
sua contnua orientao: Graham Bath (Presidente, Grupo de Trabalho de Nvel Expert), Judy McKay (Vice-
Presidente, Grupo de Trabalho de Nvel Expert).
Este documento foi formalmente divulgado pela Assembleia Geral do ISTQB em 18 de maro de 2016.

0 Introduo a este Syllabus
0.1 Objetivos deste documento
Este programa forma a base para a Certificao do ISTQB Advanced Level - Security Tester. O ISTQB fornece
este programa da seguinte forma:
1. Aos Conselhos Nacionais, traduzir para o seu idioma local e credenciar os fornecedores de
treinamento. Os conselhos nacionais podem adaptar o programa s suas necessidades lingusticas
especficas e modificar as referncias para se adaptarem s suas publicaes locais.
2. Para os Conselhos de Exame, para derivar questes de exame em sua lngua local com base nos
objetivos de aprendizagem para cada mdulo.
3. Para os provedores de treinamento, produzir material didtico e determinar mtodos de ensino
apropriados.
4. Para os candidatos de certificao, como uma fonte para se preparar para o exame.
5. Para a comunidade internacional de software e engenharia de sistemas, para avanar a profisso de
software e testes de sistema, e como base para livros e artigos.
O ISTQB pode permitir que outras entidades usem este programa para outros fins, desde que obtenham
autorizao prvia por escrito.
0.2 Viso geral

A certificao Advanced Level Security Tester destina-se a pessoas que j alcanaram um ponto avanado em
suas carreiras em testes de software e desejam desenvolver ainda mais sua experincia em testes de
segurana. Os mdulos oferecidos no Nvel Avanado cobrem uma ampla gama de tpicos de teste.
Para receber a Certificao do ISTQB Advanced Level - Security Tester, os candidatos devem possuir o
certificado CTFL e satisfazer a Qualificao junto ao BSTQB para realizar exames CTAL. Consulte o site do BSTQB
para conhecer os critrios especficos de experincia prtica para certificaes CTAL.
0.3 Exames
Todos os exames realizados no Nvel Avanado para este mdulo so baseados neste Syllabus. O formato do
exame definido pelas Diretrizes de Exames Avanados do ISTQB.
Os exames podem ser tomados como parte de um curso de treinamento acreditado ou realizados
independentemente (por exemplo, em um centro de exames). Exames podem ser feitos em papel ou
eletronicamente, mas todos os exames devem ser supervisionados / observados (supervisionados por uma
pessoa mandatada por um Conselho Nacional ou de Exame).
0.4 Como este Syllabus organizado

H dez captulos. O ttulo de nvel superior mostra a quantidade de minutos que devem ser dedicados a estudo
de cada captulo. Por exemplo:
1. A Base de Testes de Segurana (105 min)
Mostra que o Captulo 1 pretende ter um tempo de 105 minutos de dedicao ao estudo deste captulo.Os
objetivos de aprendizagem especficos so listados no incio de cada captulo.

0.5 Definies
Muitos termos usados na literatura de software so comuns todas as certificaes. Considerando que os
candidatos dos nveis Fundamental e Avanado podem responder questes baseadas apenas no Glossrio de
Termos, esperado, alm disso, que os candidatos deste nvel devem estar cientes e capazes de trabalhar com
as diferentes definies.
NOTA: A "garantia de informao" (IA) chamada apenas na seo 2.4. Uma citao em 2.4.3 seguida pela
assero de que IA deve ser visto como mais amplo do que "testes de segurana" da mesma forma que o QA
mais amplo do que o teste de software.
A "segurana da informao" utilizada nas seces 2.2, 2.3.1, 2.7.2, 6 (Antecedentes), 6.1.3 e no Captulo 9.
No h uso do termo "segurana ciberntica", que em alguns setores agora referido como IA.
As palavras-chave listadas no incio de cada captulo neste programa de Nvel Avanado so definidas no
Glossrio Padro de Termos usados em Testes de Software, publicado pelo ISTQB, ou so fornecidos na
literatura referenciada.
0.6 Nvel de detalhe

O nvel de detalhe neste programa permite um aprendizado e um exame consistentes internacionalmente.
Para atingir esse objetivo, o programa de estudos consiste em:
Objetivos gerais de instruo descrevendo a inteno do Nvel Avanado
Objetivos de aprendizagem para cada rea de conhecimento, descrevendo o resultado de
aprendizagem cognitiva e mentalidade a ser alcanada
Uma lista de informaes a aprender, incluindo uma descrio e referncias a fontes adicionais, se
necessrio
Uma descrio dos conceitos-chave para aprender, incluindo fontes como literatura ou padres
aceitos
Algumas ferramentas, mtodos e marcas podem ser mencionados neste programa. Este programa
no se destina a promover ou recomendar qualquer soluo de segurana especfica.
O contedo do programa no uma descrio de toda a rea de conhecimento para Testadores em
segurana Avanados, ele reflete o nvel de detalhe a ser coberto em um curso Advanced Security Tester.
0.7 Objetivos de Aprendizado e Nveis de Conhecimento

O contedo deste programa, os termos e os principais elementos (fins) de todas as normas listadas devem
pelo menos ser lembrados (K1) e compreendidos (K2), mesmo que no mencionados explicitamente nos
objetivos de aprendizagem.
Os seguintes objetivos de aprendizagem so definidos como aplicveis a este programa. Cada tpico no
programa ser examinado de acordo com o objetivo de aprendizagem para ele.
0.7.1 Nvel 1: Lembre-se (K1)

O candidato reconhecer, lembrar e recordar um termo ou conceito.
Palavras-chave: Lembrar, recordar, reconhecer, saber. Exemplo

Pode reconhecer a definio de "risco" como: "um fator que poderia resultar em consequncias negativas
futuras; geralmente expressa como impacto e probabilidade".
0.7.2 Nvel 2: Compreender (K2)

O candidato pode selecionar as razes ou explicaes para declaraes relacionadas ao tpico e pode resumir,
diferenciar, classificar e dar exemplos de fatos (por exemplo, comparar termos), os conceitos de teste,
procedimentos de teste (explicando a sequncia de tarefas).
Palavras-chave: Resumir, classificar, comparar, mapear, contrastar, exemplificar, interpretar, traduzir,
representar, inferir, concluir, categorizar.
0.7.2.1 Exemplos
Explique a razo pela qual os testes de segurana devem ser concebidos o mais cedo possvel:
Encontrar defeitos de segurana e vulnerabilidades quando eles so mais baratos para evitar a
construo de um sistema ou aplicativo propenso a patches contnuos de vulnerabilidades de
segurana.
0.7.3 Nvel 3: Aplicar (K3)

O candidato pode selecionar a aplicao correta de um conceito ou tcnica e aplic-lo a um dado contexto. K3
normalmente aplicvel ao conhecimento processual. No h nenhum ato criativo envolvido, como avaliar
um aplicativo de software ou criar um modelo para um determinado programa de software. Quando um
modelo fornecido, o programa explica as etapas processuais necessrias para criar casos de teste a partir
desse modelo, ento K3.
Palavras-chave: Implementar, executar, usar, seguir um procedimento, aplicar um procedimento.
0.7.3.1 Exemplo
Utilize o procedimento genrico para a criao de casos de teste de segurana para selecionar os casos
de teste de um dado diagrama de transio de estado para cobrir todas as transies.
0.7.4 Nvel 4: Analisar (K4)

O candidato pode separar informaes relacionadas a um procedimento ou tcnica em suas partes
constituintes para melhor compreenso, e pode distinguir entre fatos e inferncias. Aplicao tpica analisar
um documento, software, situao do projeto e propor aes adequadas para resolver um problema ou tarefa.
Palavras-chave: analisar, diferenciar, selecionar, estrutura, foco, atributo, desconstruir, avaliar, julgar,
monitorar, coordenar, criar, sintetizar, gerar, hiptese, plano, projeto, construir, produzir.
0.7.4.1 Exemplo
Analisar os riscos de segurana do produto e propor atividades preventivas e corretivas de mitigao.
Selecione as ferramentas de teste de segurana que seriam mais apropriadas em uma determinada
situao com falhas de segurana passadas.
Referncia (Para os nveis cognitivos dos objetivos de aprendizagem)
Bloom, B. S. (1956). Taxonomia de Objetivos Educacionais, Manual I: O Domnio Cognitivo, David
McKay, Co. Inc.
Anderson, L. W. e Krathwohl, D. R. (eds) (2001). Uma Taxonomia para Aprender, Ensinar e Avaliar:
Uma Reviso da Taxonomia de Bloom de Objetivos Educacionais, Allyn & Bacon.

1 A base do Teste de Segurana (105 min)
Palavras-chave
Privacidade do dado, hacker tico, segurana da informao, teste de penetrao, avaliao de risco,
exposio ao risco, mitigao do risco, ataque de segurana, auditoria de segurana, poltica de segurana,
procedimento de segurana, risco de segurana
Objetivos de Aprendizagem
1.1 Riscos de segurana
AS-1.1.1 (K2): Compreender o papel da avaliao de risco no fornecimento de informaes para o
planejamento de testes de segurana e modelagem e alinhamento de testes de segurana com as
necessidades do negcio.
AS-1.1.2 (K4): Identificar os ativos significativos a serem protegidos, o valor de cada ativo e os dados
necessrios para avaliar o nvel de segurana necessrio para cada ativo.
AS-1.1.3 (K4): Analisar a utilizao eficaz das tcnicas de avaliao de riscos numa dada situao para
identificar as ameaas atuais e futuras segurana.
1.2 Polticas e Procedimentos de Segurana da Informao
AS-1.2.1 (K2): Compreender o conceito de polticas e procedimentos de segurana e como eles so aplicados
em sistemas de informao.
AS-1.2.2 (K4): Analisar um determinado conjunto de polticas e procedimentos de segurana, juntamente com
os resultados dos testes de segurana para determinar a eficcia.
1.3 A auditoria de segurana e seu papel no teste de segurana
AS-1.3.1 (K2): Compreender a finalidade de uma auditoria de segurana.
Os testes funcionais baseiam-se em uma variedade de itens, como riscos, requisitos, casos de uso e modelos.
Os testes de segurana baseiam-se nos aspectos de segurana dessas especificaes, mas tambm buscam
verificar e validar os riscos de segurana, procedimentos e polticas de segurana, comportamento do invasor
e vulnerabilidades de segurana conhecidas.

1.1 Riscos de segurana
1.1.1 O Papel da Avaliao de Risco em Testes de Segurana
Os objetivos do teste de segurana so baseados em riscos de segurana. Estes riscos so identificados atravs
da realizao de uma avaliao de risco de segurana. Tcnicas gerais de gesto de risco so descritas em
[BSTQB_FL_SYL] e [BSTQB_ATM_SYL].
O risco uma medida da extenso em que uma entidade ameaada por uma circunstncia ou evento em
potencial, e tipicamente uma funo de:
Impactos adversos que ocorreriam se a circunstncia ou evento ocorrer,
Probabilidade da ocorrncia.
Os riscos de segurana da informao so aqueles que resultam da perda de confidencialidade, integridade
ou disponibilidade de informaes ou sistemas de informao e refletem os impactos adversos potenciais s
operaes organizacionais (i.e., misso, funes, imagem ou reputao), ativos organizacionais, outras
organizaes e um pas. [NIST 800-30]
O papel de uma avaliao de risco de segurana permitir que uma organizao compreenda quais reas e
ativos podem estar em risco e determinar a magnitude de cada risco. Para os testadores em segurana, uma
avaliao de risco de segurana pode ser uma rica fonte de informaes a partir da qual os testes de segurana
podem ser planejados e projetados. Alm disso, uma avaliao de risco de segurana pode ser usada para
priorizar testes de segurana para que o mais alto nvel de rigor de teste e cobertura, pode ser focada nas
reas com a grande exposio ao risco.
Ao priorizar os testes de segurana com base em uma avaliao de risco de segurana, os testes ficam
alinhados com os objetivos de segurana do negcio. No entanto, para que esse alinhamento ocorra, a
avaliao de risco de segurana deve refletir com preciso as ameaas de segurana da organizao, as partes
interessadas impactadas e os ativos a serem protegidos.
importante entender que qualquer avaliao de risco (de segurana ou de outra forma) apenas um
instantneo em um dado momento e com base em informaes limitadas que podem levar a suposies
invlidas e concluses. Riscos de segurana mudam continuamente dentro de uma organizao e projetos
desde novas ameaas surgem diariamente. Por conseguinte, as avaliaes dos riscos de segurana devem ser
efetuadas a intervalos regulares. O intervalo de tempo exato para a realizao de avaliaes de risco de
segurana varia com base na organizao e no grau de mudana que ela experimenta. Algumas organizaes
realizam avaliaes de risco de segurana em uma base de trs a seis meses, enquanto outros realiz-los em
uma base anual.
Outra questo com as avaliaes de risco o nvel de conhecimento dos participantes. Os riscos podem ser
perdidos devido falta de informaes detalhadas. Alm disso, os riscos podem ser perdidos se as pessoas
no entenderem ameaas e riscos de segurana. Por esta razo, bom para solicitar a entrada de uma
variedade de pessoas e prestar muita ateno ao nvel de detalhe contido na informao que eles fornecem.
uma expectativa realista que as suposies erradas podem ser feitas que podem conduzir aos riscos de
segurana importantes que so faltados na avaliao. Maneiras de lidar com a possibilidade de falta ou
incompleta de informaes de risco incluem o uso de uma metodologia de avaliao de risco de segurana
estabelecida como uma lista de verificao e recebendo a entrada de vrias pessoas. Uma tal metodologia
pode ser encontrada em [NIST 800-30].

1.1.2 Identificao de ativos
Nem todas as informaes a serem protegidas esto em formato digital, como documentos copiados
(contratos, planos, notas escritas, logins e senhas em forma escrita). Embora no estando em formato digital,
esta informao pode ter alto valor. Portanto, a pergunta precisa ser feita, qual informao digital e qual
no o ? Talvez o bem a ser protegido exista tanto em formato digital quanto fsico. Ao identificar os ativos
a serem garantidos, devem ser feitas as seguintes perguntas:
Quais ativos so valiosos para a organizao?
Exemplos de informaes sensveis de alto valor incluem:
Dados do cliente
Planos de negcios
Software proprietrio desenvolvido pela empresa
Documentao do sistema
Imagens e diagramas que so propriedade da empresa
Propriedade intelectual (por exemplo, processos, segredos comerciais)
Planilhas financeiras
Apresentaes e cursos de formao
Documentos
E-mails
Registros de funcionrios
Declaraes fiscais
Embora muitos ativos sejam baseados na informao, possvel que alguns ativos em uma organizao sejam
de natureza fsica ou intangvel. Exemplos desses ativos incluem:
Prottipos fsicos de novos dispositivos em desenvolvimento
A capacidade de prestar servios
Reputao e confiana da empresa
Qual o valor do ativo?
Muitos ativos sensveis tm um valor tangvel. Outros so medidos mais nos custos e nas consequncias de
sua perda. Por exemplo, o que um competidor faria com o plano de negcios de um rival?
Valor pode ser difcil de avaliar com certeza, entretanto, alguns mtodos para determinar o valor de ativos
digitais incluem:
A receita futura a ser gerada pelo ativo
O valor para um concorrente que pode obter as informaes
O tempo e o esforo necessrios para recriar o ativo
Multas e penalidades por no poderem produzir a informao quando necessrio, por exemplo, para
uma auditoria ou ao judicial
Multas e multas por perda de dados de clientes
Onde esto localizados os ativos digitais?
No passado, os ativos digitais residiam em servidores, computadores de mesa ou perifricos, como discos ou
CDs. Embora esta seja uma abordagem desatualizada e desorganizada, ainda pode haver dados sensveis em
CDs, DVDs e drives USB antigos. Um meio mais seguro de armazenar ativos digitais o uso de servidores
corporativos seguros, usando criptografia forte para todos os dados confidenciais. Para acessar dados
confidenciais armazenados em servidores seguros, a autenticao e a autorizao devem ser necessrias.

Alm disso, pode ser necessria outra proteo de segurana, como certificados digitais para acessar
informaes confidenciais pela Internet.
Armazenamento est mudando. Agora, grandes quantidades de dados de negcios podem existir em
dispositivos mveis, como smartphones e tablets. Se as informaes digitais foram migradas para
armazenamento em nuvem, haver um novo conjunto de preocupaes de segurana com base no acesso a
dados.
A importncia da questo do armazenamento de dados surge de casos passados em que as pessoas de
confiana, com acesso a dados sensveis, simplesmente saram de um edifcio da empresa com um disco rgido
cheio de dados de clientes privados e de negcios. Um desses casos nos Estados Unidos envolveu um disco
rgido roubado de uma rea protegida em uma agncia de segurana do governo, que incluiu folha de
pagamento e informaes bancrias para mais de 100.000 trabalhadores atuais e antigos. [Washington Post,
2007].
Como so acessados os ativos digitais?
Os mtodos comuns para acessar ativos digitais incluem:
Acesso do computador atravs de uma rede de rea local ou redes Wi-Fi
Acesso remoto atravs de uma rede privada virtual (VPN) ou unidade Cloud
Passando armazenamentos fsicos de dados (CDs, DVDs, pendrivers) de pessoa para pessoa, o que
uma prtica de baixa tecnologia, mas muito comum
Envio de arquivos por e-mail
Como os ativos digitais so protegidos?
Existem vrias maneiras de proteger ativos digitais, incluindo:
Criptografia (Que tipo e fora, quem tem as chaves?)
Autenticao e tokens (So necessrios certificados digitais? As polticas de senha so adequadas e
seguidas?)
Autorizao (Que nveis de privilgio foram concedidos aos usurios que lidam com ativos digitais?)
1.1.3 Anlise das Tcnicas de Avaliao de Risco
O processo de avaliao de riscos de segurana muito semelhante a uma avaliao de risco padro, com a
principal diferena sendo o foco em reas relacionadas segurana.
Uma avaliao de risco de segurana deve incluir as perspectivas de partes interessadas no teste de segurana
externa (ou seja, pessoas ou partes envolvidas no projeto ou com o produto que esto fora da empresa e tm
uma participao clara na segurana do projeto/produto). Estas partes interessadas incluem:
Clientes e usurios teis para entender a perspectiva, obter entrada para testes de segurana e
estabelecer boas comunicaes
O pblico e a sociedade. Importante para transmitir que a segurana da informao um esforo e
uma responsabilidade da comunidade
Agncias reguladoras. Necessrias para assegurar o cumprimento das leis aplicveis em matria de
segurana da informao
A preparao para uma avaliao de risco inclui as seguintes tarefas [NIST 800-30]:
Identificar o propsito da avaliao
Identificar o escopo da avaliao
Identificar os pressupostos e constrangimentos associados avaliao
Identificar as fontes de informao a serem utilizadas como insumos para a

Identificar o modelo de risco e abordagens analticas (isto , abordagens de avaliao e anlise) a
serem empregadas durante a avaliao
A realizao de avaliaes de risco inclui as seguintes tarefas especficas [NIST 800-30]:
Identificar fontes de ameaas relevantes para a organizao
Identificar os eventos de ameaa que poderiam ser produzidos por essas fontes
Identificar vulnerabilidades dentro da organizao que poderiam ser exploradas por fontes de
ameaas atravs de eventos de ameaa especficos e as condies predisponentes que poderiam
afetar a explorao bem-sucedida
Determinar a probabilidade de as fontes de ameaa identificadas iniciarem eventos de ameaa
especficos e a probabilidade de que os eventos de ameaa sejam bem-sucedidos
Determinar os impactos adversos s operaes e bens organizacionais, aos indivduos, a outras
organizaes e nao resultante da explorao de vulnerabilidades por ameaas
A comunicao e a partilha de informaes consistem nas seguintes tarefas especficas [NIST 800-30]:
Comunicar os resultados da avaliao de risco
Compartilhar informaes desenvolvidas na execuo da avaliao de risco para apoiar outras
atividades de gerenciamento de risco
1.2 Polticas e Procedimentos de Segurana da Informao

1.2.1 Compreendendo Polticas e Procedimentos de Segurana
comum que as polticas de segurana da informao variem entre as organizaes com base no modelo de
negcio, na indstria especfica e nos riscos de segurana nicos enfrentados pela organizao. Mesmo com
uma ampla variao, os objetivos das polticas de segurana so semelhantes. A base de todas as polticas de
segurana deve ser uma avaliao de risco de segurana que examina ameaas de segurana especficas e
como elas afetam a organizao. [Jackson, 2010]
Exemplos de polticas de segurana incluem, mas no esto limitados a [Jackson, 2010]:
Uso Aceitvel: Esta poltica define prticas que um usurio de um sistema de computador deve aderir para
ser compatvel com as polticas e procedimentos de segurana da organizao. Esta poltica abrange
comportamentos aceitveis e no aceitveis no uso de recursos digitais, como redes, sites e dados. Alm disso,
a poltica pode ser aplicada a usurios internos e externos dos sistemas de uma organizao. importante que
os usurios do sistema compreendam e sigam a poltica em todos os momentos. Para evitar confuses e
violaes acidentais da poltica, deve definir regras especficas relativas a comportamento aceitvel,
comportamento inaceitvel e comportamento exigido.
Acesso Mnimo: Esta poltica define os nveis mnimos de acesso necessrios para executar determinadas
tarefas. O objetivo desta poltica impedir que as pessoas recebam direitos de acesso superiores ao necessrio
para executar suas tarefas. Ter direitos de acesso mais altos do que o necessrio pode fornecer oportunidades
para abuso inadvertido ou intencional de privilgios de usurio.
Acesso Rede: Esta poltica define critrios para acessar vrios tipos de redes, como redes de rea local (LANs)
e redes sem fio. Alm disso, esta poltica pode definir o que permissvel e no permitido enquanto na rede.
Esta poltica, muitas vezes, probe os usurios de adicionar dispositivos no autorizados, como roteadores e
hot spots para a rede.
Acesso Remoto: Esta poltica requer o que necessrio para que o acesso remoto rede possa ser concedido
tanto a funcionrios internos como a usurios externos (no-funcionrios). O uso de VPN muitas vezes
coberto nesta poltica.

Acesso Internet: Esta poltica define o uso permitido da Internet pelos funcionrios e convidados de uma
organizao. O escopo desta poltica inclui os tipos de sites que podem e no podem ser acessados, como sites
de jogos de azar ou pornografia, e tambm aborda se a utilizao no comercial da Internet permitida.
Embora alguns dos itens cobertos na poltica tambm possam ser abordados na poltica de uso aceitvel,
algumas organizaes optam por definir essa poltica separadamente por causa do nmero de pessoas que
fazem negcios na Internet.
Gerenciamento de Conta de Usurio: Esta poltica define a criao, manuteno e excluso de contas de
usurio. A auditoria regular das contas de usurio tambm est coberta nesta poltica para garantir o
cumprimento da poltica.
Classificao de Dados: H muitas maneiras de classificar dados de uma perspectiva de segurana. Neste
programa, o termo "dados sensveis" usado como um termo geral para quaisquer dados que devem ser
protegidos para evitar perda. Uma poltica de classificao de dados define os diferentes tipos de dados que
so considerados sensveis e devem ser protegidos. Por ter uma poltica de classificao de dados, uma
organizao pode criar controles para proteger os dados com base em seu valor para a organizao e seus
clientes. Normalmente, a rea de negcios que cria os dados responsvel por sua classificao baseada em
uma estrutura de classificao padro.
O seguinte um exemplo de estrutura de classificao de dados (a partir de um contexto de negcios):
Pblico: Qualquer pessoa, dentro ou fora da organizao, pode visualizar esses dados (por exemplo,
documentos voltados para fora e pginas da Web).
Confidencial: Esta normalmente a classificao padro para todos os documentos criados
internamente. Esses documentos podem incluir e-mails, relatrios e apresentaes que so usados
internamente na organizao. Um exemplo disto seria um relatrio de vendas. Apenas os utilizadores
autorizados destes dados devem poder trabalhar com este nvel de informao. Contratos de no
divulgao so muitas vezes necessrios antes de compartilhar esse tipo de informao com terceiros,
como consultores.
Altamente confidencial: este um nvel mais elevado de confidencialidade para informaes sensveis
que devem estar disponveis apenas para certas pessoas na organizao. Isso inclui informaes como
segredos comerciais, planos estratgicos, projetos de produtos e dados financeiros no-pblicos. O
compartilhamento deste tipo de dados no permitido exceto com permisso explcita do
proprietrio dos dados.
Privado: Trata-se de informaes que so frequentemente restritas a funcionrios da organizao que
devem ser especificamente autorizados a ter acesso a ele. Se divulgadas, essas informaes podem
ter um impacto negativo importante, como danos financeiros, para a organizao. Devido ao alto risco
associado perda, a informao privada deve ser protegida com extremo cuidado. Esses dados podem
incluir informaes de pesquisa e desenvolvimento, planos de fuso e aquisio, bem como
informaes de clientes, como informaes de carto de crdito e de conta.
Segredo: No contexto corporativo, trata-se de informaes que uma organizao recebe de uma parte
externa para fazer alteraes, mas que no permitido tornar-se conhecido dentro ou fora da
organizao. Um exemplo no contexto corporativo seria um documento de projeto criado por um
consultor trabalhando em um novo tipo de tecnologia que envolve a colaborao de outras empresas,
cada uma das quais deve manter as informaes em um nvel secreto at que a tecnologia esteja
pronta para ser revelada. comparvel a altamente confidencial com a diferena que pode no ter
nenhum valor tangvel para a prpria organizao. A este respeito, diferente de um segredo
comercial. No entanto, a divulgao de informaes secretas pode causar danos organizao, outras
organizaes ou o pas. No contexto militar e governamental, trata-se de informaes que podem ser
desenvolvidas ou obtidas, mas devem ser conhecidas apenas por pessoas com certos nveis de
habilitao de segurana. No contexto militar, incluiria dados de projetos cientficos ou de pesquisa

que incorporassem novos desenvolvimentos tecnolgicos ou tcnicas com aplicaes militares de
importncia vital para a defesa nacional.
Gerenciamento de Configurao e Mudana: Esta poltica pode ter um contexto operacional normal, como
descrever como as alteraes aos sistemas so gerenciadas e configuradas, a fim de evitar interrupes devido
a impacto inesperado. Do ponto de vista de segurana, o gerenciamento de configurao controla como as
configuraes de segurana so aplicadas a dispositivos e aplicativos seguros. O risco que uma alterao no
autorizada em um dispositivo seguro pode causar uma vulnerabilidade de segurana que pode ser detectada.
Outro risco que uma alterao no autorizada no cdigo ou na configurao do aplicativo pode criar uma
vulnerabilidade de segurana. Essa poltica inclui configuraes padro a serem usadas, um processo de
aprovao para todas as alteraes e um processo de reverso se ocorrerem problemas. Esta poltica pode se
aplicar a todos os servios de TI, aplicativos e dispositivos em uma organizao.
Segurana do Servidor: Esta poltica confere responsabilidade ao(s) proprietrio(s) do servidor para seguir
prticas de segurana corporativa, bem como prticas recomendadas da indstria para instalar, configurar e
operar servidores e sistemas. Alm disso, as configuraes de linha de base devem ser definidas e mantidas.
Exemplos de prticas descritas nesta poltica incluem requisitos de segurana, backup e recuperao e
limitao de servios ativos aos necessrios para executar aplicativos. Tambm includos nessa poltica podem
ser requisitos de monitoramento e auditoria para garantir que o servidor esteja configurado e atualizado
corretamente.
Dispositivos Mveis: Os dispositivos mveis tm um conjunto nico de preocupaes de segurana, portanto,
uma poltica separada pode ser necessria apenas para dispositivos mveis. Por exemplo, laptops e telefones
inteligentes podem ser facilmente perdidos ou roubados, o que pode resultar em perda de dados da empresa
e privados. Estes dispositivos tambm tm um alto risco de contato com malwares. Esses riscos exigem regras
e precaues especficas que devem ser seguidas para mitigar os riscos e limitar a exposio da organizao a
ameaas de segurana. Esta poltica pode incluir requisitos para os quais os dados devem ser criptografados,
a instalao e manuteno de verses atuais do software anti-malware e quando as senhas so necessrias
para acessar o dispositivo. Alm disso, os tipos de informaes organizacionais que podem residir em
dispositivos mveis so definidos nesta poltica. A segurana fsica tambm pode ser abordada, como ter
bloqueios de cabo para computadores portteis e ter procedimentos para relatar dispositivos perdidos ou
roubados.
Acesso de Convidado: Essa poltica define as prticas que devem ser implementadas para proteger a
organizao, permitindo que a empresa hospede convidados e outras pessoas em redes organizacionais. Um
aspecto desta poltica exigir que os hspedes leiam e aceitem polticas de uso aceitveis antes de conceder
acesso rede. Essa poltica pode ser implementada de vrias maneiras, como fazer com que os clientes
assinem uma poltica de uso aceitvel, e fornecer a eles um cdigo para acesso temporrio. A principal
inteno desta poltica reforar os padres de segurana da organizao e ainda fornecer procedimentos
para permitir que os hspedes acessem a rede ou a Internet.
Segurana Fsica: Esta poltica define os controles necessrios para instalaes fsicas, uma vez que estar em
proximidade fsica com dispositivos seguros pode aumentar o risco de violao de segurana. Esta poltica
tambm pode cobrir outros riscos, tais como perda de energia, roubo, incndio e desastres naturais. Tambm
abordado aqui quais os dispositivos podem ser retirados ou trazidos para a empresa, especialmente para as
reas que abrigam informaes sensveis.
Poltica de Senhas: Esta poltica define os requisitos mnimos para senhas fortes e outras prticas seguras de
senha, como o perodo de tempo permitido entre as alteraes de senha obrigatrias, como as pessoas
protegem a privacidade de suas senhas (como no usar o recurso "lembrar senha" Navegadores, proibindo o
compartilhamento de senhas e proibindo a transmisso de senhas por e-mail). Esta poltica pode ser aplicada
a aplicativos, contas de usurio e outros locais onde as senhas so necessrias.

Proteo contra Malware: Esta poltica define uma estrutura de defesas e comportamentos para prevenir,
detectar e remover malwares. Uma vez que o malware e o spyware podem ser apanhados a partir de uma
variedade de fontes, esta uma poltica importante para que todos na organizao compreendam e sigam.
Por exemplo, esta poltica pode restringir o uso de unidades USB.
Resposta a Incidentes: Esta poltica descreve como responder a um incidente relacionado segurana. Esses
incidentes podem variar desde a descoberta de malwares e violaes da poltica de uso aceitvel at o acesso
no autorizado a dados confidenciais. importante que esta poltica seja implementada antes que ocorra um
incidente para evitar ter que determinar as respostas apropriadas caso a caso. Esta poltica tambm aborda a
comunicao, incluindo as respostas dos meios de comunicao e notificao de aplicao da lei.
Poltica de Auditoria: Esta poltica autoriza os auditores a solicitar acesso a sistemas com a finalidade de
realizar uma auditoria. A equipe de auditoria pode precisar de acesso a dados de log, registros de trfego de
rede e outros dados forenses.
Licenciamento de Software: Esta poltica aborda como a organizao obtm e licencia o software que utiliza.
Se as licenas de software comercial forem violadas, a organizao corre o risco de multas e aes legais.
Devido a isso, importante que as licenas sejam identificadas e monitoradas. Fazer o download e instalar
software no aprovado uma proibio fundamental frequentemente encontrada nesta poltica.
Monitoramento Eletrnico e Privacidade: As organizaes tm o direito e a responsabilidade de monitorar as
comunicaes eletrnicas em todo o hardware e recursos da empresa. Isso inclui correspondncia de e-mail
e mdias sociais. Esta poltica descreve qual o monitoramento realizado pela organizao e quais dados esto
sujeitos coleta. Leis variam entre os pases, por isso necessrio aconselhamento jurdico antes de escrever
esta poltica. [Jackson, 2010]
1.2.1.1 Procedimentos de segurana
Os procedimentos de segurana especificam as etapas a serem tomadas na implementao de uma poltica
ou controle especfico e as etapas a serem tomadas em resposta a um incidente de segurana especfico.
Procedimentos formais e documentados facilitam a implementao das polticas de segurana e controles
obrigatrios.
As polticas, normas e diretrizes descrevem os controles de segurana que devem estar em vigor, enquanto
um procedimento descreve detalhes especficos, explicando como implementar os controles de segurana
passo a passo. Por exemplo, um procedimento poderia ser escrito para explicar como conceder nveis de
acesso de usurio, detalhando cada passo que precisa ser tomado para garantir o nvel correto de acesso
concedido para que os direitos de usurio satisfaam a poltica, normas e diretrizes aplicveis.
1.2.2 Anlise de Polticas e Procedimentos de Segurana

Antes de avaliar um conjunto de polticas e procedimentos de segurana, importante determinar o(s)
objetivo(s) da avaliao e definir um conjunto de critrios para avaliar a adequao das polticas e
procedimentos. Em alguns casos, os critrios podem ser definidos por padres como COBIT [COBIT], ISO27001
[ISO27001] ou PCI [PCI].
Alm disso, necessrio definir:
Que recursos so necessrios em termos de competncias e conhecimentos em reas especficas a
serem avaliadas
Como medir a adequao das polticas e procedimentos
O que medir e avaliar (por exemplo, eficcia, eficincia, usabilidade, adoo)
Onde as polticas e procedimentos esto localizados na organizao
Uma lista de verificao para orientar a avaliao

A lista de verificao funciona como um guia que direciona o auditor onde procurar e o que esperar.
Ferramentas, como ferramentas de auditoria de senha, podem ser teis no teste de determinados controles
para determinar se esto cumprindo seus objetivos e gerar dados que podem ser usados posteriormente na
avaliao de riscos. O auditor olha para encontrar a conformidade da "prova" s polticas, aos controles e s
normas.
Algumas das tarefas na lista a seguir so de natureza esttica, enquanto outras, como a observao de
processos em ao, so dinmicas. O auditor faz o seguinte:
Revisa a documentao do sistema
Entrevista as pessoas sobre a sua percepo da eficcia das polticas e procedimentos
Entrevistas com pessoal-chave envolvido nos processos que esto sendo controlados
Sistemas de testemunhas e processos sendo realizados
Analisa resultados de auditoria anteriores para descobrir tendncias
Analisa logs e relatrios
Revisa a configurao do controle tcnico, como configurao do firewall e configurao do sistema
de deteco de intruso
Amostra de transaes de dados para quaisquer anomalias ou transaes suspeitas [Jackson, 2010]
1.2.2.1 Controles
Os controles de segurana so salvaguardas tcnicas ou administrativas ou contramedidas para evitar,
neutralizar ou minimizar a perda ou indisponibilidade devido a ameaas que agem em sua vulnerabilidade
correspondente, ou seja, risco de segurana [Northcutt, 2014]. Por exemplo, um controle de segurana em
um sistema de folha de pagamento pode ser que duas pessoas devem aprovar separadamente uma alterao
nas informaes de remunerao de um empregado. Testadores em segurana devem estar cientes dos
controles especficos em sua organizao e incluir testes para eles nos testes de segurana.
Os principais tipos de controle de segurana so administrativos, tcnicos e fsicos. Em cada categoria, os
controles especficos que podem ser implementados so preventivos, detectives, corretivos ou de
recuperao. Esses tipos de controle funcionam em conjunto e, em geral, os controles devem ser fornecidos
de cada categoria para proteger efetivamente um ativo. [Jackson, 2010]
Uma lista dos 20 principais controles crticos de segurana pode ser encontrada em www.sans.org. [Web-1]
1.2.2.2 Testes de segurana
A principal diferena nos testes de segurana em comparao com uma anlise esttica de polticas e
procedimentos de segurana a utilizao dos resultados de testes concebidos especificamente para verificar
ou validar a eficcia das polticas e procedimentos de segurana. Esses testes se concentram no risco de que
uma poltica de segurana pode estar em vigor, pode ser seguido, mas no eficaz na proteo de ativos.
Tambm possvel ser informado durante a execuo das avaliaes de polticas e procedimentos de
segurana que determinadas tarefas so executadas. Um teste de segurana dessas tarefas pode ajudar a
determinar a eficcia das polticas e procedimentos de segurana na prtica. Por exemplo, uma poltica e
procedimento de senha pode parecer razovel e eficaz no papel, mas quando uma ferramenta de quebra de
senhas usada, o procedimento pode ficar aqum de seus objetivos.
As polticas e procedimentos de segurana podem ser uma fonte de testes de segurana, no entanto, o
testador em segurana deve ter em mente que os ataques esto sempre evoluindo. Novos ataques surgem e,
assim como em qualquer aplicativo de software, novos defeitos podem tornar-se evidente - todos os quais
so razes para realizar testes de segurana a partir da mentalidade atacante.

1.3 A auditoria de segurana e seu papel no teste de segurana
A auditoria de segurana um exame e uma avaliao manual que identificam deficincias nos processos e
na infraestrutura de segurana de uma organizao. As auditorias de segurana a nvel processual (por
exemplo, para rever os controles internos) podem ser realizadas manualmente. As auditorias de segurana no
nvel arquitetural so muitas vezes realizadas com ferramentas de auditoria de segurana, que podem ser
alinhadas com uma soluo de fornecedor especfica para redes, arquitetura de servidor e estaes de
trabalho.
Assim como os testes de segurana, uma auditoria de segurana no garante que todas as vulnerabilidades
sero encontradas. No entanto, a auditoria mais uma atividade no processo de segurana para identificar
reas problemticas e indicar onde a remediao necessria.
Em algumas abordagens de auditoria de segurana, o teste executado como parte do processo de auditoria.
No entanto, o escopo da auditoria de segurana muito maior do que os testes de segurana. A auditoria de
segurana geralmente investiga reas como procedimentos, polticas e controles que so difceis de testar de
forma direta. Os testes de segurana esto mais envolvidos com as tecnologias de suporte segurana, como
configurao de firewall, aplicao correta de autenticao e criptografia e aplicao de direitos de usurio.
Existem cinco pilares para a auditoria de segurana [Jackson, 2010]:
Avaliao: As avaliaes documentam e identificam ameaas potenciais, ativos-chave, polticas e
procedimentos e tolerncia da gerncia ao risco. As avaliaes no so eventos nicos. Uma vez que o
ambiente e as empresas esto constantemente em fluxo, avaliaes devem ser realizadas em uma base
regular. Isso tambm fornece a oportunidade de saber se as polticas de segurana ainda so relevantes e
eficazes.
Preveno: Isso vai alm da tecnologia e inclui controles administrativos, operacionais e tcnicos. A preveno
no realizada apenas atravs da tecnologia, mas tambm atravs de polticas, procedimentos e
conscientizao. Embora a preveno de todos e quaisquer ataques no seja realista, a combinao de defesas
pode ajudar a tornar muito mais difcil para um atacante ter sucesso.
Deteco: Deteco como uma violao de segurana ou intruso identificada. Sem mecanismos de
deteco adequados, existe o risco de no saber se a rede foi comprometida. Controles espies ajudam a
identificar incidentes de segurana e fornecem visibilidade em atividades na rede. A deteco precoce de
incidentes permite uma reao adequada para recuperar servios rapidamente.
Reao: O tempo de reao muito reduzido com boas defesas de segurana e mecanismos de deteco.
Embora as violaes de segurana sejam ms notcias, importante saber se ocorreu uma. O tempo de reao
rpida crtico para minimizar a exposio ao incidente. Reao rpida requer boas defesas preventivas e
mecanismos de deteco para fornecer os dados e o contexto necessrio para a resposta. A velocidade e a
eficincia da resposta a incidentes um indicador-chave da eficcia dos esforos de segurana de uma
organizao.
Recuperao: A recuperao comea com a determinao do que ocorreu para que os sistemas possam ser
recuperados sem recriar a mesma vulnerabilidade ou condio que causou o incidente, em primeiro lugar. A
fase de recuperao no termina com a restaurao do sistema. H tambm a anlise de causa raiz que
determina quais mudanas precisam ser feitas para processos, procedimentos e tecnologias para reduzir a
probabilidade do mesmo tipo de vulnerabilidade no futuro. Um auditor deve assegurar-se de que a
organizao tenha um plano de recuperao que inclua formas de prevenir futuros incidentes semelhantes.
1.3.1 Finalidade de uma Auditoria de Segurana

O seguinte uma lista de itens que podem ser detectados em uma auditoria de segurana:

Segurana fsica inadequada: Uma poltica de segurana pode exigir a criptografia de todos os dados
do cliente, tanto em armazenamento quanto em transmisso. Por exemplo, durante a auditoria,
descobre-se que uma vez por semana, um arquivo de informaes do cliente enviado por relatrio
fsico a todos os gerentes. Este relatrio descartado todas as semanas, mas descobriu-se que alguns
gerentes esto lanando os relatrios fsicos no lixo, onde podem ser encontrados por qualquer
pessoa que queira passar pelo lixo (ou seja, "dumpster diving").
Manuteno de senha inadequada: Uma poltica de segurana pode exigir que cada usurio altere
sua senha a cada 30 dias. Uma auditoria de segurana revela que as senhas so alteradas, mas muitos
usurios simplesmente alternam entre "PasswordA" e "PasswordB" a cada ms. (O histrico de senhas
uma caracterstica comum nas ferramentas de auditoria de senhas.)
Controles inadequados para direitos de usurio e privilgios de compartilhamento. Um exemplo de uma
concluso negativa poderia ser quando os usurios tiveram mais direitos de acesso aos itens do que eles
precisam para executar seu trabalho. Outro exemplo pode ser quando os arquivos de um usurio individual
so compartilhados na rede quando devem ser privados. Esta uma preocupao particular para os usurios
com PCs notebook e especialmente aqueles que acessam a intranet atravs de conexes Wi-Fi em casa ou em
locais pblicos.
Segurana inadequada no nvel do servidor. As reas de auditoria especficas incluem:
Atribuio e segurana dos portos
Proteo de dados
Proteo de contas de usurio (logins e outras informaes sensveis)
Aplicao inadequada de atualizaes de segurana de fornecedores
Mecanismos de deteco de intruso inadequados
Planos de resposta inadequados em caso de violao de segurana
1.3.2 Identificao, Avaliao e Mitigao de Riscos

Uma vez que as reas problemticas foram identificadas pela auditoria, o risco deve ser avaliado e um plano
de melhoria deve ser implementado. O relatrio do auditor pode incluir recomendaes, bem como outras
reas de risco. A partir deste ponto, as atividades de identificao, avaliao e mitigao de riscos podem ser
planejadas.
Identificao de risco o processo de documentao de um risco ou uma rea de risco. No contexto da
segurana de TI, os riscos so relacionados segurana. A avaliao de risco a atividade que atribui um valor
aos riscos identificados. importante entender que os modelos tradicionais de avaliao de riscos de TI no
so suficientes para enfrentar os riscos de segurana de TI. Qualquer modelo ou abordagem de avaliao de
riscos de segurana deve ser orientado especificamente para perfis de risco de segurana de TI.
Riscos de segurana muitas vezes so medidos em termos de exposio ao risco. A exposio ao risco
calculada multiplicando o impacto ou perda potencial pela probabilidade de ocorrncia dessa perda. Por
exemplo, se as informaes da conta de um cliente estiverem comprometidas, qual seria o impacto? E se esse
cliente tivesse $ 100 milhes de ativos em depsito?
A probabilidade de ocorrncia pode ser determinada pela aplicao de um modelo de avaliao de risco de
segurana como o encontrado no Guia para Realizao de Avaliaes de Risco [NIST 800-30]. Outro excelente
guia para realizar avaliaes de risco de segurana a Metodologia de Avaliao de Risco OWASP [OWASP2].
As informaes a seguir so extradas do [NIST 800-30].
Os modelos de risco definem os fatores de risco a serem avaliados e as relaes entre esses fatores. Os fatores
de risco so caractersticas utilizadas em modelos de risco como insumos para determinar os nveis de risco
nas avaliaes de risco. Fatores de risco tambm so usados extensivamente em comunicaes de risco para
destacar o que afeta fortemente os nveis de risco em situaes, circunstncias ou contextos particulares.

Fatores de risco tpicos incluem ameaa, vulnerabilidade, impacto, probabilidade e condio predisponente.
Os fatores de risco podem ser decompostos em caractersticas mais detalhadas (por exemplo, ameaas
decompostas em fontes de ameaas e eventos de ameaa). Essas definies so importantes para que as
organizaes documentem antes de realizar avaliaes de risco porque as avaliaes dependem de atributos
bem definidos de ameaas, vulnerabilidades, impacto e outros fatores de risco para efetivamente determinar
o risco.
1.3.2.1 Ameaas
Uma ameaa qualquer circunstncia ou evento com o potencial de afetar adversamente as operaes
organizacionais e os bens, indivduos, outras organizaes ou um pas por meio de um sistema de informao
por acesso no autorizado, destruio, divulgao ou modificao de informaes e / ou negao de servio.
Os eventos de ameaa so causados por fontes de ameaas. Uma fonte de ameaa caracterizada como:
A inteno e o mtodo visando a explorao de uma vulnerabilidade; ou
Uma situao e um mtodo que podem explorar acidentalmente uma vulnerabilidade.
Em geral, os tipos de ameaas incluem:
Hostil cyber ou ataques fsicos
Erros humanos de omisso ou comisso
Falhas estruturais de recursos controlados pela organizao (por exemplo, hardware, software,
controles ambientais)
Desastres naturais, causados pelo homem, acidentes e fracassos que escapam ao controle da
organizao.
Vrias taxonomias de fontes de ameaas foram desenvolvidas. Algumas taxonomias de fontes de ameaas
usam o tipo de impactos adversos como um princpio organizador. Vrias fontes de ameaas podem iniciar ou
causar o mesmo evento de ameaa - por exemplo, um servidor de provisionamento pode ser desconectado
por um ataque de negao de servio, um ato deliberado por um administrador de sistema mal-intencionado,
um erro administrativo, uma falha de hardware ou uma falha de hardware. Falha de energia.
1.3.2.2 Vulnerabilidades e Condies predispostas
Uma vulnerabilidade uma fraqueza em um sistema de informao, procedimentos de segurana do sistema,
controles internos ou implementao que poderiam ser explorados por uma fonte de ameaa.
A maioria das vulnerabilidades do sistema de informao pode ser associada a controles de segurana que
no foram aplicados (intencionalmente ou no), ou que foram aplicados, mas mantm alguma fraqueza. No
entanto, tambm importante permitir a possibilidade de vulnerabilidades emergentes que podem surgir
naturalmente ao longo do tempo como misses organizacionais, evoluo de funes de negcios, mudanas
em ambientes de operao, novas tecnologias proliferam e novas ameaas surgem. No contexto de tais
alteraes, os controles de segurana existentes podem tornar-se inadequados e podem ter de ser reavaliados
para efeitos de eficcia. A tendncia de controles de segurana potencialmente degradarem a eficcia ao
longo do tempo refora a necessidade de manter avaliaes de risco durante todo o ciclo de vida do software
e tambm a importncia dos programas de monitorizao contnua para obter uma conscincia situacional
contnua da postura de segurana organizacional.
Vulnerabilidades no so identificadas apenas dentro dos sistemas de informao. Vendo os sistemas de
informao em um contexto mais amplo, as vulnerabilidades podem ser encontradas nas estruturas de
governana organizacional (por exemplo, a falta de estratgias eficazes de gerenciamento de risco e
enquadramento de risco adequado, comunicaes intra-agncias pobres, decises inconsistentes sobre
prioridades relativas de misses/funes empresariais ou desalinhamento Da arquitetura corporativa para
apoiar a misso/atividades de negcios).

Vulnerabilidades tambm podem ser encontradas em relaes externas (i.e., dependncias de fontes de
energia especficas, cadeias de suprimento, tecnologias de informao e provedores de telecomunicaes),
processos de misso/negcios (por exemplo, processos ou processos mal definidos que no esto conscientes
do risco), Arquiteturas de segurana da informao (por exemplo, decises arquitetnicas pobres resultando
em falta de diversidade ou resilincia em sistemas de informao organizacional).
1.3.2.3 Impacto
O nvel de impacto de um evento de ameaa a magnitude do dano que pode ser esperado resultar das
consequncias de divulgao no autorizada de informaes, modificao no autorizada de informaes,
destruio desautorizada de informaes ou perda de informaes ou disponibilidade de sistema de
informao. Esse dano pode ser vivenciado por uma variedade de participantes organizacionais e no-
organizacionais, incluindo:
Chefes de agncias
Misso e empresrios
Proprietrios / comissrios de informao
Misso / proprietrios de processos de negcios
Proprietrios de sistemas de informao
Indivduos / grupos do setor pblico ou privado dependentes da organizao - em essncia, qualquer
pessoa com um interesse pessoal nas operaes, bens ou indivduos da organizao, incluindo outras
organizaes em parceria com a organizao ou um pas
As seguintes informaes devem ser explicitamente documentadas por uma organizao:
O processo usado para conduzir determinaes de impacto
Premissas relacionadas a determinaes de impacto
Fontes e mtodos para obter informaes sobre o impacto
A justificativa para as concluses alcanadas em relao s determinaes de impacto
As organizaes podem definir explicitamente como prioridades e valores estabelecidos orientam a
identificao de ativos de alto valor e os potenciais impactos adversos para os atores organizacionais. Se tais
informaes no forem definidas, as prioridades e os valores relacionados identificao de alvos de fontes
de ameaa e impactos organizacionais associados podem normalmente ser derivados do planejamento
estratgico e polticas. Por exemplo, os nveis de categorizao de segurana indicam os impactos
organizacionais de comprometer diferentes tipos de informao.
1.3.2.4 Probabilidade
A probabilidade de ocorrncia aborda a probabilidade (ou possibilidade) de que o evento de ameaa resulte
em um impacto adverso, independentemente da magnitude do dano que pode ser esperado. Este um fator
de risco ponderado baseado em uma anlise da probabilidade de que uma determinada ameaa capaz de
explorar uma determinada vulnerabilidade (ou conjunto de vulnerabilidades). O fator de risco de
probabilidade combina uma estimativa da probabilidade de que o evento de ameaa ser iniciado com uma
estimativa da probabilidade de impacto (ou seja, a probabilidade de que o evento de ameaa resulte em
impactos adversos).
Para as ameaas adversrias, uma avaliao da probabilidade de ocorrncia normalmente se baseia em:
Inteno do adversrio
Capacidade adversa
Segmentao adversria

Para eventos que no sejam adversrios, a probabilidade de ocorrncia estimada usando evidncias
histricas, dados empricos ou outros fatores. Observe que a probabilidade de que um evento de ameaa ser
iniciado ou ocorrer avaliada em relao a um perodo de tempo especfico (por exemplo, nos prximos seis
meses, no prximo ano ou no perodo at que um marco especificado seja atingido).
Se um evento de ameaa quase certo para ser iniciado ou ocorrer no prazo (especificado ou implcito), a
avaliao de risco pode levar em considerao a frequncia estimada do evento. A probabilidade de ocorrncia
de ameaas tambm pode ser baseada no estado da organizao (incluindo, por exemplo, sua misso bsica,
processos de negcios, arquitetura empresarial, arquitetura de segurana da informao, sistemas de
informao e ambientes nos quais esses sistemas operam. A presena e a eficcia dos controles de segurana
implantados para proteger contra o comportamento no autorizado ou indesejvel, detectar e limitar os
danos, e/ou manter ou restaurar as capacidades da misso ou negcio tambm devem ser levados em
considerao.
1.3.2.5 Determinao do Nvel de Risco de Segurana
A probabilidade de avaliao de ocorrncia e a avaliao de impacto podem ser combinadas para calcular uma
gravidade geral para o risco. As pontuaes de avaliao especficas podem ser utilizadas como base para a
concluso da matriz de risco. Em outros casos, estimativas (baixa, mdia ou alta) podem ser usadas.
A pontuao para a matriz de risco pode ser baseada numa escala de 0 a 9, onde os valores numricos so
determinados por critrios especficos. Por exemplo, os critrios de probabilidade de risco poderiam ser
avaliados quanto privacidade dos dados como:
Baixo (0 < 3): Os dados privados no so armazenados em dispositivos locais e so criptografados
quando armazenados em mdia segura.
Mdia (3 < 6): Os dados privados podem residir em dispositivos como computadores portteis, mas
so criptografados.
Alta (6 < 9): No se sabe exatamente se os dados particulares residem em dispositivos locais. A
criptografia no pode ser assegurada.
Da mesma forma, os critrios de impacto de risco poderiam ser avaliados na mesma escala de 0 a 9 com base
em critrios especficos. Por exemplo:
Baixo (0 < 3): Compromisso de dados privados teria impacto menos de 200 pessoas.
Mdio (3 < 6): Compromisso de dados privados teria impacto entre 200 e 1.000 pessoas.
Alto (6 < 9): Compromisso de dados privados teria impacto sobre 1.000 pessoas.
No entanto, o testador chega s estimativas de probabilidade e impacto, as estimativas podem ser combinadas
em uma classificao de severidade final para o item de risco. Se houver boas informaes de impacto nos
negcios, isso deve ser usado em vez das informaes de impacto tcnico. Se no houver nenhuma informao
sobre o negcio, ento o impacto tcnico a melhor coisa seguinte.
Abaixo est uma amostra de uma matriz de risco que pode ser usada para determinar a gravidade dos riscos
individuais.
Probabilidade
Gravidade Geral do Risco
Baixo Mdio Alto
Alto Mdio Alto Crtico
Impacto do Risco Mdio Mdio Mdio Alto
Baixo Baixo Baixo Mdio

Na matriz de exemplo acima, se a probabilidade mdia e o impacto alto, a gravidade geral alta.
Alm disso, o relatrio de avaliao de risco deve identificar se o risco est em curso. Riscos contnuos indicam
uma maior probabilidade de ocorrncia de perda.
A gravidade de um risco determina a importncia relativa da mitigao do risco. Quanto maior a gravidade do
risco, mais imediata a exigncia da resposta. O nvel de pormenor fornecido em qualquer avaliao de risco
em particular consistente com a finalidade da avaliao de risco e o tipo de insumos necessrios para apoiar
a determinao de verossimilhana e impacto subsequentes.
1.3.3 Pessoas, Processos e Tecnologia

H tambm trs componentes para as prticas de TI de uma organizao: pessoas, processos e tecnologia.
Todos estes tm um impacto na segurana. De acordo com Chris Jackson em seu livro, Network Security
Auditing [Jackson, 2010], "Todos os incidentes de segurana, para registros de clientes perdidos, geralmente
podem ser rastreados at uma deficincia que pode ser atribuda a pessoas, processos ou tecnologia."
Pessoas: as pessoas podem incluir usurios finais, administradores de sistema, proprietrios de dados e
gerentes da organizao. Cada pessoa tem diferentes nveis de habilidades, atitudes e agendas, o que
influencia a forma como a segurana as afeta e como elas afetam a eficcia dos controles de segurana.
Independentemente da presena de polticas de segurana, procedimentos e controles, eles sero ineficazes
se as pessoas no os seguir. Se as pessoas no seguem as polticas de segurana, pode haver uma necessidade
de esforos de remediao, como a necessidade de treinamento de conscientizao de segurana ou
penalidades por no-conformidade. As estruturas organizacionais e as polticas de segurana so muitas vezes
dirigidas por pessoas, tanto internas como externas a uma organizao.
Processo: os processos definem como os servios de TI, incluindo os servios relacionados segurana, so
entregues. Em um contexto de segurana, os processos incluem os procedimentos e padres que so
colocados em prtica para proteger ativos valiosos. Para serem eficazes, os processos devem ser definidos,
atualizados, consistentes e seguir as melhores prticas de segurana. Os processos definem funes e
responsabilidades, controles, ferramentas e etapas especficas envolvidas na execuo de uma tarefa.
Tecnologia: A tecnologia engloba as instalaes, equipamentos, hardware e software que automatizam ou
suportam um negcio. A tecnologia permite que as pessoas realizem trabalhos repetitivos mais rpido e com
menos erros do que se executado manualmente sem ele. Na verdade, algumas tarefas como a imposio de
senha seriam impossveis sem as ferramentas certas. O risco que a tecnologia usada incorretamente pode
ajudar as pessoas a cometer erros mais rapidamente.
Estas trs reas podem ser pensadas como um "tringulo de ferro", que juntos forma uma soluo completa
de TI. Se qualquer uma das trs reas so ignoradas, toda a entrega de TI e esforo de segurana sofre.
Ao avaliar os controles de segurana, o auditor deve olhar para um sistema na perspectiva de um invasor e
antecipar como as pessoas, processos ou tecnologias poderiam ser exploradas para obter acesso no
autorizado a ativos valiosos.
A gesto em uma organizao muitas vezes surpreendida nos mecanismos de segurana que pensavam ser
seguros, no os so. A nica maneira de saber com certeza se uma defesa de segurana especfica est
funcionando eficazmente testando o sistema de uma perspectiva do invasor. Isso muitas vezes conhecido
como hacking tico ou teste de penetrao.
aqui que a relao entre a auditoria e o teste se torna mais direta. A auditoria identifica deficincias e reas
de importncia para testar. Testes de segurana o meio pelo qual provado ou desmentido que os controles
de segurana esto realmente no lugar e trabalhando efetivamente.

Exemplo de cenrio:
A agncia fiscal de um pas objeto de uma auditoria de segurana. Uma das concluses da auditoria ser
possvel para os criminosos apresentar uma declarao fiscal fraudulenta e obter os reembolsos de imposto
devido ao contribuinte. Este achado de auditoria confirmado com testes de segurana e o risco classificado
como "crtico". A agncia fiscal reconhece a possibilidade de tal risco fraudulento, mas decide no agir sobre
o risco at o ano seguinte.
Contribuintes fraudados, que seguiram todos os procedimentos de segurana prescritos, podem apresentar
uma reclamao com a agncia fiscal que estava ciente do defeito no processo de arquivamento de imposto.
Neste caso, a agncia fiscal seria responsvel pela fraude.

2 Testes de Segurana Objetivos, Metas e Estratgias (130
min)
Palavras-Chave
cross-site scripting, mascaramento de dados, denial of service, garantia da informao, poltica de segurana,
teste de segurana, vulnerabilidade de segurana, ciclo de vida de software, estratgia de teste.
2.1 Introduo
Sem objetivos de aprendizado para esta seo.
2.2 O Propsito dos Testes de Segurana
AS-2.2.1 (K2): Entenda por que os testes de segurana so necessrios em uma organizao, incluindo
benefcios para a organizao, como reduo de risco e nveis mais altos de confiana e confiana
2.3 O Contexto Organizacional
AS-2.3.1 (K2): Entender como as realidades do projeto, as restries de negcios, o ciclo de vida do
desenvolvimento de software e outras consideraes afetam a misso da equipe de testes de segurana
2.4 Objetivos do Teste de Segurana
AS-2.4.1 (K2): Explique por que os objetivos e objetivos de testes de segurana devem estar alinhados com a
poltica de segurana da organizao e outros objetivos de teste na organizao
AS-2.4.2 (K3): Para um determinado cenrio de projeto, demonstre a capacidade de identificar objetivos de
teste de segurana com base em funcionalidade, atributos de tecnologia e vulnerabilidades conhecidas
AS-2.4.3 (K2): Compreender a relao entre a garantia de informao e os testes de segurana
2.5 mbito e Cobertura dos Objetivos de Testes de Segurana
AS-2.5.1 (K3): Para um determinado projeto, demonstre a capacidade de definir a relao entre os objetivos
do teste de segurana e a necessidade de resistncia da integridade de ativos digitais e fsicos sensveis
2.6 Abordagens de Testes de Segurana
AS-2.6.1 (K4): Analisar uma determinada situao e determinar quais abordagens de teste de segurana tm
maior probabilidade de sucesso
AS-2.6.2 (K4): Analisar uma situao em que uma tentativa de teste de segurana falhou, identificando as
provveis causas de falha
AS-2.6.3 (K3): Para um determinado cenrio, demonstre a capacidade de identificar as vrias partes
interessadas e ilustrar os benefcios dos testes de segurana para cada grupo de partes interessadas
2.7 Melhorar as Prticas de Testes de Segurana
AS-2.7.1 (K4): Analisar KPIs (indicadores-chave de desempenho) para identificar prticas de testes de
segurana que necessitam de aperfeioamento e elementos que no necessitam de melhorias

2.1 Introduo
Antes de aplicar tcnicas de teste de segurana especializadas, importante entender o contexto mais amplo
dos testes de segurana e seu papel dentro de uma determinada organizao. Este entendimento responde
s seguintes perguntas:
Por que necessrio o teste de segurana?
Qual a finalidade dos testes de segurana?
Como os testes de segurana se encaixam na organizao?
Testes de segurana diferem de outras formas de testes funcionais em duas reas significativas
[BSTQB_ATTA_SYL]:
1. Tcnicas padro para a seleo de dados de entrada de teste podem perder importantes questes de
segurana
2. Os sintomas de defeitos de segurana so muito diferentes dos encontrados com outros tipos de
testes funcionais
Os testes de segurana avaliam a vulnerabilidade de um sistema a ameaas ao tentar comprometer a poltica
de segurana do sistema. O seguinte uma lista de ameaas potenciais, que devem ser exploradas durante o
teste de segurana [BSTQB_ATTA_SYL]:
Cpia no autorizada de aplicativos ou dados
Controle de acesso no autorizado (por exemplo, capacidade de executar tarefas para as quais o
usurio no tem direitos). Direitos de usurio, acesso e privilgios so o foco deste teste. Essas
informaes devem estar disponveis nas especificaes do sistema.
Software que exibe efeitos colaterais no intencionais ao executar a funo pretendida. Por exemplo,
um reprodutor de mdia que reproduz corretamente udio, mas faz isso, escrevendo arquivos para
armazenamento temporrio no criptografado exibe um efeito colateral, que pode ser explorado por
piratas de software.
Cdigo inserido em uma pgina da Web que pode ser acessado por outros usurios (cross-site scripting
ou XSS). Este cdigo pode ser malicioso.
Estouro de memria intermediria (saturao de memria intermediria) que pode ser causado por
introduzir cadeias de dados num campo de entrada de interface de usurio que so mais do que o
cdigo pode processar corretamente. Uma vulnerabilidade de estouro de buffer representa uma
oportunidade para executar instrues de cdigo malicioso.
Denial of Service (DOS), que impede que os usurios interajam com um aplicativo (por exemplo,
sobrecarregando um servidor web com solicitaes "desagradveis"),
A intercepo, imitao e / ou alterao e subsequente retransmisso de comunicaes (por exemplo,
transaes de carto de crdito) por um terceiro de tal forma que um usurio permanece inconsciente
da presena desse terceiro (ataque "Man in the Middle"),
Quebrar os cdigos de criptografia usados para proteger dados confidenciais
Bombas lgicas (s vezes chamadas de Ovos de Pscoa), que podem ser inseridas maliciosamente no
cdigo e que se ativam somente sob certas condies (por exemplo, em uma data especfica). Quando
as bombas lgicas so ativadas, elas podem executar atos maliciosos, como a excluso de arquivos ou
a formatao de discos.
Os testes de segurana devem ser integrados com todas as outras atividades de desenvolvimento e teste. Isso
requer considerar as necessidades exclusivas da organizao, quaisquer polticas de segurana existentes,
conjuntos de habilidades atuais de testes de segurana e quaisquer estratgias de teste existentes.

2.2 O Propsito dos Testes de Segurana
Como os testes de software em geral, os testes de segurana no podem garantir que um sistema ou
organizao fique a salvo do ataque. No entanto, os testes de segurana podem ajudar a identificar riscos e
avaliar a eficcia das defesas de segurana existentes. Existem outras atividades para complementar testes de
segurana, como auditorias e revises de prticas de segurana.
Testes de segurana tambm mostram que a devida diligncia tem sido realizada na proteo de ativos
digitais. Em caso de violao de segurana, pode resultar ao legal. Se uma empresa pode mostrar que tomou
medidas razoveis para proteger ativos digitais, como testes de vulnerabilidades, pode haver uma defesa em
um tribunal de direito. Os testes de segurana tambm podem ser uma garantia para os clientes de que a
organizao toma medidas adequadas para proteger informaes confidenciais.
2.3 O Contexto Organizacional

Segurana muitas vezes um tipo de teste funcional realizado juntamente com outros tipos de testes. Com
apenas uma determinada quantidade de tempo disponvel para testes, um gerente de teste deve decidir
quantos testes podem ser realizados, incluindo testes de segurana. No raro que os testes de segurana
sejam considerados um papel de especialista e, portanto, terceirizados para uma organizao especializada
em testes de segurana. A extenso dos testes de segurana , em ltima instncia, impulsionada por riscos
empresariais ou organizacionais baseados na segurana. Quando os riscos de segurana so numerosos em
uma organizao, testes de segurana mais extensos so necessrios.
Como o teste de software, a segurana da informao uma atividade do ciclo de vida. As necessidades de
segurana devem ser definidas nas exigncias, expressas em modelagem e implementadas em cdigo. Em
seguida, os testes de segurana podem verificar e validar a correo e a eficcia da implementao de
segurana. A segurana no pode ser efetivamente corrigida em cdigo ou testada em cdigo. Somente
quando a segurana construda em software usando codificao segura e tcnicas de modelagem pode
software ser seguro.
As realidades de tempo limitado, recursos e escopo, juntamente com os nveis de risco, conjuntos de
habilidades de teste de segurana e abordagens de ciclo de vida tm grande impacto no sucesso de uma
equipe de testes de segurana em uma organizao.
2.4 Objetivos do Teste de Segurana

2.4.1 O Alinhamento dos Objetivos de Testes de Segurana
A poltica de testes de segurana pode ser escrita uma vez que a poltica de segurana da organizao tenha
sido aprovada pela alta administrao. importante que os objetivos e objetivos de testes de segurana,
conforme expressos na poltica de testes de segurana, estejam alinhados com a poltica de segurana geral
da organizao. Caso contrrio, sero realizados testes de segurana no autorizados ou os testes de
segurana podero no atingir os objetivos pretendidos.
2.4.2 Identificao dos Objetivos do Teste de Segurana

Os objetivos do teste de segurana podem ser considerados da mesma forma que os objetivos dos testes
funcionais, mas esto focados em objetivos de segurana. Deve haver um ou mais objetivos de teste de
segurana para cada recurso de segurana do sistema ou aplicativo.

Os objetivos do teste de segurana tambm devem basear-se em atributos da tecnologia (por exemplo, web,
mobile, cloud, LAN) e vulnerabilidades conhecidas, tanto nas vulnerabilidades de aplicativo quanto genricas.
Por exemplo, os objetivos do teste de segurana podem incluir:
Verifique se a autenticao de senha aplica a regra correta para a fora da senha
Verifique se todos os campos de entrada de dados so entrada validada para evitar ataques de SQL
injection
Verifique se os arquivos de dados do cliente so criptografados com a fora correta
2.4.3 A Diferena entre a Garantia da Informao e o Teste de Segurana

A Garantia da Informao (IA) definida como: "Medidas que protegem e defendem os sistemas de informao
e informao assegurando a sua disponibilidade, integridade, autenticao, confidencialidade e no-repdio.
Estas medidas incluem o reestabelecimento de sistemas de informao atravs da incorporao de
capacidades de proteo, deteco e reao. [NISTIR 7298]
O teste de segurana "Um processo utilizado para determinar se os recursos de segurana de um sistema
so implementados conforme projetado e se so adequados para um ambiente de aplicativo proposto".
[MDA1]
Ao comparar os termos Garantia de Informao (AI) e Teste de Segurana, IA um termo mais amplo e
abrangente. Esta relao semelhante quela entre Qualidade de Software e Teste de Software.
2.5 mbito e Cobertura dos Objetivos de Testes de Segurana

Quanto maior a necessidade de integridade de ativos digitais e fsicos sensveis, maior a necessidade de
cobertura dos objetivos do teste de segurana. Os objetivos do teste de segurana descrevem essencialmente
o escopo dos testes de segurana. Se o escopo for muito pequeno, a confiana de que a segurana adequada
no ser alcanada. Se o escopo for muito grande, os recursos podem ser esgotados antes que o teste possa
ser concludo.
Os objetivos dos testes de segurana devem descrever quais testes de segurana se espera alcanar em
relao verificao e validao das protees existentes para ativos digitais e fsicos sensveis. Os objetivos
dos testes de segurana devem se relacionar diretamente com ativos especficos, medidas de proteo, riscos
e identificao de vulnerabilidades de segurana.
2.6 Abordagens de Testes de Segurana

A estratgia de teste de segurana definida para formalizar e comunicar a direo geral de uma organizao
para testes de segurana. Abordagens so ento definidas que implementam a estratgia de testes de
segurana.
2.6.1 Anlise de abordagens de teste de segurana

Cada organizao tem preocupaes exclusivas de negcios e de misso, que por sua vez requerem estratgias
e abordagens de teste de segurana exclusivas para identificar e mitigar os riscos de segurana. No entanto,
h tambm algumas preocupaes de segurana que so comuns a muitas organizaes.
Uma abordagem de teste de segurana definida ao nvel do projeto e deve ser consistente com a poltica e
estratgia de teste da organizao. A abordagem de teste de segurana de um projeto ser uma combinao
nica de tcnicas, ferramentas e habilidades para abordar os objetivos de teste de segurana para esse
projeto.

Ao analisar uma situao com a finalidade de definir uma abordagem de teste de segurana, considere o
seguinte:
A origem dos sistemas ou aplicaes
Qualquer teste de segurana anterior
A poltica de segurana
A poltica de testes de segurana
Quaisquer avaliaes de risco de segurana j realizadas na organizao
O ambiente tcnico em uso (por exemplo, tipo de software e verso, frameworks, linguagens de
programao, sistemas operacionais)
Testes de segurana na equipe de teste
Riscos comuns de segurana
A estrutura organizacional do teste
A estrutura da equipe do projeto
A experincia da equipe de teste com vrias ferramentas de teste de segurana
Restries (por exemplo, recursos limitados, tempo limitado, falta de acesso a ambientes)
Suposies (por exemplo, suposies sobre outras formas anteriores de testes de segurana
realizados)
Diferentes ambientes tcnicos e tipos de aplicativos (por exemplo, cliente/servidor, web, mainframe)
geralmente requerem estratgias de testes de segurana diferentes. Por exemplo, o desenvolvimento de
software pode exigir revises de cdigo para detectar vulnerabilidades de segurana no cdigo, enquanto o
teste de software pode exigir mascaramento de dados de teste. Aplicativos baseados na Web tm
vulnerabilidades diferentes dos sistemas mainframe e, portanto, exigem diferentes tipos de testes de
segurana.
Algumas vulnerabilidades so comuns a vrias tecnologias. Por exemplo, as vulnerabilidades de estouro de
buffer podem ocorrer em aplicativos cliente-servidor, web e mveis com diferenas baseadas no
gerenciamento de memria em cada tecnologia. O resultado o mesmo em todos os ambientes, o que um
comportamento imprevisvel do software que pode permitir que um invasor acesse uma aplicao e execute
tarefas que normalmente no seriam permitidas.
A proteo inadequada de dados pode ocorrer em qualquer tecnologia ou ambiente. No entanto, criptografar
dados nos ambientes da Web e mveis diferente do que no ambiente mainframe. Os algoritmos de
criptografia podem ser os mesmos (ou similares), mas a diferena que os dados devem ser protegidos em
trnsito pela Internet no caso de aplicaes web e mveis. Em todas as tecnologias, os dados sensveis devem
ser armazenados em um formato criptografado. Houve incidentes em que dados sensveis do mainframe
foram enviados fisicamente (usando fita) para outra parte em um formato no criptografado. "O Cattles
Group, especializado em emprstimos pessoais e recuperao de dvidas, admitiu ter perdido duas fitas de
backup contendo informaes para cerca de 1,4 milho de clientes". [ComputerWeekly]
2.6.2 Anlise de falhas em abordagens de teste de segurana

necessrio entender que h graus de fracasso. S porque uma vulnerabilidade de segurana no detectada
e resolvida, isso no significa necessariamente que a abordagem de testes de segurana falhou. Existem
muitas vulnerabilidades de segurana possveis, com novas descobertas dirias. No entanto, h outros casos
em que as abordagens dos testes de segurana foram inadequadas para identificar eficazmente os riscos de
segurana, o que levou a que dados sensveis e outros ativos digitais fossem comprometidos.
A anlise de causa raiz pode ajudar a identificar por que uma abordagem de teste de segurana pode ter
falhado. Possveis causas incluem:
Falta de liderana executiva no estabelecimento de testes de segurana

Falta de proviso executiva de recursos necessrios para implementar a estratgia de testes de
segurana (como falta de financiamento, falta de tempo, falta de recursos)
Falta de implementao efetiva da abordagem de testes de segurana (como a falta de habilidades
necessrias para executar as tarefas requeridas)
Falta de compreenso organizacional e apoio abordagem de testes de segurana
Falta de entendimento das partes interessadas e apoio abordagem de testes de segurana
Falta de compreenso dos riscos de segurana
Falta de alinhamento entre a abordagem de teste e a poltica de segurana da organizao
Falta de alinhamento entre a abordagem de teste e a poltica de estratgia de testes de segurana da
organizao
Falta de compreenso da finalidade do sistema
Falta de informaes tcnicas sobre o sistema (causando suposies erradas)
Falta de ferramentas eficazes para testes de segurana
Falta de habilidades em testes de segurana
2.6.3 Identificao das partes interessadas

Para que um esforo de teste de segurana seja eficaz, um caso de negcios para ele deve ser feito gerncia.
Este caso de negcio deve definir claramente os riscos de falhas de segurana e os benefcios de se ter uma
abordagem de teste de segurana eficaz para um determinado projeto.
As diferentes partes interessadas vero diferentes benefcios em uma abordagem de testes de segurana:
A gerncia executiva ver a proteo do negcio como um benefcio
A alta administrao pode ver a devida diligncia
Os clientes podem ver a proteo contra fraude
Os agentes de conformidade (para polticas internas de segurana corporativa) podem ver garantias
de que a organizao est em conformidade com as obrigaes legais
Os reguladores (para leis de segurana externa) podem ver um benefcio que as regulamentaes de
segurana esto sendo seguidas
Os agentes de privacidade podem ver o benefcio que os dados privados so mantidos seguros e a
devida diligncia tem sido demonstrada na proteo de ativos digitais
2.7 Melhorar as Prticas de Testes de Segurana

Para melhorar as prticas de testes de segurana, primeiramente necessria uma avaliao das prticas
existentes. Deve haver uma maneira objetiva de avaliar prticas de teste de segurana. Estes so baseados em
mtricas-chave para os objetivos de testes de segurana, a partir dos quais possvel identificar o grau de
sucesso dos elementos-chave da estratgia.
Estas prticas devem ser avaliadas da seguinte forma:
A partir de uma perspectiva de curto e longo prazo
Considerar processo e organizao
Considerar pessoas, ferramentas, sistemas e tcnicas
As principais mtricas incluem, mas no esto limitadas a:
Nveis de cobertura de riscos de segurana por testes
Nveis de cobertura de polticas e prticas de segurana por testes
Nveis de cobertura dos requisitos de segurana por testes

Nveis de eficcia dos esforos anteriores de testes de segurana, com base em quando e onde as
vulnerabilidades de segurana foram identificadas. Isso inclui vulnerabilidades de segurana pr e ps-
release.

3 Processos de Teste de Segurana (140 min)
Palavras-chave
Coleta de contas, quebra de senha, engenharia social, abordagem de teste, plano de teste, processo de
teste.
3.1 Definio do processo de teste de segurana
AS-3.1.1 (K3): Para um determinado projeto, demonstre a capacidade de definir os elementos de um processo
de teste de segurana eficaz
3.2 Planejamento do teste de segurana
AS-3.2.1 (K4): Analisar um determinado plano de teste de segurana, dando feedback sobre os pontos fortes
e fracos do plano
3.3 Projeto de teste de segurana
AS-3.3.1 (K3): Para um dado projeto, implementar testes de segurana conceituais (abstract), com base numa
determinada abordagem de teste de segurana, juntamente com riscos de segurana funcionais e estruturais
identificados
AS-3.3.2 (K3): Implementar casos de teste para validar Polticas e procedimentos de segurana
3.4 Execuo do teste de segurana
AS-3.4.1 (K2): Compreender os elementos-chave e as caractersticas de um ambiente de teste de segurana
eficaz
AS-3.4.2 (K2): Compreender a importncia de planejar e obter aprovaes antes de realizar qualquer teste de
segurana
3.5 Avaliao do teste de segurana
AS-3.5.1 (K4): Analisar os resultados dos testes de segurana para determinar o seguinte:
Natureza da vulnerabilidade da segurana
Extenso da vulnerabilidade de segurana
Potencial impacto da vulnerabilidade de segurana
Sugesto de remediao
Mtodos de relatrio de teste timos
3.6 Manuteno do teste de segurana
AS-3.6.1 (K2): Compreender a importncia de manter os processos de testes de segurana, dada a natureza
evolutiva da tecnologia e das ameaas

3.1 Definio do Processo de Teste de Segurana
Como os testes de software em geral, os testes de segurana tambm so uma atividade do ciclo de vida. A
falha em implementar e testar defesas de segurana em um projeto pode levar a graves defeitos de segurana
que podem nunca serem completamente resolvidos. O processo de teste de segurana deve ser alinhado com
o processo de desenvolvimento para que as atividades de teste apropriadas sejam realizadas quando
necessrio.
Os riscos e as necessidades dos testes de segurana de cada organizao sero nicos devido natureza da
organizao, aos ambientes tcnicos, ao processo de desenvolvimento de software e aos riscos de negcio.
Portanto, o processo de teste de segurana deve ser definido no contexto desses fatores.
3.1.1 Processo de teste de segurana ISTQB

A Tabela 3.1 mostra a relao entre o processo de teste geral ISTQB, conforme descrito nos programas ISTQB
Foundation Level e Advanced Level, e o ISTQB Security Testing. Exemplos de tarefas de teste de segurana so
mostradas para cada etapa do processo.
3.1.1.1 Tabela 3.1 - Processo de Teste de Segurana ISTQB
ISTQB Testing Process Processo ISTQB Security Testing Exemplo Security Testing
Definir objetivos de teste de segurana
Planejamento e Planejamento e Controle de Testes
Definir o escopo dos testes de segurana
Controle de Teste de Segurana - O objetivo definir
Identificar os recursos de teste de
um escopo apropriado de testes que segurana
corresponda aos riscos de segurana. Definir estimativas e cronogramas de
teste de segurana
Definir mtricas de teste de segurana,
critrios de entrada e sada
Monitorar o progresso e os resultados dos
testes de segurana
Tomar as medidas necessrias em
resposta s informaes aprendidas
durante outras atividades de teste de
segurana.
Anlise e Modelagem Anlise e Modelagem de Testes de Revisar itens que servem como base de
de Teste Segurana - O objetivo obter testes de segurana, como avaliaes de
compreenso de ameaas e riscos riscos de segurana, requisitos de
de segurana especficos com base segurana e polticas de segurana
em avaliaes de segurana, Definir condies de teste de segurana
auditorias e fontes padro de com base em:
Objetivos de teste
vulnerabilidades conhecidas.
Riscos de segurana
Padres de segurana e vulnerabilidades
conhecidas
Defesas implementadas para proteger o
sistema e seus dados
Escopo dos testes de segurana
Aplicabilidade de ferramentas de teste de
segurana

ISTQB Testing Process Processo ISTQB Security Testing Exemplo Security Testing
Implementao e Implementao e Execuo de Criar casos de teste de segurana, cenrios
Execuo do Teste Testes de Segurana - O objetivo de teste, scripts de teste ou outras
traduzir testes conceituais em testes especificaes de teste
que podem ser executados Realizar testes de segurana funcionais
manualmente ou com ferramentas. com base em especificaes de segurana
Alm disso, o objetivo realizar definidas
Realizar testes de segurana funcional e
esses testes usando uma variedade
penetrao
de perspectivas de teste de
Sobre o conhecimento e intuio do
segurana - usurio interno, usurio testador
externo, usurio mal-intencionado, Realizar testes de segurana com base em
etc. um modelo de um sistema
Configurar ou preparar um ambiente de
teste para realizar testes de segurana
Avaliao dos Critrios Avaliao e Relatrios Determinar vulnerabilidades de segurana
de Sada e Relatrios Resultados do Teste de Segurana - especficas com base nos resultados dos
Isso frequentemente realizado testes
juntamente com a execuo do Avaliar os nveis de risco de segurana com
teste para avaliar testes individuais base nos resultados dos testes de
e para relatar novas ameaas o mais segurana realizados
Relatar os resultados dos testes de
rpido possvel.
segurana intermdios e finais
Gesto e outras partes autorizadas
Encerramento do Teste Encerramento do teste - O objetivo Certifique-se de que todos os testes de
colocar as atividades de teste de segurana planejados foram realizados
segurana em um ponto de Determinar se os resultados de testes de
encerramento para que os testes segurana (relatrios) foram entregues
possam ser mantidos e executados Arquivar resultados de teste, dados de
regularmente para suportar novos teste e outras informaes confidenciais
em locais seguros
requisitos de segurana e / ou
Analisar os resultados dos testes de
detectar novas ameaas. Alm disso,
segurana para melhorar o
todos os testes e resultados de desenvolvimento de sistemas e aplicativos
segurana so armazenados de em termos de segurana
forma segura, estando disponveis
para uso se necessrio em testes de
segurana futuros.
importante entender que o ISTQB Security Testing no necessariamente de natureza sequencial. O
processo de teste de segurana deve ser alinhado com o processo de ciclo de vida do software da organizao.
Uma importante implicao do processo descrito nesta seo que as atividades de teste de segurana so
realizadas ao lado e durante outras atividades e testes do ciclo de vida do projeto.
Alm disso, as tarefas de teste de segurana mostradas na Tabela 3.1 servem como exemplos e no como
requisitos prescritivos para tarefas de teste de segurana. As tarefas de teste de segurana exatas para uma
organizao dependem da estratgia de teste de segurana e da abordagem adotada pela organizao,
conforme mostrado na Figura 3.1 a seguirr.

Figura 3.1 - Hierarquia de Planejamento de Testes de Segurana
3.1.2 Alinhando o processo de teste de segurana a um modelo de ciclo de vida de

software especfico
Cada um dos seguintes tipos de processos de ciclo de vida tem preocupaes de teste de segurana.
importante alinhar os testes de segurana de acordo com o ciclo de vida.
3.1.2.1 Ciclos de Vida Sequenciais
Nesses projetos, o testador em segurana deve estar ciente do seguinte:
As necessidades e riscos de segurana so definidos no incio de um projeto e devem ser
documentados nas especificaes de requisitos de software.
As necessidades de segurana podem mudar durante o projeto, mas podem no se refletir em
requisitos de software atualizados. Os testes de segurana podem parecer muito especficos e
completos, mas podem no estar completos ou atuais devido a riscos tardios.
Testes de segurana podem ser realizados a qualquer momento, mas comum que esses testes sejam
realizados no final do projeto.
Pode ser difcil abordar os resultados dos testes de segurana no final de um projeto de ciclo de vida
sequencial.
3.1.2.2 Ciclos de Vida Iterativos / Incrementais
Projetos incrementais fornecem lanamentos pequenos e frequentes verses de um aplicativo. Mtodos geis
so um exemplo desta abordagem. Nesses projetos, o testador em segurana deve estar ciente do seguinte:
As necessidades e os riscos de segurana surgem durante todo o projeto (normalmente no contexto
de uma iterao ou sprint) e podem ser definidos em especificaes de requisitos, histrias de
usurios, modelos, critrios de aceitao e prottipos.
As necessidades e riscos de segurana podem mudar durante o projeto e podem (devem) ser
abordados na iterao em que so identificados.
Testes de segurana podem ser realizados continuamente ao longo de um projeto.
Dependendo da natureza do risco de segurana, pode no ser possvel mitigar e testar completamente
durante um curto ciclo de liberao.
3.1.2.3 Software comercial de prateleira (COTS)
Estes projetos so muitas vezes caixa-preta na natureza e podem ou no ser personalizados. Eles geralmente
contm vulnerabilidades de segurana na medida em que frequentes atualizaes de segurana e patches so
necessrios. No h acesso ao cdigo, portanto a anlise estrutural e os testes estruturais no so possveis.

3.1.2.4 Software de Cdigo Aberto
Esta uma variante do COTS, mas com uma distino importante - o cdigo est disponvel para todo o mundo.
Esses produtos tambm tm vulnerabilidades de segurana, portanto, de vital importncia que os patches
de segurana sejam mantidos atualizados. Uma vez que uma vulnerabilidade de segurana tenha sido
divulgada, os usurios dessa verso especfica do software (e anteriores) correm o risco de sofrer um ataque.
3.1.2.5 Exemplo - Processo de Teste de Segurana em um Ciclo de Vida Sequencial
importante notar que os testes de segurana no precisam ser confinados a uma fase ou atividade em um
projeto. particularmente importante evitar a situao em que os testes de segurana (e outros testes) no
so realizados at fase de aceitao do projeto. No final do projeto, especialmente oneroso e arriscado
lidar com quaisquer defeitos descobertos. O seguinte mostra as tarefas de teste de segurana apropriadas que
devem ser realizadas em cada fase do ciclo de vida sequencial:
Requisitos: Os requisitos de segurana so definidos e revistos como parte do esforo de requisitos gerais
para expressar as necessidades da organizao. tambm onde os casos de uso podem ser escritos.
neste momento que uma abordagem de teste de segurana deve ser desenvolvida.
Anlise e projeto: Normalmente, algum no papel de analista de negcios examinar a declarao inicial
de requisitos e refin-los- para preencher lacunas. Um analista de sistemas ou arquiteto, em seguida,
analisar os requisitos para propor a maneira ideal para entregar uma soluo que atenda s necessidades
do usurio. Neste caso, a segurana seria uma das necessidades funcionais e no-funcionais, juntamente
com outras como usabilidade e eficincia. Neste ponto, os criadores de testes de segurana podem ter
uma ideia da arquitetura e do que precisa ser testado, tanto a partir das perspectivas de segurana
estrutural e funcional. Principais objetivos de teste de segurana devem ser definidos neste momento.
Modelagem detalhada: Neste ponto, as interfaces de usurio e bancos de dados esto projetadas. As
regras funcionais so refinadas e o projeto de teste de segurana torna-se mais detalhado. Os primeiros
testes de segurana podem ser realizados com base em modelos.
Codificao e implementao: Isto quando as especificaes de projeto so implementadas como
cdigo. Essa a primeira oportunidade de testar a estrutura do aplicativo, incluindo testes de
vulnerabilidades de segurana, como defeitos de estouro de buffer e edies de campo que podem
permitir que a SQL injection ocorra. A anlise esttica e as revises de cdigo so muito valiosas nesta fase
e devem incluir o exame do cdigo sob a perspectiva da segurana. Testes de componentes tambm
uma atividade chave para verificar se o cdigo funciona conforme especificado. Os testes de integrao
entre componentes tambm podem comear como componentes que interagem uns com os outros
tornam-se disponveis para testes em montagens pequenas.
Teste do sistema: Este o teste de sistemas e subsistemas. O teste do sistema inclui software, hardware,
dados, procedimentos e como as pessoas interagem com o sistema. Esses testes so muitas vezes de
natureza transacional para testar os processos de negcios. A base para o teste do sistema pode ser
requisitos, modelos de modelagem, casos de uso e quaisquer outras especificaes que transmitem a
perspectiva do sistema. Alm disso, os testes de integrao de sistemas podem precisar ser realizados
para testar como vrios sistemas se comunicam e trocam dados. Testes de segurana nesta fase assume
uma viso mais ampla porque o hardware e os intercmbios de dados esto envolvidos. A segurana da
transao pode ser testada, o que inclui autenticao, armazenamento de dados, implementao de
firewall, bem como controles de segurana processuais.
Testes de Aceite de Usurio: Isto acontece quando o teste confirma que um sistema suporta processos
de negcios do mundo real e pode abranger vrios sistemas em vrias organizaes. O objetivo dessa fase
no tanto encontrar defeitos, mas sim validar que o sistema atenda s necessidades dos usurios em
condies reais. Isso inclui garantir que os requisitos de segurana foram implementados e atendidos
corretamente. Nesta fase, os testes de segurana j deveriam ter sido realizados em grande parte, mas
ainda h oportunidades para testar cenrios de segurana que ocorrem no nvel do processo de negcios.

Implantao: quando o sistema concludo e testado implantado para os usurios. H muitas maneiras
que isso pode ocorrer, como em implantaes piloto para grupos selecionados ou uma implantao
macia para todos os usurios. Outra abordagem uma implantao paralela onde um sistema antigo e
um novo sistema esto em operao ao mesmo tempo por um tempo limitado. Grande parte da deciso
de uma implementao de corte direto depende do risco de implantao para todos os usurios e da
confiana adquirida durante os testes de aceitao. A segurana uma preocupao durante a
implantao do sistema, j que todos os componentes do sistema devem ser implantados de forma que
nenhuma nova vulnerabilidade seja introduzida. Isso pode ocorrer se as configuraes de segurana no
estiverem corretas no ambiente de destino. Um exemplo disso seria se os direitos de acesso ao banco de
dados no estiverem corretos no ambiente ao vivo.
Manuteno: A medida que novas necessidades surgem ou os defeitos so descobertos aps a
implantao, a manuteno executada. O teste assume uma dimenso diferente, pois o foco est em
testar as alteraes e realizar testes de regresso. Testes de segurana tambm devem ser realizados para
garantir que novas vulnerabilidades no sejam introduzidas durante as alteraes. Parte do processo de
manuteno manter os firewalls e outras tecnologias de segurana atuais. O monitoramento contnuo
do sistema pode detectar atividades suspeitas que podem precisar ser tratadas imediatamente.
3.1.2.6 Exemplo - Processo de Teste de Segurana em um Ciclo de Vida Iterativo / Incremental
H uma variedade de metodologias que foram introduzidas nos ltimos 20 anos para definir software de
construo em incrementos ou iteraes menores. Neste exemplo, lanamentos do software so entregues a
cada quatro semanas. A base de trabalho (e de teste) so as histrias de usurios, cada um com critrios de
aceitao definidos.
A seleo de recursos para construir e entregar baseia-se em um backlog priorizado. Os recursos selecionados
devem refletir os itens que oferecem o maior valor e so alcanveis no perodo de sprint. O testador em
segurana trabalha com o negcio e/ou proprietrio do produto para ter os requisitos de segurana
adequados e corretos.
Neste exemplo, quatro principais funes de segurana so selecionadas para a primeira iterao porque elas
sero necessrias para desenvolver muitos dos outros recursos. Os recursos so:
Login de usurio
Ativao SSL (Secure Socket Layer)
Redefinir senha perdida
Bloqueio de conta aps trs tentativas malsucedidas
Cada uma dessas caractersticas escrita como histrias de usurio e refinadas em requisitos mais detalhados,
cada um com critrios de aceitao.
Do ponto de vista do teste de segurana, o testador em segurana trabalha com o desenvolvedor para garantir
que as polticas e os protocolos corretos sejam refletidos no cdigo. O testador em segurana tambm
trabalhar ao lado do desenvolvedor para testar as funes medida que forem desenvolvidas.
Neste exemplo, a primeira verso pode ser apenas a pgina de login e funes associadas para o login, como
redefinir uma senha perdida e o controle de bloqueio. Na prxima iterao, sero desenvolvidas outras
funes, com base na prioridade para as partes interessadas. Em cada iterao, o testador em segurana
testar para certificar-se de que os controles de segurana esto funcionando corretamente e nenhuma nova
vulnerabilidade de segurana foi introduzida. As iteraes continuaro at que as tarefas de backlog tenham
sido concludas.
Em ambos os exemplos (iterativo/incremental e sequencial), as etapas do processo de teste de segurana
podem ser vistas como tarefas integrais para garantir uma aplicao segura.

3.2 Planejamento do teste de segurana
3.2.1 Objetivos de planeamento do teste de segurana
Testes de segurana em geral devem se concentrar em dois aspectos:
Verificar se as defesas de segurana projetadas so implementadas e funcionar conforme planejado
Verificar se no h vulnerabilidades introduzidas durante o desenvolvimento do aplicativo
Como mencionado anteriormente neste programa todas as defesas de segurana a serem implementadas
devem ser baseadas em uma anlise de risco. Isso fornece um ponto de partida ao planejar testes de segurana
para um projeto.
Muitas das vulnerabilidades desenvolvidas no intencionais podem ser evitadas usando atividades de garantia
de qualidade e melhores prticas durante as atividades de arquitetura, modelagem e codificao. Testar se as
vulnerabilidades so introduzidas comea com uma avaliao das prticas utilizadas pela equipe de
desenvolvimento. Com base no resultado, pode ser necessrio selecionar e introduzir testes de segurana
adicionais.
3.2.2 Elementos chave do plano de teste de segurana

Os principais elementos de um plano de teste de segurana esto listados abaixo. Cada um destes pode ser
determinado por fazer as perguntas especificadas para um determinado projeto.
Identificar o escopo dos testes de segurana
O que est no escopo e fora do escopo?
O que alcanvel dados os recursos do projeto, os riscos de segurana e as restries de tempo?
Identificar quem deve realizar testes de segurana
A organizao tem pessoas com habilidades de teste de segurana apropriadas?
A organizao se sente confortvel com testes de segurana de terceirizao?
No caso de software comercial e software desenvolvido pelo fornecedor, que testes de segurana so
da responsabilidade do fornecedor e que so da responsabilidade do cliente?
Os testadores em segurana precisam de treinamento no uso de ferramentas de teste de segurana
especficas?
Atribuir o cronograma apropriado para testes de segurana, tendo em conta outros requisitos de
programao de teste do projeto
Que itens relacionados segurana precisam ser implementados e testados antes que outros testes
ocorram? (Por exemplo, direitos de acesso e logins)
Quando os recursos de segurana estaro disponveis para testes?
Quanto tempo levar para realizar testes de segurana dados os recursos planejados e o escopo?
Definir as tarefas a serem executadas e o tempo necessrio para cada
Quanto tempo necessrio para projetar os testes de segurana apropriados com base nos recursos
planejados e no escopo?
Quanto tempo necessrio para avaliar e relatar os resultados dos testes de segurana?
Quanto tempo necessrio para realizar testes de regresso relacionados segurana?
Quanto tempo necessrio para estabelecer o ambiente de teste de segurana?
Definir o (s) ambiente (s) de teste de segurana
Qual a extenso do ambiente? (Plataforma, tecnologia, tamanho, localizao)
Este um novo ambiente?
Que ferramentas de teste de segurana e outras ferramentas de teste precisam ser instaladas no
ambiente?

Obteno de autorizaes e aprovaes para atividades de teste de segurana
Quem deve autorizar e aprovar os testes de segurana?
Quando essa autorizao necessria?
O oramento e o financiamento so suficientes?
Como qualquer projeto entregue, o plano de teste de segurana deve ser revisto para avaliar a integridade e
a exatido. Uma vez que os testes de segurana so muitas vezes de natureza tcnica, uma sesso de reviso
tcnica pode ser o mtodo mais adequado. No entanto, acompanhamentos e inspees tambm podem ser
adequados.
Uma lista de verificao padro pode ajudar a formar a base do que coberto em uma sesso de reviso.
Como qualquer outra reviso, o feedback deve ser construtivo e no destinado ao produtor do plano de teste
de segurana. A equipe de reviso deve incluir pessoas conhecedoras de todas as reas afetadas pelos
aspectos de segurana discutidos no plano de testes de segurana.
Os membros da equipe de reviso podem no ser necessariamente testadores em segurana ou possuem
experincia em segurana. Por exemplo, o gerente de uma unidade de negcios pode ter informaes sobre
riscos de segurana que devem ser registradas no plano de teste de segurana. Os auditores de TI e os
administradores de segurana so especialmente teis nas revises de planos de teste de segurana devido
ao seu conhecimento das polticas e procedimentos de segurana.
3.3 Projeto de teste de segurana

H vrias maneiras de iniciar o projeto de teste de segurana. Por exemplo, pode ser iniciado baseado em:
Uma anlise de risco realizada
Um modelo de ameaa disponvel
Uma classificao de origem ad hoc de riscos de segurana (ver [BSTQB_ATTA_SYL])
Qualquer um destes pode formar uma base vivel.
Dependendo do tipo de projeto, importante garantir que h testes de segurana em cada fase de
desenvolvimento aplicvel.
3.3.1 Modelagem de Teste de Segurana

Testes de segurana detalhados so baseados nos riscos de segurana, uma estratgia de teste de segurana
e outras fontes, como modelos de ameaas. Testes de segurana tambm pode ser visto como funcional e
estrutural na natureza. Por exemplo, no caso do teste de segurana de um site de comrcio eletrnico, os
riscos de segurana funcionais podem ser SQL injection, coleta de contas e quebra de senhas. Um exemplo de
um risco de segurana estrutural seria uma condio de estouro de buffer que permitiria a um invasor obter
acesso atravs de uma falha de memria.
Os seguintes so atributos essenciais de testes detalhados de segurana:
Priorizada por riscos de segurana e modelos de ameaa identificados
Rastreado para requisitos de segurana definidos
Definido com base no pblico-alvo (desenvolvedores, testadores funcionais, testadores em
segurana)
Definido com base em perfis de defeitos de segurana
Projetado para ser automatizado, se aplicvel
O fluxo bsico do projeto de teste de segurana pode ser visto como:
1. A abordagem dos testes de segurana (nvel do projeto)

2. Riscos de teste de segurana, modelos de ameaas e requisitos (nvel de projeto)
3. Tcnicas de projeto de teste de segurana (com base em riscos, requisitos e aplicao)
4. Casos e cenrios de teste de segurana
No restante deste captulo, riscos e vulnerabilidades de segurana comuns so apresentados juntamente com
a tcnica de modelagem de teste de segurana associada. Novos riscos e vulnerabilidades de segurana
surgem rapidamente, por isso aconselhvel que os planejadores de teste de segurana permaneam
atualizados com os padres de segurana e as listas de ameaas, conforme mencionado no Captulo 9.
Um princpio fundamental que um processo de modelagem de teste de segurana deve ser capaz de criar e
implementar testes com base em qualquer risco, exigncia ou ameaa de segurana identificados.
3.3.1.1 Controles de Segurana Funcionais (por exemplo, controles de transao)
Esses testes so projetados para verificar e validar que os controles esto no lugar, funcionando corretamente
e so eficazes na deteco e preveno de aes no autorizadas.
Exemplo: Um caixa de banco no pode autorizar uma retirada em dinheiro sobre uma certa quantia de
dinheiro sem a aprovao do chefe de caixa aderida ao sistema.
3.3.1.2 Controles de Acesso Funcionais (por exemplo, logins, senhas, tokens)
Esses testes so talvez o que a maioria das pessoas pensam imediatamente em termos de testes de segurana.
Os testes incluem:
Polticas de nome de usurio e senha so aplicadas corretamente
O nvel de controle de acesso adequado para o risco
Os controles de acesso so resistentes ao software de quebra de senhas
Exemplo: A coleta de contas a prtica de identificar um nome de usurio. Uma vez que o nome de usurio
adivinhado ou identificado, a senha a pea restante necessria para obter acesso ao sistema. Um teste
comum verificar que quando um nome de usurio correto inserido com uma senha incorreta, a mensagem
de erro no indica qual dos itens est incorreta.
3.3.1.3 Controles de Acesso Estruturais (por exemplo, direitos de acesso de usurios, nveis de
criptografia, autenticao)
Os testes para esses controles so baseados em como os direitos de usurio foram estabelecidos para acesso
a dados, acesso funcional e nveis de privacidade. Os controles de acesso estrutural so normalmente
aplicados por um administrador de sistemas, administrador de segurana ou administrador de banco de
dados. Em alguns casos, os direitos de acesso so uma opo de configurao em um aplicativo. Em outros
casos, os direitos de acesso so aplicados no nvel da infraestrutura do sistema.
Os testes de controles de acesso estruturais incluem a criao de contas de usurio de teste para cada nvel
de acesso de segurana e a verificao de que cada nvel de acesso no tem direitos de acesso restritos para
esse nvel. Por exemplo, as contas de usurio seriam criadas para um nvel mnimo de acesso, acesso ao nvel
de gerenciador e acesso de administrador. Testes devem ser realizados para garantir que um usurio com
acesso mnimo no possa executar atividades de acesso ao nvel do gerente.
3.3.1.4 Prticas de Codificao Segura
Este basicamente um mtodo de teste esttico para determinar se os desenvolvedores de software e sistema
esto seguindo os mtodos de segurana estabelecidos medida que eles criam aplicativos.
Um princpio-chave que muitos ataques de segurana so realizados atravs da explorao de defeitos de
software para causar um sistema para se comportar de forma inesperada.

Uma lista muito curta de prticas de codificao seguras inclui:
Algoritmos e controles de gerenciamento de sesso comprovados so usados para criar
identificadores de sesso aleatrios.
As decises de autorizao so feitas apenas por objetos confiveis do sistema sob controle da
organizao que fornece autorizao (por exemplo, a autorizao deve ocorrer no lado do servidor).
As informaes seguras no devem aparecer em mensagens de erro. Essas informaes podem incluir
detalhes do sistema, identificadores de sesso e informaes de conta.
Erros de aplicativo devem ser manipulados dentro do aplicativo, em vez de confiar na configurao do
servidor.
As solicitaes HTTP GET no devem incluir informaes confidenciais.
Os manipuladores de erro no devem exibir rastreamento de pilha ou outras informaes de depurao.
Todas as falhas de validao de entrada de dados devem ser registradas.
Qualquer informao sensvel que possa ser armazenada temporariamente no servidor deve ser
protegida (por exemplo, a criptografia deve ser usada). Esta informao segura temporria deve ser
limpa quando no for mais necessria.
Um aplicativo no deve ser capaz de emitir comandos diretamente para o sistema operacional. Em
vez disso, as APIs internas devem ser usadas para realizar tarefas do sistema operacional.
As senhas, sequncias de conexo ou outras informaes confidenciais no devem ser armazenadas
em texto no criptografado em mquinas clientes (por exemplo, em cookies). A incorporao de tais
informaes em formatos no seguros, como o Adobe flash, o cdigo compilado e o MS Viewstate,
devem ser proibidas.
A criptografia deve ser usada para a transmisso de todas as informaes confidenciais. Transport
Layer Security (TLS) uma maneira de proteger os dados em trnsito ao usar conexes HTTP. Para
conexes no-HTTP, a criptografia deve ser usada para transmitir informaes confidenciais.
Os dados fornecidos pelo usurio no devem ser passados diretamente para qualquer funo
dinmica "include"
Todos os dados fornecidos pelo usurio devem ser adequadamente sanitizados e validados antes de
serem usados pelo aplicativo.
As variveis devem ser fortemente digitadas em idiomas que suportem a verificao de tipos. Ou seja,
as variveis devem ter um tipo de entrada definida. Por exemplo, um campo numrico no deve
aceitar caracteres alfa. Esta restrio seria definida na definio de tipo da varivel, bem como na base
de dados. possvel escrever cdigo seguro em JavaScript (n JS) ou em outros idiomas que no
suportam a verificao de tipo cumprida.
Em vez de usar o novo cdigo no gerenciado para tarefas comuns, use o cdigo testado, confivel e
aprovado que esteja sob o gerenciamento de configurao.
Executar servios com o mnimo de privilgios possveis (nunca em root) e cada servio deve ter sua
prpria conta de usurio no sistema operacional.
Uma lista de prticas de codificao segura pode ser encontrada no Guia de Referncia Rpida OWASP Secure
Coding Practices [OWASP1] e Top 10 Secure Coding Practices [CERT1]. Alm disso, o SANS compila uma lista
dos 25 erros de software mais perigosos em [SANS1].
Testes dinmicos podem ser realizados para determinar se prticas como validao de dados e mensagens de
erro foram seguidas por desenvolvedores. Alm disso, uma das vulnerabilidades de segurana mais comuns,
o estouro de buffer de memria, pode ser identificado com ferramentas de teste de memria dinmica.

3.3.1.5 Acesso ao Sistema Operacional
Uma vez que o acesso adquirido ao sistema operacional, um invasor pode controlar dados, acessar a rede e
implantar malware. Os testes para isso podem incluir testes para a capacidade de plantar rootkits e outros
cdigos maliciosos em um sistema.
3.3.1.6 Vulnerabilidades de linguagem (por exemplo, Java)
De acordo com pesquisadores de segurana da WhiteHat Security, um fornecedor de segurana de aplicativos,
no houve diferenas significativas entre linguagens quando se trata de vulnerabilidades de segurana.
[WhiteHat Security, 2014]. Em abril de 2014, a WhiteHat Security publicou um Relatrio de Estatsticas de
Segurana de Website baseado em avaliaes de vulnerabilidade realizadas contra 30.000 sites de clientes
usando um scanner proprietrio e os resultados indicaram diferenas insignificantes na segurana relativa de
idiomas como .NET, Java , PHP, ASP, ColdFusion e Perl. Essas seis lnguas compartilhavam um nmero mdio
relativamente pequeno de vulnerabilidades, e problemas como SQL injection e a vulnerabilidades de scripts
entre sites permaneciam difusos. [WhiteHat Security, 2014]. importante reconhecer que o cdigo seguro
pode ser alcanado com muitas linguagens, assim como o cdigo no seguro. O fator chave como um
aplicativo codificado (implementado) em qualquer linguagem.
A Diviso CERT do Instituto de Engenharia de Software fornece publicaes [CERT2] e ferramentas [CERT3]
que abordam questes de segurana especficas de linguagem. Alm disso, o Vulnerability Notes Database
[CERT4] fornece informaes oportunas sobre vulnerabilidades de software. As notas de vulnerabilidade
incluem resumos, detalhes tcnicos, informaes de correo e listas de fornecedores afetados.
3.3.1.7 Vulnerabilidades de Plataforma (por exemplo, Windows, Linux, Mac OS, iOS, Android)
Cada plataforma de computao tem seu prprio conjunto de vulnerabilidades de segurana. A preocupao
com o testador em segurana garantir que as atualizaes de segurana da plataforma sejam aplicadas
prontamente e em todos os dispositivos que executam a plataforma afetada.
3.3.1.8 Ameaas Externas
As ameaas externas segurana so aquelas que a maioria das pessoas conhece quando se trata de ataques
cibernticos. Algumas ameaas externas, como a explorao de vulnerabilidades de aplicativos ou de
linguagem, podem ser detectadas, testadas e prevenidas.
A negao de servio (DoS) outro tipo de ameaa externa. Em geral, esses ataques baseiam-se na sobrecarga
dos recursos do sistema ou aplicativo, de tal forma que o sistema ou aplicativo se torna inacessvel para
usurios legtimos. Os ataques DoS podem ser direcionados largura de banda da rede, sistema ou
conectividade de aplicativo ou servios ou funes especficos.
Um ataque distribudo de Negao de Servio (DDoS) um tipo de ataque DoS onde o ataque iniciado
indiretamente usando outros recursos de computador. Possveis tcnicas so amplificao ou o uso de
botnets, que um grande nmero de computadores comprometidos anteriormente sob controle ou comando
de um atacante. Um atacante pode ganhar controle simplesmente criando infeces de vrus ou usando
Trojans. Os computadores infectados podem ser usados como agentes, cada um enviando trfego para uma
vtima especfica (rede) conforme o alvo do atacante.
Ao usar ataques de amplificao ou reflexo, o atacante est usando uma vulnerabilidade (ou mesmo a
funcionalidade desejada) em protocolos especficos (por exemplo, DNS ou NTP). O atacante envia uma grande
quantidade de trfego para endereos de broadcast IP (vrios hosts) contendo o endereo de origem
falsificado da vtima. Isso resulta no servio de difuso desse trfego para o endereo da vtima e multiplicar
a quantidade original de trfego com o nmero de hosts. Quando um atacante envia estes tipos de pedidos
vrias vezes por segundo, a vtima de repente confrontada com o elevado nmero de respostas que tem de
enviar.

Exemplo: O Atacante A envia uma solicitao para o sistema B para obter uma lista completa de todos os
registros DNS conhecidos enquanto personifica a Vtima C, muitas vezes com um endereo IP falsificado. O
sistema B enviar a lista completa para a Vtima C que inunda o servidor da Vtima C com uma quantidade
ampliada de dados.
Outra forma de ataques DoS so ataques de exausto de recursos. Esses tipos de ataques abusam de uma
funcionalidade desejada, consumindo os recursos de computao (CPU, memria, armazenamento em disco,
etc.) necessrios para fornecer a funcionalidade.
Exemplo: Uma das funcionalidades do protocolo SSL a opo de gerar novas chaves em uma sesso existente
se o cliente ou servidor suspeitar de uma sesso comprometida. Gerar chaves um processo caro. Quando
um invasor envia uma solicitao para gerar novas chaves vrias vezes por segundo, um sistema mal
configurado ou desprotegido pode acabar em uma situao em que ele est gerando apenas novas chaves e
no tem recursos para fazer outras coisas.
Por ltimo, existem os chamados ataques DoS lgicos, em que um intruso pode abusar da funcionalidade
pretendida para impedir que outros utilizadores acedam ao sistema.
Exemplo: Um aplicativo usa nomes de usurio previsveis e bloqueia um usurio permanentemente aps trs
tentativas de login falhos. Um invasor pode adivinhar os nomes de usurios e bloquear muitas contas no
sistema, fazendo com que muitos usurios no possam acess-lo (e indiretamente, fazer o servio de
helpdesk).
H quatro nveis de teste para DDoS.
1. Teste para garantir que os computadores no estejam infectados com malware conhecido
2. Testar a capacidade dos sistemas de deteco de intruso para identificar rapidamente mltiplas
solicitaes de um nico computador em um curto perodo de tempo
3. Identificar configuraes que permitem funcionalidades que podem ser abusadas por um invasor (por
exemplo, SSL, servidor web, DNS)
4. Identificar defeitos lgicos que podem permitir um DoS
Intruses so outra forma de ataque externo. H muitas maneiras de realizar intruso externa em um sistema.
Esses ataques baseiam-se em algum "invadindo" um sistema para obter informaes. Alguns dos mtodos
so descritos na lista abaixo:
Engenharia social
Ataques de injeo (SQL injection, cdigo malicioso script injection)
Compromisso da conta (colheita, redefinio de senha)
Explorando vulnerabilidades conhecidas (firewall, SO, framework, aplicativo)
Ataques de malware
Iniciativas de configurao inseguras
Defeitos de autorizao
Ataques de lgica de aplicativo (aproveitando os defeitos de aplicativo, especialmente em aplicativos
baseados na Web, para usar indevidamente a funo - por exemplo, executar etapas fora de ordem
em um aplicativo de compras de comrcio eletrnico para obter desconto ou crdito)
Interceptar uma transmisso de rede enviada de dentro de uma organizao para algum de outra
organizao no considerado um ataque de intruso, mas sim uma violao interna.
3.3.1.9 Ameaas internas
As maiores ameaas podem ser internas. Considere as seguintes fontes de ataque interno:

Espionagem corporativa onde um empregado confivel pode vender informaes corporativas,
incluindo informaes de contas de clientes, segredos comerciais, informaes de acesso de
funcionrios, etc.
Informaes obtidas por desenvolvedores terceirizados, testadores e outros funcionrios (como
representantes de atendimento ao cliente). s vezes as pessoas deixam o emprego de uma empresa
de terceirizao e levar as informaes com eles em sua cabea.
O roubo de discos rgidos e outros dispositivos fsicos de armazenamento
Funcionrios descontentes que procuram danificar a empresa por vazamento de informaes
confidenciais ou cometer atos de roubo, pagando-se dinheiro sob a aparncia de faturas legtimas
(mas fabricadas)
3.3.1.10 Formato e estrutura do teste de segurana
Cada organizao que executa testes de segurana ter sua prpria maneira de formatar testes detalhados.
Muitas vezes possvel usar o mesmo formato para o projeto de teste de segurana como outros tipos de
testes, com a nica diferena sendo o alvo do teste e o ambiente de teste.
Mesmo que uma organizao siga padres como IEEE 829-2008 e ISO 29119 [ISO / IEC / IEEE 29119-3], o uso
desse padro deve ser adaptado para atender s necessidades de uma organizao. Estes padres, no entanto,
formam um entendimento padro do que deve ser contido em vrios documentos de planejamento de teste.
Em muitos casos, os casos de teste e procedimentos de teste (scripts) podem ser definidos e implementados
em uma ferramenta de gerenciamento de teste que muitas vezes fornece estrutura de formatao.
Casos de teste so a forma mais autnoma de descrio do teste. Eles no exigem execuo sequencial. Se a
execuo sequencial necessria para atingir um objetivo de teste especfico, os casos de teste so
combinados em uma sequncia expressa em um procedimento de teste ou script. Os casos de teste so
tipicamente usados para testar condies nicas. Por exemplo, nos testes de segurana, testar a funo de
login pode consistir em casos de teste projetados para validar que os requisitos de formatao de senha so
aplicados corretamente.
Durante a implementao do teste, os casos de teste so desenvolvidos, priorizados e organizados na
especificao do procedimento de teste. O procedimento de teste especifica a sequncia de execuo do caso
de teste. Se os testes so executados usando uma ferramenta de execuo de teste, a sequncia de aes
especificada em um script de teste (que um procedimento de teste automatizado). Os procedimentos de
teste so usados quando a sequncia importante. Por exemplo, um procedimento de teste seria til para
testar o processo de "recuperao de senha perdida".
Quando so necessrios testes baseados na experincia, tais como testes exploratrios, as condies de teste
e os resultados esperados no so definidos antes do teste, mas as condies testadas e os resultados reais
devem ser registrados pelo testador em segurana para relato.
3.3.2 Desenho de Teste de Segurana Baseado em Polticas e Procedimentos

Ao projetar testes para validar polticas e procedimentos de segurana, esses itens tornam-se a base do teste.
Desta perspectiva, os testes de segurana so quase um meio de auditoria de segurana.
Polticas de segurana e procedimentos no devem ser a nica base de testes, porque outras perspectivas de
testes de segurana so necessrias. Os objetivos da criao de testes para validar polticas e procedimentos
de segurana so:
Compreender o propsito e o escopo
Avaliar a testabilidade
Criar testes relacionados diretamente

Por exemplo, pode haver um procedimento que declara: "Todos os sistemas de TI da XYZ limitam o nmero de
tentativas de login malsucedidas a trs. Um perodo de bloqueio especificado ocorrer aps trs tentativas de
login sem xito. As pessoas que no tm as informaes de conta de usurio local apropriadas no podero
acessar nosso sistema de TI e devem entrar em contato com os servios de suporte de TI para verificar a
identidade e obter uma senha temporria ".
Este um procedimento muito testvel, que exigiria as seguintes etapas:
1. Tentativa log em um aplicativo trs vezes sem xito. Uma mensagem de bloqueio deve aparecer na
terceira tentativa sem xito. Quaisquer outras tentativas de login na conta recebem a mensagem de
bloqueio.
2. Entre em contato com os servios de suporte de TI e verifique a identidade. Uma senha temporria
ser emitida para um endereo de e-mail conhecido.
3. Faa o login com a senha temporria. O acesso deve ser concedido.
4. Crie uma nova senha que esteja em conformidade com a diretiva de senha. A nova senha deve ser
aceita.
5. Sair.
6. Faa login com a senha recm-criada. O acesso deve ser concedido.
Observe que a etapa 4 fornece uma oportunidade para testar a diretiva de senha tambm.
Nem todas as polticas de segurana so testveis. Por exemplo, "O contedo dos registros de auditoria da
XYZ, Inc. contm todos os eventos auditados com carimbo de data e hora e so rastreveis para indivduos
especficos. Registros especficos do fabricante que fornecem informaes suficientes para cumprir esses
requisitos devem ser considerados adequados para fins de auditoria".
Embora no seja impossvel testar, um teste precisaria ser definido e executado para cobrir todos os eventos
auditados. As aes teriam que ser executadas para acionar um conjunto de exemplos de eventos a serem
registrados nos logs de auditoria e a preciso das informaes registradas precisaria ser verificada como
correta, como o ID do usurio e o carimbo de data e hora.
3.4 Execuo do teste de segurana

3.4.1 Elementos-chave e caractersticas de um ambiente de teste de segurana
eficaz
Embora muitas formas de teste possam utilizar um ambiente de teste localizado no mesmo servidor e em rede
com outros sistemas, os testes de segurana tm riscos exclusivos que exigem uma abordagem segregada
para a construo do ambiente de teste. Isso especialmente verdadeiro ao testar aplicativos no confiveis
(como de um provedor de terceiros ou de cdigo aberto).
Alguns testes de segurana, como testes de controles funcionais e gerenciamento de sesses, podem ser
executados em um ambiente de teste integrado tpico sem alto risco. No entanto, ao testar o cdigo
desconhecido e no confivel, a possibilidade de um malware corromper um servidor e/ou rede torna
aconselhvel testar em um ambiente de teste isolado ou virtual.
Os atributos principais para um ambiente de teste de segurana so os seguintes:
1. Isolado: de outros sistemas (dependendo do nvel de risco de malware)
2. Completo: o ambiente total ter de refletir o ambiente alvo (produo) em termos de:
Sistemas e aplicaes em teste
Sistemas operacionais (verso e configurao exatas)
Rede

Middleware
Desktops (marca de hardware, processador, memria)
Dispositivos mveis (fabricante, processador, memria, gerenciamento de energia)
Bases de dados
Direitos de acesso
Navegadores e plug-ins
Aplicaes coexistentes
Dados (dados de teste de engenharia ou dados de produo que foram obscurecidos)
3. Restaurvel: repetir os testes conforme necessrio e recuperar de corrupo caso ocorra
3.4.2 Importncia do planejamento e das aprovaes em testes de segurana

H vrias razes pelas quais um testador em segurana deve ter aprovao antes de executar testes de
segurana:
Em quase todos os pases, contra a lei (tentar) obter acesso aos sistemas de dados e suas
informaes. Em alguns pases, mesmo contra a lei ter acesso a ferramentas de teste de segurana.
Isso significa que na maioria das atividades de teste de segurana voc estar quebrando uma ou mais
leis em fazer tal. A nica maneira possvel de realizar o teste obter uma renncia do proprietrio do
sistema ou dados e aprovao de sua administrao.
Os testes de segurana podem desencadear alertas de deteco de intruso e o testador pode parecer
ser um invasor malicioso. O teste de penetrao um caso especfico quando essa autorizao
especialmente necessria.
Os testes de segurana podem levar a grandes falhas do sistema e blackouts. O risco deve ser
conhecido e possveis precaues devem ser implementadas.
Sem autorizao prvia e especfica para testes de segurana, um testador pode estar violando polticas e
procedimentos de segurana. Isso pode tornar o testador sujeito a resciso ou acusao.
Um formulrio de autorizao para testes de segurana deve conter as seguintes informaes:
Nome da entidade autorizadora
Nomes do pessoal de teste e/ou entidade
Declarao de trabalho
Datas de autorizao (de/para)
Outros detalhes relevantes, como endereos IP de origem, contas de usurio e assim por diante
Atestados:
O cliente possui o sistema a ser testado
O cliente tem autoridade para autorizar testes de segurana
O cliente realizou um backup de todos os sistemas e
O cliente testou que o sistema pode ser restaurado a partir de backups, se necessrio
O cliente entende os riscos associados aos testes de segurana
Uma clusula "inofensiva" para a entidade de teste
Assinaturas do representante do cliente autorizado a celebrar tais acordos
Um formulrio de amostra pode ser encontrado em [OWASP3].

Como grande parte dos testes, a avaliao do teste de segurana realizada durante a execuo do teste
medida que so realizados testes individuais. Avaliao de teste de segurana a avaliao do resultado de

um teste de segurana. Quando os defeitos de segurana (vulnerabilidades) so identificados, um relatrio de
incidente deve ser arquivado, que afirma o seguinte, no mnimo:
Nome do testador observando a vulnerabilidade
Ambiente de teste onde a vulnerabilidade foi observada
Etapas de teste executadas (para facilitar a recriao dos resultados do teste)
Natureza da vulnerabilidade da segurana
Extenso da vulnerabilidade de segurana
Potencial impacto da vulnerabilidade de segurana
Plano de ao sugerido para remediao
Os relatrios de incidentes de testes de segurana podem ser arquivados usando o mesmo sistema de
gerenciamento de incidentes que outras formas de teste. Relatrios de teste de segurana deve ser atribudo
uma categoria especial e pode precisar de ser protegido para proibir a visualizao por pessoal no autorizado.
Tais situaes podem ser quando:
Os testes de segurana esto sendo realizados por uma organizao independente e os incidentes so
relatados em uma ferramenta que tem poucas restries na exibio de relatrios de incidentes
As vulnerabilidades de segurana podem ser identificadas, mas no imediatamente resolvidas
O pessoal interno pode ser considerado uma ameaa potencial para tirar proveito das vulnerabilidades
de segurana
O auditor de TI deve ser capaz de fazer a determinao de restringir ou no o acesso aos resultados dos testes
de segurana.
Na concluso de um grande esforo de teste de segurana, como na concluso do teste do sistema, um
relatrio final de teste de segurana pode ser emitido. Este relatrio tambm pode ser considerado
confidencial, dependendo do status da resoluo de vulnerabilidade.
3.6 Manuteno do teste de segurana

Em muitos casos, modificar o processo de teste de segurana pode consistir somente em adicionar novos tipos
de testes em resposta a novos tipos de ameaas. Uma coisa certa, no entanto. As metas e ameaas de testes
de segurana mudam diariamente, portanto, o processo de teste de segurana precisa ser projetado para
mudar facilmente.
Novas ferramentas tambm aparecem no mercado para ajudar a realizar testes de segurana. Os testadores
em segurana devem acompanhar esses avanos e avaliar quais ferramentas podem adicionar poder e
flexibilidade aos testes de segurana.

4 Teste de Segurana durante o ciclo de vida do software
(225 min)
Palavras-chave
Caso de uso de abuso, teste de fuzz
Objetivos de aprendizagem
4.1 O Papel dos Testes de Segurana no Ciclo de Vida do Software
AS-4.1.1 (K2): Explique por que a segurana melhor alcanada dentro de um processo de ciclo de vida
AS-4.1.2 (K3): Implementar as atividades relacionadas segurana apropriadas para um determinado ciclo de
vida do software (por exemplo, iterativo, sequencial
4.2 O Papel dos Testes de Segurana em Requisitos
AS-4.2.1 (K4): Analisar um determinado conjunto de requisitos da perspectiva da segurana para identificar
deficincias
4.3 O Papel dos Testes de Segurana na Modelagem
AS-4.3.1 (K4): Analisar um determinado documento de projeto do ponto de vista da segurana para identificar
deficincias
4.4 O Papel dos Testes de Segurana nas Atividades de Implementao
AS-4.4.1 (K2): Compreender o papel dos testes de segurana durante o teste de componentes
AS-4.4.2 (K3): Implementar testes de segurana de nvel de componente (resumo) dados uma especificao
de codificao definida
AS-4.4.3 (K4): Analisar os resultados de um determinado teste de nvel de componente para determinar a
adequao do cdigo a partir da perspectiva de segurana
AS-4.4.4 (K2): Compreender o papel dos testes de segurana durante os testes de integrao de componentes
AS-4.4.5 (K3): Implementar testes de segurana de integrao de componentes (resumo) dados uma
especificao de sistema definida
4.5 O Papel dos Testes de Segurana em Atividades de Teste de Sistema e Aceitao
AS-4.5.1 (K3): Implementar um cenrio de teste de ponta a ponta para testes de segurana que verifica um ou
mais requisitos de segurana e testa um processo funcional descrito
AS-4.5.2 (K3): Demonstrar a capacidade de definir um conjunto de critrios de aceitao para os aspectos de
segurana de um dado teste de aceitao
4.6 O Papel dos Testes de Segurana na Manuteno
AS-4.6.1 (K3): Implementar uma abordagem de teste de reteste / regresso de segurana de ponta a ponta
com base em um determinado cenrio

4.1 O Papel dos Testes de Segurana no ciclo de vida de um software
A segurana no testada ou corrigida em um aplicativo j construdo. Em vez disso, alcanado atravs de
modelagem orientado segurana e verificao durante todo o processo de construo. Como os testes de
software em geral, os testes de segurana tambm so um processo que deve ocorrer dentro do ciclo de vida
do desenvolvimento.
4.1.1 Viso do ciclo de vida dos testes de segurana

Um processo de ciclo de vida do software fornece uma estrutura para executar certas atividades s vezes que
se alinham com outras atividades. Por exemplo, as necessidades do usurio devem ser obtidas antes da
modelagem do aplicativo ocorrer. A seleo do ciclo de vida do software depende da natureza da organizao,
do projeto e de fatores similares [IEEE 12207]. Para efeitos deste programa e testes de segurana, os conceitos
e tcnicas podem ser aplicados a qualquer processo do ciclo de vida - sequencial ou iterativo.
No Captulo 3 deste programa, foi descrito um processo de teste de segurana que alinha com um ciclo
genrico de software genrico. As razes para integrar os testes de segurana no ciclo de vida do software so
discutidas nas sees a seguir.
Para fornecer um tempo prescrito no ciclo de vida quando as atividades relacionadas segurana devem
ocorrer, por exemplo, ao capturar e definir as necessidades do usurio, o analista de negcios ou de sistemas
deve fazer perguntas como:
Que nveis de acesso segurana so necessrios?
Existem ativos digitais ou fsicos que exijam defesas especiais de segurana?
Quo "aberta" a aplicao pretendida?
Quais so os riscos de segurana?
Outro exemplo seria durante a codificao. Neste momento, o desenvolvedor tem a melhor oportunidade
para aplicar prticas seguras de codificao para evitar ataques como, SQL injection e ataques de estouro de
buffer de memria. Encontrar esses tipos de vulnerabilidades durante etapas posteriores do projeto difcil e
dispendioso, pois muitos outros componentes de software tambm precisam ser corrigidos e corrigidos de
maneira semelhante.
4.1.1.1 Fornecer pontos de verificao para reviso
Por exemplo, requisitos de segurana ou histrias de usurios devem ser revistos para garantir que os aspectos
relacionados segurana das necessidades do usurio tenham sido adequadamente investigados e
documentados. As alteraes de cdigo tambm devem ser revistas para detectar a presena de cdigos
maliciosos por parte de funcionrios internos ou contratados.
4.1.1.2 Fornecer pontos de verificao para testes
Por exemplo, no desenvolvimento, os testes de componentes devem ser documentados e executados para
verificar se as prticas de codificao seguras foram seguidas e implementadas com sucesso.
4.1.1.3 Fornecer critrios de entrada e sada ao longo do projeto
Um exemplo desta prtica seria que nenhum componente pode ser aceito em um ambiente de teste integrado
at que possa ser mostrado que todas as atividades relacionadas segurana (desenvolvimento e teste) foram
concludas com xito. Isso especialmente importante em fases posteriores do projeto, onde uma
vulnerabilidade de segurana pode causar um risco de segurana que afeta todo o sistema ou aplicativo.

4.1.2 Atividades relacionadas segurana no Ciclo de Vida do Software
As seguintes atividades relacionadas segurana so executadas ao lado de outras atividades do projeto, ao
contrrio de serem realizadas em seu prprio ciclo de vida separado.
Requisitos: Requisitos so reunidos e definidos em uma variedade de maneiras, dependendo do ciclo de vida
do software em uso. Deve-se reconhecer que os requisitos podem ir alm das necessidades dos usurios e das
partes interessadas. Por exemplo, pode haver requisitos regulamentares, requisitos tcnicos e requisitos de
negcios, entre outros.
Os objetivos dos requisitos incluem:
Compreender e identificar as necessidades de segurana de todas as perspectivas dentro da
organizao e fora da organizao. Por exemplo, o cliente de uma empresa no est na organizao,
mas eles tm a necessidade de suas informaes privadas para permanecerem seguras.
Documentar as necessidades de segurana de forma detalhada e inequvoca. Isso permite a
implementao e teste que rastrevel para os requisitos, permitindo que os requisitos a serem
verificados e validados.
As atividades de requisitos incluem:
Definir todas as pessoas afetadas e conhecedoras que possam ter contribudo para os requisitos.
Utilizar uma variedade de mtodos, entrevistas, workshops, etc., reunindo as necessidades de
segurana expressas por cada grupo. Isto tambm pode ser realizado durante a elicitao de outros
requisitos.
Documentar os requisitos de uma forma que possa ser revisada e rastreada.
Revisar os requisitos de correo, integridade, compreenso e no ambiguidade.
Modelagem: O sistema ou aplicativo projetado com base nas necessidades indicadas nos requisitos. Os
requisitos expressam as necessidades de segurana enquanto a modelagem traduz as necessidades em uma
abordagem de soluo vivel.
Os objetivos do projeto incluem:
Criar um projeto de sistema ou aplicativo que atenda aos requisitos de segurana estabelecidos
As atividades de projeto incluem:
Analisar os requisitos documentados
Chegar abordagem mais vivel para desenvolver a aplicao de forma segura
Documentar o projeto usando as tcnicas apropriadas de acordo com o ciclo de vida do software. Por
exemplo, numa abordagem iterativa, as sesses de projeto podem ser realizadas em um quadro
branco, enquanto em outros processos a modelagem pode ser expressa em modelos.
Implementao: Isto comumente conhecido como a atividade de codificao.
Os objetivos de implementao incluem:
Traduzir os requisitos e o modelagem em cdigo seguro que atenda s necessidades funcionais
conforme indicado nos requisitos
Implementar quaisquer outros procedimentos ou tecnologias necessrias (firewalls, tokens, etc.) para
atender s necessidades de segurana
As atividades de implementao incluem:
Criar cdigo que atenda aos requisitos de segurana

Realizao de testes de componentes para verificar a correo, eficincia e segurana da
implementao
Realizao de revises de componentes para inspecionar visualmente a correo, eficincia e
segurana da implementao
Teste do sistema:
Observe que alguns modelos de ciclo de vida de software, como abordagens de entrega iterativas, adicionam
novos componentes ou refinam componentes existentes em um perodo de tempo mais curto e so capazes
de ter o teste do sistema muito mais frequentemente do que outras abordagens mais sequenciais.
Os objetivos de teste do sistema incluem:
Realizar um teste de ponta a ponta para observar o funcionamento geral e o desempenho do sistema
completo (hardware, software, dados, pessoas e procedimentos) depois de os vrios componentes do
sistema terem sido implementados e integrados num sistema completo
Testar se os requisitos de segurana foram implementados corretamente do ponto de vista do sistema
As atividades de teste do sistema incluem:
Realizar testes de segurana em alguma aproximao do ambiente final de destino, necessitando de
uma transio do ambiente de desenvolvimento no qual as atividades anteriores de implementao
e integrao ocorreram
Teste de aceitao:
Este o nvel final de teste durante o qual os usurios ou representantes dos usurios do sistema acreditam
que o sistema fornecer os recursos necessrios no ambiente de destino.
Os objetivos de teste de aceitao incluem:
Ter os usurios ou agentes atuando em nome dos usurios, realizar testes de segurana contra os
critrios de aceitao relacionados segurana estabelecidos para o sistema. Muitas vezes, os
critrios de aceitao relacionados segurana se concentram em controles e processos de segurana
funcionais.
As atividades de teste de aceitao incluem:
Instalar o sistema em seu ambiente operacional
Realizar testes de segurana com base em critrios de aceitao
Determinar a aceitao com base nos resultados dos testes
Deve notar-se que tanto o sistema como os testes de aceitao so essencialmente testes de "caixa-preta" ou
de resposta a estmulos sem considerar a estrutura interna ou o comportamento dos componentes dentro do
sistema global. O componente anterior e os testes de integrao fornecem avaliaes complementares
considerando e explorando a arquitetura interna dos componentes e suas interaes dentro do sistema.
Manuteno:
Depois de um sistema ter sido colocado em servio, pode ser necessrio esforo de desenvolvimento adicional
para corrigir defeitos na verso lanada (manuteno corretiva), para ajustar a outras mudanas no ambiente
operacional (manuteno adaptativa) ou para ampliar ou aprimorar recursos (manuteno aperfeioada).
A perspectiva de testes de segurana para a manuteno do sistema centra-se em testar as alteraes feitas
para corrigir os defeitos (testes de confirmao) e a funcionalidade principal (teste de regresso) para:
Assegurar que nenhuma nova vulnerabilidade tenha sido introduzida no sistema pelas atividades de
manuteno

Verificar se as defesas de segurana existentes ainda so eficazes aps uma alterao
Nesse contexto, a manuteno pode incluir atualizaes (por exemplo, sistema operacional, bancos de dados),
alteraes de codificao, converses de dados e migraes de plataformas.
Em essncia, qualquer atividade de manuteno deve ser tratada com o mesmo cuidado e ateno que o
desenvolvimento original. Caso contrrio, o risco de introduzir novas vulnerabilidades pode comprometer
seriamente a segurana do sistema operacional.
4.2 O Papel dos Testes de Segurana em Requisitos

As seguintes consideraes precisam ser entendidas sobre os requisitos em geral:
Muitas organizaes so desafiadas apenas a escrever requisitos bsicos do usurio que sejam claros,
inequvocos, completos, corretos e testveis.
Os requisitos so altamente sujeitos a mudanas ao longo de um projeto e, portanto, a manuteno
de requisitos pode ser um desafio.
So necessrias habilidades especiais para entender as necessidades do usurio e outras
necessidades, como a conformidade e as necessidades tcnicas, antes de poder redigi-las em
documentos ou inseri-las em ferramentas de gerenciamento de requisitos.
Requisitos podem conter lacunas e erros. Portanto, tanto a verificao como a validao so
necessrias.
Requisitos devem conter necessidades de caractersticas de qualidade, como segurana, desempenho,
usabilidade e assim por diante. No entanto, esses atributos so muitas vezes ignorados em favor da
funcionalidade apenas.
O desafio conseguir que a perspectiva de segurana seja compreendida e expressa no conjunto completo de
requisitos para um projeto. Ao avaliar os requisitos, uma tcnica eficaz usar uma lista de verificao como
um guia. Pode haver muitos itens contidos na lista de verificao para cobrir uma variedade de tpicos. Para
os atributos relacionados segurana, o seguinte um bom ponto de partida para a avaliao:
Necessidades de Privacidade:
Todos os grupos de usurios e suas necessidades de privacidade de dados relacionados foram
identificados e documentados?
Foram identificados todos os tipos de dados impactados por esse requisito e definidas as necessidades
de privacidade relacionadas?
Os direitos de acesso dos usurios foram identificados e definidos?
Necessidades de Conformidade (para polticas de segurana):
Todas as polticas de segurana relevantes foram identificadas e documentadas?
Foram identificadas e documentadas excees s polticas de segurana?
Vulnerabilidades Comuns: Estas mudanas sero alteradas ao longo do tempo, medida que os ataques de
segurana mudam, mas devem ser definidas como riscos no momento de se definir os requisitos. Estes
tambm se tornam a base para testes de segurana.
Todas as vulnerabilidades de segurana comuns e conhecidas para o recurso que est sendo
documentado foram identificadas como riscos conhecidos?
Testabilidade:
O requisito est escrito de forma a que os testes de segurana e outros testes possam ser escritos com
base no documento?

Quaisquer termos ambguos como "processamento deve ser seguro" e "acesso apenas concedido
ao pessoal autorizado" identificado e clarificado para ser especfico e testvel?
Usabilidade: H trade-offs entre segurana e usabilidade. Por exemplo, um login de usurio em um site pode
ser to confuso e difcil que os clientes desistem e vo para outro lugar.
Os requisitos refletem um nvel apropriado de processo de segurana em relao funo
especificada?
Os procedimentos de segurana so claros e compreensveis?
H solues especificadas para usurios legtimos que podem ter problemas no acesso a informaes?
Desempenho: H um trade-off entre segurana e desempenho. Por exemplo, possvel que altos nveis de
criptografia diminuam o desempenho.
Os requisitos refletem um nvel apropriado de eficincia de segurana em relao funo
especificada?
4.3 O Papel dos Testes de Segurana no Modelagem

As prticas de modelagem degradantes da segurana devem ser identificadas e evitadas. As atividades
relacionadas ao teste contribuem com o reconhecimento de projetos de sistemas de software que
provavelmente sero vulnerveis a comprometer e direcionar a modelagem de sistemas de software com
propriedades de segurana fortes e identificveis.
O IEEE Computer Society Center for Secure Modelagem [IEEE1] recomenda estas abordagens de modelagem
chave:
Ganhe ou d, mas nunca assuma, confiana
Use um mecanismo de autenticao que no possa ser ignorado ou adulterado
Autorizar aps a autenticao
Instrues e dados de controle estritamente separados e nunca processe instrues de controle
recebidas de fontes no confiveis
Definir uma abordagem que garanta que todos os dados so explicitamente validados
Usar criptografia corretamente
Identificar dados sensveis e como devem ser tratados
Considere sempre os usurios
Compreender como a integrao de componentes externos altera a sua superfcie de ataque
Seja flexvel ao considerar mudanas futuras em objetos e atores
4.4 O Papel dos Testes de Segurana nas Atividades de Implementao

Os testes de segurana, como em outros tipos de testes, comeam no nvel mais baixo de implementao,
exercendo componentes de software separados que sero montados no sistema geral. Aps a avaliao
esttica desses componentes, os testes fornecem um nvel adicional de avaliao, examinando o
comportamento dinmico em resposta a entradas vlidas e invlidas.
4.4.1 Teste de segurana durante o teste de componentes

4.4.1.1 Consideraes sobre a caixa-branca
Testes estticos, envolvendo toda a gama de inspeo, acompanhamento, auditoria e atividades de reviso
tcnica, j foi observado.

Os chamados testes caixa-branca (estruturais) referem-se a testes concebidos com base na visibilidade do
desenho ou implementao do software. Em contraste, o teste caixa-preta (funcional e no funcional) no se
baseia no acesso a nenhuma dessas informaes estruturais e simplesmente um teste de resposta a
estmulo.
O teste caixa-branca pode direcionar controles especficos implementados dentro do mdulo e determinar
sua efetividade. A visibilidade na estrutura do componente tambm permite medir a cobertura do teste, como
em termos de percentual de extratos executveis exercidos, porcentagem de resultados de decises exercidos
ou porcentagem de trajetrias lgicas percorridas.
Os testes de segurana estrutural podem ser realizados por ferramentas automticas de anlise esttica e
ferramentas de verificao de segurana. O teste de Fuzz uma tcnica de teste de segurana usada para
descobrir vulnerabilidades de segurana, introduzindo quantidades macias de dados aleatrios, chamados
fuzz, para o componente ou sistema sob teste. Teste de fuzz de caixa branca (em pequenos blocos de software,
funes, classes) pode obter resultados utilizveis em muito menos tempo do que uma ferramenta de fuzzing
em caixa preta.
As ferramentas de teste de fuzz de caixa branca so capazes de detectar corrupo de memria, estouro de
buffer, etc., instrumentando o cdigo que est sendo testado.
As vulnerabilidades de segurana a seguir podem ser identificadas e corrigidas durante os testes estruturais:
Transbordamento do buffer de memria
Cdigo malicioso inserido por um empregado ou contratado interno
Acesso "Backdoor" (acesso via uma interface no documentada conhecida apenas pelo
desenvolvedor, que foi intencionalmente implementada para ignorar os controles de segurana
normais)
4.4.1.2 Consideraes sobre testes de segurana funcionais
A adequao dos testes de segurana a qualquer nvel deve ser determinada confirmando a satisfao dos
requisitos de segurana especificados, alm de observar respostas a estresses no explicitamente
especificados em requisitos de segurana, avaliaes de risco de segurana e documentos similares. A
criatividade necessria para testar os pontos fracos de segurana, porque os testadores esto investigando
o que os desenvolvedores de software ignoraram.
4.4.2 Desenho de teste de segurana no nvel de componente

Um exemplo de conjunto de prticas recomendadas de codificao de alto nvel pode ser encontrado no artigo
"Top 10 Secure Coding Practices" [CERT1] que afirma:
"Os testes para qualquer componente devem incluir a avaliao de possveis violaes destas prticas:
Validar entrada.
Respeite os avisos do compilador.
Arquiteto e modelagem para polticas de segurana.
Mantenha simples.
Negao predefinida.
Aderir ao princpio do privilgio mnimo.
Desinfetar os dados enviados para outros sistemas.
Defesa da prtica em profundidade.
Usar tcnicas eficazes de garantia de qualidade.
Adoptar um padro de codificao segura. "

Os testes realizados em relao a essas listas de verificao das melhores prticas devem incluir avaliaes de
possveis violaes destas prticas com base numa anlise de risco bem documentada que incorpore modelos
de ameaas realistas. Em outras palavras, concentre-se nos requisitos mais cruciais em termos de
probabilidade de ataque e as consequncias do compromisso.
4.4.3 Anlise de testes de segurana no nvel de componente

Uma medida chave da adequao envolve a avaliao da cobertura do teste. Diversas medidas de cobertura
derivam da natureza do teste realizado.
Testes baseados em requisitos testam o sistema para fornecer garantia de que ele atende aos requisitos
especificados. Sem considerao para a implementao (caixa-preta), a cobertura pode ser medida com
qualquer uma das seguintes porcentagens:
Nmero total de requisitos testados
Casos de uso / abuso especificados testados
Funes crticas, cenrios ou segmentos de misso testados
Testes orientados a dados testam o sistema para fornecer a garantia de seu comportamento em um intervalo
e combinao de dados de entrada, tentando escolher em poucos valores de teste possveis, dividindo o
espao de dados em classes de equivalncia e selecionando um representante de cada classe (com a
expectativa que os elementos desta classe so equivalentes em termos de sua capacidade de detectar falhas).
Os critrios de cobertura Pairwise e Nwise so formas tpicas de critrios de cobertura de dados.
Testes baseados em modelos fornecem garantia de cobertura em termos de uma notao de modelagem
escolhida. Quando o modelo usa uma notao pr-post, os critrios podem incluir cobertura de causa-efeito
e cobertura de todos os arranjos na ps-condio. Para as notaes de modelagem algbrica, a cobertura dos
axiomas um critrio de cobertura tpico.
Para os modelos baseados na transio, que utilizam grficos explcitos que contm ns e arcos, os critrios
de cobertura de grfico incluem porcentagem de ns (estados), porcentagem de transies, porcentagem de
pares de transio e porcentagem de ciclos.
Os testes estruturais fornecem garantia baseada na visibilidade e na anlise da implementao real. Por
simples enumerao, cobertura de teste comumente relatada como a porcentagem dos pacotes, classes,
mtodos, decises ou linhas de cdigo executvel no aplicativo que so executados pelos testes. Este ltimo
referido como cobertura de declarao.
A complexidade ciclomtica uma medida de quantos caminhos independentes diferentes existem atravs
de um elemento e podem ser visualizados em termos de um grfico de fluxo de controle com ns (pontos de
deciso) e arcos (caminhos). O mais forte dos critrios baseados no fluxo de controle a cobertura do caminho,
que mede contra todos os caminhos de entrada a sada no grfico de fluxo de controle. Uma vez que o teste
de exaustivo de caminho geralmente no vivel por causa de loops, outros critrios menos rigorosos podem
ser expressos em termos de caminhos lgicos selecionados considerados crticos (cobertura do caminho
crtico) ou da porcentagem de resultados de deciso exercidos (cobertura de desvio).
4.4.4 Teste de segurana durante o teste de integrao de componentes

Como componentes de nvel inferior so integrados em subsistemas e, eventualmente, o sistema de destino
completo, as possibilidades de violaes de segurana no so simplesmente o somatrio das vulnerabilidades
em cada um dos componentes considerados separadamente. Em vez disso, novos vetores de ataque tornam-
se possveis devido a interaes entre componentes e com elementos maiores do sistema e da organizao.

Por outro lado, algumas interaes entre componentes podem mitigar ou bloquear possveis sequncias que
levam a violaes de segurana. Novamente, os testadores em segurana precisam ser criativos na busca de
algo que os desenvolvedores ignoraram.
Os testes de integrao podem demonstrar a complexidade de um projeto de sistema e a estabilidade de seu
comportamento. A abordagem de teste de integrao (por exemplo, de cima para baixo ou de baixo para cima)
pode afetar o momento de revelar preocupaes de segurana ou a necessidade de testes adicionais
especficos de segurana.
4.4.5 Modelagem de Testes de Segurana no Nvel de Integrao de Componentes

Tal como acontece com os testes de componentes, os testes de integrao devem ser concebidos com base
numa anlise de risco bem documentada que incorpore uma modelizao de ameaas realista. Como
componentes separados so integrados juntos, note que a plataforma (na forma de simuladores e
controladores) pode ser necessria para testar menos caminhos atravs de um sistema durante a integrao.
medida que mais componentes implementados so adicionados ao sistema, esta plataforma removida de
forma incremental, permitindo uma avaliao mais completa da funcionalidade, assim como novos caminhos
para vulnerabilidades que possam ser exploradas.
4.5 O Papel dos Testes de Segurana em Atividades de Teste de Sistema e

Aceitao
4.5.1 O Papel dos Testes de Segurana nos Testes do Sistema
O teste do sistema o primeiro exerccio de ponta a ponta dos componentes totalmente integrados. Embora
geralmente feito em um ambiente de desenvolvimento, ele deve revelar propriedades emergentes do sistema
que no teria sido observado antes da integrao foi concluda. Os requisitos de segurana so normalmente
considerados em conjunto com um dos requisitos mais funcionais.
Por exemplo, "No processo de fazer x o sistema no deve permitir que y acontea". medida que os testes
funcionais so conduzidos, o testador deve estar investigando as maneiras pelas quais as restries de
segurana podem ser violadas.
Requisitos funcionais, incluindo os de segurana, normalmente atendem aos imperativos. Outras
especificaes, como casos de uso, casos de abuso, modelos de processo e modelos de transio de estados
descrevem procedimentos que podem ser usados para definir cenrios de teste de ponta a ponta para testes
de segurana.
4.5.2 O Papel dos Testes de Segurana nos Testes de Aceitao

Os testes de aceitao distinguem-se dos testes do sistema pelo fato de serem realizados em um ambiente
operacional realista, se no na configurao real em que o sistema se tornar operacional. Tais testes
permitem uma avaliao razovel do desempenho e outros comportamentos baseados em interaes atravs
de interfaces externas. Ele finalmente coloca o sistema no ambiente em que agentes de ameaas externas
estariam buscando encontrar fraquezas no dia-a-dia.
Testes de aceitao idealmente devem validar que os objetivos iniciais do projeto foram entregues. Isto
conseguido atravs da concepo e realizao de testes para validar que os critrios de aceitao so
cumpridos. As necessidades de segurana devem ser documentadas nos critrios de aceitao.
O melhor momento para definir e documentar os critrios de aceitao antes do desenvolvimento ou da
compra do sistema. Portanto, uma compreenso inicial pode ser feita entre o fornecedor e o adquirente,
mesmo se ambos estiverem na mesma organizao. Tambm comum que os critrios de aceitao mudem

ou surjam durante um projeto, portanto, esses critrios devem ser analisados quanto ao seu impacto nos
testes de segurana.
No contexto dos testes de segurana, os critrios de aceitao podem ser de natureza global. Por exemplo,
pode haver pontos de critrios de aceitao que especifiquem o que aceitvel em termos de segurana geral
do sistema. Isso incluiria critrios que so aplicados a todas as funes do sistema, como autenticao de
usurio, direitos de usurio, nveis de criptografia, trilhas de auditoria e assim por diante. Em outros casos,
podem ser necessrios critrios especficos de aceitao de segurana. Por exemplo, algumas funes, como
a emisso de pagamentos em excesso de um determinado montante podem exigir duas pessoas para aprovar
o pagamento.
4.6 O Papel dos Testes de Segurana na Manuteno

O teste de regresso pretende confirmar que todos os comportamentos previamente aceitveis do sistema
permanecem intactos aps modificaes terem sido feitas. Nos aspectos negativos dos testes de segurana,
tal confirmao envolveria a verificao de que o sistema continua a resistir com sucesso as tentativas de
derrotar os controles de segurana estabelecidos. Os aprimoramentos na usabilidade ou na eficincia so
especialmente propensos a sacrificar os controles de segurana.
Os testes de regresso de segurana devem se concentrar em confirmar a satisfao de todos os requisitos de
segurana, bem como em testar novas vulnerabilidades que possam ter sido introduzidas durante as
atividades de manuteno.
Teste de regresso muitas vezes aplicado com uma coleo de casos de teste que se baseiam em testes de
funes individuais. No entanto, para testes de segurana, isso muitas vezes insuficiente para detectar
defeitos de regresso com impacto de segurana. Os cenrios de teste de regresso de ponta a ponta so mais
robustos e proporcionam um nvel mais elevado de confiana de que transaes completas podem ser
realizadas de forma segura.
Para este tipo de teste de regresso, um conjunto de cenrios de teste de segurana deve ser definido e
testado sempre que uma alterao feita ao sistema. Tenha em mente que as alteraes do sistema podem
ser estendidas para incluir hardware, arquivos de configurao, sistemas operacionais, SGBDs, rede e software
- e quaisquer outros componentes do sistema. Defeitos de regresso podem aparecer a partir de alteraes a
qualquer um destes. Alguns dos defeitos de regresso podem ter um impacto na segurana.
Exemplo de cenrios:
Os usurios podem fazer login em um site e concluir uma compra de forma segura sem comprometer suas
informaes pessoais.
Os usurios s so capazes de executar aes definidas em seus direitos de usurio e privilgios. (Um usurio
que trabalha no departamento de folha de pagamento pode ser capaz de adicionar um novo funcionrio, mas
no ter acesso s suas informaes bancrias.)

5 Mecanismos de Teste de Segurana (240 min)
Palavras-chave
Anti-malware, autenticao, autorizao, zona desmilitarizada, encriptao, firewall, hashing, ameaa interna,
sistema de deteco de intruso, malware, varredura de malware, zona de rede, pharming, phishing, salting,
enrijecimento do sistema, varredura de vulnerabilidade.
5.1 Enrijecimento de sistema
AS-5.1.1 (K2): Compreender o conceito de enrijecimento do sistema e seu papel no aprimoramento da
segurana
AS-5.1.2 (K3): Demonstrar como testar a eficcia dos mecanismos comuns de enrijecimento do sistema
5.2 Autenticao e Autorizao
AS-5.2.1 (K2): Compreender a relao entre autenticao e autorizao e como elas so aplicadas na proteo
de sistemas de informao
AS-5.2.2 (K3): Demonstrar como testar a eficcia dos mecanismos comuns de autenticao e autorizao
5.3 Criptografia
AS-5.3.1 (K2): Compreender o conceito de criptografia e como ele aplicado na proteo de sistemas de
informao
AS-5.3.2 (K3): Demonstrar como testar a eficcia de mecanismos comuns de criptografia
5.4 Firewalls e Zonas de Rede
AS-5.4.1 (K2): Compreender o conceito de firewalls e o uso de zonas de rede e como elas so aplicadas na
proteo de sistemas de informao
AS-5.4.2 (K3): Demonstrar como testar a eficcia de implementaes de firewall e zonas de rede existentes
5.5 Deteco de Intruso
AS-5.5.1 (K2): Compreender o conceito de ferramentas de deteco de intruso e como elas so aplicadas na
AS-5.5.2 (K3): Demonstrar como testar a eficcia das implementaes de ferramentas de deteco de intruso
existentes
5.6 Varredura de malware
AS-5.6.1 (K2): Compreender o conceito de ferramentas de varredura de malware e como elas so aplicadas na
AS-5.6.2 (K3): Demonstrar como testar a eficcia das implementaes de ferramentas de verificao de
malware existentes
5.7 Mascaramento de dados
AS-5.7.1 (K2): Compreender o conceito de ferramentas de mascaramento de dados e como elas so aplicadas
na proteo de sistemas de informao
AS-5.7.2 (K3): Demonstrar como testar a eficcia das abordagens de mascaramento de dados

5.8 Formao
AS-5.8.1 (K2): Compreender o conceito de treinamento de segurana como atividade de ciclo de vida do
software e por que necessrio para proteger sistemas de informao
As-5.8.2 (K3): Demonstrar como testar a eficcia do treinamento em segurana

5.1 Enrijecimento de Sistema
Ao longo dos anos, uma variedade de mecanismos de segurana surgiu como prtica-chave na obteno de
ativos digitais e fsicos. Cada um desses mecanismos pode ser aplicado de vrias maneiras - algumas atravs
de ferramentas e infraestrutura, outras atravs de esforo manual. Nenhum desses mecanismos por si s
suficiente na maioria dos casos para garantir a informao. Cada mecanismo tem suas prprias vantagens e
desvantagens.
Os testadores em segurana precisam entender as nuances de cada linha de defesa para que testes adequados
possam ser projetados para verificar e validar sua eficcia. Os testadores em segurana de nvel avanado
precisam entender as implicaes de cada um dos mecanismos descritos neste captulo para projetar uma
arquitetura de teste que fornecer uma estrutura para testes de segurana contnuos.
5.1.1 Compreendendo o enrijecimento do sistema

Os sistemas modernos esto se tornando cada vez mais complexos, assim sua superfcie de ataque est
crescendo continuamente. Vulnerabilidades vm de erros de projeto (por vulnerabilidades de projeto),
defeitos de cdigo-fonte (por vulnerabilidades de construo) ou falta de rigor na configurao desses
sistemas (por vulnerabilidades de configurao).
O enrijecimento do sistema o processo passo-a-passo de reduzir a superfcie de ataque aplicando uma
poltica de segurana e diferentes camadas de proteo. O principal objetivo garantir o sistema e reduzir os
riscos de comprometimento da segurana.
Dependendo do contexto, o enrijecimento pode ser aplicado em diferentes nveis:
Enrijecimento de um componente de software ou hardware
Enrijecimento de um produto / aplicao
Enrijecimento de um sistema
Enrijecimento de um sistema de sistemas
As defesas de segurana organizacional e tcnica a serem aplicadas devem incluir:
Remover software desnecessrio (pode conter defeitos)
Remover bibliotecas desnecessrias e ferramentas de desenvolvedor (pode conter defeitos)
Remover contas / logins desnecessrios (vetores de ataque)
Remover aplicativos desnecessrios (podem conter defeitos) e servios de rede (vetores de ataque)
Remover perifricos e portas de hardware desnecessrios (por exemplo, portas USB, leitores de
cartes)
Atualizaes rpidas e instalao de atualizaes (por exemplo, ativar atualizaes automticas)
Atualizar as configuraes
Seguir as regras de codificao (evite vulnerabilidades "de construo")
Configurar o servidor de registro remoto (por exemplo, remote-syslog) para que, em caso de
compromisso, o invasor somente consiga excluir os arquivos de log da mquina comprometida, mas
no no servidor de log remoto
Os seguintes mecanismos de segurana devem ser usados:
Autenticao forte e gerenciamento eficiente da autorizao (apenas conceder os direitos necessrios
para realizar aes para funes dedicadas)
Criptografia (comunicao e armazenamento hospedado local)
Firewalls (aplicativos pessoais, de sistema ou web) e zonas de segurana definidas (por exemplo,
execuo em uma caixa de areia)

Sistema de deteco de intruso
Anti-malware / anti-spyware
Mascaramento de dados e aplicaes (por exemplo, proteo contra engenharia reversa)
O enrijecimento do sistema vital para proteger os ativos sensveis de uma organizao, mas as regras de
segurana devem ser aplicadas no nvel correto e equilibradas com a usabilidade do sistema. No extremo
desse trade-off, as protees so desativadas porque bloqueiam a produtividade da empresa.
5.1.2 Testando a Eficcia dos Mecanismos de Enrijecimento do Sistema

Testar a eficcia dos mecanismos de enrijecimento do sistema pode ser realizado de vrias maneiras. Os testes
dependero da natureza do sistema ou da aplicao que est sendo endurecida, da sensibilidade dos ativos
protegidos e das ameaas identificadas. O enrijecimento do sistema restringe o acesso do sistema s funes
certas, abre apenas os servios necessrios e monitora as atualizaes de aplicativos. Portanto, para testar a
eficcia do enrijecimento do sistema, os testes devem ser concebidos de modo que se saiba se os esforos de
enrijecimento esto funcionando, aplicados nos lugares certos e aplicados da maneira correta. Tambm
importante testar protees de enrijecimento do sistema que so muito restritivas e podem ser excessivas em
vista dos riscos de segurana.
Alguns testes de enrijecimento do sistema podem ser baseados na reviso ou na auditoria, enquanto outros
testes podem ser baseados na capacidade de determinados grupos de usurios executar determinadas aes
ou acessar determinados dados.
Os testes podem incluir:
A auditoria da configurao dos servidores de banco de dados e aplicativos para verificar se as senhas
padro foram alteradas
A auditoria da configurao do sistema para identificar servios desnecessrios e portas de rede
A verificao de componentes, bibliotecas e verses de aplicativos para verificar se eles no so
obsoletos e vulnerveis
Um scanner de vulnerabilidade pode ser executado para facilitar as tarefas de avaliao de vulnerabilidades,
especialmente se o sistema for complexo (por exemplo, um ambiente multi-site). Ferramentas de anlise
esttica podem ser usadas para detectar violaes de regras de codificao que podem introduzir
vulnerabilidades de construo. Os analisadores orientados para a segurana podem ser particularmente teis
para detectar vulnerabilidades.
5.2 Autenticao e Autorizao

5.2.1 Relao entre Autenticao e Autorizao
Os ativos sensveis de uma organizao (por exemplo, nmeros de contas bancrias de uma lista de clientes,
modelagem de um novo produto) precisam ser protegidos e devem ser acessveis somente pela pessoa
autorizada.
A autenticao baseada na verificao de um identificador de usurio e um token para responder s
perguntas:
Login: quem o usurio?
Senha: o usurio realmente quem ele finge ser?
Implementaes diferentes de mecanismos de autenticao podem ser usadas dependendo da necessidade
de proteger contra-ataques para sequestrar a autenticao ou roubar uma senha. Estes incluem a deteco

de senhas fracas, empregando senhas nicas (OTP), impresses digitais, certificados de software, certificados
em tokens rgidos e meios de autenticao semelhantes.
Dependendo da arquitetura de um sistema, do contexto aplicativo e das necessidades de uma organizao
(facilidade de gerenciar login/senha), os mecanismos de autenticao podem incluir autenticao local,
autenticao de servidor, autenticao de rede, SSO (Single Sign-On) e similares significa.
A autorizao utilizada para os seguintes fins:
Para verificar se o usurio autenticado tem os direitos para executar uma ao (por exemplo, o usurio
pode fazer login em um servidor, mas no pode modificar seus dados ou um usurio est autorizado
a usar um servidor FTP, mas apenas em seu espao dedicado)
Determinar que nvel de acesso deve ser permitido aos recursos do sistema
H um forte vnculo entre autenticao e autorizao com base no princpio de que um usurio no
autenticado no tem direitos ou direitos restritos no sistema (no autorizado a manipular dados
confidenciais). Por exemplo, no contexto de um site comercial, um usurio no autorizado pode ver a lista de
produtos, mas antes de comprar o artigo escolhido, o usurio deve criar uma conta de usurio. O usurio
autenticado pode comprar um item, mas no pode executar funes administrativas.
5.2.2 Testando a Eficcia dos Mecanismos de Autenticao e Autorizao

O objetivo dos atacantes roubar senhas ou ignorar sistemas para executar aes no autorizadas.
Geralmente, eles exploram diferentes tipos de fraquezas: erros de codificao (falta de filtragem de entrada),
verso antiga vulnervel das bibliotecas, erros de configurao do sistema (mantendo senhas padro, direitos
padro) e senhas fracas (por exemplo, a senha mais usada "123456").
Uma organizao pode ter um conjunto de regras de senha que devem ser seguidas, mas se o usurio no for
diligente em manter a senha segura, as regras de senha no faro a diferena. Alm disso, as regras de senha
devem refletir as boas prticas atuais na definio de senhas. Tais prticas podem ser encontradas nas
Diretrizes de Construo de Senhas do Instituto SANS [SANS2].
Os testes para os mecanismos de autenticao e autorizao podem incluir:
Fora bruta e ataques de dicionrio para tentar descobrir senhas de usurio. Os primeiros passos
podem ser tentar "123456", "111111", data de nascimento, nome do animal de estimao, etc.
Falta de explorao de filtragem de entrada, por exemplo, para injetar solicitaes SQL para ser
autenticada sem nenhum login/senha conhecidos.
Introduza URI no autorizado (../../ em uma conta FTP) ou URL (endereo do site/admin) para tentar
obter acesso a dados confidenciais.
Outro exemplo pode ser explorar uma vulnerabilidade no sistema alvo (talvez porque no tenha sido
atualizado) para causar um comportamento no intencional e geralmente resultando em ganhar o controle
do sistema e permitindo a escalao de privilgios.
5.3 Criptografia
5.3.1 Entendendo a criptografia
Para evitar a divulgao de dados sensveis, mesmo que possa ser acessado quando armazenado ou trocado
entre cliente e servidor, um mecanismo de criptografia pode ser usado. Hashing e Salting so mtodos usados
durante a criptografia.
A criptografia um processo de codificao de dados (texto simples) em dados cclicos (criptografar texto),
usando um algoritmo criptogrfico e segredos, de tal forma que somente pessoas autorizadas tm o direito

de acessar usando um mecanismo de descriptografia. O segredo compartilhado e s conhecido pelos
usurios autorizados. O objetivo ter uma criptografia que seja suficientemente forte para impedir que um
invasor, que pode ter conseguido roubar dados criptografados, tenha recuperado o texto sem formatao. O
uso de algoritmos criptogrficos ajuda a garantir a confidencialidade, a integridade, a disponibilidade de ativos
sensveis e o repdio manipulao.
Protocolos criptogrficos podem ser usados para proteger informaes:
Armazenado em um sistema, por exemplo, senhas cifradas em um banco de dados, unidade
criptografada lgica, unidade de disco rgido inteiramente cifrada
Durante a comunicao, por exemplo, e-mail cifrado, protocolo de comunicao criptografado (SSL, TLS)
Os principais e bem conhecidos protocolos criptogrficos utilizados so:
Criptografia simtrica: uso de chave secreta compartilhada
Criptografia assimtrica: uso de chave pblica e privada
5.3.2 Testando a Eficcia dos Mecanismos Comuns de Criptografia

Alguns mecanismos criptogrficos so conhecidos por serem fracos, especialmente devido ao tamanho curto
das chaves secretas, ou chaves estticas. Outros mecanismos so vulnerveis porque ou no so
implementados com as melhores prticas ou incorporam defeitos de codificao (como estouro de buffer).
Os testes para mecanismos de criptografia devem incluir:
Testes para vulnerabilidades de modelagem:
Avaliao de que os modos direitos so usados na criptografia simtrica
Verificao de que o tamanho das chaves criptogrficas no muito pequeno (por exemplo, a partir
de 2015, uma chave RSA com menos de 2048 bits considerada insegura)
Validao da validade dos certificados e capacidade de levantar um alerta se o certificado for auto-
assinado (SSL-trip pode ser usado para evitar ataques man-in-the-middle)
Repetio de ataque (por exemplo, ataque contra protocolos Wired Equivalent Privacy (WEP))
Ataques contra protocolos criptogrficos para verificar seu nvel de fora [Bittau]
Testes para vulnerabilidades de construo:
Revises de cdigo (por exemplo, para verificar que a funo padro random () no usada para gerar
nmeros aleatrios (semente) porque o algoritmo aleatrio relativamente fcil de quebrar)
Fuzzing para explorar comportamentos inesperados
Ataques de tempo (analisando o tempo necessrio para executar algoritmos criptogrficos)
Anlise de potncia (usada para dispositivos de hardware criptografados)
Testes de vulnerabilidades de configurao:
Avaliao de configurao de protocolo criptogrfico (por exemplo, configurao do lado do servidor
de TLS), protocolos autorizados do lado do cliente, com base no guia de configurao TLS para
administradores)
Ordem de cifra TLS no lado do servidor, para ver se existe algum meio para rebaixar ou renegociar a
cifra que est sendo usada
Testes de envelhecimento para verificar mecanismos de criptografia que podem ter se tornado fracos
e propensos a ser rachados

5.4 Firewalls e Zonas de Rede
5.4.1 Compreendendo os Firewalls
De acordo com [Chapman 2000], "um firewall um componente ou um conjunto de componentes que restringe
o acesso entre uma rede protegida e a Internet, ou entre outros conjuntos de redes". Um firewall implementa
e impe uma poltica de segurana baseada na definio de autorizao e proibio. Um firewall pode ser
baseado em host (software executado em um nico host que monitora entradas/sadas de aplicativos) ou
baseado em rede (software que monitora o trfego entre redes).
A tarefa principal de um firewall controlar o trfego entre diferentes zonas de rede confiveis, filtrando os
dados que trafegam na rede. Desta forma, o trfego malicioso proveniente de uma zona no confivel
detectado e bloqueado.
Uma zona de rede uma sub-rede identificada com um nvel de confiana definido:
Internet/zona pblica considerada como no confivel
Vrias zonas de segurana denominadas zonas desmilitarizadas ou DMZ, com diferentes nveis de
confiana
Uma ou mais redes privadas/internas consideradas como as mais confiveis
As zonas de rede so partes da configurao do firewall: so utilizadas para definir os fluxos autorizados entre
as diferentes redes. Todo o trfego proibido est bloqueado.
Normalmente, um firewall filtra a comunicao com base em:
Endereos e protocolos de origem e de destino (endereos Ethernet ou IP, portas TCP / UDP, etc.)
Opes de protocolo (fragmentao, TTL, etc.)
Tamanho dos dados
Os firewalls de aplicativos da Web (WAFs) tambm filtram a comunicao com base em:
Usurios sendo as conexes
Filtragem de dados (por exemplo, usando descries de padres)
5.4.2 Testando a Eficcia do Firewall

Devido ao nmero de protocolos, s suas diferentes opes e complexidade das redes a proteger, difcil
configurar um firewall de forma eficiente. Os testes de eficcia do firewall devem incluir:
Digitalizao de portas para verificar se a poltica de segurana est bem implementada
Utilizar pacotes de rede malformados e fuzzing de rede para explorar um comportamento inesperado
(por exemplo, um Denial of Service)
Ataques de fragmentao para ignorar recursos de filtragem com o objetivo de realizar o ataque por
trs do firewall
Outro exemplo de testes, visando o WAF, codificar e comprimir dados ou ofusc-lo para ocultar as
informaes maliciosas que transmite o ataque.
5.5 Deteco de Intruso

5.5.1 Compreendendo as Ferramentas de Deteco de Intruso
Cada ano, o nmero de ataques aumenta. As tcnicas de intruso evoluem rapidamente e nenhum sistema
100% seguro.

Um Sistema de Deteco de Intruso (IDS) um sistema (dispositivo autnomo ou aplicativo) que monitora
atividades em diferentes nveis (da rede ao aplicativo, 7 camadas do modelo OSI) para detectar violaes da
poltica de segurana. Se forem detectados desvios do comportamento normal, so levantados alertas que
podem ser analisados para outras aes (por exemplo, bloqueio de trfego, caminho virtual).
Em relao padronizao do IDS, o Internet Engineering Task Force Working Group Intrusion Detection
Exchange Format descreve um modelo de modelagem para um IDS baseado em dois modelos de segurana:
Modelo de segurana negativa (deteco baseada em assinatura ou deteco de lista negra): a regra
"tudo o que no proibido explicitamente permitido". A deteco de intruso baseada em uma
lista de ataques conhecidos ou padres.
Modelo de segurana positiva (deteco baseada em comportamento ou deteco de lista branca):
a regra "tudo o que no explicitamente permitido rejeitado". A deteco de intruso baseada
na especificao do comportamento do sistema para proteger, por exemplo, as caractersticas de uma
entrada numa forma descrita como uma expresso regular. A intruso detectada se o
comportamento se desviar do comportamento normal ou esperado do sistema. O trfego confivel
pode ser usado para gerar a especificao.
Um IDS difere de um firewall em que um firewall olha para fora no trfego para parar intruses enquanto o
IDS analisa intruses suspeitas e levanta um alerta se eles so confirmados.
5.5.2 Testando a Eficcia das Ferramentas de Deteco de Intruso

A deteco baseada em cenrios fcil de ignorar, porque apenas os ataques conhecidos so detectados. Os
testes podem incluir as seguintes tcnicas de evaso:
Codificao de caracteres ou modificao de dados (por exemplo, adicionar espao em branco, fim de
linhas, etc.)
Fragmentao de IP, Segmentao TCP
Criptografia, mascaramento
Codificao de URL
A deteco baseada em comportamento gera um grande nmero de resultados falsos positivos e resultados
falsos negativos. Um resultado negativo falso qualquer alerta que deveria ter informado, mas no foi. Falso
negativos podem ocorrer quando um novo ataque desenvolvido que um IDS no est ciente de, ou talvez
uma regra pode ser escrita de tal forma a detectar alguns ataques, mas perder outros. Alm disso, a preciso
deste mtodo de deteco deve ser considerada. possvel que um invasor desvie o comportamento do IDS
do seu comportamento normal resultando em uma nova especificao contendo comportamento intrusivo.
Assim, este novo trfego no considerado anmalo. Os testes complementares devem usar trfego malicioso
para adicionar novas especificaes intrusivas consideradas como trfego autorizado.
Algumas entradas podem ser usadas para definir um conjunto de testes para IDS, como "Sistema de Deteco
de Intruso de Proteo de Perfil" [PP-IDS] e "Web Application Firewall Evaluation Criteria" [WAFEC].
5.6 Varredura de malware

5.6.1 Compreendendo as Ferramentas de Varredura de Malware
O cdigo malicioso pode afetar os servidores e computadores dos usurios finais, fornecendo aos seus
inventores os privilgios esperados e os dados sensveis alvos. O cdigo malicioso colocado no destino
usando diferentes meios, como um e-mail com anexos maliciosos, URLs falsas, execuo de cdigo no lado do
cliente, etc.

Uma aplicao anti-malware um software usado para analisar, detectar e remover cdigos maliciosos
recebidos de diferentes fontes, com diferentes alvos de deteco: malware, phishing e pharming.
O recurso de deteco principal usado pelo anti-malware uma estratgia baseada em assinatura. O princpio
pesquisar em um banco de dados os padres conhecidos de dados que descrevem um pedao de cdigo
suspeito. No entanto, novos malwares ou malwares para os quais a assinatura no est presente no banco de
dados no sero detectados e podero infectar sua vtima. Um mecanismo heurstico muitas vezes
incorporado em anti-malware para identificar pequenas variaes de padres maliciosos conhecidos para
ajudar a combater este problema.
5.6.2 Testando a Eficcia das Ferramentas de Varredura de Malware

Os desenvolvedores de malware e backdoors usam diferentes tcnicas para proteger seu cdigo contra a
deteco. Algumas destas tcnicas incluem:
Explorando as funes da biblioteca do sistema usadas por malware (por exemplo, FindWindow que
pode ser usado para fechar uma aplicao anti-malware)
Mascaramento de strings para desativar a compreenso do comportamento de cdigo mal-
intencionado (por exemplo, usando criptografia). Um exemplo pode ser armazenar script Java em um
documento PDF. Outra usar compresso como Ultimate Packer para executveis (UPX).
Carregamento dinmico de funes e bibliotecas (por exemplo, para limitar a anlise do cdigo
malicioso)
Atualizao automtica de aplicativos (por exemplo, Trojan Skype)
O malware tambm pode usar outros recursos de hardware, como a Unidade de Processamento Grfico
(GPU), para descompactar cdigo malicioso e armazen-lo na memria para ser executado pelo processador.
Nesse caso, o malware no pode ser analisado antes da execuo.
Do ponto de vista de testes funcionais, uma ferramenta como "Eicar" (arquivo de teste anti-malware) pode
ser usada para testar a eficcia do anti-malware sem desenvolver cdigos maliciosos.
Uma considerao importante ao implementar um novo aplicativo anti-malware ou atualizar um aplicativo
anti-malware existente testar a implementao em uma plataforma representativa antes de implant-la em
toda a organizao. Houve casos em que o software anti-malware identificou falsamente arquivos legtimos
do sistema operacional como malware e os colocou em quarentena, encerrando assim toda a capacidade de
computao da organizao.
5.7 Mascaramento de dados

5.7.1 Compreendendo a Mascaramento de Dados
Mascaramento (s vezes chamada de mascaramento de dados) um mecanismo para tornar os dados e
cdigo-fonte no compreensvel para um ser humano.
Esta tcnica usada principalmente para proteger dados sensveis contra:
Cpia, para ignorar mecanismos de proteo de licena
Engenharia Reversa, para entender o cdigo para explorar vulnerabilidades
A mascaramento de dados tambm pode ser usada para permitir que os funcionrios de uma empresa
(pessoal de suporte, testadores funcionais, etc) para trabalhar com dados no-sensveis, escondendo os dados
sensveis de vista. Alguns podem se referir a mascaramento de dados como "anonimizao de dados", na
medida em que mantm annimos os dados pessoais de um indivduo.

A mascaramento tambm pode ser usada para proteger o cdigo-fonte contra o simples copiar-colar (por
exemplo, para proteger um novo algoritmo inovador) e reutilizao futura depois de ter sido modificado para
entend-lo.
s vezes, os desenvolvedores precisam otimizar seu cdigo para torn-lo mais eficiente. Isto pode resultar em
cdigo fonte ofuscado (por exemplo, codificando algumas partes na linguagem de montagem). Alguns ataques
de nvel de aplicativo da web consistem em script injection. Para ter sucesso, os atacantes precisam conhecer
a estrutura do site e das pginas HTML. A mascaramento pode ajudar na proteo de pginas HTML sensveis
e crticas (por exemplo, pginas de conexo e administrao).
Vrias tcnicas de mascaramento podem ser usadas, tais como codificao de base64, XORing, renomeando
aleatoriamente funes, mtodos substituindo, supresso de espao de retorno de tabulao, baralhamento,
etc. A criptografia tambm uma tcnica de mascaramento, mas com problemas porque os dados cifrados
permanecero visveis para aqueles Com chaves vlidas.
Observao: Mascaramento de dados frequentemente usada por atacantes para ocultar seus cdigos
maliciosos e ataques.
5.7.2 Testando a Eficcia dos Mtodos de Mascaramento de Dados

O controle de configurao apertado entre os dados ofuscados e as chaves usadas para a mascaramento
necessrio para garantir que as verses corretas das chaves sejam usadas. Caso contrrio, os dados no podem
ser desmascarados para uso.
Como os dados privados podem estar envolvidos em alguns testes, a mascaramento de dados pode ser usada
para fins de teste para tornar os dados de produo usados em um ambiente de teste do sistema como
annimos. Dados sensveis, como informaes de usurio usadas por um sistema de informaes de sade,
no devem ser divulgados aos testadores. Os testes podem incluir:
Fora bruta ou ataques de dicionrio para tentar obter dados simples de dados ofuscados
Os testes para verificar a obscurecimento do cdigo podem incluir:
Engenharia reversa do cdigo de bytes Java, por exemplo, regenerar o cdigo-fonte Java usando o
Java Decompiler ou programas .Net, por exemplo, recuperar o cdigo fonte .Net com o .NET Reflector.
Ataques de fora bruta, porque alguns mecanismos de mascaramento so vulnerveis, por exemplo,
usando unXOR [Chopitea]).
Em teoria, o cdigo no pode se proteger contra a mascaramento, porque a depurao pode sempre ser
usada. Embora existam ferramentas com a finalidade de proteger o cdigo contra a descompilao, ainda
existem riscos e limitaes na proteo de informaes proprietrias representadas por cdigo.
5.8 Formao
5.8.1 Importncia do treinamento em segurana
Os seres humanos so muitas vezes o elo mais fraco no quadro geral de segurana. Portanto, necessrio
treinamento consistente e contnuo para lembrar as pessoas sobre a importncia de seguir as polticas de
segurana estabelecidas e para enfatizar porque as polticas so necessrias. Esse treinamento deve ocorrer
ao longo do processo do ciclo de vida do software e ser atualizado medida que novas polticas so
adicionadas e novas ameaas surgem. O treinamento deve abranger a identificao de ataques de engenharia
social e ameaas internas.

5.8.2 Como testar a eficcia do treinamento de segurana
Por exemplo, um programa de treinamento de segurana pode abordar a importncia de ter senhas de usurio
fortes que so mantidas confidenciais.
Os testes podem incluir:
Engenharia social para tentar obter um usurio para revelar sua senha durante uma conversa
telefnica com uma pessoa de suporte tcnico falso
Olhando ao redor de mesas para notas (postits) com senhas neles (especialmente sob teclados)
Executar ferramentas de auditoria de senha para identificar senhas fracas. Um risco deste tipo de
ferramenta que as senhas podem ser visualizadas para a pessoa que executa o teste.
Outro exemplo seria que um desenvolvedor no consegue colocar uma edio em nvel de campo para impedir
a entrada de comandos SQL em um campo de entrada de dados. Devido a esse erro, um testador em segurana
capaz de injetar um comando SQL e ver o contedo de um banco de dados de clientes. Isso indicaria que o
desenvolvedor precisa de treinamento adicional em prticas seguras de codificao. Tambm seria bom
examinar as prticas de codificao de outros desenvolvedores para ver se essa prtica generalizada e uma
iniciativa geral de melhoria de processos necessria.
Um terceiro exemplo seria quando um testador tenta obter acesso fsico no autorizado a um escritrio e
visualizar documentos que foram deixados em aberto.

6 Fatores humanos em Teste de Segurana (105 min)
Palavras-chave
Ataque, botnet, computao forense, hacker, reconhecimento, script kiddies
6.1 Compreendendo os Atacantes
AS-6.1.1 (K2): Explicar como o comportamento humano pode levar a riscos de segurana e como ele afeta a
eficcia dos testes de segurana
AS-6.1.2 (K3): Para um determinado cenrio, demonstre a capacidade de identificar formas pelas quais um
invasor pode descobrir informaes-chave sobre um alvo e aplicar medidas para proteger o ambiente
AS-6.1.3 (K2): Explicar as motivaes e origens comuns para a execuo de ataques de sistemas informticos
AS-6.1.4 (K4): Analisar um cenrio de ataque (ataque executado e descoberto) e identificar possveis fontes e
motivao para o ataque
6.2 Engenharia Social
AS-6.2.1 (K2): Explicar como as defesas de segurana podem ser comprometidas pela engenharia social
6.3 Conscincia de Segurana
AS-6.3.1 (K2): Compreender a importncia da sensibilizao para a segurana em toda a organizao
AS-6.3.2 (K3): Tendo em conta determinados resultados de ensaios, aplicar medidas adequadas para aumentar
a sensibilizao para a segurana

6.1 Compreendendo os Atacantes
No contexto da segurana da informao, o ser humano tanto a maior ameaa quanto o ponto mais fraco
da defesa.
Ataques de segurana so realizados por pessoas com uma variedade de habilidades e motivaes. Alm disso,
os seres humanos so os (maiores) ativadores para a maioria dos ataques de segurana. Basta compreender
a tecnologia de segurana e implement-la no suficiente para se defender de contra-ataques. Tambm
importante compreender a mentalidade, motivaes e mtodos dos atacantes maliciosos e estar ciente das
fraquezas humanas na linha de defesa.
6.1.1 O Impacto do Comportamento Humano nos Riscos de Segurana

A fase chave em qualquer ataque a fase de coleta da informao (reconhecimento) onde o atacante tenta
encontrar e recolher informaes sobre o alvo. Toda a informao que publicada, s vezes sem que se saiba,
sobre uma organizao, sistemas em uso, etc., e armazenada no Internet ser encontrada e pode ou ser
usada em um ataque. No uma questo de "se", mas uma questo de "quando". Alm das informaes
publicadas oficialmente pela organizao, os funcionrios tambm esto publicando informaes sobre a
empresa em suas redes sociais. A quantidade e o contedo desta informao estar em constante mudana,
muitas vezes apresentando algumas informaes-chave para os atacantes.
Os atacantes no usam uma poltica de segurana ou procedimentos predefinidos quando atacam um sistema.
Com base nas informaes que eles podem coletar, eles decidem sua estratgia. Eles atualizaro sua base de
conhecimento para cada ataque realizando buscas seletivas e 'visitando' endereos IP j conhecidos.
Quando a poltica de segurana para uma empresa formulada, geralmente baseada na situao e os fatos
que esto disponveis. s vezes, isso no inclui todas as informaes acessveis ao pblico e, mesmo que isso
acontea, essas informaes provavelmente mudaro. Testes de segurana que eram vlidos quando foram
criados podem no fornecer cobertura adequada quando as alteraes de informaes publicadas.
6.1.2 Entendendo a Mentalidade do Atacante

Durante a atividade de reconhecimento ou coleta, o atacante tentar encontrar todos os tipos de informaes
sobre o alvo usando meios passivos e/ou ativos. A maioria dos equipamentos de TI que trafega em redes
pblicas deixa uma pegada nessas redes. Essas pegadas podem e sero encontradas. O Google (incluindo o
Google Earth e Street View) ou outros motores de busca, Shodan [Web-5], Facebook, LinkedIn e outras redes
sociais so as primeiras fontes usadas para encontrar informaes sobre o alvo. Endereos IP, pginas da Web,
nmeros de telefone, nomes e estruturas de endereos de e-mail, SO e aplicativos podem fornecer
informaes teis ao invasor.
Um possvel uso do mecanismo de busca do Google encontrar informaes especficas sobre um destino.
Centenas de consultas podem ser encontradas no Google Hacking Database [Web-4]. Shodan [Web-5] outra
ferramenta que usada para encontrar informaes especficas, por exemplo, quais empresas em uma rea
especfica esto executando um servidor Apache com uma verso vulnervel.
A maioria dessas informaes pode ser encontrada passivamente sem realmente se conectar ao sistema de
destino. Outras ferramentas utilizadas incluem:
Whois [Web-13]
Base de dados Ripe (Redes IP Europeias) [Web-12]
Pesquisas DNS [Web-25]
Com tcnicas de reconhecimento ativas o atacante usa ferramentas para detectar hosts, portas abertas,
sistemas operacionais e aplicativos tocando no sistema. Mtodos e ferramentas usados aqui incluem:

Ping - Fping [Web-15], Hping [Web-19]
Varredura TCP / UDP - Nmap [Web-20], Zenmap [Web-21]
Deteco de SO - Nmap [Web-20], Xprobe2 [Web-22]
Servios de impresso de digitais (o Nmap tem capacidade para determinar tambm o tipo e a verso
do servio em execuo na porta aberta descoberta, comparando a "impresso digital" do servio
descoberto com o prprio banco de dados de impresses digitais do Nmap).
Como hacking em um sistema proibido por lei na maioria, se no todos os pases, o hacker vai tentar destruir
todas as provas de sua invaso depois. Outras razes para destruir evidncias so prolongar a permanncia,
continuar o uso do sistema no futuro e usar o sistema comprometido ou rede de sistemas (botnets) para atacar
outros sistemas. O atacante pode implementar ferramentas como o NetCat [Web-14] para isso ou usar sites
como o IP TRacer [Web-7], bem como tunelar ou alterar arquivos de log.
Outros mtodos e ferramentas utilizados para ocultar evidncias incluem ferramentas de ocultar [Web-16],
rootkits e fluxo de arquivos. Todas, ou a maioria das ferramentas aqui mencionadas so acessveis atravs da
Internet. Baixando a verso mais recente do Kali Linux [Web-17] e uma pesquisa no site OWASP [OWASP1]
dar acesso a muitas dessas ferramentas.
6.1.3 Motivaes comuns e fontes de ataques a sistemas de informao

Muitos ataques e violaes nos sistemas de informao vm de dentro da organizao. Os usurios de
sistemas mal-intencionados (hackers internos ou ameaas internas) tentaro comprometer os sistemas
enquanto forem usurios autorizados da rede. Na maioria das vezes vingana a motivao, mas tendncias
recentes esto mostrando um aumento para espionagem econmica ou roubo.
Os hackers externos so responsveis pela minoria dos ataques. Curiosidade para a informao foi um dos
primeiros motivadores para invadir sistemas de informao, e ainda . Ter alguma informao de grandes
empresas ou organizaes e saber que outros no o fazem outro motivador (prestgio). Outros motivadores
incluem notoriedade ou fama, desafio, tdio e vingana, onde este ltimo considerado a forma mais perigosa
(maior motivao).
Atacantes so frequentemente classificados por sua motivao e habilidades. Na extremidade inferior do
espectro de atacantes esto "script kiddies" que simplesmente executam os ataques que outros criam,
enquanto na extremidade superior do espectro so profissionais (governo, hacktivismo) organizaes e
indivduos. Hacktivismo o ataque de sistemas baseados em motivos principalmente polticos, mas tambm
econmicos ou demogrficos.
Motivao pode escalar para diverso em derrubar um sistema ou organizao completamente por qualquer
motivo (por exemplo, poltico, ideologicamente, econmico, guerra, comercial, terrorismo).
As habilidades de hacking variam de indivduos com algum conhecimento de rede e sistema trabalhando com
um computador domstico simples, para profissionais altamente treinados e educados com acesso a
laboratrios, redes de proxy e todos os outros equipamentos tcnicos necessrios. Ter uma imagem sobre os
atacantes em potencial ajudar uma organizao a implementar a proteo necessria e fornece uma diretriz
para a estratgia de teste de segurana.
6.1.4 Compreendendo cenrios de ataque e motivaes

Um incidente de segurana definido como um evento relevante segurana de um sistema em que sua a
poltica de segurana desobedecida ou violada. [RFC2828]
Descobrir o que aconteceu e quem foi responsvel pelo incidente relacionado segurana um alvo para a
disciplina de computao forense [Web-8], onde se concentra em encontrar provas digitais do ataque.

O processo de recuperao de evidncias baseia-se em trs fases:
1. Adquirir e autenticar
2. Analisar
3. Relatrio
6.1.4.1 Adquirir e autenticar
O processo de gerenciamento de incidentes da organizao deve restaurar o sistema para seu estado original
(pr-ataque) aps a evidncia ser coletada e armazenada. Ele inicia quando o administrador do sistema
alertado pelo IDS ou por outros meios de monitoramento. Outros sintomas tpicos de incidentes de segurana
so:
Entradas de registro suspeitas
Contas de usurio inexplicveis
Arquivos ou pastas modificadas
Servios incomuns em execuo
Comportamento incomum do sistema
Tentativas de login malsucedidas
Aps ser alertado, o processo a ser executado o seguinte:
4. Faa um instantneo ou cpia do sistema em investigao para recolher todas as provas necessrias.
5. Depois de autenticar a evidncia ( uma cpia genuna e completa), criar uma cpia e armazen-lo em
um local seguro.
6. Analise as evidncias.
7. Depois que o processo forense estiver concludo, remova a causa do incidente (erradicao).
8. O sistema volta ao seu estado normal (recuperao).
Durante essas etapas, todas as vulnerabilidades so removidas com patches ou instalando novos softwares.
Ao relatar os resultados, o processo seguido deve ser descrito juntamente com as ferramentas usadas durante
este processo.
6.1.4.2 Analisar
Aps tentativas de hacking, pode ser possvel encontrar a origem dos ataques examinando os arquivos de log
do sistema e as conexes de rede ativas. importante fazer cpias de todos os arquivos de log e capturar as
informaes de status do processo. Durante um ataque ativo, pode fazer sentido reunir informaes do
sistema relacionadas ao atacante antes de bloque-las.
Qualquer ataque via Internet pode ser rastreado para o endereo IP de sua origem, se ele usou e-mail ou
conexes de Internet. apenas uma questo de tempo, dinheiro e esforo, e uma avaliao dos custos
envolvidos. A maioria dos atacantes usa proxies ou cadeias de proxies, rede Tor [Web-9] ou outras opes
annimas gratuitas para cobrir seu endereo IP real. Quanto mais proxies os atacantes usam, mais tempo
necessrio para rastrear o endereo de origem. As leis locais baseadas nas localizaes fsicas dos proxies
tambm podem obstruir esta investigao.
Descobrir intrusos e traar um endereo IP de volta sua origem pode ser feito com ferramentas como Netstat
(Windows) [Web-10], Tracert [Web-11] e o site Web Tracer IP [Web-7]. Netstat mostra as conexes para uma
mquina, portas e servios em execuo. Esta ferramenta pode ser usada para procurar qualquer endereo IP
estranho ou desconhecido ou nmero de porta. Nota: H tambm um utilitrio tracert no Microsoft Windows
(no Linux e OS/X, "traceroute"), mas os servios baseados na web mencionados acima so independentes
desses utilitrios.

No cabealho de um e-mail contendo vrus, o endereo IP do ISP que enviou o e-mail pode ser mostrado. No
entanto, para a maioria dos e-mails baseados na web (Gmail, Yahoo mail, Outlook.com), este o endereo IP
do provedor. Para encontrar o endereo IP real, preciso procurar o valor X-Originating-IP. Usando os bancos
de dados Whois [Web-13] levar aos detalhes que podem ser usados para entrar em contato com a
organizao ISP para continuar a investigao. Deve-se notar que o e-mail pode ser originado de servidores
privados e servidores de e-mail de retransmisso abertos. Nesse caso, pode ser muito difcil identificar a fonte
real de uma mensagem de e-mail.
Investigar ataques que usaram uma botnet difcil. No h necessidade de o atacante ter uma conexo on-
line com o botserver ou os botclients, muito difcil ou quase impossvel o rastreamento. Neste caso, investigar
os clientes pode levar ao servidor, mas um deve ter acesso ao servidor, a fim de investigar a verdadeira fonte
do ataque. Os proprietrios desses servidores podem no estar cientes de que suas mquinas fazem parte de
uma botnet.
6.1.4.3 Relatrio
O relatrio de vulnerabilidades de segurana descrito no Captulo 7.
6.2 Engenharia Social

Podemos implementar todas as defesas tcnicas que podemos imaginar para proteger os ativos digitais do
mundo exterior, mas no final tudo se resume ao fato de que os funcionrios (usurios e administradores)
precisam ter acesso a esses ativos para fazer seu trabalho. Eles podem precisar usar autenticao para obter
acesso de seus desktops, notebooks, telefones inteligentes, tablets ou outros meios. Qualquer defesa de
segurana fsica para proteger o acesso ao escritrio e equipamento de escritrio no tem sentido se a
segurana para a rea de trabalho do gerente de TI em sua casa pode ser facilmente comprometida.
o ser humano e o seu comportamento que a maior ameaa segurana. Se as pessoas so desleixadas
com informaes sensveis, isso deixa muitas pegadas para proteger lugares e transmite essas informaes
em voz alta (oralmente e eletronicamente) em locais pblicos.
A engenharia social a arte de explorar o ser humano usando seu comportamento geral como vetor de ataque.
Como seres sociais, as pessoas esto dispostas a confiar e ajudar estranhos. Isso cria uma vulnerabilidade ao
ataque. Ao manipular, influenciar e persuadir pessoas teis, um invasor tentar obter acesso, detalhes de
autorizao ou outros tipos de informaes confidenciais.
Os exploits podem ser realizados por meio de interao humana direta ou usando equipamentos de
computador / rede.
A interao humana direta pode ser feita em pessoa, incluindo:
Tailgating ou piggybacking (algum que no tem a autenticao adequada aps um funcionrio em
uma rea restrita)
Escutar (ouvir as conversas privadas de outra pessoa sem o seu conhecimento)
Surfar no ombro (olhar por cima do ombro de algum sem o seu conhecimento enquanto executam
tarefas no computador ou por escrito)
Usar o telefone (como obter uma senha de um usurio desavisado, agindo como outra pessoa, como
um gerente ou pessoa de suporte tcnico)
A engenharia social baseada em computador pode ser feita por:
Enviar e-mails infectados com malware.
Usando bate-papo ou aplicaes de mensagens instantneas. Usando o bate-papo e as aplicaes
mensagens instantneas, toda a pessoa annima pode ter um bate-papo com o outro em qualquer

lugar no mundo, sem saber a identidade verdadeira da outra pessoa. Alm disso, os dados atravs de
mensageiros instantneos podem ser facilmente rastreados.
Utilizar telas pop-up. Por exemplo, uma janela pode aparecer na tela do computador do usurio com
uma mensagem para o usurio que a conexo de rede foi perdida. Nesse ponto, o usurio solicitado
a digitar novamente seu nome de usurio e senha. Um programa previamente instalado pelo intruso
pode ento transmitir as informaes para um site remoto.
Enviando e-mails de spam. Os e-mails de spam esto repletos de ofertas e links fraudulentos. Clicar
nesses links pode instalar malware que pode expor uma rede inteira.
Persuadir as pessoas a visitar sites infectados (manipulados). Essas tentativas de phishing podem ser
amplamente enviadas, ou podem ser altamente especficas.
No existe uma nica defesa contra a engenharia social. As defesas podem ser implementadas para controlar
os danos (por exemplo, fornecer o menor nvel de privilgio que ainda permite que algum execute seu
trabalho, separao de deveres, rotao de deveres), mas a principal defesa a educao e a conscientizao
em todos os nveis da organizao.
6.3 Conscincia de Segurana

6.3.1 A Importncia da Conscincia de Segurana
O modelo de ameaa est em constante mudana, como mencionado em outros captulos neste programa.
As redes esto evoluindo, novas aplicaes so introduzidas, novas interfaces so tornadas operacionais e
novas vulnerabilidades so introduzidas e descobertas.
Alm desses aspectos tcnicos, h o fator humano. Riscos que foram identificados, mas no se tornaram
problemas so facilmente esquecidos e as salvaguardas so retiradas. Isso oferece maiores oportunidades
para ataques de hackers e engenharia social. O treinamento regular de conscientizao de segurana
necessrio para manter os administradores de segurana e todos os funcionrios alertas e informados sobre
as mudanas no modelo de ameaa. O treinamento de conscientizao de segurana pode se concentrar em
diferentes grupos de usurios: desenvolvedores, operaes, gerenciamento e equipe geral de usurios.
6.3.2 Aumentar a sensibilizao para a segurana

importante manter uma mentalidade de "conscincia de segurana". Alm de informaes gerais sobre
defesas de segurana na empresa, o treinamento deve conter estudos de caso reais descobertos durante os
testes de segurana ou em incidentes reais. Com base nesses casos, deve ser mais fcil discutir quaisquer
defesas ou mudanas a serem implementadas na organizao.
Um esboo para esta seo no treinamento de conscientizao deve incluir respostas para as seguintes
perguntas:
Como eles (ns) fizeram isso?
Quais foram as consequncias do negcio?
Quais foram os custos para investigar e processar o incidente?
Quais foram os custos para reparar o problema?
Como o incidente pode ter sido evitado?
Que mudanas sero implementadas?

7 Avaliao e relatrios de testes de segurana (70 min)
Palavras-chave
Critrio de aceite, vetor de ataque, dashboard, critrio de sada.
AS-7.1.1 (K2): Compreender a necessidade de rever as expectativas de segurana e os critrios de aceitao
medida que o escopo e as metas de um projeto evoluem
7.2 Relatrios de teste de segurana
AS-7.2.1 (K2): Compreender a importncia de manter os resultados dos testes de segurana confidenciais e
seguros
AS-7.2.2 (K2): Entenda a necessidade de criar controles adequados e mecanismos de coleta de dados para
fornecer os dados de origem dos relatrios de status do teste de segurana de forma oportuna, precisa e
precisa (por exemplo, um painel de teste de segurana)
AS-7.2.3 (K4): Analisar um determinado relatrio de status de teste de segurana provisrio para determinar
o nvel de exatido, compreenso e apropriao de partes interessadas

A mensurao dos resultados dos testes de segurana e o estado de avaliao com relao s expectativas de
segurana, critrios de sada e/ou critrios de aceitao so necessrios para determinar a concluso do teste.
difcil conhecer todos os riscos de segurana no incio de um projeto. Alm disso, as expectativas das partes
interessadas e dos usurios s vezes mudam em relao ao nvel de segurana necessrio. Por exemplo, a
conscientizao de uma nova ameaa pode levar as partes interessadas a exigirem nveis mais elevados de
segurana do que se pensava inicialmente. Esta uma razo pela qual as avaliaes de risco de segurana
precisam ser revisadas ao longo de um projeto e os resultados incorporados no planejamento e execuo de
testes de segurana.
7.2 Relatrios de teste de segurana

7.2.1 Confidencialidade dos Resultados dos Testes de Segurana
verdade que o testador mdio sabe mais sobre o objeto de teste aps o teste concludo em comparao
com a maioria dos desenvolvedores ou modeladores. Ao testar completamente um pode encontrar as
fraquezas mais importantes e pontos fortes do sistema. O mesmo se aplica aos testes de segurana.
Testando a implementao de segurana, possvel encontrar buracos ocultos e vulnerabilidades de
segurana. A diferena reside no possvel impacto negativo na comunicao destas vulnerabilidades para
outras pessoas que no as partes interessadas diretas. Uma boa prtica geralmente que as informaes
devem ser disponibilizadas apenas para aqueles que precisam saber. Isso se aplica especificamente aos
resultados dos testes de segurana, para ser conservador com a partilha deste tipo de informao
considerada uma boa prtica.
7.2.2 Criando Controles Adequados e Mecanismos de Coleta de Dados para

Relatrio de Status de Teste de Segurana
O impacto e o efeito de uma vulnerabilidade de segurana so normalmente considerados como tendo uma
sensibilidade mais elevada em comparao com defeitos "normais". Isto leva necessidade de ser mais preciso
e acurado sobre o relato da natureza do defeito e dos riscos implcitos. Na maioria dos projetos, os defeitos
de segurana so categorizados com uma gravidade maior do que defeitos funcionais comparveis.
Esta ltima implica que a administrao tem maior foco nos defeitos de segurana, seus riscos e possveis
resolues. O relatrio de defeitos de segurana deve avaliar cuidadosamente o impacto de um problema
descoberto, a preciso dos resultados dos testes e deve estar disponvel de forma bem definida e oportuna.
uma boa prtica discutir com a gerncia como e quando eles gostariam de ter acesso aos relatrios de defeitos
de segurana.
7.2.3 Analisando relatrios de status de teste de segurana provisrios

Os relatrios de testes de segurana podem ser produzidos durante todo o processo de teste de segurana ou
somente no final dos testes de segurana (como no final dos testes de segurana do sistema ou no final dos
testes de segurana realizados como parte dos testes de aceitao). Os primeiros relatrios de teste de
segurana so incentivados porque permitem mais tempo para remediar vulnerabilidades de segurana. Se o
processo de teste de segurana estiver seguindo o descrito neste programa, a equipe de teste poder
descobrir vulnerabilidades e observaes de documentos durante todas as atividades de teste.

A estrutura de um relatrio de teste de segurana deve conter as seguintes sees:
1. Identificador do relatrio
2. Resumo
a. Sumrio executivo
b. Principais concluses
3. Desvios
a. Processo de teste seguido
b. Qualquer desvio do processo de teste planejado
c. Mtodos e ferramentas (configuraes, polticas) utilizados
4. Avaliao abrangente
a. Avaliao da cobertura do teste com base nos critrios indicados no plano de teste
b. Explicao de quaisquer itens ou recursos que no foram testados
5. Resumo dos resultados
a. Resumindo os resultados dos testes de segurana
b. Lista de todas as vulnerabilidades de segurana resolvidas e suas resolues
c. Lista de todas as vulnerabilidades no resolvidas
6. Avaliao
a. Avaliao dos resultados dos testes observados e seu status com base em critrios de sada
b. Riscos identificados (classificaes) e impacto de vulnerabilidades de segurana no resolvidas
7. Resumo das atividades
8. Aprovaes
A eficcia dos relatrios de testes de segurana depende do seguinte:
O momento do relatrio
O contedo do relatrio
Os destinatrios do relatrio
A afinao do contedo para corresponder necessidade dos destinatrios de mltiplos relatrios
pode ser importante para atender s necessidades de vrias partes interessadas. Por exemplo, o
contedo de um relatrio para gerenciamento executivo no ser o mesmo que o contedo para um
arquiteto de sistema.

8 Ferramentas de Teste de Segurana (55 min)
Palavras-chave
Nenhum
8.1 Tipos e objetivos das ferramentas de teste de segurana
AS-8.1.1 (K2): Explicar o papel das ferramentas de anlise esttica e dinmica nos testes de segurana
8.2 Seleo da Ferramenta
AS-8.2.1 (K4): Analisar e documentar os testes de segurana devem ser abordados por uma ou mais
ferramentas
AS-8.2.2 (K2): Compreender os problemas com as ferramentas de cdigo aberto
AS-8.2.3 (K2): Compreender a necessidade de avaliar os recursos do fornecedor para atualizar ferramentas em
uma base frequente para se manter atualizado com ameaas de segurana

8.1 Tipos e Objetivos das Ferramentas de Teste de Segurana
As faanhas desenvolvidas pela comunidade de hackers impulsionaram o desenvolvimento de ferramentas de
teste de segurana para se defenderem contra essas ameaas. Mesmo a partir das primeiras atividades de
hacking (como cracking de senhas) ferramentas simples foram inventadas, criadas e melhoradas por aqueles
que as usam. Ferramentas que provaram ser eficazes foram compartilhadas na comunidade de hackers e
melhoradas e aprimoradas. Inicialmente, essas ferramentas foram desenvolvidas para tarefas e ambientes
dedicados. A Usabilidade no foi um problema, pois quase todos os usurios tinham um fundo tcnico.
Eventualmente, algumas das ferramentas de hackers se tornaram a base para ferramentas de teste de
segurana legtimas usadas por administradores de segurana de informaes e testadores.
Como exemplo, "John the Ripper" era uma ferramenta de cracking de senhas de cdigo aberto, usada
originalmente por hackers para adivinhar senhas e acesso a redes ou aplicativos Unix. Hoje, esta ferramenta
foi refinada e usada para fins legtimos para detectar senhas fracas Unix. [Web-26]
Como principais fornecedores de ferramentas de teste e desenvolvimento de software e fornecedores de
ferramentas especializadas comearam a desenvolver ferramentas de teste de segurana, muitas dessas
ferramentas alcanaram capacidades funcionais mais amplas e usabilidade aprimorada. No entanto, essa
ampla funcionalidade levou a configuraes de ferramentas mais complexas e preocupaes de
implementao.
Ao mesmo tempo em que as primeiras ferramentas de segurana estavam surgindo, as primeiras verses de
frameworks como Nessus, Metasploit e outros foram desenvolvidas como ferramentas de cdigo aberto que
oferecem funcionalidade melhorada e expandida e, em alguns casos, tambm uma GUI fcil de aprender.
Hoje, o nmero de ferramentas de teste de segurana disponveis enorme. Para quase qualquer ambiente
ou tarefa, possvel encontrar uma ferramenta de teste dedicada, seja como cdigo aberto ou licenciado. O
desafio com todas essas ferramentas que a maioria delas so sistemas inteligentes que implementam testes
no padronizados. Todos os desenvolvedores desses sistemas concordam mais ou menos sobre como testar
defesas de segurana ou testar vulnerabilidades. No entanto, essas ferramentas podem usar diferentes dados
de teste, diferentes implementaes de teste e diferentes interpretaes dos resultados.
Ferramentas de teste de segurana podem ser usadas para automatizar a avaliao de defesas de segurana.
As ferramentas de teste de segurana tambm podem ser usadas para detectar tipos conhecidos de
vulnerabilidades. Com a compreenso de que o mesmo tipo de defesa ou vulnerabilidade de segurana pode
ser implementado de diferentes maneiras, a seleo e o uso de ferramentas de teste de segurana um
desafio para o testador em segurana porque as ferramentas diferem em como encontrar vulnerabilidades e
validar defesas.
Os Web sites do Web Application Security Consortium [Web-18] e OWASP [OWASP1] oferecem listas de
ferramentas categorizadas. A estrutura de teste de penetrao Backtrack [Web-23] (ou Kali Linux [Web-17])
apresenta outras formas de classificar as ferramentas de teste de segurana.
O nmero de ferramentas de segurana comercial bastante limitado em comparao com o nmero de
ferramentas de cdigo aberto. No momento em que este programa foi desenvolvido (2016), conseguimos
encontrar apenas um nmero limitado de recursos apresentando uma viso geral mais ou menos completa
de ferramentas de segurana de fonte aberta confiveis e confiveis. Uma lista de ferramentas de segurana
pode ser encontrada em https://sectools.org [Web-24]. Espera-se que o testador em segurana avanado
mantenha sua prpria lista de ferramentas disponveis e mantm essa lista atualizada medida que o mercado
de ferramentas muda.
As ferramentas de anlise esttica e dinmica so teis em testes de segurana. A vantagem do teste esttico
que ele pode ser realizado muito cedo no ciclo de vida do desenvolvimento. As ferramentas estticas da

anlise esto disponveis para a maioria de lnguas do software e tm geralmente uma habilidade de relatar
em aspectos da segurana.
A diferena entre as ferramentas de teste dinmico e esttico no contexto de teste de segurana s vezes
um pouco confusa em comparao com outros tipos de teste. A definio de teste esttico est relacionada
com a realizao de atividades de teste enquanto o sistema ou objeto sob teste no est no modo operacional.
No incomum para as ferramentas de teste dinmico de segurana para sondar o sistema em vez do
aplicativo em teste. Nesta perspectiva, essas ferramentas de teste dinmicas so usadas como um tipo de
ferramentas de teste esttico. Por exemplo, uma ferramenta de teste de segurana dinmica pode executar
uma varredura esttica de um banco de dados. Claro, se todo o sistema considerado como o objeto de teste,
ento as ferramentas verdadeiramente so ferramentas de teste dinmico.
8.2 Seleo da Ferramenta

8.2.1 Analisando e Documentando as Necessidades de Testes de Segurana
Entre outros, os seguintes documentos podem formar uma base de teste para testes de segurana:
Poltica de segurana da organizao
Poltica de teste da organizao
Resultados da anlise de ameaas e riscos para o sistema / projeto atual
Requisitos e outras especificaes do sistema
Arquitetura do sistema e modelagem
Estratgia de segurana (teste)
O sistema ou aplicativo em teste
Alertas, vulnerabilidades e vulnerabilidades de segurana conhecidas
Perfis de usurio
Todos estes e mais podem fornecer informaes sobre ameaas e sobre vulnerabilidades que
poderiam ser exploradas. Os requisitos e documentos de projeto devem indicar como os dados ou
informaes esto protegidos. Isto levar a uma viso geral de:
Interfaces a serem testadas (incluindo a GUI)
Protocolos e padres a serem verificados
Diretrizes de codificao da Web que promovem prticas seguras de codificao a serem utilizadas
Configuraes dos componentes do sistema a serem verificados (endurecidos)
preciso determinar se o teste de segurana ser uma atividade de desenvolvimento ou uma atividade de
operacional. Todas essas informaes levaro aos requisitos para o conjunto de ferramentas de teste de
segurana.
8.2.2 Problemas com Ferramentas de Cdigo Aberto

Consulte [BSTQB_ATM_SYL] para obter uma discusso completa dos problemas que podem ser encontrados
com as ferramentas de cdigo aberto.
Como mencionado anteriormente, muitas ferramentas de teste de segurana so encontradas no domnio de
cdigo aberto. Essas ferramentas so distribudas e podem ser usadas sob uma ampla variedade de licenas
que permitem o uso livre e a modificao do cdigo-fonte. Nem todas as empresas ou projetos podem
considerar o uso de ferramentas de cdigo aberto em seus processos de desenvolvimento. Com base em
questes de conformidade regulamentar, as organizaes podem ser foradas a usar apenas ferramentas
comerciais ou certificadas.

Existem muitas vantagens e desvantagens relacionadas a ferramentas sob essas licenas. Em muitos casos, as
ferramentas de cdigo aberto podem ser obtidas gratuitamente, mas a organizao pode precisar ter
capacidade tcnica disponvel para suporte e configurao especfica. Se esta capacidade estiver faltando,
ento um custo pode ser incorrido para obt-lo a partir do desenvolvedor do software. Os manuais de
administrao e de usurio, se houver, so, em sua maioria, escritos com um pblico especfico (tcnico) em
mente e, na maioria das vezes, no descrevem nem cobrem toda a funcionalidade da ferramenta. Os canais
de mdia como o YouTube so recentemente uma fonte adicional de informaes sobre o uso dessas
ferramentas.
Aspectos a considerar ao configurar o clculo ROI para qualquer ferramenta opensource incluem:
O escopo limitado da ferramenta (na maioria dos casos, nenhuma funcionalidade adicional ou outra
oferecida)
O tempo para aprender a administrar, configurar e usar a ferramenta
O tempo para investir nos fruns e grupos de usurios durante o ciclo de vida
O tempo necessrio para atualizar e atualizar (e a poltica interna sobre atualizaes)
A direo futura da ferramenta (algumas ferramentas podem desaparecer ou ir comerciais)
O nvel de resposta na comunidade de suporte para a ferramenta
Para a maioria das empresas ou projetos, o nmero de licenas necessrias para as ferramentas de teste de
segurana limitado a um ou a alguns. Apenas as grandes empresas consideraro mais licenas. O nmero de
licenas basear-se- principalmente na soma total das reas de funcionalidade fornecidas pela ferramenta
(por exemplo, aplicao web, servios web, anlise de cdigo, outros) e a frequncia assumida, o tempo de
utilizao destes servios e o nmero de testadores em segurana utilizando a ferramenta.
8.2.3 Avaliando as Capacidades do Vendedor de uma Ferramenta

Se uma ferramenta comprada de um fornecedor, esse fornecedor deve oferecer uma srie de servios para
permitir que o servio de teste de segurana para iniciar e crescer para o nvel necessrio de suporte interno.
Os seguintes atributos podem ser usados para avaliar os recursos do fornecedor:
Tipos de licenas oferecidas (fixo / desk / floating / token)
Opes de escalabilidade de licenas (por rea funcional, nmero de licenas)
Helpdesk e instalaes de apoio (horas de apoio)
Fruns e comunidades de usurios
Frequncia de atualizao
Manuais de administrao e de usurio
Contratos de suporte e manuteno

9 Padres e tendncias da indstria (40 min)
Palavras-chave
consensus-based standard
9.1 Compreendendo os Padres de Testes de Segurana
9.1.1 (K2): Compreender os benefcios do uso de padres de testes de segurana e onde encontr-los
9.1.2 (K2): Compreender a diferena na aplicabilidade das normas em situaes regulatrias versus contratuais
9.2 Aplicao de padres de segurana
9.2.1 (K2): Compreender a diferena entre as clusulas obrigatria (normativa) e opcional (informativa) dentro
de qualquer norma
9.3 Tendncias da indstria
9.3.1 (K2): Entender onde aprender das tendncias da indstria em matria de segurana da informao

9.1 Compreendendo os Padres de Testes de Segurana
Padres de vrios tipos fornecem visibilidade sobre o consenso profissional ou obrigaes regulatrias. Um
padro consensual representa o parecer de um grupo de peritos bem informado e disponibilizado para uso
voluntrio (total ou parcial) em acordos contratuais entre fornecedores e clientes. Existem tipos menores de
padres que surgem de grupos mais informais ou auto-identificados e podem ser especficos a alguns
fornecedores.
Nas indstrias regulamentadas (incluindo os setores mdico, financeiro, de transporte e de energia), as
agncias governamentais podem exigir o cumprimento de seus prprios regulamentos ou suas interpretaes
de padres voluntrios.
9.1.1 Os Benefcios do Uso de Padres de Testes de Segurana

Padres, em geral, fornecem orientao e consistncia na execuo de uma tarefa. Normalmente, os padres
so desenvolvidos por especialistas em matria de assunto com base no consenso de prticas eficazes. Os
seguintes so benefcios de usar padres de teste de segurana:
Eles definem uma estrutura para testes de segurana eliminando a necessidade de iniciar a partir de
uma pgina em branco.
Eles descrevem defesas eficazes e como testar os ataques de segurana mais comuns.
Os padres podem ser adaptados para atender s necessidades do projeto ou da organizao.
A devida diligncia nos testes de segurana pode ser demonstrada seguindo padres de teste de
segurana reconhecidos.
9.1.2 Aplicabilidade de Normas em Situaes Regulamentares versus Contratuais

Em atividades regulamentadas, todas as partes precisam estar cientes de suas obrigaes de cumprir as
normas impostas, pois o no cumprimento dessa medida pode retardar ou impedir a aprovao do produto
em desenvolvimento e, em casos extremos, resultar em sanes financeiras ou criminais.
Em situaes contratuais, as normas fornecem uma base razovel e conveniente para negociar o acordo sobre
os requisitos do projeto e do produto. Eles fornecem um ponto de partida em vez das partes que comeam
com nada. As normas baseadas no consenso permitem que as melhores prticas sejam comunicadas e
adoptadas ou adaptadas situao especfica.
A menos que seja imposta unilateralmente por um regulador ou em um contrato no negocivel, as normas
podem ser usadas como o quadro bsico para um acordo negociado ou auto-imposto sobre a conduta do
prprio trabalho. Se um contrato adjudicado com base em uma reivindicao ou acordo para cumprir com
normas especficas, ento a entidade tem a obrigao de seguir essas normas estritamente e documentar
quaisquer desvios.
9.1.3 Seleo de Padres de Segurana

Certamente, nem todos os padres de segurana se aplicam a todas as situaes. da responsabilidade de
uma organizao pesquisar os padres mais apropriados para seus sistemas, aplicaes, ativos digitais
sensveis, nvel de risco e requisitos de conformidade. Tambm importante entender que muitos padres
podem ser adaptados para atender s necessidades especficas de uma organizao.
Uma lista de normas de segurana comuns pode ser encontrada no Captulo 10.

9.2 Aplicao de padres de segurana
Observe o uso preciso da linguagem dentro de qualquer padro: a palavra deve identificar os requisitos
obrigatrios a serem seguidos de acordo com a norma, enquanto as palavras devem e podem indicar tarefas
opcionais que no so obrigados a reivindicar a conformidade com a norma. Um mau uso tpico confundir
esta distino quer exigindo um item opcional ou tratando um item obrigatrio como opcional.
Situaes especficas da organizao ou do projeto podem ditar o desvio do senso estrito de um padro em
uso. Justificao para omisses, modificaes ou adies ao contedo da norma precisam ser documentadas
e acordadas por todas as partes.
9.3 Tendncias da indstria

9.2.1 Onde aprender das tendncias da indstria na segurana da informao
Tanto os servios de notcias de uso geral e especficos da indstria (publicaes, websites, distribuies de e-
mail) e eventos (conferncias, feiras comerciais, reunies da sociedade profissional) apresentam informaes
e discusso de novas ou crescentes preocupaes. Pertencer a uma sociedade ou comunidade profissional
focada provavelmente fornecer atualizaes oportunas e direcionadas. Com a velocidade com que novas
faanhas se desenvolvem, os alertas eletrnicos podem oferecer as respostas mais imediatas acionveis.
A divulgao peridica das exploraes mais frequentes ou prejudiciais pode identificar tendncias
generalizadas, mas deve-se prestar especial ateno a questes mais especficas para a indstria, rea de
aplicao ou produtos com os quais se est trabalhando. Estas questes so mais susceptveis de serem
comunicadas em publicaes especializadas e servios de notcias ou em conferncias tcnicas e eventos
profissionais.
9.2.2 Avaliando Prticas de Testes de Segurana para Melhorias.

medida que novas tecnologias ou novos usos da tecnologia existente so introduzidos, muitas vezes h uma
janela de oportunidade para uso indevido ou explorao da tecnologia at que seus riscos e limitaes sejam
mais bem compreendidos.
Por exemplo, considere dispositivos mveis com servios de reconhecimento de local. Em troca de
convenincia ou outros incitamentos, os indivduos parecem dispostos a permitir o rastreamento minuto a
minuto de seus movimentos e atividades.
Uma gama maior de motivaes e maiores recursos esto emergindo de agentes criminais, hacktivistas,
econmicos e polticos. Os esquemas de extorso e proteo passaram de ameaas fsicas para domnios
digitais.
Grandes redes ad hoc de indivduos ideologicamente orientados podem ser direcionadas em muito curto prazo
contra alvos de sua ira. Espionagem corporativa muitas vezes bem financiado e motivado. As Naes-Estado
que buscam vantagens econmicas e militares so particularmente bem-dotadas de recursos e podem
acreditar que esto imunes a sanes ou retaliaes.
Como as ameaas esto constantemente mudando e evoluindo, os testadores em segurana devem estar
sempre prontos para enfrentar a prxima ameaa. A conscientizao da indstria, o acompanhamento
rigoroso das tendncias de segurana e a aquisio das ferramentas mais adequadas proporcionam a melhor
defesa para uma organizao.

10 Referencias
10.1 Documentos BSTQB
[BSTQB_FL_SYL] BSTQB Foundation Syllabus, 2011
[BSTQB_ATM_SYL] BSTQB Advanced Test Manager Syllabus, 2012
[BSTQB_ATTA_SYL] BSTQB Advanced Technical Test Analyst Syllabus, 2012
10.2 Normas e Padres

[ISO/IEC/IEEE 29119-3] Software and Systems Engineering, Software testing, Part 3: Test documentation
[IEEE 12207] Standard for Systems and Software Engineering, Software Life Cycle Processes
[COBIT] www.isaca.org
[ISO27001] Information Security Management,
www.iso.org/iso/home/standards/managementstandards/iso27001.htm
[PCI] Payment Card Industry Standard, www.pcisecuritystandards.org/
10.3 Literatura
[Chapman, 2000] Chapman, Cooper, Zwicky, Building Internet Firewalls, OReilly & Associates, 2000.
[Jackson, 2010] Jackson, Christopher; Network Security Auditing, 2010.
10.4 Artigos
[ComputerWeekly] www.computerweekly.com/news/2240113549/Cattles-lost-backup-tapeshighlight-
risk-of-unencrypted-data-storage
[Northcutt, 2014] Northcutt, Stephen; Security Controls, SANS Institute.
[Washington Post, 2007],
www.washingtonpost.com/wpdyn/content/article/2007/05/04/AR2007050402152.html
10.5 Guias
[Bittau] Cryptographic Protection of TCP Streams, tools.ietf.org/html/draft-bittau-tcp-crypt-04
[CERT1] Top 10 Secure Coding Practices,
www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices
[CERT2] www.cert.org/secure-coding/publications/index.cfm
[CERT3] www.cert.org/secure-coding/tools/index.cfm
[IEEE1] Avoiding the Top 10 Security Flaws, cybersecurity.ieee.org/center-for-secure-
modelagem/avoiding-the-top-10-security-flaws.html
[MDA1] MDA Glossary, DoD Missile Defense Agency, www.mda.mil
[NIST 800-30] NIST Special Publication 800-30, Rev 1, Guide for Conducting Risk Assessments (2012)
[NISTIR 7298] Glossary of Key Information - Security Terms, Revision 2 (2013)
[OWASP1] OWASP Secure Coding Practices Quick Reference Guide,
www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide
[OWASP2] OWASP Risk Rating Methodology,
www.owasp.org/index.php/OWASP_Risk_Rating_Methodology

[OWASP3] OWASP Sample Authorization Form, www.owasp.org/index.php?title=Authorization_form
[PP-IDS] US Government Protection Profile Intrustion Detection System for basic robustness
environments, version 1.7, 25 July 2007.
[SANS1] 25 Most Dangerous Software Errors, www.sans.org
[SANS2] Password Construction Guidelines,
www.sans.org/securityresources/policies/general/pdf/password-construction-guidelines
[WAFEC] Web Application Firewall Evaluation Criteria, wasc-wafec-v1.0.pdf, 2006.
10.6 Relatrios
[WhiteHat Security, 2014], www.whitehatsec.com
10.7 Web
[CERT4] Vulnerability Notes Database, www.kb.cert.org/vuls/
[Chopitea] tomchop.me/2012/12/yo-dawg-i-heard-you-like-xoring/
[EICAR] www.eicar.org
[RFC2828] Internet Security Glossary, www.rfc-archive.org/getrfc.php?rfc=2828
[Web-1] Top 20 Critical Security Controls, sans.org
[Web-2] National Vulnerability Database, web.nvd.nist.gov/view/ncp/repository
[Web-3] Website Security Statistics Report, www.whitehatsec.com/resource/stats.html
[Web-4] The Google Hacking Database, hackersforcharity.org/ghdb
[Web-5] Shodan, shodanhq.com
[Web-6] NetCat, sectools.org/tool/netcat/
[Web-7] IP Tracer, www.ip-adress.com/ip_tracer
[Web-8] Computer Forensics, Cybercrime and Steganography Resources, www.forensics.nl
[Web-9] Tor Project, www.torproject.org/
[Web-10] Netstat, technet.microsoft.com/en-us/library/Bb490947.aspx
[Web-11] Tracert, www.tracert.com
[Web-12] RIPE Scan, www.ripe.net
[Web-13] Whois, www.whois.net/
[Web-14] NetCat, netcat.sourceforge.net/
[Web-15] Fping, fping.org
[Web-16] Hidetools, hidetools.com/
[Web-17] Kali Linux, www.kali.org/
[Web-18] Web Application Security Consortium, www.webappsec.org/
[Web-19] Hping, www.hping.org/
[Web-20] Nmap, nmap.org/
[Web-21] Zenmap, nmap.org/zenmap/
[Web-22] Xprobe2, null-byte.wonderhowto.com/how-to/hack-like-pro-conduct-os-fingerprintingwith-
xprobe2-0148439/
[Web-23] BackTrack, www.backtrack-linux.org/
[Web-24] Top 125 Network Security Tools, sectools.org
[Web-25] DNS Lookup, who.is/dns/
[Web-26] John the Ripper, www.openwall.com/john/

Syllabus Ctal ST 2016br

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Syllabus Ctal ST 2016br

Caricato da

Copyright:

Formati disponibili

International Software Testing Qualifications Board

ISTQB Advanced Level

Comisso Internacional para Qualificao de Teste de Software

Traduo realizada pela WG Tradues do BSTQB baseada na verso

Brazilian Software Testing Qualifications Board

Verso Data Descrio

1.0 - Beta 20/09/2015 Beta release alpha release comments incorporated

2016br 15/03/2017 Traduo para a Lngua Portuguesa

Verso 2016br Pgina 2 de 88

Verso 2016br Pgina 3 de 88

Verso 2016br Pgina 4 de 88

Verso 2016br Pgina 5 de 88

Verso 2016br Pgina 6 de 88

Verso 2016br Pgina 7 de 88

0.2 Viso geral

0.4 Como este Syllabus organizado

Verso 2016br Pgina 8 de 88

0.6 Nvel de detalhe

0.7 Objetivos de Aprendizado e Nveis de Conhecimento

0.7.1 Nvel 1: Lembre-se (K1)

Verso 2016br Pgina 9 de 88

0.7.2 Nvel 2: Compreender (K2)

0.7.3 Nvel 3: Aplicar (K3)

0.7.4 Nvel 4: Analisar (K4)

Verso 2016br Pgina 10 de 88

Verso 2016br Pgina 11 de 88

Verso 2016br Pgina 12 de 88

Verso 2016br Pgina 13 de 88

Verso 2016br Pgina 14 de 88

1.2 Polticas e Procedimentos de Segurana da Informao

Verso 2016br Pgina 15 de 88

Verso 2016br Pgina 16 de 88

Verso 2016br Pgina 17 de 88

1.2.2 Anlise de Polticas e Procedimentos de Segurana

Verso 2016br Pgina 18 de 88

Verso 2016br Pgina 19 de 88

1.3.1 Finalidade de uma Auditoria de Segurana

Verso 2016br Pgina 20 de 88

1.3.2 Identificao, Avaliao e Mitigao de Riscos

Verso 2016br Pgina 21 de 88

Verso 2016br Pgina 22 de 88

Verso 2016br Pgina 23 de 88

Verso 2016br Pgina 24 de 88

1.3.3 Pessoas, Processos e Tecnologia

Verso 2016br Pgina 25 de 88

Verso 2016br Pgina 26 de 88

Verso 2016br Pgina 27 de 88

Verso 2016br Pgina 28 de 88

2.3 O Contexto Organizacional

2.4 Objetivos do Teste de Segurana

2.4.2 Identificao dos Objetivos do Teste de Segurana

Verso 2016br Pgina 29 de 88

2.4.3 A Diferena entre a Garantia da Informao e o Teste de Segurana

2.5 mbito e Cobertura dos Objetivos de Testes de Segurana

2.6 Abordagens de Testes de Segurana

2.6.1 Anlise de abordagens de teste de segurana

Verso 2016br Pgina 30 de 88

2.6.2 Anlise de falhas em abordagens de teste de segurana

Verso 2016br Pgina 31 de 88

2.6.3 Identificao das partes interessadas

2.7 Melhorar as Prticas de Testes de Segurana

Verso 2016br Pgina 32 de 88

Verso 2016br Pgina 33 de 88