As abordagens de testes baseados em modelo têm chamado a atenção nos últimos anos. Esses métodos usam modelos do SET para derivar casos de teste a partir deles. Os casos de teste depois, são executados contra o programa e a saída é comparada com os valores esperados, para descobrir se o programa se comporta de acordo com sua especificação representada pelo modelo. Na seção 3.1 apresentamos alguns trabalhos que abordam testes de segurança baseados em modelo, em 3.2 apresentamos trabalhos relacionados com testes de segurança em web services e em 3.3 fazemos uma comparação entre os trabalhos relacionados a MBT e a nossa abordagem
3.1. Testes de segurança baseados em modelos
Existem inúmeros trabalhos na área de testes de segurança baseados em modelos; aqui, apresentamos alguns, que são mais parecidos com a proposta utilizada. Um destes trabalhos envolve a criação de três modelos [39]: um de especificação padrão que é abstrato e é designado como sistema de transição de estados; um modelo de implementação que aplica o conceito de injeção de falhas e representa uma mutação a ser aplicada no modelo de estados. O terceiro modelo representa a intenção do atacante e funciona como objetivo de teste. Este modelo é usado para gerar dados adequados que são depois combinados com o modelo baseado em falhas ligando o modelo de especificação e o modelo de implementação. Casos de teste podem ser gerados com recurso constraint solvers7 e consiste na identificação de contextos de falhas8.
Um outro trabalho utiliza grafos acíclicos dirigidos (DAG-Directed Aciclic Graphs) como modelo de ataques para avaliação de segurança [40]. Este modelo representa o comportamento do atacante. É usado um parser das políticas do firewall que converte as suas regras9 para o DAG e, em seguida, cada sequência de regras no DAG é considerada como uma sequência de eventos. Na etapa de geração de casos de teste, um algoritmo cria um caso de teste para cada sequência completa de eventos, que são derivadas do DAG. A geração de teste para este método usa critérios de cobertura de transições e de cobertura de estados;
7Este conceito vem de Programação por Restrições que é o “estudo de sistemas computacionais baseados em restrições” onde uma restrição é uma relação lógica entre algumas incógnitas em um modelo matemático de um domínio de interesse (Del Palo et al 2007).
8Segundo o autor, é o contexto gerado pela combinação dos três modelos.
também estabelece restrições, por exemplo de que a soma dos comprimentos dos caminhos deve ser mínima. Estas restrições permitem reduzir o custo de execução de testes [41]. Um método foi proposto e implementado que usa modelo para resolver o problema de efetividade de fuzzing [42]. O modelo de SET é extraído com ajuda de técnicas de inferência e o processo de fuzzing é guiado por um algoritmo evolutivo. A técnica de inferência é responsável por interpretar o estado do SET, permitindo realizar o processo de fuzzing a partir de um estado apropriado. O processo evolutivo funciona da seguinte forma: a primeira geração é criada usando sequências de entrada, baseadas em sequências já utilizadas em testes de outros SET. As sequências constituem as várias populações, que evoluem em paralelo, em diferentes grupos. Mutações e cruzamentos são realizados dentro de uma determinada população e entre diferentes grupos. A função de adequação depende dos estados percorridos e das saídas correspondentes. É usado o elitismo para criar a entrada da próxima geração.
Outro método utiliza um modelo de ameaças para gerar automaticamente sequências de teste de segurança [43]. O método consiste em dois passos. O primeiro passo envolve a geração automatizada de sequência de teste a partir de árvores de ameaças. As árvores de ameaças (semelhante a árvore de ataque) são estruturas em árvore com nós filhos com relacionamentos AND ou OR, e descrevem o processo de tomada de decisão pelo qual um invasor passaria para comprometer o software. O nó raiz de uma árvore de ameaças é o objetivo da ameaça. O nó raiz é então decomposto em sub-objetivos (nós filhos) continuando a decompor até que os nós de folha que representam as ações de ataque individuais sejam determinados. As árvores de ameaças descrevem o processo de tomada de decisão pelo qual um invasor passaria para comprometer o software. O segundo passo envolve a transformação dos testes de segurança em casos de testes executáveis. Inicialmente são geradas sequências de teste de segurança a partir de árvores de ameaças e parâmetros de teste a partir das sintaxes de entrada. Em seguida, são integrados os parâmetros de teste nas sequências de teste para criar casos de teste de segurança completos, mas abstratos, i.e., independentes da implementação. Com o conhecimento de implementação, são convertidos, ainda mais, os testes de segurança abstratos para testes de segurança concretos; finalmente são geradas entradas de teste válidas e inválidas para depois gerar scripts de teste que executam todas as sequências de teste com valores de entrada atribuídos [39].
Um método para testes de propriedades de segurança específicas de cartões inteligentes (smart cards) permite a validação do sistema com MBT a partir de esquemas de teste [44].
Esquemas de teste são uma expressão de alto nível que formalizam o propósito de teste associado a uma propriedade de segurança e que servem de base para a geração de testes automatizados no modelo comportamental. Combinam esta abordagem MBT com a técnica de verificação de segurança UMLsec que é uma extensão da UML para garantir o desenvolvimento de sistemas seguros. Assim são usados estereótipos UMLsec para verificar o modelo com respeito a propriedades de segurança dados e ganhar mais confiança no modelo [45].
O trabalho realizado por Tian, et al. [46] utiliza MBT para testar vulnerabilidades de SQLI usando o conceito de testes de penetração. A geração de casos de teste é dividida em duas fases; a primeira, que é a construção de um modelo de ataque, o qual descreve abstratamente a regularidade de SQL e, sob o comando desses modelos de ataque, estabelecem um modelo de entradas de casos de testes para vulnerabilidades SQLI; a segunda fase instancia o modelo de casos de testes de acordo com um certo critério de cobertura para gerar casos de testes executáveis.
O método de testes de segurança apresentado em [47] é baseado em árvores de ameaças, à semelhança do que vimos anteriormente em [43]. Neste trabalho o processo de modelagem de ameaças pode ocorrer em qualquer fase do processo de desenvolvimento do software. O modelo é representado textualmente em um documento XML podendo estabelecer uma relação entre elementos de XML e o modelo de ameaças. O documento XML é submetido a uma análise pelo algoritmo de geração de sequências de testes de segurança, gerando uma sequência de testes abstratos. Posteriormente o processo de geração de casos de testes é iniciado, o qual se baseia no uso de um diagrama de sequência.
Um outro trabalho propôs uma abordagem de testes de vulnerabilidades que consiste na formalização de objetivos de testes a partir de padrões de vulnerabilidades e na criação de um modelo dos aspectos comportamentais do sistema [48]. Os casos de testes abstratos são produzidos pela combinação dos aspectos funcionais do sistema e dos objetivos de testes advindos dos padrões de vulnerabilidades. Finalmente concretiza-se a execução de testes transformando os casos de teste abstratos em scripts executáveis.
Finalmente o método de Bozic e Wotawa [7] permite modelar vários padrões de ataques para a realização de testes online. Um padrão de ataque especifica um ataque que ocorre em circunstâncias específicas. Padrões de ataque, descritos em linguagem natural, são transformados por modelos de estado. O modelo não é utilizado para a geração de testes,
mas para simular o comportamento do atacante durante a execução dos testes. O modelo utiliza entradas que são geradas utilizando testes combinatórios.
3.2. Teste de segurança de ws
Um dos trabalhos estudados apresenta um conjunto de ataques tidos como os mais proeminentes em WS [49]. Dentre esses ataques constam os de negação de serviços e o de injeção. Além de apresentar uma Taxonomia de Ataques em WS o artigo ainda apresenta alguns exemplos de como podem ser realizados alguns desses ataques. Esses exemplos incluem ataques de SQL Injection e Cross Site Scripting que são os ataques considerados neste trabalho. Finalmente, o trabalho apresenta uma Taxonomia de contra-medidas aos ataques de segurança discutidos no trabalho realizado.
Antunes, Vieira e Madeira [6] apresentam uma abordagem para detecção de SQLI e Injeção de XPATH que consiste de dois passos: Primeiro, é gerado e executado uma carga de trabalho para exercitar o serviço da web e aprender o perfil dos comandos SQL/XPATH emitidos. Depois, aplica-se um conjunto de ataques de injeção de comando e observam-se os comandos SQL/XPATH sendo executados. Isso permite detectar vulnerabilidades existentes, combinando comandos de entrada durante os ataques com o conjunto válido de comandos previamente aprendidos. Este método resultou numa ferramenta de detecção das vulnerabilidades SQLI e XPATH, utilizada pelos autores em que obtiveram resultados positivos.
3.3. Comparativo com o trabalho que foi feito
O nosso trabalho é baseado em [4], que utiliza um modelo de estados e, portanto, se enquadra na categoria de testes de segurança baseados em modelo, mais precisamente, como testes de vulnerabilidades de segurança (veja 2.4.1). Analisando do ponto de vista da taxonomia apresentada em 2.4.2, de acordo com o critério de filtragem, o modelo utilizado está no nível de sistema e ambiente, pois representa o comportamento do atacante; já a seleção de caso de teste é feita obedecendo ao critério de cobertura de dados (testes combinatórios).
Pelo critério de evidência, recorremos a uma aplicação com vulnerabilidades conhecidas e, portanto, é um exemplo de aplicação em que o objetivo é verificar se o método de teste utilizado foi capaz de detectar ou não vulnerabilidades. Em termos de eficácia é fundamental saber se o método encontrou ou não as vulnerabilidades.
A tabela 3 mostra como o nosso trabalho pode ser comparado com os trabalhos relacionados. A comparação é feita com base na taxonomia mostrada na Figura 14. A tabela tem duas
grandes partes, separando o critério de filtro e o critério de evidência. Nos critérios de filtro, a tabela se subdivide em três categorias que caracterizam o que o modelo de teste representa, nomeadamente, o SET ou o ambiente e ainda os critérios de seleção de teste. Na categoria dos critérios de evidência, a coluna também se subdivide em três, nomeadamente: maturidade do SET, medidas de evidência e nível de evidência (ver Seção 2.4.2). A linha P representa o trabalho utilizado neste estudo.
Tabela 3: Classificação dos trabalhos relacionados segundo a Taxonomia de Felderer et al [8]
Cit
Critério de Filtro Critério de Evidência
SET Amb Seleção de teste Maturidade Medidas Nível
Prop. S eg V ul FMS Mod. A t Mod. A m C ob. E st C ob. D CBR E .E .C .T A e E B . Falhas B. A v B . Rel P ro to tipo P re ma turo P ro du çã o E x . Aplic E fec tiv id E ficiência Abs tra to Co ncre to [39] x x x x x [40] x x x [43] x x [44] x x x x [46] x [47] x x x x x [48] x x x x [7] x x x [42] x x P x x x x Legenda: Prop. Seg-Propriedades de Segurança, Vul-Vulnerabilidade, Mod. At-Modelo de Atacante, Mod.
Amb – Modelo do Ambiente, FMS – Funcionalidade dos Mecanismos de Segurança, Cob. Est-Cobertura
Estrutural, Cob. D - Cobertura de Dados, CBR – Cobertura Baseada em Requisitos, A e E – Aleatório e Estocástico, EECT – Especificação Explicita de Casos de Dados, B. Falhas – Baseado em Falhas, B. R. – Baseado em Relacionamento, Ex. Aplic. – Exemplo de Aplicação