Um Mapeamento Sistemático sobre Testes de Penetração · Ethical+Hacking!e!ressaltaadivisão!dos!tipos!de!Pentest! entreblack2box,white2box!egray2box.!! Em[8],!o!artigo!trata!as!minúcias!emtestes!de!penetração,discutindo

Um Mapeamento Sistemático sobre Testes de Penetração

Daniel Dalalana Bertoglio, Avelino Francisco Zorzo

Relatório Técnico: no 084. Setembro de 2015.

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO GRANDE DO SUL FACULDADE DE INFORMÁTICA

PROGRAMA DE PÓS-‐GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

SUMÁRIO

Dentro da área de segurança da informação, as pesquisas envolvendo técnicas para testes de segurança de ambientes corporativos, redes e sistemas tem apresentado grande variedade nas suas contribuições. Dessa forma, a compreensão de como metodologias e ferramentas de testes de segurança tem sido modernizadas e evoluídas, principalmente no âmbito de Testes de Penetração (Pentest), torna-‐se uma tarefa complexa e essencial. O principal objetivo deste trabalho é fornecer um overview sobre a área de Pentest, apresentando seus cenários de aplicação, modelos, metodologias e ferramentas a partir dos trabalhos que foram publicados. Nesse sentido, este trabalho pode ajudar pesquisadores acadêmicos e interessados na área de segurança a entender os aspectos e soluções relacionadas a Pentest. Para isso, um mapeamento sistemático foi realizado com uma coleta inicial de 1019 artigos, representados por 964 artigos distintos que foram avaliados e ao final 50 estudos primários foram selecionados para serem analisados de modo quantitativo e qualitativo. Como resultado, foram classificadas ferramentas e metodologias que são utilizadas no contexto de Pentest, além de relacionar os principais cenários nos quais tais metodologias e ferramentas são aplicadas. Assim, é possível concluir que juntamente a área de segurança da informação como um todo, o tema Pentest tem tomado frente em grande parte das pesquisas, gerando contribuições e trabalhos de maneira significativa. Palavras-‐chave: Testes de Penetração, Mapeamento Sistemático, Testes de Segurança

1. INTRODUÇÃO Os riscos de segurança para empresas, organizações e entidades que trabalham com dados sensíveis, sejam eles públicos ou não, é mais que evidente. Muitas vezes, tais empresas são incapazes de compreender a extensão das estruturas de comunicação complexas de hoje e efetuam pouco ou até nenhum controle sobre elas [1]. Além disso, esse fator de risco é ainda maior quando as aplicações estão voltadas para o contexto web. Riscos que não são controlados potencializam ataques a segurança, que por sua vez implicam em perdas consideráveis. O uso de técnicas para testes de segurança, então, é tarefa essencial para os cuidados referentes a esses riscos [2].

Uma das técnicas conhecidas para isso é o Teste de Penetração (Pentest). Pentest é a tentativa controlada de penetrar um sistema ou rede a fim de detectar vulnerabilidades. Ela emprega as mesmas técnicas que são utilizadas em uma ataque propriamente dito. Essa alternativa permite que sejam tomadas

medidas adequadas para eliminar as vulnerabilidades antes que possam ser exploradas por terceiros não autorizados [3].

O processo de um Pentest se subdivide, normalmente, em atividades como: coleta de informação sobre o sistema alvo; escaneamento do sistema alvo e descoberta dos serviços; identificação de sistemas e aplicações; descoberta de vulnerabilidades e exploração de vulnerabilidades [4]. Para uma empresa, este processo é aplicado visando objetivos variados, como o natural aumento da segurança dos sistemas, identificação de vulnerabilidades, teste da equipe de segurança da empresa alvo e até mesmo o aumento da segurança organizacional e de pessoas.

Ainda nesse sentido, a aplicação do Pentest pode ser classificada em critérios como [3]:

• Base de informações: nível de conhecimento sobre a empresa antes da execução do Pentest.

• Agressividade: nível de aprofundamento do tester, variando entre apenas identificar as vulnerabilidades até a exploração de todas as vulnerabilidades detectadas.

• Escopo: define o escopo do Pentest, se é determinado para um ambiente, abrangente ou limitado.

• Abordagem: trata o método de execução do Pentest quanto a geração de ruído no ambiente.

• Técnica: quais as técnicas e metodologias usadas no Pentest.

A completude de um teste de penetração, enquanto técnica para avaliação de segurança, é robusta o suficiente para fornecer um nível de segurança no mínimo adequado e em um nível de detalhe alto em respeito a fraquezas do alvo. Inerente as atividades e critérios do Pentest, existem ainda as preocupações legais da execução e aplicação de um teste de penetração dentro de uma empresa ou ambiente, aspectos que devem ser levados fortemente em consideração.

Este trabalho apresenta um Mapeamento Sistemático (Systematic Mapping Study -‐ SMS)[5], conduzido para mapear o campo de Pentest, visando encontrar evidências que podem ser usadas para aperfeiçoar as pesquisas da área. Além disso, visa identificar tendências de pesquisa, metodologias, cenários e ferramentas de uso.

Considera-‐se SMS um estudo secundário realizado a fim de encontrar e

agregar evidências disponíveis sobre um tema específico. Portanto, ele fornece uma visão geral de uma área de pesquisa, identifica a quantidade, qualidade, tipo de pesquisa e os resultados disponíveis. A motivação para execução deste SMS é

aprofundar o conhecimento sobre os metodologias, cenários e ferramentas que estão no contexto de Pentest. Dessa forma, este estudo pode servir como base para outros, uma vez que os resultados identificam as respostas relacionadas a estes modelos e ferramentas disponíveis que são utilizados, além dos cenários de execução em questão. Provê também a discussão sobre os desafios da área, relacionando as tendências e identificando lacunas para futuras pesquisas. A principal contribuição é fornecer um overview sobre as pesquisas e trabalhos desenvolvidos sobre o tema de Testes de Penetração.

2. PESQUISAS RELACIONADAS Nos últimos anos, a área de Pentest tomou boa representatividade nas pesquisas aplicadas em Segurança da Informação. Contudo, poucos são os estudos de mapeamento, survey ou com caráter de overview dentro do campo.

Em [6], é apresentado um survey voltado a teste de penetração web, discutindo metodologias e comparando ferramentas de escaneamento de vulnerabilidades, além do levantamento de trabalhos que contém novas propostas de método ou ferramentas direcionados a Pentest. Este trabalho apresenta uma seleção de estudos primários identificados a partir de três visões: artigos que comparam métodos e ferramentas existentes, artigos que propõem um novo método ou ferramenta e estudos que propõem ambientes de teste para o processo. Inicialmente a pesquisa apresenta um comparativo de 13 ferramentas de escaneamento, com licença Open-‐source, avaliando os critérios referentes a estrutura (interface gráfica, configuração, usabilidade, estabilidade e performance) e a funcionalidades (spider, manual crawl, análise de arquivo, logging e relatório). Uma comparação em relação aos mesmo critérios é efetuada também com 7 ferramentas de escaneamento com licença comercial, avaliando conceitualmente a aplicação das mesmas. Em geral, os autores nortearam suas contribuições principais em torno da relação entre o funcionamento das ferramentas de descoberta de vulnerabilidades e seus cenários de aplicação, ambientes alvo, limitações e completude.

Já em [7], de forma mais abrangente, a pesquisa é direcionada para a discussão sobre as técnicas de teste de segurança existentes. O artigo disserta sobre Pentest considerando as seguintes outras técnicas de teste de segurança: Fuzz Testing, Binary Code Analyses e Vulnerability Scanning. Conceitualmente o autor trata Pentest como Ethical Hacking e ressalta a divisão dos tipos de Pentest entre black-‐box, white-‐box e gray-‐box.

Em [8], o artigo trata as minúcias em testes de penetração, discutindo sobre a interpretação correta dos resultados de um Pentest e reiterando a

necessidade de análises detalhadas acerca das atividades que o compõem. Da mesma forma de pesquisa teórica, [9] apresenta as principais abordagens e opiniões sobre Pentest em um artigo que representa grande parte das citações atuais de pesquisas da área em virtude da sua consolidação.

3. PLANEJAMENTO DO SMS Em particular, a ideia de realizar um mapeamento sistemático é estruturada com o intuito de identificar e investigar uma determinada área de pesquisa, neste caso, direcionada a Testes de Penetração. Em contraponto ao método de Revisão Sistemática [10], que além da identificação visa também analisar, avaliar e interpretar todas as pesquisas disponíveis para uma questão determinada, o Mapeamento Sistemático fornece uma abordagem mais abrangente e concisa em relação aos estudos primários existentes para o tema investigado.

Para tal objetivo, este SMS segue o processo proposto por Petersen et al. [5], conforme ilustrado na Figura 1.

Figura 1. Processo do mapeamento sistemático [5].

O processo demonstrado na Figura 1 é dividido em três grandes fases que

contém subatividades: Planejamento (Planning), Condução (Conduction) e Apresentação (Reporting). O Planejamento do Mapeamento Sistemático é descrito nesta seção enquanto a Condução é apresentada na seção 4 e os resultados são discutidos na seção 5. As atividades dentro de cada fase do processo resultam em um artefato, totalizando assim dois artefatos por fase. 3.1. Escopo e Objetivo Neste SMS, o foco está em identificar as principais contribuições em relação a Testes de Penetração e prover um overview sobre modelos, metodologias e ferramentas utilizadas neste campo de estudo. Deste modo, esta pesquisa destina-‐se em fornecer o embasamento necessário, de forma abrangente, sobre o processo de Pentest e sua estrutura em geral. Os resultados podem permitir uma

A SYSTEMATIC MAPPING STUDY ON MODEL-BASED TESTING 5

Software Engineering. Therefore, our process is divided in three phases (see Figure 1): Planning,

Conduction and Reporting. The SMS planning is described in this section, the study conduction is

presented in Section 4 and the SMS results are discussed in the Section 5. It is important to notice

that each phase has two activities and each activity in turn results in an artifact. As shown in Figure 1

the final artifact of the process is the systematic map.

Planning Conduction Reporting

Protocol Review Scope All Retrieved Papers

Relevant PapersClassification

Scheme Systematic Map

Legend:Activity ArtifactPhase

Definition of Research Question

Definition of the Protocol Conduct Research Screening of Papers Keyworking

Relevant TopicsData Extraction and

Mapping

Figure 1. Systematic Mapping Studies Process [5]

3.1. Scope and Objective

In this SMS, we focus on identifying the main contributions to the MBT field and to provide an

overview about the processes, models and tools from several works that were produced from January

2006 to December 2013 (inclusive). Therefore, this SMS is intended to provide a broad overview

on MBT works, presenting the main tools used to support MBT, in which domains MBT is applied

and what are the models or notations used. These results can provide a comprehensive overview to

researchers, test engineers and test analysts about MBT, its process, supporting tools, and modeling

notations.

3.2. Question Structure

We structure our research question based on PICO [13] (Population, Intervention, Comparison,

Outcome) criteria:

• Population: Published research papers on Software.

• Intervention: Model-Based Testing.

• Comparison: Not applied.

• Outcome: The expected results are the Approaches in which MBT is applied to from 2006 to

2013.

c� 2014 The Institution of Engineering and Technology IET Software (2014)

Prepared using iet.cls DOI: 10.1049/iet-sen.2014.0000/IET

análise e visão compreensivas para pesquisadores, analistas de segurança e demais profissionais correlacionados através da discussão sobre tais modelos, metodologias e ferramentas. 3.2. Estrutura da Questão A questão de pesquisa deste SMS é estruturada baseada nos critérios PICO [10] (Population, Intervation, Comparison, Outcome):

• População (Population): artigos de pesquisa publicados em Segurança da Informação.

• Intervenção (Intervention): Testes de Penetração. • Controle (Comparison): Não aplicado. • Resultados (Outcome): Tipo e quantidade de evidências relativas a

abordagens de Testes de Penetração, a fim de identificar as ferramentas, modelos, metodologias, cenários e principais desafios da área.

3.3. Questões de Pesquisa Foram definidas as seguintes questões de pesquisa: RQ1. Quais são as principais ferramentas utilizadas em Pentest? RQ2. Quais os cenários de execução de Pentest? RQ3. Quais os modelos para ferramentas de Pentest? RQ4. Quais os principais desafios em Pentest? 3.4. Processo de Pesquisa 3.4.1. Bases de Dados. Para executar a pesquisa foram selecionadas as bases de dados que (1) contém uma engine de busca na web; (2) contém um mecanismo de busca habilitado a usar palavras-‐chave; e, (3) contém artigos da Ciência da Computação. A seleção inclui ACM Digital Library, IEEE Xplore, SCOPUS e Springer Link*. 3.4.2. Termos e Sinônimos. Foram utilizadas as questões estruturadas (ilustrada na Tabela I) para a construção das strings de busca.

* dl.acm.org;ieeexplore.ieee.org; scopus.com; link.springer.com

Tabela I. Definição das Strings de Busca Estrutura Termos Sinônimos

População Security Information

Intervenção Penetration Test Pentest

Penetration Testing

Pentesting

Resultados Tool Tools

Software

Suite

Model Process

Methodology

Standard

Framework

Environment Context

Challenges Open reserch topics

Open problems 3.4.3. String. Foi utilizado o operador booleano "OR" para selecionar alternadamente palavras e sinônimos, e o operador booleano "AND" para selecionar os termos para população, intervenção e resultados (descrito na Figura 2).

3.5. Critérios de Inclusão e Exclusão Uma das atividades essenciais durante o planejamento do SMS é a definição dos Critérios de Inclusão (IC) e dos Critérios de Exclusão (EC). Tais critérios são responsáveis por apoiar a seleção dos artigos apropriados e são empregados para reduzir o número de artigos que retornam das engines de busca. Por

(("penetration test" OR "penetration testing" OR "pentest") AND (tool OR tools OR software OR suite) AND (model OR process OR framework OR methodology OR standard) AND (environment OR context) AND ("open research topics" OR challenges OR "open problems"))

Figura 2. String de busca

exemplo, se um artigo é classificado em apenas um IC, será incluído como um estudo primário e se o artigo é associado com apenas um EC, será excluído. Neste SMS os critérios de inclusão e exclusão foram definidos como:

• IC1. O estudo principal discute sobre uma ou mais ferramentas dentro do processo de Pentests;

• IC2. O estudo principal propõe um modelo/processo/framework/metodologia de Pentest;

• EC1. O estudo principal não está relacionado diretamente a Pentests; • EC2. O estudo apresenta algum

modelo/processo/framework/metodologia de Pentest, mas não fornece informações suficientes sobre seu uso.

• EC3. O estudo não contém algum tipo de avaliação para a demonstração de resultados, tais como: estudo de caso, experimentos ou exemplos de utilização.

3.6. Critérios de Avaliação de Qualidade A proposta dos critérios de qualidade (QA) é garantir a avaliação adequada dos estudos, como uma forma de mensurar a relevância de cada um deles. Os critérios de qualidades definidos são: QA1. O estudo apresenta uma contribuição ao tema de Pentests? QA2. Existe algum tipo de avaliação com análise/discussão em cima do uso dos modelos ou ferramentas de Pentest? QA3. O estudo descreve as ferramentas ou modelos utilizados?

Para cada uma das questões dos critérios de qualidade é utilizado o seguinte score: Y (sim) = 1; P (parcialmente) = 0.5, N (não) = 0. Assim, o score total (soma das três questões) pode resultar em: 0 ou 0.5 (limitado), 1 (regular), 1.5 (bom), 2 (muito bom) e 2.5 ou 3 (excelente).

Baseado nisso, a classificação tem como aspectos de avaliação: QA1. Y: a contribuição está explicitamente definida no estudo; P: a contribuição está implícita; N: a contribuição não pode ser identificada e não está claramente estabelecida; QA2. Y: o estudo tem explicitamente uma avaliação aplicada (por exemplo, um estudo de caso, um experimento, ou outro); P: a avaliação é um pequeno exemplo; N: nenhuma avaliação foi apresentada;

QA3. Y: as ferramentas ou modelos são claramente especificados; P: as ferramentas ou modelos são ligeiramente especificados; N: ferramentas ou modelos não podem ser identificados; 3.7. Processo de Seleção O processo de seleção é dividido em seis etapas, conforme demonstrado na Figura 3: Passo 1. Busca nas bases de dados. Inicialmente as strings de busca são geradas através das palavras-‐chave e seus sinônimos. Nesse sentido, a primeira seleção se dá baseadas nos critérios de inclusão e exclusão citados na seção 3.5. Passo 2. Eliminação de redundâncias. Como os resultados provêm de engines de buscas diferentes, aqueles estudos que são redundantes são eliminados e armazenados. Passo 3. Seleção intermediária. O título e o resumo de cada estudo retornado são lidos (quando necessário também são lidos introdução e conclusão). Passo 4. Seleção final. Nesta etapa todos os estudos são lidos de forma completa, e os mesmos critérios da etapa intermediária são aplicados. Passo 5. Eliminação de divergências. Em caso de conflitos ou dúvidas sobre os estudos, um terceiro especialista em Pentest lê os estudos e discute a inclusão do mesmo na seleção final; Passo 6. Avaliação da qualidade. Baseado nos critérios de qualidade citados anteriormente, a qualidade dos estudos lidos na etapa de seleção final é avaliada.

Figura 3. Processo de seleção dos estudos. 3.8. Estratégia de Extração dos Dados A extração de dados é projetada para coletar todas as informações necessárias para abordar as questões de pesquisa e os critérios de qualidade. Tais informações envolvem:

« Database: ACM, IEEE, Scopus and SpringerLink « Source: full reference conference, book, journal name « Title « Abstract « Authors « Year « Publication Type: Book Chapter, Conference, Journal, Symposium or Other « Document Type: Article, Collection, Proceeding, Periodical, Technical Report « Research Type: Empirical Study, Experimental Study, Industrial Experience, Proof

of Concepts, Opinion Papers or Theoretical « Contribution Type: Approach, Framework, Method, Methodology, Model,

Technique, Strategy or Tool « Tools: tools created or used in Pentest « Scenarios: scenarios that applying the Pentest process. « Models: models used in the Pentest process

3.9 Análise dos Dados Os dados foram tabulados da seguinte maneira:

• Identificar as ferramentas utilizadas em Pentest e suas características

(RQ1);

• Mapear os principais domínios de aplicação de Pentest (RQ2);

• Enumerar os estudos selecionados por modelos ou especificações (RQ3);

• Agregar os estudos primários selecionados pelo processo de Pentest, tipo de pesquisa e tipo de contribuição (RQ4).

4. CONDUÇÃO A condução deste SMS descreve sua realização no processo de busca baseado na string previamente definida. Tal condução foi iniciada em abril de 2015 e persistiu até maio de 2015, retornando 1019 artigos no total. Nesta seção são ainda apresentados os detalhes das etapas "Busca nas bases de dados" e "Avaliação da qualidade". 4.1. Busca nas bases de dados Os 1019 estudos retornados foram obtidos a partir da submissão da string de busca para as quatros bases de dados anteriormente citadas. Com a remoção dos 55 artigos duplicados, foram lidos o título e resumo de 964 artigos e selecionados 65 que tinham qualquer relação com algum critério de inclusão. Durante a quarta etapa todos os 65 artigos foram lidos e 3 foram descartados por não representarem correlação direta as contribuições. Dos 62 restantes, 12 foram descartados depois da avaliação de qualidade (passo 6). A Tabela II apresenta o total de estudos primários resultantes de cada base de dados, o número de estudos não duplicados, o número de estudos selecionados, a taxa de precisão e o índice de precisão. Tabela II. Engines de busca, estudos recuperados, não duplicados e selecionados Database Recuperados Não Duplic. Selecionados Taxa Prec. Índice Prec.

ACM DL 140 137 8 0.0571 0.1600 IEEE Xplore 500 492 32 0.0640 0.6400 SCOPUS 121 83 3 0.0247 0.0600 Springer Link 258 252 7 0.0271 0.1400 Total 1019 964 50

4.2. Avaliação da qualidade Os critérios de inclusão/exclusão citados anteriormente fornecem a base para a discussão sobre os critérios de avaliação de qualidade que são aplicados. Tais critérios tem como objetivo avaliar a confiabilidade dos estudos primários. A Tabela III apresenta a informação sobre os scores de qualidade dos estudos. Cada estudo é identificado por uma coluna ID e sua referência é apresentada na coluna Referência, assim como o ano de publicação. na coluna Ano. As colunas 1, 2 e 3 mostram os scores obtidos no Quality Assessment (QA). A coluna Sc mostra o score final para cada estudo enquanto a coluna Des descreve a classificação do estudo baseado no score. Como resultado final, é possível verificar que os estudos selecionados foram aqueles que obtiveram score mínimo de 1.5 pontos.

Tabela III. Scores dos estudos selecionados.

Legenda – Y: Sim, N: Não, P: Parcialmente, Sc: Score, Des: Descrição, G: Bom, V: Muito Bom, E: Excelente.

Estudos QA Qualidade Estudos QA Qualidade ID Referência Ano 1 2 3 Sc Des ID Referência Ano 1 2 3 Sc Des 01 [11] Austin 2013 Y Y Y 3.0 E 26 [36] Somorvsky 2012 Y Y Y 3.0 E

02 [12] Hsu 2008 P P P 1.5 G 27 [37] Garn 2014 Y Y Y 1.5 G 03 [13] Holm 2011 P Y N 1.5 G 28 [38] Line 2008 Y P P 2.0 V 04 [14] Sklavos 2012 Y P Y 2.5 E 29 [39] Mainka 2012 Y P Y 2.5 E 05 [15] Sarraute 2011 Y Y Y 3.0 E 30 [9] Geer 2002 Y Y Y 3.0 E 06 [16] Khoury 2011 P Y N 1.5 G 31 [40] Traore 2011 Y P N 1.5 G 07 [17] Antunes 2015 Y Y N 2.0 V 32 [41] Benkhelifa 2013 P P P 1.5 G 08 [18] Xu 2012 P P Y 2.0 V 33 [42] Salas 2014 Y Y Y 3.0 E 09 [19] Shen 2011 Y P Y 2.5 E 34 [43] Büchler 2012 Y Y Y 3.0 E 10 [20] Mendes 2011 P Y P 2.0 V 35 [44] Sandouka 2009 Y P P 2.0 V 11 [21] Fong 2008 Y Y P 2.5 E 36 [45] Liu 2012 Y Y Y 3.0 E 12 [22] Williams 2012 Y Y P 2.5 E 37 [46] Masood 2011 Y P Y 2.5 E 13 [23] Bou-‐harb 2014 P Y Y 2.5 E 38 [47] Igure 2008 Y Y P 2.5 E 14 [24] Kasinathan 2013 P P P 1.5 G 39 [48] Khoury 2011 Y P N 1.5 G 15 [25] Xing 2010 Y P Y 2.5 E 40 [49] Leibolt 2010 P P P 1.5 G 16 [26] Antunes 2009 Y Y P 2.5 E 41 [50] Fonseca 2010 Y P P 2.0 V 17 [27] Holik 2014 Y Y Y 3.0 E 42 [51] Jajodia 2005 P P Y 3.0 E 18 [28] Avramescu 2013 Y Y Y 3.0 E 43 [52] Blackwell 2014 Y Y Y 3.0 E 19 [29] Ridgewell 2013 P P P 1.5 G 44 [53] Prandini 2010 Y Y Y 3.0 E 20 [30] Walden 2008 P Y P 2.0 V 45 [54] Dimkov 2010 Y Y Y 2.0 V 21 [31] Mink 2006 P P P 1.5 G 46 [55] Stepien 2012 Y P Y 2.5 E 22 [32] Tondel 2008 P Y P 2.0 V 47 [56] Badawy 2013 P P P 1.5 G 23 [33] Armando 2010 Y P P 2.0 V 48 [57] Curphey 2006 P P P 1.5 G 24 [34] Dahl 2006 Y Y Y 3.0 E 49 [58] Huang 2005 P P P 1.5 G 25 [35] Mclaughlin 2010 Y Y Y 3.0 E 50 [59] Doupé 2010 P Y P 2.0 V

5. ANÁLISE DOS RESULTADOS 5.1 Esquemas de classificação De acordo com o processo do mapeamento sistemático, os modelos de classificação são obtidos através da atividade “Keywording Relevant Topics”. Tal atividade foi executada em dois passos: primeiramente leitura dos resumos (introdução e conclusão, quando necessário) e identificação de palavras-‐chave (keywords), conceitos e contexto da pesquisa que implica na contribuição dos artigos, e depois análise e combinação das palavras-‐chave para um entendimento mais detalhado para os diferentes artigos. Este segundo passo auxilia a definição de determinados aspectos para o processo do mapeamento, onde a partir desta atividade em questão foi possível delimitar as seguintes facetas: I) cenários de aplicação de Pentest, por exemplo, aplicações web, rede e protocolos de comunicação, bases de dados, e outros; II) tipo de pesquisa, por exemplo, empirical study, experimental study, industrial experience, opinion papers, proof of concept e theoretical; III) tipo de contribuição, por exemplo, ferramenta, framework, modelo, metodologia, estratégia, técnica ou abordagem; IV) modelos de Pentest e suas variações, por exemplo, OSSTMM, Owasp Testing Guide, ISSAF, entre outros. A Tabela IV descreve os tipos de pesquisa e suas descrições detalhadas, os demais itens são auto explicativos.

Tabela IV. Tipos de Pesquisa [5].

Category Description Experimental Study Techniques investigated are novel and have not yet been implemented

in practice. Techniques used are, for example, experiments, i.e., work done in the lab.

Empirical Study Techniques are implemented in practice and an evaluation of the technique is conducted. That means, it is shown how the technique is implemented in practice (solution implementation) and what are the consequences of the implementation in terms of benefits and drawbacks (implementation evaluation). This also includes to identify problems in industry.

Industrial Experience Experience papers explain on what and how something has been done in practice. It has to be the personal experience of the author.

Opinion Papers These papers express the personal opinion of somebody whether a certain technique is good or bad, or how things should been done. They do not rely on related work and research methodologies.

Proof of Concept A solution for a problem is proposed, the solution can be either novel or a significant extension of an existing technique. The potential benefits and the applicability of the solution is shown by a small example or a good line of argumentation.

Theoretical These papers sketch a new way of looking at existing aspects by structuring the field in form of a taxonomy or conceptual framework.

5.2 Mapeamento Nesta seção é realizada uma avaliação qualitativa da literatura em relação as questões de pesquisas apresentadas anteriormente. A Figura 4 apresenta um gráfico de bolha com a distribuição dos cenários de aplicação em relação ao seu ano de publicação, onde o tamanho da bolha descreve o número de estudos relacionados em cada intersecção dos eixos.

Figura 4. Bubble Plot da Distribuição dos Estudos por Cenário e por Ano.

Dos artigos analisados, percebe-‐se que a distribuição por ano ressalta o

quanto o tema de pesquisa é relativamente recente, uma vez que não foram determinados filtros em relação ao ano de publicação no processo de busca. Apenas um estudo apresenta uma diferença de mais de dez anos em relação a busca realizada, e o mesmo não foi descartado em virtude de ser caracterizado como um referencial primordial para este SMS. Além disso, os estudos com o contexto de aplicação de Pentests direcionados ao cenário de sistemas web podem ser identificados como emergentes e de relevância exponencial no âmbito da área.

Dessa forma, é igualmente possível verificar que grande parte dos

cenários de aplicação de Pentest tem uma distribuição direcionada principalmente a aplicações web e a ambientes de rede. A análise da Figura 4 está relacionada a questão de pesquisa RQ2, onde os domínios de aplicação de Pentest são alvo da mesma. Ainda neste sentido, tais cenários discutidos nos artigos selecionados descrevem e citam uma série de ferramentas que são

utilizadas diferentemente de acordo com cada contexto. Dessa forma, os experimentos/discussões que são relatados nos artigos, descrevendo ou não as ferramentas em questão, são variados principalmente em virtude do cenário de aplicação. A Figura 5, por sua vez, apresenta a relação do cenário com o tipo de contribuição e o tipo da pesquisa.

Figura 5. Bubble Plot da Distribuição dos Cenários por Tipo de Pesquisa e Contribuição.

A Figura 5 ilustra a relação dos tipos de pesquisa em contraponto ao tipo de contribuição para cada cenário de aplicação de Pentests. Duas análises são essenciais baseado em tal ilustração:

• Discussão em torno de metodologias para Pentest: 14 dos estudos

primários selecionados e analisados detém sua contribuição em torno de metodologias. Essa reflexão incita as discussões em torno da amplitude das metodologias existentes para a aplicação dos Pentests, principalmente a respeito do nível de profundidade e alvo das mesmas, uma vez que para determinados cenários torna-‐se interessante utilizar um modelo mais direcionado para cada processo de teste de segurança.

• Distribuição dos tipos de pesquisa: 34 estudos (68% do total) analisados são caracterizados como estudos empíricos. Essa característica, em geral, pode ser justificada em virtude da grande área na qual se encontra o tema de Testes de Penetração. Grande parte das pesquisas em Segurança da Informação, de um ponto de vista abrangente, tem seu direcionamento a este tipo de pesquisa.

6. AMEAÇAS A VALIDADE

As principais ameaças identificadas que podem comprometer a validade do SMS em Pentest são: Publication bias: refere-‐se possibilidade de alguns artigos não serem selecionados ou publicados porque os resultados da pesquisa ainda não fornecerem o resultado desejado, resultados de cunho confidencial, ou porque a pesquisa foi realizada em tópicos que não se encaixam nas conferências e revistas da área. Primary studies selection bias: em geral não se pode garantir que todos os estudos primários relevantes foram retornados durante o processo de pesquisa e durante a avaliação dos mesmos. Nesse sentido os critérios de qualidade estabelecidos, bem como a atribuição dos scores, visa mitigar tal ameaça. Unfamiliarity with other fields: a string de busca foi definida baseada na experiência e conhecimento dos autores, mas é necessário considerar que pode-‐se não ter completamente evitado a possibilidade de que alguns termos definidos na string de busca tenham sinônimos que não foram identificados.

7. DISCUSSÃO Nesta seção são apresentadas e discutidas as respostas das questões de pesquisa. 7.1. RQ1. Quais são as principais ferramentas utilizadas em Pentest? Depois da análise dos artigos selecionados, foram identificadas 72 ferramentas utilizadas em Pentest citadas ao longo dos estudos. Dentre as 72, 12 (doze) são categorizadas como ferramentas utilizadas para Static Analysis, que é uma técnica para análise de segurança tal como Pentest. Estas ferramentas, por sua vez, são contabilizadas em virtude da sua utilidade quanto a análise e identificação de vulnerabilidades em código, tarefa importante dentro do processo de Pentest.

Das outras 60 ferramentas identificadas, é possível perceber que a maioria tem seu foco de utilização para a tarefa de escaneamento de vulnerabilidades, tratando-‐se então de ferramentas utilizadas nas etapas iniciais de um Pentest. Ainda é possível ressaltar que ferramentas de monitoramento de tráfego e do processo de invasão fazem parte também de uma relevante parcela

dos estudos analisados, mesmo que em um proporção menor em relação aquelas destinadas a descoberta de vulnerabilidades.

Ao longo dos artigos analisados, 13 (treze) ferramentas são amplamente citadas, e por essa razão são tratadas de uma forma diferencial das demais. A Tabela V descreve as principais ferramentas utilizadas em Pentest, relacionando para cada ferramenta seu fabricante e descrição (uso e objetivo).

Tabela V. Principais ferramentas utilizadas em Pentest.

Ferramenta Fabricante Descrição

Acunetix WVS Acunetix Tool that automatically checks web applications for vulnerabilities such as SQL Injections, cross site scripting, arbitrary file creation/deletion, and weak password strength on authentication pages.

Burp Suite Portswigger An integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application's attack surface, through to finding and exploiting security vulnerabilities.

WebInspect HP An automated and configurable web application security and penetration testing tool that mimics real-‐world hacking techniques and attacks, enabling your customers to thoroughly analyse complex web applications and services for security vulnerabilities.

AppScan IBM A tool that enhances web application security and mobile application security, improves application security program management and strengthens regulatory compliance. By scanning your web and mobile applications prior to deployment, AppScan enables you to identify security vulnerabilities and generate reports and fix recommendations.

Metasploit Rapid7 A tool for developing and executing exploit code against a remote target

machine. Other important sub-‐projects include the Opcode Database, shellcode archive and related research.

Nessus Tenable Nessus is a remote security scanning tool, which scans a computer and raises an alert if it discovers any vulnerabilities that malicious hackers could use to gain access to any computer you have connected to a network.

NeXpose Rapid7 A vulnerability scanner which aims to support the entire vulnerability management lifecycle, including discovery, detection, verification, risk classification, impact analysis, reporting and mitigation.

Nikto CIRT An Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers.

Nmap -‐ A security scanner used to discover hosts and services on a computer network, thus creating a "map" of the network. To accomplish its goal, Nmap sends specially crafted packets to the target host and then analyzes the responses.

Paros -‐ A Java-‐based web proxy for assessing web application vulnerability. It supports editing/viewing HTTP/HTTPS messages on-‐the-‐fly to change items such as cookies and form fields.

QualysGuard Qualys A popular SaaS (software as a service) vulnerability management offering. It's web-‐based UI offers network discovery and mapping, asset prioritization, vulnerability assessment reporting and remediation tracking according to business risk.

WebScarab OWASP A web security application testing tool. It

serves as a proxy that intercepts and allows people to alter web browser web requests (both HTTP and HTTPS) and web server replies. WebScarab also may record traffic for further review.

Wireshark Wireshark A open source multi-‐platform network protocol analyzer. It allows you to examine data from a live network or from a capture file on disk. You can interactively browse the capture data, delving down into just the level of packet detail you need.

É necessário indicar que as informações detalhadas sobre as ferramentas identificadas não estão presentes na maioria dos artigos. Os estudos avaliados basicamente apresentam as contribuições relevantes e avaliações do uso de cada ferramenta dentro de contextos específicos juntamente ao processo de Pentest. Dessa forma, nós tivemos que procurar as características e documentação das ferramentas diretamente nos websites ou repositórios referentes, com o intuito de listar as características principais. 7.2. RQ2. Quais os cenários de execução de Pentest? Os resultados SMS mostram que o processo de Pentest é aplicado em diversos cenários específicos, que por sua vez podem ser brevemente generalizados para determinados contextos. Tais cenários, presentes nos estudos analisados, correspondem a: web-‐based applications and systems [11][16][18][21][28][30][33][37][42][45][46][49][53][56][57][58][59], web services [17][20][26][39][41], network protocols and devices [12][14][15][19][23][24][25][35][9][48][51], software and desktop applications [13][27][32][44], network game devices[29], SAML frameworks[36], physical penetration[54], operating system[55] and process control system[38]. A Figura 4 mostra que os diferentes cenários de execução de pentest apresentam certa diversidade em relação ao número de estudos referentes, uma vez que web-‐based applications e systems e network protocols and devices detém a maior parte do direcionamento das pesquisas. 7.3. RQ3. Quais os modelos para ferramentas de Pentest? Assim como os cenários de execução de Pentest, os modelos apresentam certa diversidade nos estudos analisados. No que se refere a modelos de teste de segurança, os resultados obtidos permitem uma análise dividida em metodologias e categorias dos modelos de testes de segurança.

As categorias descrevem, com base na taxonomia do processo de teste, como é a base de informações possuída para a execução do mesmo. O modelo dos testes é categorizado então em white-‐box, gray-‐box e black-‐box. White-‐box descreve o modelo de teste no qual o tester detém o completo conhecimento sobre a infraestrutura a ser testada, como discutido em [34] e [45]. Black-‐box, em contraponto, assume que não há nenhum conhecimento a priori sobre o ambiente o qual se quer aplicar o teste. Nota-‐se que a maioria dos trabalhos, principalmente em torno de ferramentas de descoberta de vulnerabilidade, executam testes do tipo black-‐box, como em [17], [48] e [59], por exemplo. Já os testes que são do tipo gray-‐box representam o meio termo entre os categorizados anteriormente, onde a quantidade de informações a respeito do alvo não são totais mas também não são inexistentes. Entre os artigos analisados, [28] traz um exemplo de aplicação de teste gray-‐box.

Essa categorização implica diretamente no processo de Pentest, independente da metodologia a qual será utilizada. Nas pesquisas analisadas detalhadamente, foi possível identificar claramente as indicações e citações as seguintes metodologias, frameworks e modelos de teste de segurança: OSSTMM (Open Source Security Testing Methodology Manual) [22][27][45][53][54], ISSAF (Information Systems Security Assessment Framework) [53], PTES (Penetration Testing Execution Standard) [45], NIST (National Institute of Standards and Technology) Guidelines [53] e OWASP Testing Guide [22][27][45]. No que diz respeito a classificação mais abrangente dos modelos, [1] define três abordagens para pentesting: Exploratory Manual Pentest, Automated Pentest e Systematic Manual Pentest. 7.3.1. OSSTMM

OSSTMM [60] é a metodologia que detém um padrão internacional para testes de segurança, mantida pela ISECOM (Institute for Security and Open Methodologies). Suas definições são consituídas a partir do escopo, que representa todo o ambiente de segurança operacional possível para qualquer interação com qualquer ativo. Este escopo é composto por três classes: COMSEC (Communications Security Channel), PHYSSEC (Physical Security Channel) e SPECSEC (Spectrum Security Channel). Essas classes são divididas em cinco canais antes de serem usados pelo tester:

• Humano. Trata todos os elementos humanos de comunicação onde a

interação pode ser tanto física como psicológica. • Físico. Lida com todos elementos tangíveis de segurança de natureza

física ou não-‐eletrônica. Trata os elementos onde a interação requer esforços físicos ou uma energia de transmissão para manipular.

• Wireless. Trata todas as comunicações eletrônicas, sinais e frequências que tem um espectro eletromagnético conhecido.

• Telecomunicações. Compreende todas as redes de telecomunicações, digitais ou analógicas, onde as interações ocorrem através das linhas de rede telefônicas.

• Redes de dados. Representa todos sistemas eletrônicos e redes de dados onde as interações ocorrem através de cabos estabelecidos e linhas de rede com fio.

Dentro desses canais são descritos dezessete módulos para suas análises. Esses módulos, por sua vez, são divididos em quatro fases: fase Regulatória, fase de Definições, fase de Informações e fase de Teste de Controles Interativos. A fase Regulatória envolve os módulos de Revisão de Estado, Logística e Verificação de Detecção Ativa e representa a direção a ser tomada, o background que o tester deve ter antes de realizar a auditoria, os requisitos de auditoria, o escopo e suas restrições. Já a fase de Definição é a principal em todo o processo, pois é responsável pela definição do escopo do teste. Na maioria das vezes, definir o escopo é uma tarefa complexa já que não é evidente o que o tester precisa procurar, quais as consequências em encontrar erros e que tipo de testes ele deve executar (quais são obrigatórios e quais são opcionais). A composição desta fase é constituída pelos módulos Visibilidade de Auditoria, Verificação de Acesso, Verificação de Confiança e Verificação de Controles. A fase de Informação é a fase responsável por organizar o processo de coleta de informações, sendo composta pelos módulos de Verificação do Processo, Verificação de Configuração, Validação de Propriedade, Revisão da Segregação, Verificação da Exposição e Inteligência Competitiva. Por fim, a fase de Teste de Controles Interativos descreve os testes práticos reais realizados sobre as informações coletadas. Essa fase é composta pelos módulos Verificação de Quarentena, Auditoria de Privilégios, Validação de Sobrevivência, Alerta e Revisão de Logs.

Existem diferentes formas que um teste de segurança pode ser classificado considerando a metodologia OSSTMM, divididas em seis padrões de tipos (conforme ilustrado na Figura 6):

Figura 6. Tipos de teste de segurança [60].

• Blind: o teste é feito sem nenhum conhecimento prévio do alvo sobre

suas defesas, ativos ou canais. O alvo é preparado para a auditoria, cujo objetivo principal pode ser considerado como o teste das habilidades do analista. Por esta razão, em um teste do tipo Blind, a amplitude e a profundidade estão relacionadas ao conhecimento do analista. Nas classes COMSEC e SPECSEC, este teste pode ser chamado de Ethical Hacking, enquanto na classe PHYSSEC, esse comportamento é categorizado como War Gaming.

• Double blind: similar ao teste Blind, o Double Blind descreve um teste onde além do tester não ter nenhum conhecimento prévio sobre o alvo, o alvo também não é notificado sobre a auditoria, os canais a serem testados ou os vetores de teste. Double Blind é um teste mais conhecido como Penetration Test ou Teste Black Box.

• Gray box: o teste é realizado com conhecimento limitado das defesas do alvo e seus ativos, porém com completo conhecimento de seus canais. O alvo é preparado para a auditoria, sabendo todo o processo que será auditado. Em geral a natureza deste teste preza pela eficiência e é mais frequente que seja iniciado pelo alvo para um processo de auto-‐avaliação. O teste do tipo Gray Box é também conhecido como Teste de Vulnerabilidade.

• Double gray box: seguindo a linha do teste Gray Box, o Double Gray Box detém a sua diferença no fato de que o alvo é notificado com antecedência apenas sobre o escopo e o tempo de duração da auditoria, mas não detém conhecimento sobre os canais testados ou vetores de teste. Neste tipo de teste, são verificados a perícia do tester e também a preparação do alvo

OSSTMM 3 – The Open Source Security Testing Methodology Manual

2.3 Common Test Types

These six types differ based on the amount of information the tester knows about the targets, what the target knows about the tester or expects from the test, and the legitimacy of the test. Some tests will test the tester’s skill more than actually testing the security of a target.

Do note when reporting the audit, there is often a requirement to identify exactly the type of audit performed. Too often, audits based on different test types are compared to track the delta (deviations) from an established baseline of the scope. If the precise test type is not available to a third-party reviewer or regulator, the audit itself should be considered a Blind test, which is one with the least merit towards a thorough security test.

Creative Commons 3.0 Attribution-Non-Commercial-NoDerivs 2010, ISECOM, www.isecom.org, www.osstmm.org

36 Official OSSTMM Certifications: www.opsa.org, www.opst.org, www.opse.org, www.owse.org, www.trustanalyst.org

para as ações desconhecidas no processo de teste. Este teste também é conhecido como Teste White Box.

• Tandem: neste tipo de teste, tanto o tester como o alvo são preparados para a auditoria e detém completo conhecimento sobre os detalhes da mesma, desconsiderando a avaliação do quanto o alvo está preparado para ações de teste e comportamentos desconhecidos do ponto de vista de segurança. Também definido por Teste Cristal Box ou Auditoria In-‐House.

• Reversal: de posse do pleno conhecimento do tester em relação ao alvo, e o alvo sem nenhum conhecimento sobre o que, como e quando será o teste, o teste Reversal objetiva avaliar a preparação do alvo para as ações e comportamentos desconhecidos em relação a sua segurança. Esse teste é mais conhecido como Exercício Red Team.

A metodologia também direciona suas preocupações em relação aos tipos

de erros que podem ser encontrados, considerando que um teste de segurança não avalia a soma desses erros, mas sim a sua contabilização. Os erros são divididos em doze tipos: false positive, false negative, gray positive, gray negative, specter, indiscretion, entropy error, falsification, sampling error, constraint, propagation e human error.

Para mensurar os resultados dos testes de segurança a metodologia OSSTMM utiliza a ideia de RAV (Risk Assessment Values). A função básica do RAV é analisar os resultados do teste e computar o valor atual da segurança baseado em três fatores: segurança operacional, controle de perda e limitações. O valor final de segurança é conhecido como RAV score. Usando o RAV score, um auditor pode facilmente extrair e definir marcos baseado no estado atual da segurança para realizar uma melhor proteção. De uma perspectiva de negócio, RAV pode otimizar a quantia de investimento requerido na segurança e pode ajudar a justificativa de investimentos em soluções mais efetivas.

Com base em tantos detalhes no que diz respeito às especificações do modelo, a metodologia OSSTMM tornou-‐se uma das mais completas e robustas. Um dos diferencias da mesma é a inclusão de fatores humanos como parte dos testes, respeitando a máxima de que o ser humano representa um potencial perigo para a segurança das informações. Por outro lado, cabe a ressalva de que tais fatores representam uma mínima parte da metodologia e tem pouca documentação e descrição a respeito. Mesmo com a sua completude, a metodologia OSSTMM desconsidera vagamente itens como hipóteses induzidas e diagramas claros e intuitivos [61]. Tais itens impactam, respectivamente, em uma diminuição de descobertas alternativas de vulnerabilidades e em um maior trabalho de interpretação dos inúmeros módulos que constituem o modelo. Da mesma forma, não são especificadas explicitamente as ferramentas a serem

usadas durante os testes, porém a metodologia detalha os métodos utilizados para avaliar de modo consistente superfície de ataque em relação ao contexto que está sendo analisado. Aliado a isso, no âmbito de testes de penetração, uma boa prática é o registro no relatório das atividades, ações e resultados ao fim de cada etapa, em virtude do processo de teste ser representativamente longo. Na presente metodologia são oferecidos templates para o preenchimento dos relatórios, porém esses templates seguem um processo de leitura linear [62]. Assim, para ter o conhecimento sobre a segurança do sistema e realizar as devidas análises é preciso passar por todo o relatório. 7.3.2. ISSAF

A representação da metodologia ISSAF [63] se dá como um framework capaz de modelar os requisitos de controle internos para a segurança da informação, direcionado para avaliar a segurança de redes, sistemas e aplicações. Integrando o framework com um regular ciclo de vida de negócio, é possível fornecer acurácia, completude e eficácia requeridos para completar os requisitos de teste de segurança em uma organização. Com isso, subentende-‐se os focos da metodologia ISSAF: a área técnica, que estabelece o conjunto de regras e procedimentos para seguir e criar um processo adequado de avaliação de segurança, e a área gerencial, que realiza os compromissos com o gerenciamento e melhores práticas que devem ser seguidas ao longo do processo de teste. Sua concepção é estruturada em três grandes áreas de execução: planejamento e preparação, avaliação e relatório, limpeza e destruição de artefatos. A fase de Planejamento e Preparação trata os passos necessários para definir o ambiente de teste, seja no planejamento e preparação das ferramentas de teste, contratos e aspectos legais, definição da equipe de trabalho, prazos, requisitos e estrutura dos relatórios finais. Já a fase de Avaliação representa o centro da metodologia, onde o teste de penetração é realmente executado. A mesma é composta das seguintes atividades:

1. Coleta de informações: Consiste em coletar toda a informação possível sobre o alvo em questão a ser avaliado, auxiliando o avaliador a realizar a tarefa da maneira mais completa possível. Na maioria dos casos a principal e talvez única fonte de informação inicial é a Internet. Esta etapa é muito importante para o início do Pentest, no qual o processo de coleta interfere diretamente na completude do mesmo. Em geral, o objetivo desta atividade é explorar todas as vias possíveis de ataque dando uma visão completa do alvo.

2. Mapeamento da rede: Informações específicas da rede, baseado também na atividade de coleta, são mapeadas para produzir a topologia de rede do alvo. Existem diversas ferramentas que podem ser utilizadas para auxiliar

a descoberta e o mapeamento da rede e dos hosts envolvidos no teste. Essa atividade, resumidamente, foca seus esforços nos aspectos técnicos de descoberta de informações. Durante a enumeração e o mapeamento de rede o tester busca identificar todos os hosts vivos, sistemas operacionais envolvidos, firewalls, sistemas de detecção de intrusão, servidores e serviços, dispositivos de perímetro, roteamento e topologia geral rede (layout físico).

3. Identificação de vulnerabilidades: Esta atividade, de posse dos dados enumerados e da topologia de rede, busca encontrar falhas dentro da rede, servidores, serviços e outros recursos. A partir da enumeração e mapeamento de rede o tester busca verificar fatores como a precisão na identificação de serviços e sistemas operacionais. Com essa informação, o tester está habilitado a listar hosts e servidores vulneráveis. O objetivo desta etapa é usar as informações coletadas para fazer uma avaliação técnica atualizada sobre a existência de vulnerabilidades. Esta atividade é realizada combinando versões de serviços vulneráveis com exploits conhecidos e teóricos, percorrendo a rede em diversas direções, testando webservices, localizando senhas fracas e contas e escalando privilégios.

4. Penetração: Prova as vulnerabilidades e exploits que o tester identificou anteriormente.

5. Acesso e Escalada de Privilégio: Esta atividade é um advento de quando o tester ganhou algum acesso no alvo através da execução das atividades anteriores e assim pode realizar a escalada de privilégio. Este privilégio é categorizado como compromise, final compromise, least privilege ou intermediate privileges.

6. Enumeração: Uma vez que o tester ganhou o acesso e os privilégios, são executados, por exemplo: ataques a senhas, monitoramento e análise de tráfego, coleta de cookies, coleta de endereços de e-‐mail, identificação de rotas na rede e mapeamento de redes internas.

7. Comprometer usuários remotos: O tester deve tentar comprometer os usuários remotos, tele-‐comutadores e sites remotos.

8. Manutenção de acesso: O tester precisa reter os links de comunicação com a rede alvo. Essa comunicação, por sua vez, é interessante que seja através de um canal secreto (covert channel) para diminuir as chances de detecção.

9. Cobrindo rastros: O principal objetivo desta atividade é esconder ferramentas/exploits usados durante o comprometimento do alvo.

Por fim, a fase de Relatório, Limpeza e Destruição de Artefatos é

responsável pelo processo de pós-‐invasão do teste. O tester escreve um relatório completo e destrói os artefatos construídos durante a fase de Avaliação.

A metodologia ISSAF possui ampla documentação sobre a sua estrutura, e apresenta como uma das principais vantagens a criação de uma conexão clara entre as tarefas do Pentest e as ferramentas utilizadas. Da mesma forma, a ordem na qual a metodologia descreve o processo do Pentest é otimizada para ajudar o tester na execução completa e correta do teste, evitando erros comumente associados com estratégias de ataques selecionados aleatoriamente [61]. Pelo viés de limitações, ressalta-‐se a falta de melhores orientações na elaboração de relatórios, que não é bem definida e possui pontos que deveriam ser atualizados. Juntamente a isso, o fato do fluxo de controle ser one-‐way desconsidera hipóteses que podem melhorar o procedimento do teste uma vez que o tester já descobriu algumas vulnerabilidades, assim como o que acontece na metodologia OSSTMM.

7.3.3. PTES

Com foco em aspectos técnicos, a metodologia PTES [64] detalha instruções de como executar as tarefas que são requeridas para testar precisamente o estado da segurança em um ambiente. A intenção do modelo é não estabelecer padrões engessados para um teste de penetração, e a comunidade de analistas e profissionais de segurança responsável por sua criação trata a ideia de que as diretrizes para o processo de avaliação da segurança de um ambiente devem ser de fácil compreensão para as organizações. Por essa razão, as diretrizes técnicas ajudam a definir procedimentos a serem seguidos durante um Pentest, fazendo com que a metodologia forneça um estrutura base para iniciar e conduzir um teste de segurança, além de possuir gráficos bem organizados e uma série de métodos incluídos. A estrutura da metodologia é composta por sete fases:

• Pre-‐engagement interactions: apresenta o planejamento de ferramentas

e técnicas que serão utilizadas no Pentest. • Intelligence gathering: fornece um padrão destinado ao processo de

reconhecimento do alvo em questão. • Threat modeling: define a modelagem de ameaças para que o Pentest

tenha seu direcionamento realizado de maneira correta. • Vulnerability analysis: trata o processo de descoberta de falhas e

vulnerabilidades de um sistema ou ambiente. • Exploitation: foca em estabelecer o acesso a um sistema ou recurso

passando pelas restrições de segurança. • Post-‐exploitation: determina o valor de uma máquina compromissada e

mantém o controle da mesma para uma futura utilização. • Reporting: define os critérios basilares para o relatório do teste.

Em resumo, PTES é um framework projetado para fornecer às empresas e os prestadores de serviços de segurança uma linguagem e escopo comuns para a realização de Pentest. Tal tarefa está relacionada principalmente a realização de padrões concisos para medir testes de penetração e oferecer orientações de como o teste precisa ser realizado aos clientes. A forma como são fornecidas as diretrizes de execução do processo representa a principal vantagem do modelo em relação aos demais, aliado ao fato de que o mesmo considera o conhecimento do tester como aspecto primordial ao longo das fases. Dessa forma, a construção da metodologia por parte da comunidade de experts na área de segurança fornece uma abordagem diferenciada e diretamente ligada aos critérios técnicos de um teste de segurança [65]. Em contraponto, isso impacta vagamente nos aspectos de negócio, tornando-‐se uma fator limitante para a completude de um Pentest. Em relação a documentação da metodologia, a citação do uso de ferramentas e técnicas para cada uma das fases é descrita de maneira extremamente robusta, ao passo que orientações em relação à medidas de eficiência, elaboração dos relatórios e tratamento de caminhos alternativos na descoberta de vulnerabilidades, por exemplo, poderiam ser melhor definidas.

7.3.4. NIST Guidelines

A metodologia proposta pela NIST [66] foi inicialmente introduzida como GNST (Guideline on Network Security Testing), reproduzida na publicação especial 800-‐42, e a sua última versão continuada é apresentada na publicação especial 800-‐15 como Technical Guide to Information Security Testing and Assessment. A elaboração deste modelo é considerada como a primeira que introduz um processo detalhado e formal para a escrita de relatórios, e da mesma forma em relação a trabalho e processo que lida com hipóteses induzidas. Basicamente, sua estrutura segue quatro etapas principais: Planejamento, onde o sistema é analisado para encontrar os alvos de teste mais interessantes; Descoberta, onde o tester procura as vulnerabilidades no sistema; Ataque, onde o tester verifica se as vulnerabilidades encontradas podem ser exploradas; e Relatório, onde cada resultado proveniente das ações realizadas na etapa anterior é reportado.

Adicionalmente, cada passo executado possui um vetor de entrada, que representa o conjunto de dados a serem analisados, e um vetor de saída, que representa o conjunto completo de resultados derivados das ações executadas. Em seu fluxo, a seta orientada entre ataque e descoberta é a primeira tentativa de representação de hipóteses induzidas. A ideia principal de hipóteses induzidas se baseia nos artefatos: Vetor Alvo (TV), Vetor de Vulnerabilidade (VV) e Vetor de Ataque (AV), que representam respectivamente: o conjunto de alvo com investigação em andamento, conjunto de vulnerabilidade conhecidas e o conjunto de ataque relevantes.

Além do fato de considerar hipóteses induzidas, outra característica

positiva da metodologia é a forma como a mesma orienta o tester na elaboração dos relatórios. De acordo com as melhores práticas, a metodologia sugere escrever um relatório passo-‐a-‐passo, onde o tester relata suas descobertas depois da fase de planejamento e depois de cada ataque (realizado com sucesso ou não), descrevendo as vulnerabilidades que puderam ou não ser exploradas. Em compensação a isso, a metodologia não provê templates e orientações para a escrita dos relatórios finais [61]. Da mesma forma, cabe ressaltar a maneira como é construído o vetor de vulnerabilidade, onde apenas uma parte dos problemas encontrados durante a primeira fase originam vulnerabilidades em potencial. Em paralelo a isso, não fazem parte do relatório aqueles problemas que não listam falhas, e tal prática deve ser reconsiderada: todos os problemas encontrados devem ser levados em conta como descobertas interessantes e então, devem ser documentados pois posteriormente podem vir a serem riscos relevantes. Por fim, a forma utilizada pela norma para explicitar as suas definições e conceitos pode ser considerada uma limitação no que diz respeito ao entendimento da mesma, uma vez que sua compreensão sobre o que, onde, porque e como o processo de teste será realizado não é completamente claro [66]. 7.3.5. OWASP Testing Guide

A metodologia proposta no OWASP Testing Guide é um advento consolidado de todos os estudos que a comunidade OWASP realiza. Sua concepção é guiada pela ideia norteadora de tornar softwares seguros uma realidade, e por essa razão percebe-‐se que suas diretrizes são direcionadas a testes de segurança em softwares e aplicações web. Na grande maioria das organizações voltadas a desenvolvimento de software, as preocupações com segurança não fazem parte do processo de desenvolvimento padrão e, por muitas vezes, também não detém importância para as mesmas. A metodologia, então, idealiza o uso de testes de segurança como forma de conscientização e estrutura-‐se com base em outros projetos providos pela própria OWASP como o Code Review Guide e Development Guide. As orientações da metodologia disposta no OWASP Testing Guide são organizadas em três grandes blocos: a etapa introdutória que trata os pré-‐requisitos para testar as aplicações web e também o escopo do teste, a etapa intermediária que apresenta o OWASP Testing Framework e suas tarefas e técnicas relacionadas as diversas fases do ciclo de vida de desenvolvimento de software, e a etapa conclusiva que descreve como as vulnerabilidades são testadas através da inspeção de código e dos testes de penetração.

No contexto de aplicações web, a metodologia considera Pentest a técnica para testar uma aplicação em execução, de maneira remota, para encontrar vulnerabilidades de segurança sem ter o conhecimento sobre os aspectos inerente ao funcionamento da aplicação. Nesse sentido, ferramentas automatizadas de Pentest tem baixa eficácia no âmbito de aplicações web, uma vez que tais aplicações são constituídas de maneira um tanto quanto individual, fazendo com que a automatização não seja interessante. Por outro lado, comparando com as atividades de revisão de código, os testes de penetração não exigem tanto conhecimento do tester e também são mais rápidos.

A representatividade dos testes de segurança no workflow da metodologia é relativamente pequena, ao passo que é bem detalhada. Dessa forma, os principais conceitos e atividades relacionados aos testes são concisamente bem escritos no documento, fornecendo uma excelente compreensão. Mesmo assim, a ocupação propriamente dita do teste de penetração neste workflow é destinada somente na etapa de deployment, sendo apenas um item entre os dezoito que o constituem.

Em geral, a metodologia apresenta-‐se como a melhor alternativa para testes de penetração em aplicações web. Isso justifica-‐se pela forma como são apresentadas as ferramentas, soluções, técnicas a atividades para toda a cobertura do processo de teste. Além disso, são apresentados possíveis resultados esperados e as soluções a serem tratadas, devidamente divididos e bem descritos graficamente. Portanto, quando considerado meio de validação de segurança de uma estrutura web, a metodologia OWASP Testing Guide fornece uma avaliação detalhada de tecnologias específicas, onde suas orientações possibilitam uma visão mais ampla e colaborativa auxiliando o tester na escolha do melhor procedimento a ser tomado. 7.3.5. Avaliação das metodologias

A avaliação das metodologias para testes pode ser construída de diversas maneiras, mas necessita de critérios base para tal. Esta pesquisa é voltada especificamente para modelos de Pentest, e entre as metodologias avaliadas, somente a PTES é diretamente direcionada para testes de penetração, enquanto as demais englobam testes de segurança em geral. Contudo, as outras metodologias citadas possibilitam que o foco da atividade seja conforme um teste de penetração, mas não são delineadas para isto. A Figura 7 exemplifica essa afirmação ilustrando a comparação de atuação da metodologia OSSTMM em relação a outros tipos de teste de segurança.

Figura 7. Comparativo entre OSSTMM e outros tipos de teste de segurança [60]. A relação do comparativo citado pela Figura 7 é direcionada aos fatores

acurácia e completude. Dessa forma, subentende-‐se por exemplo que Pentest é um tipo de teste voltado a uma avaliação precisa de um determinado ponto em um sistema ou rede, e por sua vez não tem objetivo de avaliar toda a segurança do alvo. De acordo com a documentação apresentada em [60], os tipos de teste também podem ser discutidos em consideração aos aspectos custo e tempo, conforme ilustrado na Figura 8.

Figura 8. Tipos de teste considerando custo x tempo [60].

A atuação dos tipos de teste de acordo com custo e tempo delimita as

definições de cada um dos mesmos da seguinte maneira:

2.1. OSSTMM

Figure 2.1.: OSSTMM comparison with common security tests (from [8])

that is well in line with our findings from the previous chapter as it will also apply toCI.An important aspect of the OSSTMM is the compliance with general security policies.

The methodology is developed taking into account major legislation and regulations.Furthermore, OSSTMM defines three di↵erent types of compliance and a set of rules todeal with all of them. The three types of compliance defined in the methodology are:

Legislation: enforces the security test to be compliant with region/country legis-lation. The lack of this requirement could lead to criminal charges.

Regulation: enforces the security test to be performed accordingly to standardregulation within industry sector. A failure in this task could lead to a dismissalof the company from the group.

Policy: enforces the security test to be done according to business and organizationpolicies. Violation could cause a dismissal of the responsible from the company.

OSSTMM provides a list of national and international regulations already proved tobe compliant to the proposed methodology.

FP7-SEC-285477-CRISALIS 13

OSSTMM 2.1. - The Open Source Security Testing Methodology Manual 23 August 2003

14

Copyright 2000-2003 Peter V. Herzog, ISECOM – The Institute for Security and Open Methodologies – www.isecom.org - www.osstmm.org ISECOM is the OSSTMM Professional Security Tester (OPST) and OSSTMM Professional Security Analyst (OPSA) certification authority.

time

cost Vulnerability Scanning

Security Scanning

Ethical Hacking

Penetration Testing

Security Auditing

3 6

5

1

2

7 Posture Assessment & Security Testing

Risk Assessment 4

For clarity, ISECOM applies the following terms to types of system and network security testing as based on time and cost for Internet Security Testing:

1. Vulnerability Scanning refers generally to automated checks for known vulnerabilities against a system or systems in a network.

2. Security Scanning refers generally to vulnerability scans which include manual false positive verification,

network weakness identification, and customized, professional analysis.

3. Penetration Testing refers generally to a goal-oriented project of which the goal is the trophy and includes gaining privileged access by pre-conditional means.

4. Risk Assessment refers generally to security analysis through interview and mid-level research which

includes business justification, legal justifications, and industry specific justifications.

5. Security Auditing refers generally to a hands-on, privileged security inspection of the OS and Applications of a system or systems within a network or networks.

6. Ethical Hacking refers generally to a penetration test of which the goal is to discover trophies throughout

the network within the predetermined project time limit.

7. Security Testing and it’s military equivalent, the Posture Assessment, is a project-oriented risk assessment of systems and networks through the application of professional analysis on a security scan where penetration is often used to confirm false positives and false negatives as project time allows.

1. Vulnerability Scanning (Escaneamento de Vulnerabilidade): refere-‐se

geralmente a verificações automáticos para vulnerabilidades conhecidas contra um sistema de uma rede.

2. Security Scanning (Escaneamento de Segurança): refere-‐se geralmente a varreduras de vulnerabilidades que incluem verificação manual de falsos positivos, identificação de fraqueza da rede e análise customizada.

3. Penetration Testing (Teste de Invasão): refere-‐se geralmente a um projeto orientada a um objetivo no qual este objetivo é o direcionamento do teste.

4. Risk Assessment (Avaliação de Risco): refere-‐se geralmente a análise de segurança por meio de entrevista e de pesquisa que inclui justificativa de negócios, as justificações legais e justificativas específicas da indústria.

5. Security Auditing (Auditoria de Segurança): refere-‐se geralmente a uma inspeção hands-‐on de segurança do sistema operacional e aplicativos de um ou mais sistemas dentro de uma rede.

6. Ethical Hacking: refere-‐se geralmente a um teste de penetração de que o objetivo é atingir os objetivos dentro do prazo pré-‐determinado projeto.

7. Security Testing (Teste de Segurança): é uma avaliação de riscos dos sistemas e redes através da aplicação de análise profissional em uma verificação de segurança onde a penetração é muitas vezes usada para confirmar falsos positivos e falsos negativos de acordo com o tempo de projeto permite. Com base nessas informações, a avaliação das metodologias é baseada

em algumas características descritas a seguir. A Figura 9 apresenta visualmente o quadro comparativo entre as metodologias discutidas neste SMS.

Figura 9. Comparativo entre modelos para Pentest.

De início, um dos critérios considerado importante para um teste de

segurança é a abrangência, que neste trabalho diz respeito ao alcance do teste em relação aos possíveis cenários. As metodologias OSSTMM, ISSAF, PTES e NIST são facilmente integradas e podem ser adequadas ao contexto de aplicações e sistemas operacionais, banco de dados, avaliações de segurança física e aplicações web. Contudo, o modelo OWASP Testing Guide tem seu foco precisamente definido: serviços e aplicações web. Dessa forma, considera-‐se que, para um modelo robusto de teste de penetração, isso representa uma limitação.

A possibilidade de integrar meios, itens e direções adicionais ao teste de segurança a partir dos resultados obtidos em cada etapa ou fase da metodologia, é uma característica importante no contexto atual de verificações de segurança. Nesse sentido, mesmo que uma definição estática dos planos e passos a serem seguidos seja um requisito primordial, essa flexibilidade de novos recursos torna os modelos mais interessantes. Para essa característica, o modelo fornecido pela NIST apresenta uma conjuntura interessante ao permitir que o tester tenha

maior dinamicidade ao longo do teste, podendo considerar e reavaliar suas ações de posse dos artefatos obtidos a cada atividade. Em contraponto, pode-‐se considerar que as metodologias OSSTMM ISSAF e OWASP Testing Guide, ao mesmo tempo que são extremamente consolidadas e robustas, limitam tal flexibilidade por tratarem os cenários de execução dos testes de maneira concisa e detalhada. Assim, alinha-‐se esse raciocínio com a ideia de que a escolha por mais minúcias em cada etapa do teste é inversamente proporcional a flexibilidade do modelo.

Ao definir detalhadamente os aspectos e conceitos norteadores para o processo de teste, o modelo pode até limitar a flexibilidade, mas incrementa sua qualidade no quesito modelagem. Esses conceitos-‐chave facilitam o tester na sua atividade de modelar todo o fluxo de ações do teste, além de modelar o sistema e ambiente alvo. Isso ratifica um ponto crucial em testes de segurança, que é a eliminação de possíveis ambiguidades no que diz respeito a cada passo subsequente a ser realizado. Para tal característica, os modelos OSSTMM, OWASP Testing Guide e PTES cumprem precisamente essa completude, principalmente pela forma com que abordam a etapa de planejamento do seu processo de teste. A metodologia ISSAF trata rigorosamente esse quesito, sendo a parte principal das atividades iniciais do teste responsável pelo sucesso na identificação de vulnerabilidades.

Evitar as possíveis ambiguidades através de conceitos bem definidos não deve impactar no fator adaptação. A possibilidade de adaptar o modelo e suas ações mediante as variações dos sistemas e ambientes a serem testados fornece uma ampla gama de pontos positivos ao fluxo do teste. Dentre esses pontos, a escolha dos tipos de teste, juntamente com o plano e definição de escopo (mediante análise do alvo), são atividades que podem sofrer alteração e adequação. No critério adaptação a metodologia OSSTMM detém, em seu processo de delimitação de atividades, maior possibilidade em relação a possíveis variações do alvo. De forma adversa, a metodologia PTES apresenta certa limitação por não detalhar concisamente tais adaptações como alternativa.

Todo o conjunto de aspectos definidos em um teste de segurança deve ser devidamente planejado de maneira prévia. Assim, o planejamento é a característica que trata o suporte fornecido ao tester para a definição das fases, execução das atividades, pré-‐requisitos para continuação e andamento do teste, escolha das ferramentas a serem utilizadas e também o retorno esperado para cada subatividade dentro do teste. Uma excelente referência nessa característica é a metodologia PTES, que descreve atentamente todo o planejamento que deve ser realizado, além de instituir nessa descrição todo o conjunto de ferramentas para cada etapa, contendo inclusive as formas de execução das mesmas. Apenas

os modelos OSSTMM e NIST contrariam levemente essa construção, já que optam por maior amplitude e flexibilidade.

Por fim, é possível considerar também a documentação como parte das características principais da constituição de um modelo de teste. Todos os modelos possuem documentos detalhados e fortemente delimitados, com divisões e sequência facilmente entendíveis. Somente o modelo PTES não prima por uma construção textual tão completa e com explicações verdadeiramente detalhadas sobre cada processo e atividade. Por este razão, é o único dos modelos que não atende completamente tal característica. 7.4. RQ4. Quais os principais desafios em Pentest? A relação entre os cenários de execução, ferramentas e modelos fornece um nível de abstração interessante para a ideia em torno dos desafios em Pentest. Um dos principais problemas discutidos em alguns dos estudos analisados é voltado a eficiência no processo de descoberta de vulnerabilidades, independente do contexto de aplicação do Pentest. Aliado a isso, pode-‐se delimitar também que outro grande desafio da área de pesquisa é fornecer modelos e ferramentas adequadas para assegurar níveis de segurança cada vez mais elevados para os cenários alvo. Ambos desafios estão relacionados as problemas como: complexidade de ataques, surgimento frequente de novas vulnerabilidades e variação da aplicabilidade do Pentest para cada contexto alvo.

A ideia de ferramentas e modelos automatizados corrobora com essa afirmação, uma vez que os estudos selecionados discutem amplamente sobre o processo de automatização tanto para evitar problemas de viés do tester quanto para acelerar a descoberta de vulnerabilidades e geração de avaliações sobre as mesmas.

A formalização de metodologias/modelos disseminados na comunidade de segurança provê cada vez mais a robustez necessária para as melhores práticas em Pentest. Contudo, outro desafio está relacionado justamente a isso: a carência de modelos específicos que lidem com ampla abrangência com o processo de Pentest, envolvendo os distintos cenários analisados neste mapeamento sistemático. Dessa forma, discute-‐se como desafio a avaliação, desenvolvimento e aplicação de metodologias e recomendações para a execução de Testes de Penetração de qualidade.

8. CONCLUSÃO A relevância e notoriedade dos estudos sobre Testes de Penetração são evidentes do ponto de vista de pesquisa. Tal tema, posicionado dentro da grande área de Segurança da Informação, tem sido amplamente alvo dos trabalhos atuais relacionados a testes e verificações de segurança, uma vez que o crescimento e evolução de falhas e vulnerabilidades tem sido tão exponencial quanto. Este SMS tem seu foco em mapear o campo de Pentest, identificando os cenários de aplicação, ferramentas utilizadas, metodologias empregadas em diferentes contextos e as principais contribuições e desafios relacionados. Detalhadamente, foi possível indicar e analisar as descrições de uso das ferramentas identificadas e a diferenciação das metodologias, fornecendo um overview sobre as principais aplicações de descoberta de vulnerabilidades, escaneamento de rede, pré-‐invasão e pós-‐invasão, e análise web. A partir destas informações, os resultados podem ajudar um tester a definir dentro do seu escopo do teste quais as ferramentas indicadas de acordo com a etapa do processo, auxiliando também a tomada de decisão quanto as metodologias mais adequadas. Em geral os resultados deste SMS representam não apenas a identificação de aspectos pré-‐determinados pelas questões de pesquisa, mas sim uma abordagem concisa e relacionada com possíveis trabalhos futuros e desenvolvimento e adequação de novos modelos para Pentest. Os resultados em si fornecem o apoio necessário para tal construção dentro deste âmbito de pesquisa de testes de segurança, seja pela própria indicação das ferramentas consolidadas para o processo de Pentest ou até mesmo pela percepção em torno de vantagens e desvantagens da relação de metodologias em determinados cenários. Aliado a essa percepção, a avaliação realizada sobre as metodologias discutidas na subseção 7.3 direciona a possibilidade da criação de um conjunto de recomendações que vise aperfeiçoar e/ou complementar o processo de Pentest baseado nas principais metodologias existentes. Assim, compreende-‐se que a proposta de um conjunto de recomendações trataria os problemas de pesquisa e limitações dos modelos, ao passo que forneceria uma forma flexível, dinâmica e completa de escolha das atividades, etapas e demais aspectos inerentes a um teste de penetração.

REFERÊNCIAS

[1] LAM, Kevin; LEBLANC, David; SMITH, Ben. Assessing network security. Microsoft Press, 2004. [2] ZHAO, Jensen J.; ZHAO, Sherry Y. Opportunities and threats: A security assessment of state e-‐government websites. Government Information Quarterly, v. 27, n. 1, p. 49-‐56, 2010.

[3] WHITAKER, Andrew; NEWMAN, Daniel P. Penetration testing and network defense. Cisco Press, 2005. [4] HENRY, Kevin. Penetration Testing: Protecting Networks and Systems. IT Governance Publishing, 2012. [5] PETERSEN, K; FELDT, R.; MUJTABA, S.; MATTSSON, M. Systematic mapping studies in software engineering. EASE’08: Proceedings of the 12th International Conference on Evaluation and Assessment in Software Engineering, University of Bari, Italy (2008). [6] MIRJALILI, Mahin; NOWROOZI, Alireza; ALIDOOSTI, Mitra. A survey on web penetration test. 2014. [7] AL-‐GHAMDI, Abdullah Saad AL-‐Malaise. A Survey on Software Security Testing Techniques. International Journal of Computer Science and Telecommunications, v. 4, 2013. [8] BISHOP, Matt. About penetration testing. Security & Privacy, IEEE, v. 5, n. 6, p. 84-‐87, 2007. [9] GEER, Daniel; HARTHORNE, John. Penetration testing: A duet. In: Computer Security Applications Conference, 2002. Proceedings. 18th Annual. IEEE, 2002. p. 185-‐195. [10] KITCHENHAM, B.; CHARTERS, S. Guidelines for performing Systematic Literature Reviews in Software Engineering, Technical Report EBSE 2007-‐001, Keele University and Durham University Joint Report, 2007. [11] AUSTIN, Andrew; HOLMGREEN, Casper; WILLIAMS, Laurie. A comparison of the efficiency and effectiveness of vulnerability discovery techniques.Information and Software Technology, v. 55, n. 7, p. 1279-‐1288, 2013. [12] HSU, Yating; SHU, Guoqiang; LEE, David. A model-‐based approach to security flaw detection of network protocol implementations. In: Network Protocols, 2008. ICNP 2008. IEEE International Conference on. IEEE, 2008. p. 114-‐123. [13] HOLM, Hannes et al. A quantitative evaluation of vulnerability scanning.Information Management & Computer Security, v. 19, n. 4, p. 231-‐247, 2011.

[14] SKLAVOS, Nicolas; BECHTSOUDIS, Anestis. Aiming at higher network security through extensive penetration tests. Latin America Transactions, IEEE (Revista IEEE America Latina), v. 10, n. 3, p. 1752-‐1756, 2012. [15] SARRAUTE, Carlos; RICHARTE, Gerardo; LUCÁNGELI OBES, Jorge. An algorithm to find optimal attack paths in nondeterministic scenarios. In:Proceedings of the 4th ACM workshop on Security and artificial intelligence. ACM, 2011. p. 71-‐80. [16] KHOURY, Nidal et al. An analysis of black-‐box web application security scanners against stored SQL injection. In: Privacy, Security, Risk and Trust (PASSAT) and 2011 IEEE Third Inernational Conference on Social Computing (SocialCom), 2011 IEEE Third International Conference on. IEEE, 2011. p. 1095-‐1101. [17] ANTUNES, Nuno; VIEIRA, Marco. Assessing and Comparing Vulnerability Detection Tools for Web Services: Benchmarking Approach and Examples.Services Computing, IEEE Transactions on, v. 8, n. 2, p. 269-‐283, 2015. [18] XU, Dianxiang et al. Automated security test generation with formal threat models. Dependable and Secure Computing, IEEE Transactions on, v. 9, n. 4, p. 526-‐540, 2012. [19] SHEN, Lu et al. Automatic Generation for Penetration Testing Scheme Analysis Model for Network. In: Computational and Information Sciences (ICCIS), 2011 International Conference on. IEEE, 2011. p. 821-‐826. [20] MENDES, Naaliel; DURAES, Joao; MADEIRA, Henrique. Benchmarking the Security of Web Serving Systems Based on Known Vulnerabilities. In:Dependable Computing (LADC), 2011 5th Latin-‐American Symposium on. IEEE, 2011. p. 55-‐64. [21] FONG, Erin et al. Building a test suite for web application scanners. In:Hawaii International Conference on System Sciences, Proceedings of the 41st Annual. IEEE, 2008. p. 478-‐478. [22] WILLIAMS, Gustavious P. Cost effective assessment of the infrastructure security posture. In: System Safety, incorporating the Cyber Security Conference 2012, 7th IET International Conference on. IET, 2012. p. 1-‐6.

[23] BOU-‐HARB, Elias; DEBBABI, Mourad; ASSI, Chadi. Cyber scanning: a comprehensive survey. Communications Surveys & Tutorials, IEEE, v. 16, n. 3, p. 1496-‐1519, 2013. [24] KASINATHAN, Pounraj et al. Denial-‐of-‐Service detection in 6LoWPAN based Internet of Things. In: Wireless and Mobile Computing, Networking and Communications (WiMob), 2013 IEEE 9th International Conference on. IEEE, 2013. p. 600-‐607. [25] XING, Bin et al. Design and implementation of an XML-‐based penetration testing system. In: Intelligence Information Processing and Trusted Computing (IPTC), 2010 International Symposium on. IEEE, 2010. p. 224-‐229. [26] ANTUNES, Nuno et al. Effective detection of SQL/XPath injection vulnerabilities in web services. In: Services Computing, 2009. SCC'09. IEEE International Conference on. IEEE, 2009. p. 260-‐267. [27] HOLIK, Filip et al. Effective penetration testing with Metasploit framework and methodologies. In: Computational Intelligence and Informatics (CINTI), 2014 IEEE 15th International Symposium on. IEEE, 2014. p. 237-‐242. [28] AVRAMESCU, Gabriel et al. Guidelines for discovering and improving application security. In: Control Systems and Computer Science (CSCS), 2013 19th International Conference on. IEEE, 2013. p. 560-‐565. [29] RIDGEWELL, Walter W. et al. Immersive and Authentic Learning Environments to Mitigate Security Vulnerabilities in Networked Game Devices. In: Signal-‐Image Technology & Internet-‐Based Systems (SITIS), 2013 International Conference on. IEEE, 2013. p. 1042-‐1048. [30] WALDEN, James. Integrating web application security into the IT curriculum. In: Proceedings of the 9th ACM SIGITE conference on Information technology education. ACM, 2008. p. 187-‐192. [31] MINK, Martin; FREILING, Felix C. Is attack better than defense?: teaching information security the right way. In: Proceedings of the 3rd annual conference on Information security curriculum development. ACM, 2006. p. 44-‐48. [32] TONDEL, Inger Anne; JAATUN, Martin Gilje; JENSEN, Jostein. Learning from software security testing. In: Software Testing Verification and Validation

Workshop, 2008. ICSTW'08. IEEE International Conference on. IEEE, 2008. p. 286-‐294. [33] ARMANDO, Alessandro et al. Model-‐checking driven security testing of web-‐based applications. In: Third International Conference on Software Testing, Verification, and Validation Workshops. IEEE, 2010. p. 361-‐370. [34] DAHL, Ole Martin; WOLTHUSEN, Stephen D. Modeling and execution of complex attack scenarios using interval timed colored Petri nets. In:Information Assurance, 2006. IWIA 2006. Fourth IEEE International Workshop on. IEEE, 2006. p. 12 pp.-‐168. [35] MCLAUGHLIN, Stephen et al. Multi-‐vendor penetration testing in the advanced metering infrastructure. In: Proceedings of the 26th Annual Computer Security Applications Conference. ACM, 2010. p. 107-‐116. [36] SOMOROVSKY, Juraj et al. On Breaking SAML: Be Whoever You Want to Be. In: USENIX Security Symposium. 2012. p. 397-‐412. [37] GARN, Bernhard et al. On the applicability of combinatorial testing to web application security testing: a case study. In: Proceedings of the 2014 Workshop on Joining AcadeMiA and Industry Contributions to Test Automation and Model-‐Based Testing. ACM, 2014. p. 16-‐21. [38] LINE, Maria B. et al. Penetration testing of opc as part of process control systems. In: Ubiquitous Intelligence and Computing. Springer Berlin Heidelberg, 2008. p. 271-‐283. [39] MAINKA, Christian; SOMOROVSKY, Juraj; SCHWENK, Jörg. Penetration testing tool for web services security. In: Services (SERVICES), 2012 IEEE Eighth World Congress on. IEEE, 2012. p. 163-‐170. [40] TRAORE, Moussa Djiriba et al. RAPn: Network Attack Prediction Using Ranking Access Petri Net. In: Chinagrid Conference (ChinaGrid), 2011 Sixth Annual. IEEE, 2011. p. 108-‐115. [41] BENKHELIFA, Elhadj; WELSH, Thomas. Security testing in the cloud by means of ethical worm. In: Globecom Workshops (GC Wkshps), 2013 IEEE. IEEE, 2013. p. 500-‐505. [42] SALAS, M. I. P.; MARTINS, E. Security testing methodology for vulnerabilities detection of xss in web services and ws-‐security. Electronic Notes in Theoretical Computer Science, v. 302, p. 133-‐154, 2014.

[43] BÜCHLER, Matthias; OUDINET, Johan; PRETSCHNER, Alexander. Semi-‐automatic security testing of web applications from a secure model. In:Software Security and Reliability (SERE), 2012 IEEE Sixth International Conference on. IEEE, 2012. p. 253-‐262. [44] SANDOUKA, Hanan; CULLEN, Andrea; MANN, Ian. Social Engineering Detection using Neural Networks. In: CyberWorlds, 2009. CW'09. International Conference on. IEEE, 2009. p. 273-‐278. [45] LIU, Bingchang et al. Software vulnerability discovery techniques: A survey. In: Multimedia Information Networking and Security (MINES), 2012 Fourth International Conference on. IEEE, 2012. p. 152-‐156. [46] MASOOD, Rahat et al. SWAM: Stuxnet Worm Analysis in Metasploit. In:Frontiers of Information Technology (FIT), 2011. IEEE, 2011. p. 142-‐147. [47] IGURE, Vinay M.; WILLIAMS, Ronald D. Taxonomies of attacks and vulnerabilities in computer systems. Communications Surveys & Tutorials, IEEE, v. 10, n. 1, p. 6-‐19, 2008. [48] KHOURY, Nidal et al. Testing and assessing web vulnerability scanners for persistent SQL injection attacks. In: Proceedings of the First International Workshop on Security and Privacy Preserving in e-‐Societies. ACM, 2011. p. 12-‐18. [49] LEIBOLT, Gregory. The Complex World of Corporate CyberForensics Investigations. In: CyberForensics. Humana Press, 2010. p. 7-‐27. [50] FONSECA, Jose; VIEIRA, Marco; MADEIRA, Henrique. The web attacker perspective-‐a field study. In: Software Reliability Engineering (ISSRE), 2010 IEEE 21st International Symposium on. IEEE, 2010. p. 299-‐308. [51] JAJODIA, Sushil; NOEL, Steven; O’BERRY, Brian. Topological analysis of network attack vulnerability. In: Managing Cyber Threats. Springer US, 2005. p. 247-‐266. [52] BLACKWELL, Clive. Towards a Penetration Testing Framework Using Attack Patterns. In: Cyberpatterns. Springer International Publishing, 2014. p. 135-‐148.

[53] PRANDINI, Marco; RAMILLI, Marco. Towards a practical and effective security testing methodology. In: Computers and Communications (ISCC), 2010 IEEE Symposium on. IEEE, 2010. p. 320-‐325. [54] DIMKOV, Trajce et al. Two methodologies for physical penetration testing using social engineering. In: Proceedings of the 26th annual computer security applications conference. ACM, 2010. p. 399-‐408. [55] STEPIEN, Bernard; PEYTON, Liam; XIONG, Pulei. Using TTCN-‐3 as a modeling language for web penetration testing. In: Industrial Technology (ICIT), 2012 IEEE International Conference on. IEEE, 2012. p. 674-‐681. [56] BADAWY, Mohamed Alfateh; EL-‐FISHAWY, Nawal; ELSHAKANKIRY, Osama. Vulnerability Scanners Capabilities for Detecting Windows Missed Patches: Comparative Study. In: Advances in Security of Information and Communication Networks. Springer Berlin Heidelberg, 2013. p. 185-‐195. [57] CURPHEY, Mark; ARAWO, Rudolph. Web application security assessment tools. Security & Privacy, IEEE, v. 4, n. 4, p. 32-‐41, 2006. [58] HUANG, Yao-‐Wen; LEE, D. T. Web Application Security—Past, Present, and Future. In: Computer Security in the 21st Century. Springer US, 2005. p. 183-‐227. [59] DOUPÉ, Adam; COVA, Marco; VIGNA, Giovanni. Why Johnny can’t pentest: An analysis of black-‐box web vulnerability scanners. In: Detection of Intrusions and Malware, and Vulnerability Assessment. Springer Berlin Heidelberg, 2010. p. 111-‐131. [60] HERTZOG, P. OSSTMM -‐ Open Source Security Testing Methodology Manual. Institute for Security and Open Methodologies, ISECOM. Disponível em: http://www. isecom. org/osstmm. [61] ALLEN, Lee; HERIYANTO, Tedi; ALI, Shakeel. Kali Linux–Assuring Security by Penetration Testing. Packt Publishing Ltd, 2014. [62] PAULI, Josh. The basics of web hacking: tools and techniques to attack the Web. Elsevier, 2013. [63] Open Information Systems Security Group. Information Systems Security Assessment Framework, 2006.

[64] Penetration Testing Execution Standard. Technical Guidelines. Disponível em: http://www.pentest-‐standard.org [65] O'GORMAN, Jim; KEARNS, Devon; AHARONI, Mati. Metasploit: the penetration tester's guide. No Starch Press, 2011. [66] STOUFFER, Keith; FALCO, Joe; SCARFONE, Karen. NIST SP 800-‐115: Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology (September, 2008), 2008.

Documents

Um Mapeamento Sistemático sobre Testes de Penetração · Ethical+Hacking!e!ressaltaadivisão!dos!tipos!de!Pentest! entreblack2box,white2box!egray2box.!! Em[8],!o!artigo!trata!as!minúcias!emtestes!de!penetração,discutindo