METODOLOGIA OSSTMM PARA TESTE DE SEGURANÇA EM TI

Edilberto Silva1, Idalêncio Machado2, Marconi Oliveira2, Roberto Amorim2

1
Docente da disciplina Projeto de Gestão da Segurança da Informação
2
Pós-graduandos do Curso MBA em Gestão de Segurança da Informação da UniDF/ICAT

E-mails: edilms@yahoo.com; idalencio@superig.com.br; marconi_souza@yahoo.com.br; amorim.roberto1@gmail.com

Resumo – Este artigo apresenta uma breve contextualização da metodologia open source de Teste de Segurança OSSTMM em sua versão
mais estável 2.2. O Open Source Security Testing Methodology Manual é um documento elaborado pelo ISECOM1 que apresenta uma
metodologia científica para o planejamento, execução e verificação (relatórios) de testes de segurança em ambientes de TI. Pode ser usado
como referência independentemente do tipo e da forma do teste escolhido pela organização-alvo. A última fase do PDCA (Agir) não é
contemplada na metodologia, pois se refere à avaliação dos resultados encontrados e reportados nos relatórios de teste, tarefa eminentemente
de responsabilidade da organização, que deve lançar mão de suas soluções de Gestão de Segurança da Informação para adoção das melhorias
propostas.

Palavras-chave – Teste de Segurança; OSSTMM; PGSI; PenTest; Hacking Ético.

1
Institute for Security and Open Technologies – organização de pesquisa de segurança científica, colaborativa, aberta e sem fins lucrativos registrada na
Catalunha, Espanha, e em NY, EUA.
uma análise imparcial e lógica, bem como procura
1 Introdução apresentar um padrão para certificação dos relatórios de
O termo “Teste de Segurança” quando aplicado no auditoria de segurança [1].
escopo da Segurança de TI pode assumir vários significados Baseando-se na estrutura de um Projeto de Gestão de
isoladamente ou então “embarcar” alguns deles em uma Segurança da Informação – PGSI, mostrada na Figura 1,
espécie de pacote. Sua definição semântica – quais tipos e pode-se situar o Teste de Segurança nas fases de Execução
formas de testes a serem usados – depende dos objetivos e (5ª etapa) e de Verificação/Ação em um momento inicial, e
requisitos escolhidos pela organização. como suporte para as fases de Concepção, de Planejamento
Entretanto, é pacífica a importância desse processo (3ª etapa) e de Execução (4ª etapa) em um momento
dentro da Gestão da Segurança da Informação, na medida posterior, quando o ciclo é realimentado.
em que proporciona um mapeamento da postura de
segurança quanto às vulnerabilidades, ameaças e riscos, e
em conseqüência, possibilita a efetiva conformidade e
adequação às melhores práticas, quando e no que for
aplicável.
Porém, para quê o uso de uma metodologia? Um Teste
de Segurança que não segue metodologia científica não
possui direcionamento nem apresenta resultados claros e de
valor mensurável [1].
Neste sentido, em 2000, foi criada por Pete Herzog a
metodologia de Teste de Segurança OSSTMM – Open
Source Security Testing Methodology Manual. Atualmente,
o desenvolvimento do documento, em sua versão estável
2.2, conta com a colaboração de diversos profissionais da
comunidade de segurança.
O OSSTMM é um documento de pesquisa cujo
conteúdo pode ser aplicado e distribuído livremente, desde
que sem fins lucrativos, sob a OML – Open Methodology
License; o caso de uso comercial é sujeito a restrições de
licença e deve ser solicitado ao ISECOM. Esta metodologia
não se preocupa com o tipo de teste efetivamente escolhido,
tampouco com o porte da organização ou de suas
tecnologias e proteções em uso. Seu objetivo primordial é
apresentar um padrão metodológico prático e consistente de Figura 1: Ciclo PGSI
verificação e avaliação (com uso de métricas) da presença
Considerando o ciclo de qualidade do PDCA – Figura
de segurança2 operacional da empresa, além da proposição
2, normatizado na ISO 9001 e usado também para a Gestão
de controles apropriados depois dos resultados encontrados.
de Segurança da Informação pela NBR/ISO 17799:2005, o
Ainda se compromete a listar regras de compromisso para
processo do Teste de Segurança deve abordar elementos da
garantir aos aplicadores do teste – doravante auditores –
fase de Planejamento (Pré-Teste), de Execução (Teste) e
2
Ambiente de um Teste de Segurança (pontos de risco)
Verificação (Pós-Teste). A fase de Ação fica a cargo da
organização que solicitou o teste, que julgará a

1
aplicabilidade das recomendações resultantes e expressas no
Pós-Teste, de acordo com suas diretrizes estratégicas.
Este artigo abordará essas três fases do Teste de
Segurança na visão da metodologia OSSTMM, ou seja:
- FASE I: Pré-Teste (Planejamento)
- FASE II: Teste (Execução)
- FASE III: Pós-Teste (Verificação)
Figura 2: Ciclo PDCA
Segundo o manual [1], a metodologia OSSTMM pode
ser utilizada para diversos tipos e formas de Teste de
Segurança. A classificação adotada no manual, mostrada na
Figura 3, aborda seis tipos comuns, cujos critérios são os
níveis de conhecimento do auditor e do(s) alvo(s). Por
exemplo, no Blind, o auditor não tem conhecimento prévio
do ambiente da organização-alvo, mas o alvo conhece todos
os detalhes do teste e do auditor. Já no Reversal, o auditor
tem total conhecimento do alvo e dos seus processos,
enquanto a organização-alvo não sabe quais os testes, nem
quando e como eles serão executados.
A escolha do teste mais conveniente a ser aplicado
dependerá das necessidades da organização e da negociação
com o auditor. Muitas vezes, é realizado mais de um tipo de
teste, a fim de comparar os resultados e avaliar desvios da
postura base de segurança da organização.
Figura 3: Tipos de Teste de Segurança
Ainda de acordo com o manual, pode-se classificar as
formas de Teste de Segurança de acordo com os quesitos de
tempo e custo, como mostra a Figura 4. As formas de teste
são independentes dos tipos de teste, apresentados na Figura
3. A princípio, quando escolhida uma forma de teste, pode-
se adotar qualquer abordagem (tipo) para o teste, a depender
também dos requisitos adotados pela organização-alvo.
Vale observar que os termos apresentados no gráfico
geram controvérsias inclusive entre os profissionais de
segurança especializados. Um Teste de Segurança metódico
difere-se de um PenTest – Teste de Intrusão. No primeiro, o
auditor tem uma base de dados com os ataques atuais
conhecidos e tenta explorar falhas no ambiente da empresa-
alvo até conseguir sucesso. No segundo, o auditor combina
criatividade, base de conhecimento das melhores práticas e
das ameaças conhecidas, e a amplitude da presença de
segurança da empresa-alvo. Neste caso, há a tentativa de
exploração das falhas previsíveis – em seus extremos – e
das imprevisíveis – com o uso das melhores práticas contra
os cenários de pior caso.
Figura 4: Formas de Teste de Segurança
O OSSTMM define as sete formas de Teste de
Segurança da seguinte maneira:
1. Varredura de Vulnerabilidade
verificações
automatizadas de vulnerabilidades conhecidas
contra um ou mais sistemas em uma rede;
2. Varredura de Segurança
varreduras de
vulnerabilidades que incluem verificação manual
de falso positivo, identificação de fraquezas na
rede, e análise profissional customizada;
3. Teste de Intrusão ou Invasão (PenTest)

projeto orientado ao objetivo de estabelecer o
“troféu”3 e tentar ganhar acesso privilegiado por
meios pré-condicionais;
4. Avaliação dos Riscos
análise de segurança por
meio de entrevistas e pesquisas estratégicas que
incluem requisitos de negócio, legais e
regulamentares (área de atuação da empresa);
5. Auditoria de Segurança
inspeção de
segurança manual, de nível privilegiado, do sistema
operacional e das aplicações de um ou mais
sistemas em uma rede;
3
“Troféu”: Snapshot ou “retrato” da segurança de um ativo da organização
(tecnologia, pessoas ou processos).
2
 6. Hacking Ético
PenTest cujo objetivo é
descobrir diversos “troféus” por toda a rede dentro
de um limite de tempo predeterminado no projeto;
7. Teste de Segurança, e o equivalente militar
Avaliação de Postura
avaliação de riscos de
sistemas e redes, orientada a projetos, que usa
como meio análise profissional de uma varredura
de segurança em que a intrusão é freqüentemente
usada para confirmar falsos positivos e falsos
negativos dentro do prazo do projeto.
Assim como o tipo de teste, a escolha da forma do
Teste de Segurança depende das necessidades e dos
requisitos de segurança da organização-alvo, principalmente
os relacionados a tempo e custo de sua aplicação.
2 FASE I: Pré-Teste
2.1 Conformidade
Conformidade é o alinhamento com um conjunto de
políticas e normas gerais, cujo tipo depende da localidade
(país, estado, cidade), do tipo de negócio, do setor
regulamentador e/ou regulatório, e das políticas da
organização. Apesar de ser teoricamente obrigatório, o
investimento em certo tipo de conformidade, como qualquer
outra ameaça, deve ter sua viabilidade estudada na avaliação
dos riscos.
O OSSTMM trabalha com três tipos de conformidade
[1]:
- Legislação: conformidade com a legislação de
acordo com a região de sua aplicabilidade. A força e
o cumprimento das leis originam-se na sua
popularidade e em argumentos legais bem-sucedidos
e medidas executórias apropriadas. Seu não-
cumprimento pode ocasionar ao infrator penas
criminais.
- Regulação: conformidade com normas industriais,
comerciais ou do setor de atuação da empresa. Seu
não-cumprimento pode acarretar ao infrator: saída do
setor, perda de privilégios, multas, penas civis, e em
alguns casos, onde a legislação existe para suportar o
corpo regulador, penas criminais.
- Política: conformidade com o negócio da
organização e suas políticas. Pode incluir também as
melhores práticas do mercado, principalmente as de
Segurança da Informação. Seu não-cumprimento
pode provocar ao infrator: saída da organização,
perda de privilégios, multas, penas civis, e em alguns
casos, onde a legislação existe para suportar o corpo
regulador, penas criminais.
O desenvolvimento do OSSTMM pauta-se na
preocupação com legislação e regulação, principalmente as
da Europa e EUA. Como nem toda conformidade é criada
igualmente, o foco principal do OSSTMM é a Segurança da
Informação.
Como a legislação e a regulação podem ser auditadas
tanto sob a letra quanto sob o espírito da lei, dependendo do
corpo de auditoria, a prova da aplicação de proteção e de
controles operacionais adequados, como os que podem ser
provados por um teste OSSTMM, pode ou não ser
satisfatória.
Em casos de legislação e regulação sem concretude
prévia, não se pode saber se a letra da lei triunfará o espírito
da lei. Portanto, o OSSTMM também foi desenvolvido para
descobrir onde elementos de serviços e produtos especiais
podem ser determinados, como saber se uma outra auditoria
obrigatória mostrará conformidade. Nesse sentido, pode-se
aplicar a letra e o espírito da lei sempre que possível e os
dois não conflitarão.
Alguns exemplos de leis respeitadas pelo OSSTMM
são a GLBA4, SOX e a HIPAA5 (EUA), e a “UK Data
Protection Act 1998” (Reino Unido). Aquelas ainda não
analisadas também devem ser seguidas por esta
metodologia, ao menos no espírito da lei. Já referente às
políticas, o OSSTMM adequa-se à ISO 17799:2000
(BS7799), a algumas normas do NIST6 e à “IT Information
Library” (Reino Unido), entre outras.
2.2 Regras de Compromisso dos envolvidos
Devido à natureza mais superficial do artigo, serão
apresentadas apenas algumas regras para o comportamento
das pessoas e empresas envolvidas no planejamento,
execução e verificação (resultados) dos testes, inclusive no
processo de marketing e venda do trabalho e na elaboração
dos relatórios. (Maiores detalhes no documento [1]).
Essas regras, divididas em sete grupos de processos –
listados abaixo – são como um código de ética e conduta
operacional cujo cumprimento é obrigatório na realização
de um teste que usa o OSSTMM.
1. Marketing e Venda
 O uso de medo, incerteza, dúvida e engano não
pode ser usado nas apresentações, sítios web,
materiais de suporte, relatórios, ou discussões
referentes a marketing e venda, com o propósito
de vender e realizar testes de segurança. Isso
inclui, mas não está limitado a, usar crimes, fatos,
perfis hacker ou criminais glorificados, e
estatísticas, não verificados pessoalmente com a
motivação do medo para criar vendas.
2. Avaliação / Estimativa da Entrega
 É proibido verificar limitações de segurança sem
permissão escrita explícita.
3. Negociações e Contratos
 Com ou sem contrato de Acordo de Não-
Revelação, o auditor de segurança deve prover
confidencialidade e não-revelação das
informações do cliente e dos resultados dos
testes.
4. Definição do Escopo
 O escopo deve ser claramente definido em
contrato antes de se verificarem serviços
vulneráveis.
5. Plano de Teste
 O plano de Teste deve incluir o tempo
(calendário) e os homens-hora.
6. Processo de Teste
4
U.S. Gramm-Leach-Bliley Act [11]
5
Health Insurance Portability and Accountability Act of 1996 [12]
6
National Institute of Standards and Technology [13]
3
  O auditor deve respeitar e manter segurança,
saúde, bem-estar e privacidade do público interno
e externo ao escopo.
7. Apresentação dos Resultados (Relatórios)
 O auditor deve respeitar a privacidade de todos
os indivíduos e manter a privacidade deles para
todos os resultados.
2.3 Avaliação dos Riscos
A avaliação dos riscos é mantida tanto pelo aplicador
do teste – auditor – quanto pelo analista (podem ser a
mesma pessoa) para todos os dados coletados, visando dar
suporte a uma avaliação válida por meio de teste não-
privilegiado. Isto implica que se forem coletados poucos ou
impróprios dados, então talvez não seja possível prover uma
avaliação de risco válida. O auditor deve, portanto, confiar
nas melhores práticas, nas regulações industriais ou
comerciais do cliente, na política de segurança do cliente, e
em assuntos legais referentes ao cliente e a sua região de
negócio. [1]
O OSSTMM considera o risco como sendo aqueles
limites na presença de segurança que têm efeito negativo em
pessoas, cultura, processos, negócio, imagem, propriedade
intelectual, direitos legais, ou capital intelectual. O manual
mantém quatro dimensões no Teste de Segurança para um
ambiente de risco mínimo:
• Segurança (segurança física e emocional das
pessoas);
• Privacidade (ética e cultura, algo além da
legislação);
• Senso Prático (complexidade mínima, viabilidade
máxima e clareza profunda);
• Usabilidade (segurança prática, usável).
A técnica aplicada pelo OSSTMM para a avaliação dos
riscos é a chamada “Segurança Perfeita”. Para encontrar a
“Segurança Perfeita” da organização-alvo ou do cliente, o
auditor e o analista levantam alguns requisitos e documentos
relacionados à empresa, ao seu mercado de atuação e à
legislação vigente. Como exemplo, tem-se a Revisão de
Postura (melhores práticas), as regulações comerciais e
industriais, os requisitos de negócio, a política de segurança,
e as questões legais e comerciais de certa região. A partir
disso, eles realizam uma análise gap (diferencial ou delta)
entre o estado atual da segurança da organização e a
“Segurança Perfeita”.
É importante frisar que o resultado do levantamento – o
qual define a “Segurança Perfeita” – é individual para cada
cliente e deve ser o mais profundo possível, para garantir
uma boa avaliação dos riscos e servir de benchmark para as
outras fases do teste. E outra questão emanada seria: existe
efetivamente segurança perfeita? Talvez, por causa dessa
dúvida, este termo esteja entre aspas nas suas aparições. De
qualquer forma, o manual apresenta um modelo teórico que
abrange Serviços e Gateway de Internet, Computação
Móvel, Aplicações, e Pessoas.
2.4 Métricas de Segurança
As métricas de segurança são indicadores importantes
do real estado da segurança (presença de segurança) da
organização. Uma auditoria de segurança minuciosa resulta
em métricas objetivas, acuradas e efetivas. Ademais, o
sucesso no uso das métricas não pode depender de
habilidade, nível de conhecimento e experiência do auditor
e do analista na identificação e análise dos dados coletados,
por serem critérios subjetivos e mais suscetíveis a erros
como falso positivo, falso negativo, erro de amostragem e
erro humano.
A metodologia define e quantifica três áreas dentro do
escopo definido – (I) Operações, (II) Controles, e (III)
Limitações. Essa abordagem envolve o cálculo de hashes,
os chamados RAV’s (Risk Assessment Value) das três áreas
separadamente, que são combinados para formar o quarto
hash, chamado “Segurança Real”. Este RAV será a métrica
final para comparações futuras. É importante dizer que a
mudança do escopo acarretará um novo cálculo da
“Segurança Real”.
O RAV é usado como métrica objetiva, consistente e
repetível, que não se preocupa com a pessoa do auditor.
Com isso, mesmo não sendo uma avaliação de riscos
propriamente dita, ele pode ser usado como base efetiva
para a avaliação de riscos completa da organização.
Cada uma das três áreas citadas engloba diversos
requisitos que devem ser medidos dentro do escopo
definido. O quadro abaixo apresenta esses requisitos, mas
não faz parte do escopo deste artigo mostrar
desenvolvimento dos cálculos de cada um e das áreas.
Tabela 1: RAV
Visibilidade
Operações Confiança
S Acesso
E Classe A Autenticação
G (interativo) Identificação
U Subjugação
R Continuidade
A Resiliência
Controles
N Classe B Não-repúdio
Ç (processo) Confidencialidade
A Privacidade
Integridade
R Alarme
E Vulnerabilidade
A Fraqueza
L Limitações Preocupação
Exposição
Anomalia
Para se encontrar o delta da “Segurança Real”, o valor
resultante da soma dos itens da área “Controles” deve ser
subtraído do valor resultante da soma dos itens da área
“Operações” e do valor resultante de uma fórmula
específica dos itens da área “Limitações”. O nível RAV da
Segurança Real é dado em porcentagem pela subtração do
valor ideal de 100%, correspondente ao nível de “Segurança
Perfeita”, do delta da Segurança Real.
Na referência [4], pode ser consultada a planilha com
todas as fórmulas envolvidas neste processo de cálculo de
métricas e dos RAV’s.
4
 3 FASE II: Teste comunicação da organização-alvo, como fax, VoIP, modem,
acesso remoto, PABX, e outros.
3.1 Mapa de Segurança Uma seção que tem grande destaque ultimamente é a de
O Mapa de Segurança é uma visualização da presença Segurança Wireless, por ainda ser de pouco interesse das
de segurança da organização e divide-se em seis seções de organizações, mas que, em contrapartida, pode apresentar
teste, que são as seções do manual e cujas inter-relações são falhas e vulnerabilidades cuja exploração geram grandes
mostradas na Figura 5. impactos. Nela, são previstos testes de redes WLAN
(802.11), Bluetooth, RFID, e outras.
A sexta – e última – seção refere-se à Segurança
Física, ou seja, sua atuação engloba testes de perímetro, de
controle de acesso físico, de ambiente, de resposta a
alarmes, de backup/recovery, etc. Enfim, aborda testes dos
recursos de infra-estrutura física da organização e dos
possíveis parceiros.
3.2 Metodologia
A metodologia de testes OSSTMM divide-se em
seções, módulos e tarefas. As seções são os pontos da
segurança abordados no Mapa de Segurança. Os módulos
são o fluxo da metodologia de um ponto de presença para
outro, e possuem uma entrada e uma saída de dados. A
entrada é usada para processar uma tarefa daquele ou de
outro módulo, e a saída é o resultado obtido desta tarefa
completada, que servirá para outro(s) módulo(s) ou outra(s)
seção(ões). Cada seção tem relação com outras seções e
com alguns dos respectivos módulos.
A Figura 6 abaixo ilustra a metodologia.

Figura 5: Mapa de Segurança

Cada seção é composta de vários módulos, os quais

devem incluir todas as dimensões de segurança, que se
integram em tarefas para serem atingidas. Para realizar um
teste OSSTMM de uma seção em particular, todos os
módulos relacionados devem ser testados, com exceção
daqueles em que não há infra-estrutura correspondente e,
por isso, não podem ser verificados. Neste caso, deve-se
então determiná-lo NÃO APLICÁVEL nos relatórios de
resultados.
Na seção de Segurança da Informação, é feita a coleta
da documentação de nível tático, como a avaliação da Figura 6: Metodologia OSSTMM
postura, revisão da integridade e da privacidade da
A metodologia permite a separação entre a parte de
informação, revisão dos controles e dos recursos humanos.
Coleta de Dados e a parte de Teste de Verificação dos dados
Isto subsidiará também a fase de avaliação dos riscos e de
coletados. O fluxo permite também determinar o momento
definição da “Segurança Perfeita”.
para coleta e o momento para inserção desses dados.
A seção de Segurança de Processos preocupa-se
Ademais, cada módulo relaciona-se com seu anterior e
primordialmente com a questão da Engenharia Social e o
seu posterior, tendo que atender certos resultados esperados.
tratamento dado à segurança da informação pelo corpo
Um módulo pode não ter entrada de dados, devendo ser
funcional. Prevê testes de postura, de solicitações aos
ignorado no teste. Caso o módulo não apresente saída, deve
empregados e de suas respostas, de sugestão direcionada, e
ser verificado o motivo, podendo ser [1]:
de pessoas confiáveis.
 O canal foi obstruído de alguma forma durante a
Pode-se dizer que os testes tecnológicos envolvendo a
realização das tarefas;
Internet são abordados na seção de Segurança de
 As tarefas não foram executadas corretamente;
Tecnologia de Internet. Nela, são executados testes de
 As tarefas não foram aplicáveis;
varredura de vulnerabilidades na rede, de detecção de
 Os dados resultantes da tarefa não foram analisados
intrusão, de controle de acesso, de quebra de senhas, de
corretamente;
ataques DoS, etc.
 A tarefa revela uma segurança superior.
Na seção de Segurança das Comunicações, os testes
envolvem a descoberta de falhas nos diversos canais de No total, o Teste de Segurança inicia-se com uma
entrada, que pode ser, por exemplo, o endereço IP ou a URL
5
do servidor ou sistema objeto do teste. Ele termina com o
começo da fase de análise dos dados e construção do
relatório final, que depende essencialmente da experiência e
do conhecimento do auditor e dos objetivos traçados pela
organização-alvo.
Em resumo, os elementos da metodologia e suas
características são:
I. Seções: modelo de segurança dividido em pedaços
gerenciáveis e testáveis;
II. Módulos: variáveis de teste nas seções, que
requerem uma entrada para realizar as tarefas
internas e externas (de outro módulo), cuja saída
será a entrada para o módulo posterior ou, em
alguns casos, para o anterior;
III. Tarefas: testes de segurança a serem realizados que
dependem da entrada do módulo e cujos resultados
serão a saída do módulo.
4 FASE III: Pós-Teste
4.1 Relatórios
Esta fase, de apresentação dos resultados por
intermédio dos relatórios de teste, é de fundamental
importância na realimentação dos ciclos do PDCA e do
PGSI. Os relatórios mostram a realidade da postura de
segurança da organização-alvo dentro do escopo elaborado.
A partir disso, pode-se reavaliar os trabalhos feitos nas
etapas de Avaliação de Risco e de Seleção dos Controles a
fim de verificar a viabilidade e a conformidade dos
resultados encontrados nos testes com os riscos previamente
endereçados. De fato, é uma fase essencial na Gestão do
Risco, pois apontará os acertos e erros das avaliações
anteriores e proporá as possíveis melhorias nos controles.
Nesta fase, o OSSTMM aponta alguns requisitos a
serem seguidos para garantir a efetividade e a certificação
dos testes.
É importante estender aqui as recomendações expostas
nas Regras de Compromisso, além do respectivo exemplo
colocado no item 2.2, no que se refere à postura do
profissional na elaboração dos relatórios e aos itens formais
e de conteúdo tidos como premissa. São elas:
• O auditor deve respeitar a privacidade de todos os
indivíduos e manter a privacidade deles para todos
os resultados;
• Resultados envolvendo pessoas não-treinadas em
segurança ou não-pertencentes à área de segurança
somente devem ser reportados por meios não-
identificativos ou estatísticos;
• O auditor e o analista não podem assinar resultados
de testes e relatórios de auditoria nos quais não
tiveram diretamente envolvidos;
• Os relatórios devem se ater ao objeto sem quaisquer
falsidades e maldades direcionadas a pessoas;
• Notificações ao cliente são requeridas sempre que o
auditor alterar o plano de testes ou o local físico de
origem do teste, descobrir riscos altos antes de
realizar novos testes com alto risco ou tráfego,
ocorrerem problemas nos testes, e houver
atualizações de progresso;
• Soluções e recomendações incluídas no relatório
devem ser válidas e práticas;
• Os relatórios devem apontar claramente tudo que é
desconhecido e anômalo;
• Os relatórios devem declarar todos os controles e as
medidas de segurança encontrados, falhos ou bem-
sucedidos;
• Os relatórios devem usar apenas métricas
quantitativas para medir a segurança. Essas métricas
devem ser baseadas em fatos e sem interpretações
subjetivas;
• O cliente deve ser notificado quando o relatório
estiver sendo confeccionado para contar com a
entrega e confirmar seu recebimento;
• Todos os canais de comunicação para a entrega do
relatório devem ser fim-a-fim e confidenciais;
• Os resultados e relatórios nunca devem ser usados
para ganho comercial.
O manual apresenta ainda templates de relatórios com
as informações consideradas indispensáveis para qualificá-
los como do OSSTMM. Alguns exemplos referem-se a
Perfil de Rede, Firewall, IDS, Informação de Servidor,
Engenharia Social, DoS, Revisão de Medidas de Contenção,
Análise de Confiança, entre outros.
A título de ilustração das informações requeridas nos
templates, aquele que reporta o Perfil de Rede deve conter
os seguintes dados: (I) Faixas de IP a serem testadas e seus
detalhes; (II) Informações do domínio e configurações; (III)
Pontos focais de transferência de zona; e (IV) Lista dos
servidores com IP, Domínio e Sistema Operacional.
4.2 Certificação
Além dos requisitos mencionados no item 4.1 para
certificação dos relatórios e dos testes, o manual apresenta
ainda outros que devem ser seguidos se o auditor pretende
certificar em qualidade e credibilidade seu teste pelo
OSSTMM. Ao executar os testes, ele deve verificar se:
• O teste tem sido conduzido minuciosamente,
atentando para todos os detalhes;
• O teste inclui todos os canais necessários;
• A postura para o teste inclui a conformidade com
os direitos civis vigentes;
• Os resultados são mensuráveis em meios
quantitativos;
• Os resultados recebidos são consistentes e
repetíveis;
• Os resultados contêm somente fatos derivados dos
próprios testes.
Após realizar essas análises e concluir o cumprimento
de todos os requisitos exigidos, o auditor e o analista devem
assinar o Relatório de Auditoria OSSTMM. Este relatório,
com uma versão anônima do relatório de auditoria de
segurança, é submetido ao ISECOM para revisão, que
proverá a certificação oficial OSSTMM.
Não é necessário seguir completamente o manual ou
alguma subseção específica para garantir o teste certificado
e o relatório credenciado. Precisa apenas mostrar o que foi e
o que não foi testado para ser passível de certificação [1].
6
 Apesar de a certificação não ser obrigatória para [4] SECURITY METRICS – RAVs (Risk Assessment Values).
realizar uma auditoria OSSTMM, existem alguns benefícios Disponível em:
se ela estiver em conformidade com os requisitos, quais http://www.isecom.org/securitymetrics.shtml. Acessado em:
sejam [1]: out/2007.
- Serve como prova para um teste efetivo;
- Torna o(s) auditor(es) responsável(is) pelo teste; [5] NBR ISO/IEC 17799 – Tecnologia da informação —
- Mostra uma declaração aberta ao cliente; Técnicas de segurança — Código de prática para a gestão
- Provê uma abordagem mais conveniente que um da segurança da informação. 2ª ed. ABNT, 2005.
sumário executivo;
- Provê um checklist válido para o auditor; [6] FULLERTON, Chuck. The need for Security Testing An
- Provê métricas claramente calculadas e Introduction to the OSSTMM 3.0. Disponível em:
compreensíveis. http://www.securitydocs.com/library/2694. Acessado em:
Para a certificação da organização auditada, é out/2007.
necessário que ela mantenha o nível RAV no mínimo em
95% e valide com uma auditoria anual OSSTMM realizada [7] MELO, Sandro. Executando PENTEST utilizando
por um auditor terceiro. Essas validações precisam da Ferramentas Open Source e OSSTMM (Open Source
verificação por parte do ISECOM para garantir a Security Testing Methodology Manual). Disponível em:
consistência e a integridade. http://www.4linux.com.br/pdf/pentest20061221.pdf.
Acessado em: out/2007.
5 Conclusão
A decisão de realizar um Teste de Segurança deve ser [8] INTRUDERS. Por que realizar um PenTest em minha
considerada e “comprada” pela organização na fase de empresa? Disponível em:
planejamento de um PGSI ou da Gestão de Segurança de http://www.intruders.org.br/index.html. Acessado em:
Informação, preconizada pela ISO 17799. É uma solução out/2007.
que provê os indicadores para a avaliação da postura de
segurança operacional da empresa, identificando e [9] NEVES, Eduardo Jorge F. S. OSSTMM v2.1.
analisando as vulnerabilidades e ameaças do negócio, e Disponível em: http://h2hc.org.br/repositorio/2004/osstmm-
conseqüentemente, tratando os riscos de forma mais efetiva. pt.pdf. Acessado em: out/2007.
Os relatórios de teste com as melhorias propostas podem ser
usados pelo gestor como base para a fase de Ação (PDCA), [10] ROGER, Denny. Teste de Invasão. Disponível em:
ou seja, de revisão das políticas de segurança e da análise de http://idgnow.uol.com.br/seguranca/mente_hacker/idgcoluna
riscos. .2006-12-11.7946072081/. Acessado em: out/2007.
O uso de uma metodologia científica como o OSSTMM
agrega mais valor a um Teste de Segurança. Proporciona [11] FEDERAL TRADE COMISSION. U.S. Gramm-
que este seja melhor planejado, executado seguindo padrões Leach-Bliley Act. Disponível em:
e melhores práticas, e com resultados expressos em http://www.ftc.gov/privacy/privacyinitiatives/glbact.html.
relatórios que podem ser certificados pelo ISECOM. A Acessado em: out/2007.
metodologia livre OSSTMM garante maior acurácia no
planejamento e execução dos testes, além de resultados mais [12] CENTERS FOR MEDICARE & MEDICAID
apropriados, pois se baseia em métricas de segurança SERVICES. Health Insurance Portability and
objetivas e em um mapa de segurança que abrange todas as Accountability Act of 1996. Disponível em:
áreas afetadas pela Segurança da Informação. Com isso, a http://www.cms.hss.gov/HIPAAGenInfo/. Acessado em:
visão que a organização tem da sua presença de segurança é out/2007.
mais realista e consistente.
[13] National Institute of Standards and Technology.
6 Referências Bibliográficas Disponível em: http://www.nist.gov. Acessado em:
out/2007.
[1] HERZOG, Pete. OSSTMM 2.2 – Open Source Security
Testing Methodology Manual. Disponível em:
http://www.isecom.org/osstmm/. Acessado em: out/2007.

[2] WHITAKER, Andrew; NEWMAN, Daniel P.

Penetration Testing and Network Defense. Indianapolis,
EUA: Cisco Press, 2005.

[3] WACK, John; TRACY, Miles; SOUPPAYA, Murugiah.

NIST Special Publication 800-42 – Guideline on Network
Security Testing. Disponível em:
http://csrc.nist.gov/publications/nistpubs/800-42/NIST-
SP800-42.pdf. Acessado em: out/2007.