Faça do PaaS o seu campo de testes de vulnerabilidade

Construir um local de testes de segurança na nuvem é difícil; explore vários conceitos e modelos

Avalie, integre e defina vários conceitos de testes de segurança em cenários diferentes com o autor; também é possível explorar uma estrutura do ambiente de teste PaaS do usuário de amostra como base para um modelo de testes de segurança.

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson é arquiteta de sistemas e engenheira. Suas áreas de interesse incluem sistemas corporativos, tecnologias middleware, tecnologias de bancos de dados, computação em nuvem, políticas de limite, indústrias, gerenciamento de rede, segurança, tecnologias de RFID, gerenciamento de apresentação e gerenciamento de projeto.



03/Jun/2014

Vamos examinar o uso da Plataforma como Serviço (PaaS) como um campo de testes de vulnerabilidade por meio do uso de diferentes conceitos de testes de segurança em diferentes cenários. Neste artigo, mostraremos como avaliar, integrar e definir quaisquer conceitos de testes de segurança e, em seguida, explicaremos melhor as informações vinculando os conceitos aos cenários.

Mas, antes de iniciar com os conceitos mais difíceis, vejamos uma estrutura de modelo de PaaS de usuário para nos familiarizarmos com o tópico.

Estrutura de modelo de PaaS de usuário

A estrutura de modelo de PaaS de usuário se divide em três tipos:

  • O processo de ciclo de vida de desenvolvimento do aplicativo, que acompanha um aplicativo no PaaS, passando por requisitos, design, codificação, testes de segurança e estágios de implementação.
  • O ciclo de vida de gerenciamento de risco acompanha os processos de mitigação de riscos, da identificação de ativos à implementação de proteções com custo reduzido. Risco é a probabilidade de um agente de ameaça aproveitar uma ou mais vulnerabilidades.
  • O ciclo de vida do processo de negócios permite ao desenvolvedor controlar e proteger aplicativos em cada etapa PaaS. Como parte deste ciclo, o desenvolvedor usa planilhas, processadores de texto, faturamento e outras ferramentas de negócios.

Vejamos, de forma simplificada, como esses ciclos de vida são interligados uns aos outros em testes de segurança:

  • No ciclo de vida de gerenciamento de risco, os testadores do PaaS identificam os riscos para o desenvolvimento de aplicativos e, em seguida, criam uma abordagem baseada no risco para testes de segurança.
  • No ciclo de vida de desenvolvimento de aplicativos, os testadores aplicam a abordagem baseada em risco.
  • No ciclo de vida de processos de negócios, os testadores usam planilhas e documentos para registrar os resultados dos testes de segurança com base no risco, incluindo avaliações de vulnerabilidade.

Agora vejamos um modelo de testes de segurança genérico.


Modelo de teste de segurança

Identificar a ligação mais fraca, realizar testes de penetração e contar com normas e estruturas são métodos insuficientes para descobrir e detectar estes três tipos de problemas de segurança:

  • As falhas de segurança no nível do design do aplicativo PaaS
  • Erros de segurança no nível de implementação de aplicativos de PaaS
  • Indisponibilidades de recursos no nível da plataforma do PaaS

Uma solução melhor seria a configuração de um modelo de testes de segurança usando o PaaS como o campo de testes de vulnerabilidade. O modelo consiste nas seguintes fases:

  • Estágio de descoberta
  • Varredura de vulnerabilidade automatizada
  • Processo de avaliação de vulnerabilidade
  • Processo de avaliação de segurança
  • Teste de penetração
  • Auditoria de segurança
  • Revisão de segurança

A fase de estágio de descoberta é a base do modelo de testes de segurança; é o bloco de construção das fases subsequentes. Usando este modelo, as diferenças podem ser encontradas em qualquer fase e analisadas antes de prosseguir para a fase seguinte. Esse processo é repetido até que se chegue à fase de avaliação de segurança.

Se o testador localizar problemas de testes de segurança em uma fase, poderá retornar a uma fase anterior para repetir o processo de testes com as novas informações e, em seguida, avançar para a próxima fase.

O testador deve configurar seu próprio limite para o número de vezes que deve retornar a qualquer estágio anterior. Ele deve documentar os resultados dos testes de segurança novos ou melhorados em cada fase até que atinja o limite.

Agora vamos ver cada um desses estágios e vinculá-los a cenários.


Estágio de descoberta: upgrade do SaaS

A fase de descoberta é o primeiro estágio nos testes de segurança ao usar o PaaS como o campo de testes de vulnerabilidade.

Sobre o que é isso?

Primeiro identificam-se quais aplicativos estão sendo desenvolvidos e testados no PaaS. Em seguida, tentamos detectar ou descobrir as potenciais vulnerabilidades do aplicativo, como:

  • Falhas lógicas no aplicativo
  • Respostas lentas a consultas de usuários
  • Configuração incorreta de conexões de banco de dados

Muitas vezes, é possível localizar essas informações na documentação, incluindo códigos e logs.

Cenário do problema

Você descobre que um aplicativo que executa bem no local não executa tão bem como um aplicativo de software como serviço (SaaS). As vulnerabilidades de injeção de ataque do aplicativo (causadas pelo processamento de dados inválidos) aparecem durante a sua execução na nuvem.

Cenário de solução

Analise o código no aplicativo local e, em seguida, realize injeções de ataque simulado enquanto estiver no ambiente de teste PaaS.


Varredura de vulnerabilidade automatizada: upgrade do IaaS

Após o estágio de descoberta, procure por problemas de segurança conhecidos usando uma ferramenta de verificação de vulnerabilidade automatizada (ou várias) para combinar as condições com vulnerabilidades conhecidas.

Sobre o que é isso?

Este tipo de ferramenta configura automaticamente os níveis de risco, sem necessidade de intervenção humana para verificar ou interpretar os níveis. A ferramenta pode ser complementada com a varredura baseada em credenciais que ajuda a remover alguns falsos positivos comuns usando as credenciais fornecidas para autenticar um serviço de contas locais.

Cenário do problema

A Infraestrutura como serviço (IaaS) em que o PaaS executa é atualizada com a adição de máquinas virtuais que podem vir com vulnerabilidades ocultas.

Em um ambiente virtualizado, podem ser criadas zonas de isolamento e segurança ativadas por meio do uso de firewalls, roteadores, comutadores e dispositivos de IPS. O problema é que as máquinas virtuais (VMs) flutuam dentro do IaaS, e pode ser difícil fazer com que as regras de segurança do sistema acompanhem de forma consistente estas máquinas.

Cenário de solução

Obtenha ferramentas de gerenciamento de política de segurança e determine se os processos que regem o gerenciamento de máquinas virtuais estão em vigor. Isso garante que a mudança do local das VMs acionará a replicação de funções de segurança necessárias para o novo local.

Busque soluções compatíveis com virtualização. Sistemas e componentes de rede compatíveis com virtualização, ou compatíveis com VM, identificam VMs que ajudam uma ferramenta de console de gerenciamento centralizado a localizar, monitorar e atualizar essas VMs com políticas corretas e variáveis. Isso, por sua vez, ajuda a gerenciar as políticas de segurança de rede com o VMM/Hypervisor para maiores visibilidade e controle.


Processo de avaliação de vulnerabilidade: vulnerabilidades de diversos hosts

Construído sobre a fase de processo de descoberta e varredura de vulnerabilidade, o estágio do processo de avaliação é usado para identificar as vulnerabilidades de segurança.

Sobre o que é isso?

O processo de avaliação de vulnerabilidade coloca em teste as provas sobre as vulnerabilidades de segurança no ambiente PaaS. Um exemplo seria a remoção de falsos positivos comuns a partir do relatório e determinar os níveis de risco que devem ser aplicados a cada relatório de descobertas.

Cenário do problema

Um aplicativo de otimização de recursos em nuvem de uma desenvolvedora PaaS contribui para falsos positivos nos relatórios que um usuário acessou com sucesso no PaaS, quando, na realidade, o aplicativo falhou. A falha faz com que a plataforma PaaS seja completamente desligada. O aplicativo não identifica as falhas nem implementa tempos limites curtos. Isso afeta negativamente os dados de desempenho necessários para determinar as garantias de disponibilidade do acordo de nível de serviço (SLA).

A desenvolvedora PaaS não desenvolveu serviços simples constituídos por um host único; o host único permitiria criar instâncias de serviços replicados que podem sobreviver a falhas de host. Em vez disso, ela os construiu compreendendo vários hosts dependentes que, como descobriu tarde demais, não puderam sobreviver às falhas de host.

Vamos ver como a desenvolvedora construiu vários hosts dependentes. Se a desenvolvedora tiver um aplicativo de faturamento que consiste em componentes de lógica de negócios — A, B e C — ela pode compor um grupo de serviço como este:

Em (A1, B1, C1), (A2, B2, C2), (An, Bn, Cn), em que n é o número de tipo de componente que representa o número de uma categoria de grupo de serviço:

  • para a categoria de serviços 1:
    • A1 é a lógica para localizar o código de serviço.
    • B1 é a lógica para inserir a categoria de serviço na conta.
    • C1 é a lógica para verificar a precisão de CEPs.
  • para a categoria de serviços 2:
    • A2 é a lógica para localizar o código de serviço.
    • B2 é a lógica para inserir a categoria de serviço na conta.
    • C2 é a lógica para verificar a precisão de CEPs.
  • para a categoria de serviços n:
    • An é a lógica para localizar o código de serviço.
    • Bn é a lógica para inserir a categoria de serviço na conta.
    • Cn é a lógica para verificar a precisão de CEPs.

Devido aos longos tempos limites, o usuário é capaz de acessar o sistema quando o funcionamento do sistema estiver falhando.

Cenário de solução

Para corrigir o problema para que o sistema não falhe mais, a desenvolvedora decompõe os componentes em conjuntos independentes como este: (A1, A2,...An ), (B1, B2...Bn ), (C1, C2, ...Cn).

Isso permite que ela crie várias cópias de serviços redundantes em datacenters com bom funcionamento. Isso significa que, se o componente A1 falhar ou ficar lento, todos os outros componentes A2-An no mesmo conjunto independente não falharão. Da mesma forma, o segundo conjunto independente de componentes (B1-Bn) e o terceiro conjunto de componentes (C1-Cn) não falharão.

Como resultado, o usuário é capaz de acessar os sistemas com bom funcionamento. Os falsos positivos não aparecem nos resultados do relatório sobre o processo de avaliação de vulnerabilidade.


Processo de avaliação de segurança: Vulnerabilidades de injeção de nível limite

O processo de avaliação de segurança se baseia no processo de avaliação de vulnerabilidades, incluindo a verificação manual para confirmar o nível de exposição que pode ocorrer na fase de produção.

Sobre o que é isso?

O processo de avaliação de segurança não inclui a exploração de vulnerabilidades para ganhar acesso posterior. Isso poderia ser uma verificação sob a forma de acesso autorizado a um sistema para confirmar as configurações do sistema e envolver o exame de logs, respostas do sistema, mensagens de erro, códigos e validação da análise numérica.

Uma avaliação de segurança amplia a cobertura dos sistemas em teste. Ela não abrange a profundidade de exposição a que uma vulnerabilidade específica pode levar.

Cenário do problema

Quando a temporada de compras atinge o limite, o sistema detecta demandas de carga de trabalho mais elevadas. Em resposta, o sistema cria rapidamente instâncias adicionais de recursos para equilibrar as demandas de carga de trabalho de forma dinâmica. Isso requer usuários adicionais e um maior número de solicitações de dados para acessar o sistema.

Os recursos não necessários nunca são liberados devido a injeções de nível de limite, que fatalmente levam a uma falha no sistema. Não tem sido feito o acesso ao sistema para confirmar manualmente o nível de exposição que pode ocorrer na fase de produção.

Cenário de solução

Examinar manualmente logs, respostas do sistema, mensagens de erro e códigos para verificar o acesso autorizado ao sistema. Verifique manualmente se uma política de limite existe e determine o que os consumidores e fornecedores de serviços de computação em nuvem devem fazer para desenvolver as seguintes políticas:

  • Política de limite de recursos para garantir que o consumo seja equilibrado dinamicamente para aplicativos na nuvem que estejam abaixo ou no nível limite.
  • Política de limite de usuários para garantir que os usuários podem acessar o aplicativo simultaneamente até o limite especificado em uma licença de usuário do provedor abaixo ou no nível limite.
  • Política de limite de solicitação de dados para garantir que as solicitações de dados ao aplicativo possam ser processadas imediatamente abaixo ou no nível limite.

Teste de penetração: Vulnerabilidades de injeção LDAP/AD

O teste de penetração simula o PaaS sob ataque. Ele se baseia nas fases anteriores e testa a exploração de vulnerabilidades localizadas para ganhar maior acesso ao PaaS e ao IaaS.

Sobre o que é isso?

O teste de penetração testa a capacidade de um invasor de obter acesso a informações confidenciais e de afetar a integridade dos dados ou a disponibilidade de um serviço, e os seus respectivos efeitos sobre o PaaS.

Cada teste compara um ao outro sobre a capacidade do testador de usar suas habilidades de resolução de problemas empregando uma variedade de ferramentas de teste de penetração para localizar as vulnerabilidades que não seriam identificadas por ferramentas automatizadas. O teste de penetração também testa a capacidade de um defensor de detectar os ataques e responder adequadamente.

De acordo com o NIST SP 800-115 (Recursos ), a maioria das vulnerabilidades exploradas por testes de penetração inclui:

  • Erros de configuração
  • Estouros de buffer
  • Validação de entrada incorreta
  • Condições de disputa
  • Permissões incorretas de arquivos e diretórios

Um testador de penetração deve ser capaz de determinar quando parar antes que uma ação posterior cause danos ao PaaS e aos sistemas subjacentes. Isso poderia levar à perda de disponibilidade do sistema ou à exposição de dados confidenciais.

Cenário do problema

A exploração das vulnerabilidades de injeção de LDAP/AD resulta em um travamento do sistema. Hackers aproveitam a falha do aplicativo para neutralizar caracteres que têm significado especial em LDAP.

Muito parecida com a injeção de SQL, a injeção de LDAP ocorre quando as instruções LDAP são construídas com dados fornecidos pelo usuário que não são verificados no aplicativo. Isso resulta na execução de comandos arbitrários, como a concessão de permissões para consultas não autorizadas e mudanças no conteúdo dentro da árvore LDAP.

Cenário de solução

Explore usando ferramentas externas superiores de teste de penetração para testar o LDAP e as vulnerabilidades da injeção de SQL. A ferramenta deve cobrir outros tipos de vulnerabilidades de segurança, como Cross-Site Scripting (XSS), protocolos de autenticação impróprios e configurações impróprias de conexão ao banco de dados. Procure boas ferramentas de teste interno de penetração para testar se as políticas LDAP e de segurança são adequadas para proteger contra introdução acidental de injeções LDAP/AD.

Além disso, encontre boas ferramentas de teste de penetração local sem fio para testar wardriving (procura por redes WiFi vulneráveis em um veículo em movimento) e ataques do tipo man-in-the-middle. Certifique-se de que os protocolos de segurança sem fio sejam suficientemente seguros, e que os pontos de acesso e clientes (dispositivos móveis, laptops) estejam configurados corretamente. A configuração adequada poderá ser usada para evitar a representação de um laptop mal-intencionado, em uma tentativa de interceptar a comunicação do ponto de acesso do cliente que pode ser usado para injetar malwares no LDAP/AD. Use seu laptop ou desktop para descobrir redes sem fio desprotegidas que pertencem a você.


Processo de auditoria de segurança: Limite de falta de conformidade

Uma auditoria de segurança é uma avaliação sistemática da segurança do sistema de informações de uma empresa, medindo a sua qualidade de acordo com um conjunto de critérios de desempenho estabelecidos.

Sobre o que é isso?

As auditorias de segurança são, muitas vezes, usadas para determinar o nível de conformidade dos sistemas de informação para com os regulamentos legislativos, normas industriais e políticas de segurança. Usando as abordagens de ferramenta de segurança que cobrimos anteriormente, uma auditoria de segurança avalia a segurança dos sistemas de informação, os processos de manipulação das informações (classificadas versos não classificadas) e práticas de usuário.

Cenário do problema

Uma auditoria revela que não há níveis de limite, apesar de as abordagens anteriores da ferramenta de segurança corrigirem o problema. A auditoria conclui que quando os níveis de limite não estão configurados, um desenvolvedor não tem como saber:

  • Se o recurso é excessivamente consumido.
  • Se o número de desenvolvedores que tentam acessar o PaaS atingiu o limite especificado em uma licença de usuário.
  • Se as solicitações de dados que o desenvolvedor envia excederam o nível limite.

Cenário de solução

Um auditor deve recomendar o que os desenvolvedores devem fazer para desenvolver as seguintes políticas:

  • Política de limite de recursos para garantir que o consumo de recursos seja equilibrado dinamicamente para aplicativos na nuvem que estejam abaixo ou no nível limite.
  • Política de limite de usuários para garantir que os usuários podem acessar o aplicativo simultaneamente até o limite especificado em uma licença de usuário do provedor abaixo ou no nível limite.
  • Política de limite de solicitação de dados para garantir que as solicitações de dados ao aplicativo possam ser processadas imediatamente abaixo ou no nível limite.

A política de limite deve tratar de vulnerabilidades de análise numérica e de como lidar com elas. Resumindo, se os erros de truncamento e arredondamento excederem os limites aceitáveis, as métricas obtidas mostrarão perda de significância. Os desenvolvedores PaaS provavelmente têm mais conhecimento que o provedor no desenvolvimento de algoritmo numericamente estável que resolve um problema bem condicionado. Isso garantirá que a política de limite será estabelecida antes de você chegar à fase de revisão de segurança.


Processo de revisão de segurança: verificação de conformidade

A revisão de segurança implica verificar se políticas de segurança internas ou do segmento de mercado foram aplicadas aos componentes do sistema ou produto.

Sobre o que é isso?

A revisão de segurança é geralmente concluída por meio da análise da diferença ou por revisões do código ou pela revisão de documentos de design e diagramas de arquitetura. Ela não usa as outras abordagens de ferramentas de segurança — avaliação da vulnerabilidade, avaliação de segurança, teste de penetração ou auditoria de segurança.

Cenário do problema

Durante uma revisão de segurança, uma unidade organizacional não cumpriu integralmente com alguns aspectos do NIST Special Publication 800-115 no Guia Técnico sobre testes de Segurança da Informação e Avaliação.

Cenário de solução

Analise a documentação para determinar se os aspectos técnicos e de segurança das políticas e dos procedimentos estão atualizados e analise os logs para garantir que os controles de segurança estejam registrando as informações sobre o uso de PaaS e se a organização está aderindo às suas políticas de gerenciamento de log. Exemplos de informações de log:

  • Servidor de autenticação ou logs de sistema em tentativas de autenticação bem-sucedidas ou malsucedidas
  • Logs de sistemas de detecção e prevenção de intrusão sobre atividade maliciosa e uso inadequado
  • Logs de segurança que registram informações sobre os serviços e aplicativos vulneráveis conhecidos
  • Logs de limite que registram o nível dos limites de usuários, solicitações de dados e limites de recursos

Ferramentas automatizadas de auditoria devem estar disponíveis para reduzir o tempo de análise da maioria dos tipos de registro.


Conclusão

No planejamento de testes de segurança, considere as melhores práticas para a resolução de problemas de testes de segurança em cada fase do modelo. É necessário configurar um limite no número de vezes que você pode retornar a uma fase anterior para resolver problemas de testes antes de prosseguir para a próxima fase. Crie uma equipe de desenvolvedores, gerentes e analistas de negócios e facilite para que eles façam o seu trabalho na realização de testes de segurança em cada etapa de seu ciclo de vida.

Recursos

Aprender

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing
ArticleID=975625
ArticleTitle=Faça do PaaS o seu campo de testes de vulnerabilidade
publish-date=06032014