Existem basicamente dois tipos de testes de segurança, complementares entre si: Assessment e PenTest.

Assessment é um processo de avaliação não invasivo dos controles de segurança internos e/ou externos identificando as ameaças e quantificando todas as vulnerabilidades. Esta avaliação técnica da infraestrutura aponta não só os riscos envolvidos, mas soluções de contorno. Geralmente avaliações internas ajudam a proteger sistemas; avaliações externas ajudam a proteger perímetros.

A principal diferença entre Assessment e PenTest é que este último vai além de identificar vulnerabilidades, partindo para o processo de exploitation, escalada de privilégios e garantia de acesso ao sistema alvo.

O Assessment apresenta uma visão mais abrangente sobre as falhas de sistema ou infraestrutura. Já o PenTest tem como objetivo direto testar as políticas e implementações de segurança em uma organização. Além disso, o PenTest é muito mais intrusivo.

Assessment deve ser pensado como o primeiro passo para um PenTest. As informações obtidas a partir do Assessment são usadas no PenTest. Considerando que, o Assessment trata da verificação de falhas e vulnerabilidades potenciais, o PenTest tenta explorar os resultados [RED HAT, 2013].

Segurança da Informação

Segurança da Informação refere-se à proteção das informações contidas no domínio das empresas ou pessoas. Isto envolve qualquer ativo que gere, processe, manipule, transmita ou armazene informações. Tem como requisito a garantia de continuidade do negócio, minimizando riscos e maximizando o retorno de investimentos. É constituída de um conjunto de controles, incluindo políticas, normas, padrões e procedimentos. Tais controles estão contidos respectivamente nos planos estratégico, tático e operacional, como demonstra a Figura 1.

Figura 1. Pirâmide da Segurança da Informação [BRADESCO, 2013].

O plano estratégico trata de ideias, planejamentos e direcionamentos a serem seguidos por toda a organização. No plano tático são tomadas decisões para a implementação efetiva que permitam atender aos objetivos contidos no plano estratégico. Neste plano são desenvolvidos e implementados os projetos para a melhoria da segurança. Já no plano operacional estão contidas as atividades diárias que envolvem segurança; não só da própria área, mas de todas as áreas de uma empresa.

O auditor de segurança da informação é figura ímpar em todo o processo. É o profissional responsável por assegurar que os processos corretos e mais atualizados estão sendo aplicados à infraestrutura. O mesmo também realiza uma série de testes para garantir que a segurança da informação está de acordo com os requisitos de uma organização, identificando vulnerabilidades e as classificando.

A classificação das vulnerabilidades de acordo com sua severidade faz parte do processo de análise e avaliação do risco. É um processo complexo da gestão de riscos, que também envolve todos os levantamentos em relação às ameaças, probabilidades e impactos sobre os ativos. Não serão explorados os detalhes acerca da análise e avaliação dos riscos, pois se fugiria do escopo proposto ao aprofundar demasiadamente em tais detalhes.

A norma NBR ISO/IEC 17799:2005 estabelece os seguintes atributos básicos, também conhecidos como pilares da segurança da informação: confidencialidade, integridade, disponibilidade, autenticidade e irretratabilidade. Não serão explorados os detalhes acerca de tais atributos, pois se fugiria do escopo proposto ao aprofundar demasiadamente em tais detalhes.

Tipos de Abordagens de Testes de Segurança

Há basicamente três abordagens: Black-Box, White-Box e Gray-Box. Tais abordagens são descritas nas sessões que seguem.

  • Black-Box: Neste caso assume-se que o auditor de segurança inicia o teste de segurança sem nenhum conhecimento do ambiente a ser testado e de sua infraestrutura [RAMOS et al, 2008, p. 279]. Assim, é possível descobrir conjuntos de vulnerabilidades conhecidas e também não conhecidas (0 day). O auditor que executa testes Black-Box é conhecido como Black-Hat. Este tipo de teste também é conhecido como Teste Externo.
    Após a realização dos testes e classificação do nível de severidade das vulnerabilidades é gerado um relatório, que mostra o grau de exposição de determinado ativo ou de uma empresa inteira, dependendo do escopo da avaliação.
  • White-Box: Neste caso assume-se que o auditor de segurança possui toda a informação sobre os sistemas-alvo, topologias de rede, diagramas com nomes e endereços IP dos hosts que serão testados, etc [RAMOS et al, 2008, p. 280]. Há um esforço muito menor para descobrir vulnerabilidades neste caso. Este tipo de teste também é conhecido como Teste Interno. O auditor que executa testes White-Box é conhecido como White-Hat.
    O teste White-Box pode ser facilmente integrado em um ciclo de desenvolvimento ou manutenção regular para mitigar quaisquer problemas de segurança em sua fase inicial antes de serem divulgados e explorados. O tempo e o custo necessário para encontrar e solucionar vulnerabilidades de segurança é menor do que na abordagem Black-Box.
  • Gray-Box: Os dois tipos de testes anteriores combinados oferecem uma estratégia bastante eficiente do ponto de vista da segurança. O auditor envolvido em testes Gray-Box é também conhecido como Gray-Hat [ALI e HERIYANTO, 2011, p. 39]. Neste tipo de teste o auditor não conhece todos os detalhes da infraestrutura e/ou tecnologia envolvida.

Metodologias de Assessment

Várias metodologias de Assessment surgiram com o objetivo de endereçar problemas de segurança. A utilização de cada metodologia depende do seu foco, se gerencial ou técnico; do tamanho da organização ou complexidade da infraestrutura.

Muitas vezes a utilização de somente uma metodologia introduz erros no resultado final da avaliação. A seguir são apresentados alguns aspectos de metodologias de Assessment bastante conhecidas.

Open Source Security Testing Methodology Manual (OSSTMM)

O OSSTMM é um padrão de segurança reconhecido internacionalmente. Trata-se de um padrão puramente baseado em métodos científicos que consistem em quantificar a segurança operacional e seu custo de acordo com os objetivos do negócio.

De uma perspectiva técnica, é uma metodologia dividida em grupos principais chamados Scope, Channel, Index e Vector. Scope define o processo de coleta das informações sobre os ativos de determinado ambiente. Channel define o tipo de comunicação entre os ativos. Index classifica os ativos de acordo com sua identificação, como endereço MAC e IP. Vector aponta a direção que o auditor deve analisar e avaliar cada ativo funcional. Todo este processo inicia uma sequencia de avaliação técnica do ambiente, também chamada de Audit Scope.

Há diferentes formas de testes de segurança na metodologia OSSTMM. Os mesmos são apresentados a seguir:

  • Blind: Este teste não requer nenhum tipo de conhecimento prévio sobre o sistema alvo;
  • Double blind: Neste teste o auditor não requer nenhum conhecimento sobre o sistema alvo e nem o alvo (ou administrador do mesmo) é informado antes da execução dos testes. São exemplos a auditoria Black-Box e o PenTest;
  • Gray-Box: Neste tipo de teste o auditor possui conhecimento parcial sobre o sistema alvo e o mesmo é alertado antes que o teste seja executado;
  • Double Gray-Box: É um teste similar ao teste Gray-Box, exceto pelo fato de o tempo de duração da auditoria ser definido e por Channels e Vectors não serem testados;
  • Tandem: Neste teste o auditor possui pouquíssimas informações para avaliar o alvo, e o responsável pelo mesmo não é alertado sobre a auditoria;
  • Reversal: Neste tipo de teste o auditor possui todas as informações sobre o sistema alvo e o mesmo nunca será alertado sobre como ou quando o teste será executado [ALI e HERIYANTO, 2011, p. 42].

Information Systems Security Assessment Framework (ISSAF)

O ISSAF é outro padrão aberto de análise e testes de segurança que foca em duas áreas, técnica e gerencial. Utiliza categorização em diversos domínios para endereçar os testes de segurança em uma ordem lógica. É uma metodologia que se encaixa perfeitamente no ciclo de vida do negócio em uma organização.

Com a pretensão de ser uma framework bastante abrangente a mesma se baseia em informações atualizadas de ferramentas de segurança, melhores práticas e considerações administrativas para complementar o programa de verificação de segurança. É um padrão que escolhe o caminho mais curto para alcançar seu deadline analisando seu alvo contra vulnerabilidades críticas que podem ser exploradas com o mínimo de esforço [ALI e HERIYANTO, 2011, p. 44].

Open Web Application Security Project (OWASP)

Esta framework engloba diversos projetos, e um dos mais importantes é o Top 10. É um projeto que tem como objetivo educar desenvolvedores, designers, arquitetos de softwares, gerentes e organizações sobre as consequências das falhas de segurança mais críticas em uma aplicação web. O projeto também provê técnicas básicas para proteção destas ameaças.

Técnicas sofisticadas de proteção de perímetro e de host ainda sofrem para prevenir que uma aplicação seja exposta e atacada. O desenvolvimento de uma aplicação segura envolve pessoas, processos, gerenciamento e tecnologia. O projeto aberto da comunidade chamado OWASP é uma iniciativa que foca nos fundamentos para integrar segurança aos princípios de melhores práticas no desenvolvimento seguro.

Web Application Security Consortium Threat Classification (WASC-TC)

WASC-TC é outro padrão aberto para avaliação da segurança de aplicações web. Possui uma visão muito mais profunda que o OWASP. Há três visões diferentes para ajudar os desenvolvedores e auditores de segurança. Estas são relacionadas a seguir:

  • Enumeration View: É uma visão dedicada a prover a base para falhas e ataques de aplicações. Estas falhas são referenciadas por um identificador único, o que facilita uma referência posterior. Tais identificadores não são relacionados à severidade, mas tão somente para propósito de numeração.
  • Development View: É uma visão do ponto de vista do desenvolvimento, que relaciona ataques e falhas a vulnerabilidades que possam ser exploradas em qualquer das três fases do desenvolvimento: design, implementação e deployment.
  • Taxonomy Cross Reference View: Refere-se a uma associação cruzada de vários padrões diferentes para a segurança de aplicações web que ajudam os auditores e desenvolvedores a mapear terminologias existentes em um padrão em outro.

Ataques e falhas desta visão são mapeados com o projeto OWASP Top Ten, Common Weakness Enumeration (CWE) da Mitre, Common Attack Pattern Enumeration and Classification (CAPEC), também da Mitre e a lista SANS-CWE Top 25 [ALI e HERIYANTO, 2011, p. 49].

Proposta de Metodologia Simplificada de Assessment

Frente às fases de um ataque ou teste de segurança é essencial conhecer cada etapa a fim de que sejam utilizadas as ferramentas mais apropriadas para o sucesso da execução. Essas fases foram inicialmente sistematizadas no livro Hacking Exposed, em 1999 [RAMOS et al, 2008, p. 130].

Um ataque ou teste de segurança bem sucedido exige a utilização de uma metodologia bem estruturada e concatenada. A Figura 2 apresenta uma proposta simplificada de sistematização de ataque ou teste de segurança.

Figura 2. Proposta de Metodologia Simplificada de Assessment.

A definição do escopo trata dos limites do teste, seja para uma máquina, várias máquinas ou para toda uma rede. Define também o que será testado, como portas abertas ou serviços em execução. Nesta etapa também são previstos os fatores limitadores, como alcance da rede, hosts desligados e prazo de execução do teste.

A fase de Googling é também conhecida como fase de reconhecimento e trata da coleta de informações. Para ambientes de Internet esta coleta é feita a partir de recursos publicamente disponíveis como fóruns, listas de discussões, artigos, blogs, redes sociais, sites de busca, e outros sites, comerciais ou não. Para ambientes de intranet a coleta pode ser feita por servidores DNS, trace routes, whois, números de telefone, informações pessoais e contas de usuário. Quanto mais informações coletadas maiores as chances de sucesso no teste de segurança.

A etapa de Scanning e Footprinting trata da identificação das conexões abertas pelo host ou pelo conjunto de hosts. São relacionadas as portas abertas com os serviços em execução e suas respectivas versões, inclusive de sistemas operacionais. Pode ser uma análise mista: ativa e passiva.

Na etapa de Identificação e Análise de Vulnerabilidades é possível, através de várias ferramentas automatizadas de Assessment e PenTest, levantar serviços vulneráveis e portas abertas sem necessidade, expondo o host a uma janela de risco desnecessária. Com as informações obtidas na etapa de Scanning e Footprinting é possível otimizar o Assessment ou PenTest. Não há sentido, por exemplo, submeter um host Windows a uma série de testes automatizados específicos para ambientes Linux.

A última etapa de Assessment é a Documentação. Tal etapa só deve ser realizada após uma análise rigorosa das informações obtidas na etapa anterior. Não basta somente reproduzir no relatório o resultado de programas automatizados, mas deve haver uma crítica para dirimir falsos positivos, resultados incorretos (para abordagens White-Box e Gray-Box) e vulnerabilidades não encontradas, embora existentes. Deve constar no relatório: as vulnerabilidades associadas aos serviços e portas do referido host ou conjunto de hosts, sugestões de correção e consideração final bem objetiva (se o host avaliado pode ou não entrar em produção).

Para o PenTest, o resultado da Identificação e Análise de Vulnerabilidades serve de entrada para a etapa de Exploração de Vulnerabilidades. Esta etapa pode ser realizada através de exploits isolados e específicos para determinada vulnerabilidade ou através de ferramentas automatizadas de ataque, o que facilita bastante o trabalho principalmente em abordagens Black-Box.

A última etapa de PenTest também é a Documentação. Deve-se obedecer o mesmo rigor descrito para Assessment. Deve constar no relatório: as vulnerabilidades associadas aos serviços e portas do referido host ou conjunto de hosts, resultado da tentativa de intrusão e consideração final bem objetiva (se o host avaliado pode ou não entrar em produção).

Em um ambiente corporativo, por exemplo, a retroalimentação dos ciclos de Assessment e PenTest garante que sempre haja uma avaliação das empresas sobre sua capacidade de resistir a adversidades. Tal verificação e melhoria contínua incide também sobre o próprio processo de avaliação, certificando que esta ou aquela são as melhores práticas a serem adotadas e estão de acordo com o plano estratégico da empresa.

Estudo de Caso

Para a aplicação da proposta é utilizado um servidor devidamente configurado em sua instalação padrão, utilizado para comunicação VoIP (Voice Over Internet Protocol – Voz Sobre Protocolo Internet) com protocolo SIP (Session Initiation Protocol – Protocolo de Inicialização de Sessão). Trata-se de um Assessment em um servidor Linux AsteriskNOW, versão 3.0.0 (imagem de Sistema Operacional disponível em http://www.asterisk.org/downloads). O mesmo possui um banco de dados e um servidor Web para administração dos clientes SIP. O prazo de execução do teste é de cinco dias.

Como o servidor em questão já possui várias características conhecidas e está em ambiente de intranet será considerada uma abordagem Gray-Box. O endereço IP do mesmo fornecido: 10.15.3.199/16.

Através do ping é possível identificar que o host está ativo:


  
  root@themachine:/# ping -c 5 10.15.3.199
  PING 10.15.3.199 (10.15.3.199) 56(84) bytes of data.
  64 bytes from 10.15.3.199: icmp_req=1 ttl=64 time=0.381 ms
  64 bytes from 10.15.3.199: icmp_req=2 ttl=64 time=0.500 ms
  64 bytes from 10.15.3.199: icmp_req=3 ttl=64 time=0.216 ms
  64 bytes from 10.15.3.199: icmp_req=4 ttl=64 time=0.111 ms
  64 bytes from 10.15.3.199: icmp_req=5 ttl=64 time=0.206 ms
   
  --- 10.15.3.199 ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4000ms
  rtt min/avg/max/mdev = 0.111/0.282/0.500/0.140 ms

É possível identificar o sistema operacional através de softwares como NMAP e Xprobe.

NMAP é uma ferramenta de exploração de rede e auditoria de segurança. Também trabalha bem em varreduras de um único host. Possui inúmeras opções de varredura (TLDP, 2013). A varredura executada possui as seguintes particularidades como opções:

  • sS: Utiliza a técnica de varredura TCP SYN;
  • sU: Realiza varredura em portas UDP;
  • PE: Dispara um ICMP Echo, o que auxilia na descoberta de Sistema Operacional;
  • PS443: Realiza varredura com a técnica TCP SYN na porta 443;
  • PA80: Realiza varredura com a técnica TCP ACK na porta 80;
  • PP: Emite um ICMP timestamp request para determinar o uptime;
  • sV: Testa as portas abertas para identificação da versão dos serviços;
  • O: Habilita a identificação de Sistema Operacional;
  • fuzzy: Identifica de forma mais agressiva a versão de Sistema Operacional, mesmo que o padrão de resposta esperado não seja totalmente conhecido;
  • p-: Verifica o range de portas 1-65535;
  • d: Aumenta o nível de debug;
  • oX: Grava o resultado da varredura em um arquivo XML, no caso, nmap_10.15.3.199_08042013.xml.

A Figura 3 apresenta o resultado resumido da utilização do NMAP de acordo com o comando:


  
  root@themachine:~# nmap -sS -sU -PE -PS443 -PA80 -PP -sV -O --fuzzy -p- -d -oX nmap_10.15.3.199_08042013.xml 10.15.3.199

Figura 3. Resultado de varredura com NMAP em HTML.

Trata-se de um relatório de varredura bem mais legível e interpretável. Tal conversão é possível com a utilização da ferramenta Xalan.

A ferramenta Xprobe dispara vários pacotes ICMP e analisa a resposta dos mesmos para determinar o sistema operacional de determinado host. É mais eficiente que o NMAP [TLDP, 2013]. Segue o resultado resumido da utilização do Xprobe de acordo com o comando:


  
  root@themachine:/# /usr/bin/xprobe2 10.15.3.199
  [+] Primary guess:
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.22" (Guess probability: 100%)
  [+] Other guesses:
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.23" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.21" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.20" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.19" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.24" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.25" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.26" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.27" (Guess probability: 100%)
  [+] Host 10.15.3.199 Running OS: "Linux Kernel 2.4.28" (Guess probability: 100%)
  [+] Cleaning up scan engine
  [+] Modules deinitialized
  [+] Execution completed.

Até agora já é possível identificar por duas ferramentas diferentes que se trata de um host Linux, possivelmente um CentOS.

Há diversas ferramentas de análise de vulnerabilidades no mercado. Dentre as mais utilizadas, é adotado para este trabalho: Nessus. É uma ferramenta que procura associar as vulnerabilidades encontradas com identificadores únicos de acordo com organizações reconhecidas internacionalmente como CWE, Cert.org, dentre outras.

Nessus é a ferramenta de avaliação e configuração de Assessment mais utilizada no mundo. Há opção pelo pagamento de alimentação de assinaturas de vulnerabilidades e sugestão de correções [Tenable Network Security, 2013]. As versões dos componentes do software de varredura de vulnerabilidades utilizadas são: Nessus 5.0.3, Web Server Version 4.0.31 e HTML Client Version 1.0.21.

A opção Policies deve conter uma política de testes com os plugins de verificação condizentes com o ambiente a ser testado, no caso, ambiente Linux. Portanto não são necessários plugins relacionados com AIX, MacOS ou Windows. Para a criação de um template de Assessment, na opção Templates, seleciona-se a opção New Scan e preenche-se os campos com os dados adequados, como demonstrado na Figura 4.

Figura 4. Criação de Varrdura de Vulnerabilidades.

A Figura 5 apresenta o resultado de uma avaliação com Nessus.

Figura 5. Resultado de varredura com Nessus.

São evidenciadas as vulnerabilidades de severidade média; as demais são informativas, geralmente associadas a atividades de log.

O modelo de relatório de Assessment demonstrado na Figura 6 evidencia as vulnerabilidades encontradas e as sugestões de correção.

Figura 6. Relatório técnico de Assessment

A ausência de metodologias de Assessment bem difundidas no Brasil faz com que a Segurança da Informação, enquanto ferramenta de avaliação, não tenha a eficácia esperada.

A proposta de metodologia apresentada consolida etapas de modelos diferentes e sistematiza o processo de avaliação de hosts, com foco na análise, documentação e reavaliação. Colabora também para a comparação de resultados utilizando metodologias de avaliação comuns.

Trata-se de uma metodologia em evolução, como qualquer tópico relacionado com Segurança da Informação. Não envolve grandes investimentos, mas tão somente a sistematização de processos de segurança, talvez já executados isoladamente; o que permite sua utilização em praticamente qualquer ambiente.

Referências Bibliográficas

ALI, Shakeel; HERIYANTO, Tedi. BackTrack 4: Assuring Security by Penetration Testing. 1a Edição. Birmingham: Packt Publishing, 2011.

BRADESCO. Portal de Segurança. Disponível em : http://www.bradescoseguranca.com.br/html/content/informacao/default.asp. Acesso em: 22/04/2013.

CERT. Vulnerability Notes Database. Disponível em: http://www.kb.cert.org/vuls/id/867593. Acesso em 12/06/2013;

RAMOS A, ANDRUCIOLI A, SOUZA AD, et al. Security Officer 2. 2a Edição. Porto Alegre: Editora Zouk, 2008.

RED HAT. CentOS Project. Disponível em: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-sec-access.html. Acesso em: 11/06/2013

Tenable Network Security. Nessus Data Sheet. Disponível em: https://static.tenable.com/datasheets/nessus-datasheet.pdf. Acesso em: 25/04/2013.