Modelagem de Ameaças
Nesta página
Neste módulo
A modelagem de ameaças permite identificar e classificar sistematicamente as ameaças que têm mais chances de afetar seu sistema.
Sua abordagem estruturada é muito mais econômica e eficiente do que a aplicação casual de recursos de segurança sem o conhecimento preciso das ameaças que cada recurso deve solucionar.
Depois de ler este módulo e aplicar a metodologia de modelagem de ameaças em seu aplicativo da Web, você terá identificado e classificado as ameaças existentes com base em um conhecimento sólido das vulnerabilidades do seu aplicativo. Com essas informações, será possível tratar as ameaças existentes com as contramedidas apropriadas em uma ordem lógica, começando pelas ameaças que apresentam maior risco.
Não existe um sistema 100% seguro quando um aplicativo da Web é exposto a ambientes hostis como a internet, uma intranet ou uma extranet. A única solução possível é reconhecer a presença das ameaças e mitigar ou gerenciar os riscos associados. A modelagem de ameaças permite realizar essa análise e concentrar os recursos nas questões relevantes, maximizando o retorno do investimento.
Objetivos
Utilize este módulo para:
| • | Criar modelos de ameaça. |
| • | Aprender a classificar ameaças e utilizar o modelo DREAD. |
| • | Decompor uma arquitetura de aplicativos e descobrir suas vulnerabilidades. |
| • | Identificar e documentar as ameaças relevantes para seu aplicativo. |
Aplicação
Aplicativos da Web
Como utilizar este módulo
Este módulo descreve um processo genérico que permite identificar e documentar as ameaças a seu aplicativo. Para aproveitar ao máximo este módulo:
| • | Estabeleça um processo para a modelagem de ameaças. Utilize este módulo como um ponto de partida para introduzir um processo de modelagem de ameaças em sua empresa, se ele ainda não existir. Se você já tiver um processo, poderá usá–lo como uma referência para comparação. | ||||||
| • | Utilize os outros módulos neste guia para se familiarizar com as ameaças mais comuns. Leia, "Ameaças e Contramedidas", para obter uma visão geral das ameaças comuns que ocorrem em redes, hosts e aplicativos.
| ||||||
| • | Desenvolva seu modelo de ameaça. Primeiro crie um modelo de ameaça e, em seguida, desenvolva–o conforme a necessidade. É um trabalho contínuo. As ameaças à segurança evoluem, assim como seu aplicativo. Ter um documento que identifique as ameaças conhecidas e como elas foram eliminadas (ou não) permite que você tenha o controle da segurança do seu aplicativo. |
Antes de começar
Antes de começar o processo de modelagem de ameaças, é importante compreender a terminologia básica a seguir:
| • | Bem. Um recurso de valor, como os dados de um banco de dados ou do sistema de arquivos. Um recurso do sistema. |
| • | Ameaça. Uma possível ocorrência, mal–intencionada ou não, que pode danificar ou comprometer seus bens. |
| • | Vulnerabilidade. Uma fraqueza em algum aspecto ou recurso de um sistema que torna uma ameaça possível. As vulnerabilidades podem existir na rede, no host ou no aplicativo. |
| • | Ataque (ou exploração). Uma ação realizada por alguém, ou alguma coisa, que danifica um ativo. Pode ser conseqüência de alguma ameaça ou alguém explorando uma vulnerabilidade. |
| • | Contramedida. Uma medida de segurança que elimina uma ameaça e atenua um risco. |
Considere a seguinte analogia: uma jóia em uma casa é um bem e um ladrão, um invasor. Uma porta é um recurso da casa e uma porta aberta representa uma vulnerabilidade. O ladrão pode explorar a porta aberta para obter acesso à casa e roubar a jóia. Em outras palavras, o invasor explora uma vulnerabilidade para obter acesso a um bem. A contramedida apropriada, nesse caso, seria fechar e trancar a porta.
Princípios da modelagem de ameaças
A modelagem de ameaças não deve ser um processo de execução única. Ela deve ser um processo repetitivo que começa durante as primeiras fases do projeto e continua durante todo o ciclo de vida do seu aplicativo. Existem dois motivos para isso. Primeiro, é impossível identificar todas as ameaças possíveis de uma só vez. Segundo, como os aplicativos raramente são estáticos e precisam ser aperfeiçoados e adaptados para atender às alterações das necessidades de negócios, o processo de modelagem de ameaças deve ser repetido sempre que seu aplicativo evoluir.
O processo
A figura 3.1 mostra o processo de modelagem de ameaças que você pode realizar por meio de um processo de seis etapas.
Observação: a descrição do processo a seguir pode ser utilizada tanto para aplicativos que estão atualmente em desenvolvimento quanto para aplicativos existentes.
Figura 3.1
Uma visão geral do processo de modelagem de ameaças
1. | Identificar os bens. |
2. | Criar uma visão geral da arquitetura. |
3. | Decompor o aplicativo. |
4. | Identificar as ameaças. |
5. | Documentar as ameaças. |
6. | Classificar as ameaças. |
O resultado
O resultado do processo de modelagem de ameaças é um documento para os vários membros de sua equipe de projetos. Ele permite entender claramente as ameaças que precisam ser eliminadas e como eliminá–las. Os modelos de ameaça são formados por uma definição da arquitetura de seu aplicativo e uma lista de ameaças para o cenário de seu aplicativo, como mostra a figura 3.2.
Figura 3.2
Componentes do modelo de ameaça
Etapa 1: Identificar os bens
Identifique os bens que você precisa proteger. Isso pode ir desde dados confidenciais, como o banco de dados de clientes ou pedidos, até as páginas da Web ou a disponibilidade do site.
Etapa 2: Criar uma visão geral da arquitetura
Nessa etapa, o objetivo é documentar a função de seu aplicativo, sua arquitetura e a configuração de implantação física, bem como as tecnologias que compõem a sua solução. Procure possíveis vulnerabilidades no projeto ou na implementação do aplicativo.
Durante esta etapa, as tarefas a seguir serão realizadas:
| • | L Identificar o que o aplicativo realiza. |
| • | Criar um diagrama da arquitetura. |
| • | Identificar as tecnologias. |
Identificar o que o aplicativo realiza
Identifique o que o aplicativo realiza e como ele utiliza e acessa os bens. Documente os casos de utilização para que você e outras pessoas entendam como o seu aplicativo deve ser utilizado. Isso também ajuda a entender como ele pode ser mal utilizado. Os casos de utilização colocam a funcionalidade do aplicativo em um contexto.
Eis alguns exemplos de casos de utilização para um aplicativo de recursos humanos com informações sobre funcionários:
| • | O funcionário exibe os dados financeiros. |
| • | O funcionário atualiza os dados pessoais. |
| • | O gerente exibe detalhes do funcionário. |
Nos casos acima, você pode analisar as implicações das regras de negócios mal utilizadas. Por exemplo, considere um usuário tentando modificar os detalhes pessoais de outro usuário. Segundo os requisitos definidos pelo aplicativo, ele não deveria ter acesso a esses detalhes.
Criar um diagrama da arquitetura
Crie um diagrama da arquitetura de alto nível, como o que aparece na figura 3.3, que descreva a composição e a estrutura do seu aplicativo, bem como seus subsistemas e suas características de implantação física. Dependendo da complexidade de seu sistema, talvez você precise criar diagramas adicionais que se concentrem em diferentes áreas, por exemplo, um diagrama para modelar a arquitetura de um servidor de aplicativo de camada intermediária ou um para servir de modelo para a interação com um sistema externo.
Figura 3.3
Exemplo do diagrama da arquitetura do aplicativo
Comece desenhando um esboço do diagrama que represente a composição e a estrutura do aplicativo e seus subsistemas juntamente com suas características de implantação. Em seguida, incremente o diagrama adicionando detalhes sobre os limites de confiança, autenticação e mecanismos de autorização à medida que você os descobre (geralmente durante a Etapa 3, quando o aplicativo é decomposto).
Identificar as tecnologias
Identifique as diferentes tecnologias utilizadas para implementar sua solução. Isso irá ajudá-lo a se concentrar nas ameaças específicas às tecnologias mais adiante nesse processo, além de ajudar a determinar as técnicas de mitigação corretas e mais apropriadas. As tecnologias que você provavelmente irá identificar incluem ASP.NET, Web Services, Serviços Corporativos, Microsoft .NET Remoting e ADO.NET. Identifique também os códigos não gerenciados que são chamados pelo seu aplicativo.
Documente as tecnologias utilizando uma tabela parecida com a tabela 3.1 abaixo.
Tabela 3.1. Tecnologias de implementação
| Tecnologia/Plataforma | Detalhes da implementação |
Microsoft SQL Server no Microsoft Windows Advanced Server 2000 | Inclui logons, usuários de banco de dados, funções de banco de dados definidas pelo usuário, procedimentos armazenados, modos de exibição, restrições e disparadores. |
Microsoft .NET Framework | Utilizado para a autenticação de formulários. |
SSL (Secure Sockets Layer) | Utilizado para criptografar o tráfego HTTP. |
Etapa 3: Decompor o aplicativo
Nesta etapa, você divide seu aplicativo em partes para criar um perfil de segurança para o aplicativo tomando por base as áreas tradicionais de vulnerabilidade. Você também identifica limites de segurança, fluxo de dados, pontos de entrada e código privilegiado. Quanto mais você souber sobre a mecânica de seu aplicativo, mais fácil será descobrir as ameaças. A figura 3.4 aponta os alvos para o processo de decomposição.
Figura 3.4
Alvos para a decomposição do aplicativo
Durante esta etapa, as tarefas a seguir serão realizadas:
| • | Identificar os limites de confiança. |
| • | Identificar o fluxo de dados. |
| • | Identificar os pontos de entrada. |
| • | Identificar o código privilegiado. |
| • | Documentar o perfil de segurança. |
Identificar os limites de confiança.
Identifique os limites de segurança que cercam cada bem tangível de seu aplicativo. Esses bens são determinados pelo projeto do seu aplicativo. Para cada subsistema, considere se os fluxos de dados upstream ou a entrada do usuário é confiável e, se não for, considere como os fluxos de dados e as entradas podem ser autenticados e autorizados. Considere, também, se o código de chamada é confiável e, se não for, imagine como ele pode ser autenticado e autorizado. Você deve ser capaz de garantir que os gatekeepers adequados protejam todos os pontos de entrada de um determinado limite de segurança e que o ponto de entrada do destinatário valide totalmente todos os dados que passem por um limite de confiança.
Comece analisando os limites de segurança a partir de uma perspectiva do código. O conjunto, que representa uma forma de limite de confiança, é um bom local para começar. Quais conjuntos confiam em quais outros conjuntos? Um determinado conjunto confia no código que o chama ou usa a segurança de acesso ao código para autorizar o código de chamada?
Considere, também, as relações de confiança do servidor. Um determinado servidor confia em um servidor upstream para autenticar e autorizar os usuários finais ou o servidor fornece seus próprios serviços de gatekeeping? Além disso, um servidor confia em um servidor upstream para lhe passar dados bem–formados e corretos?
Por exemplo, na figura 3.3, o aplicativo Web acessa o servidor do banco de dados utilizando uma identidade fixa e confiável que, nesse caso, é a conta de processo do aplicativo da Web ASPNET. Sendo assim, o servidor do banco de dados confia no aplicativo para autenticar e autorizar os chamadores e encaminhar somente dados válidos de solicitação de dados em nome de usuários autorizados.
Nota: em um aplicativo do .NET Framework, o conjunto define a menor unidade de confiança. Sempre que os dados são passados por um limite de conjunto — o qual, por definição, inclui um domínio de aplicativo, processo ou limite de máquina — o ponto de entrada do destinatário deve validar os dados fornecidos.
Identificar o fluxo de dados
Uma abordagem simples é começar pelo nível mais alto e decompor, por partes, o aplicativo analisando o fluxo de dados entre os subsistemas individuais. Por exemplo: analise o fluxo de dados entre o aplicativo da Web e um aplicativo dos Serviços Corporativos e, em seguida, entre componentes de serviço individuais.
O fluxo de dados entre os limites de confiança é extremamente importante pois o código que recebe dados externos ao seu próprio limite de segurança deve presumir que os dados são mal–intencionados e realizar a validação dos dados.
Observação: os DFDs (Diagramas de Fluxo de Dados) e os diagramas seqüenciais podem ajudar na decomposição formal de um sistema. Um DFD é uma representação gráfica de fluxos de dados, armazenamentos de dados e relações entre fontes e destinos de dados. Um diagrama seqüencial mostra como um grupo de objetos colabora em termos de eventos cronológicos.
Identificar os pontos de entrada
Os pontos de entrada de seu aplicativo também servem como pontos de entrada para ataques. Eles incluem aplicativos da Web front-end que escutam solicitações HTTP. Esse ponto de entrada foi criado para ser exposto aos clientes. Outros pontos de entrada, como pontos de entrada internos expostos por subcomponentes nas camadas do aplicativo, podem existir somente para suportar a comunicação interna com outros componentes. Entretanto, você deve saber onde eles estão e quais tipos de entrada eles recebem caso um invasor consiga passar pela porta da frente do aplicativo e atacar diretamente um ponto de entrada interno.
Para cada ponto de entrada, você deve ser capaz de determinar os tipos de gatekeepers que fornecem autorização e o grau de validação.
Os pontos de entrada lógicos dos aplicativo incluem interfaces de usuário fornecidas por páginas da Web, interfaces de serviço fornecidas por Web Services, componentes de serviço e componentes .NET Remoting e filas de mensagens que fornecem pontos de entrada assíncronos. Os pontos de entrada físicos ou de plataforma incluem portas e soquetes.
Identificar o código privilegiado
O código privilegiado acessa tipos específicos de recursos seguros e realiza outras operações privilegiadas. Os tipos de recursos seguros incluem servidores DNS, serviços de diretório, variáveis de ambiente, logs de eventos, sistemas de arquivo, filas de mensagens, contadores de desempenho, impressoras, o registro, soquetes e Web Services. As operações seguras incluem chamadas de código não gerenciado, reflexão, serialização, permissões de segurança de acesso ao código e manipulação da diretiva de segurança de acesso ao código, inclusive provas.
A diretiva de segurança de acesso ao código deve conceder ao código privilegiado as permissões de segurança de acesso ao código apropriadas. O código privilegiado deve garantir que os recursos e as operações que ele encapsula não sejam expostos a um código não confiável e possivelmente mal–intencionado. A segurança de acesso ao código .NET Framework verifica as permissões concedidas ao código de chamada realizando "stack walks". No entanto, às vezes é necessário substituir esse comportamento e encurtar toda a stack walk, por exemplo, quando você deseja restringir o código privilegiado com um modo seguro ou isolar de outro modo o código privilegiado. Fazer isso abre seu código para ataques chamariz, em que o código mal–intencionado chama seu código por meio de um código intermediário confiável.
Sempre que você substituir o comportamento de segurança padrão fornecido pela segurança de acesso ao código, faça–o de modo diligente e com as proteções apropriadas. Para obter mais informações sobre como revisar o código para localizar falhas de segurança, consulte, "Revisão do Código". Para obter mais informações sobre a segurança de acesso ao código, consulte, "Segurança do Acesso ao Código na Prática" e, "Utilizando a Segurança do Acesso ao Código com o ASP.NET".
Documentar o perfil de segurança
Em seguida, você deve identificar as abordagens do projeto e da implementação utilizadas para a validação da entrada, autenticação, autorização, gerenciamento de configuração e as áreas restantes em que os aplicativos são mais suscetíveis a vulnerabilidades. Ao realizar isso, você cria um perfil de segurança para o aplicativo.
A tabela a seguir mostra os tipos de pergunta que devem ser feitos ao analisar cada aspecto do projeto e da implementação de seu aplicativo. Para obter mais informações sobre como revisar a arquitetura e o projeto do aplicativo, consulte, "Revisão da Segurança da Arquitetura e do Projeto".
Tabela 3.2. Criando um perfil de segurança
| Categoria | Considerações |
Validação de entrada | Todos os dados de entrada são validados? |
Autenticação | Ao serem passadas pela rede, as credenciais são protegidas? |
Autorização | Quais gatekeepers são utilizados nos pontos de entrada do aplicativo? |
Gerenciamento de configuração | Quais interfaces de administração o aplicativo suporta? |
Dados confidenciais | Quais dados confidenciais são manipulados pelo aplicativo? |
Gerenciamento da sessão | Como os cookies de sessão são gerados? |
Criptografia | Quais algoritmos e técnicas criptográficas são utilizados? |
Manipulação de parâmetros | O aplicativo detecta os parâmetros violados? |
Gerenciamento de exceções | Como o aplicativo manipula as condições de erro? |
Auditoria e log | O seu aplicativo audita as atividades em todas as camadas em todos os servidores? |
Etapa 4: Identificar as ameaças
Nesta etapa, você identifica as ameaças que podem afetar seu sistema e comprometer seus bens. Para conduzir esse processo de identificação, reúna os membros das equipes de desenvolvimento e de testes para uma sessão de debate em sala de aula. É uma maneira simples, porém eficaz, de identificar ameaças em potencial. De preferência, a equipe deve ser formada por arquitetos do aplicativo, profissionais de segurança, desenvolvedores, testadores e administradores de sistema.
Você pode utilizar duas abordagens básicas:
| • | Utilizar o modelo STRIDE para identificar as ameaças. Considere as amplas categorias de ameaças, como o spoofing, a violação e a negação de serviço, e utilize o modelo STRIDE, "Ameaças e Contramedidas" para realizar perguntas em relação a cada aspecto da arquitetura e do projeto de seu aplicativo. Esta é uma abordagem com base em objetivos em que são considerados os objetivos de um invasor. Por exemplo, um invasor poderia falsificar uma identidade para acessar seu servidor ou aplicativo da Web? Alguém poderia adulterar os dados na rede ou em um armazenamento? Alguém poderia negar o serviço? |
| • | Utilizar listas de categorias para as ameaças. Nessa abordagem, você começa com uma lista de ameaças comuns agrupadas por categorias de rede, host e aplicativos. Em seguida, a lista de ameaças é aplicada em sua própria arquitetura de aplicativo e em qualquer outra vulnerabilidade que você tenha identificado anteriormente no processo. Você será capaz de tratar excluir imediatamente algumas ameaças pois não se aplicam ao seu cenário. |
Use os recursos a seguir para ajudá-lo no processo de identificação das ameaças:
| • | Para obter uma lista de ameaças organizadas por rede, host e camadas de aplicativo, bem como explicações das ameaças e das contramedidas associadas, consulte, "Ameaças e Contramedidas". |
| • | Para obter uma lista de ameaças por tecnologia, consulte a seção "Ameaças e contramedidas" no início de cada módulo "Criando" na Parte III deste guia. |
Durante esta etapa, as tarefas a seguir serão realizadas:
| • | Identificar as ameaças de rede. |
| • | Identificar as ameaças de host. |
| • | Identificar as ameaças de aplicativo. |
Identificar as ameaças de rede
Esta é uma tarefa para designers e administradores de rede. Analise a topologia da rede e o fluxo de pacotes de dados, além das configurações do roteador, firewall e switch e procure possíveis vulnerabilidades. Também preste atenção aos pontos de extremidade da VPN (Rede Virual Privada). Examine as defesas de rede contra as ameaças de camada de rede mais comuns identificadas, "Ameaças e Contramedidas".
As principais ameaças de rede a considerar durante a fase do projeto incluem:
| • | Utilizar mecanismos de segurança que dependem do endereço IP do remetente. É relativamente fácil enviar pacotes IP com endereços IP de origem falsa (spoofing de IP). |
| • | Passar identificadores de sessão ou cookies por canais de rede não criptografados. Isso pode levar ao seqüestro da sessão de IP. |
| • | Passar credenciais de autenticação de texto não criptografado ou outros dados confidenciais por canais de comunicação não criptografados. Isso permitiria a um invasor monitorar a rede, obter credenciais de logon e, possivelmente, adulterar outros dados confidenciais. |
Você também deve garantir que sua rede não seja vulnerável a ameaças que surgem da configuração não protegida de dispositivo e servidor. Por exemplo, as portas e os protocolos desnecessários estão fechados e desativados? As tabelas de roteamento e o servidor DNS estão protegidos? As pilhas de rede TCP estão protegidas em seus servidores? Para obter mais informações sobre como evitar esse tipo de vulnerabilidade, consulte, "Protegendo sua Rede".
Identificar as ameaças de host
A abordagem utilizada neste guia ao configurar a segurança do host (ou seja, a configuração do Microsoft Windows 2000 e do .NET Framework) é dividir a configuração em categorias separadas para permitir que você aplique configurações de segurança de maneira estruturada e lógica. Essa abordagem também é adequada para a revisão da segurança, a detecção de vulnerabilidades e a identificação de ameaças. As categorias de configuração comuns aplicáveis a todas as funções do servidor incluem correções e atualizações, serviços, protocolos, contas, arquivos e diretórios, compartilhamentos, portas e auditoria e log. Para cada categoria, identifique as definições de configuração possivelmente vulneráveis. A partir delas, identifique as ameaças.
As principais vulnerabilidades a considerar são:
| • | A manutenção de servidores sem patch que podem ser explorados por vírus, cavalos de Tróia, worms e ataques IIS conhecidos. |
| • | A utilização de portas, protocolos e serviços não essenciais, que aumentam o perfil de ataque e permitem que os invasores reúnam informações e explorem o ambiente. |
| • | A permissão de acesso anônimo não autenticado. |
| • | A utilização de senhas de baixa segurança e de diretivas de conta que levam ao deciframento de senhas, falsificação de identidade e ataques de negação de serviço caso as contas possam ser travadas deliberadamente. |
Identificar as ameaças de aplicativo
Nas etapas anteriores, você definiu a arquitetura, o fluxo de dados e os limites de confiança de seu aplicativo. Você também criou um perfil de segurança que descreve como o aplicativo lida com as áreas fundamentais, como a autenticação, a autorização e o gerenciamento de configuração e outras áreas.
Agora, utilize as amplas categorias de ameaça STRIDE e as listas de ameaças predefinidas para investigar cada aspecto do perfil de segurança de seu aplicativo. Concentre-se nas ameaças do aplicativo, ameaças específicas da tecnologia e ameaças de código. As principais vulnerabilidades a considerar incluem:
| • | Utilizar a validação de entrada de baixa segurança que leva ao XSS (cross-site scripting), inclusão de código SQL e ataques de estouro de buffer. |
| • | Enviar credenciais ou cookies de autenticação por links de rede não criptografados e que podem levar à captura da credencial ou ao seqüestro da sessão. |
| • | Utilizar senhas de baixa segurança e diretivas de conta, que podem levar ao acesso não autorizado. |
| • | Não proteger aspectos de gerenciamento de configuração de seu aplicativo, inclusive as interfaces de administração. |
| • | Armazenar segredos de configuração, como seqüências de conexão e credenciais de conta de serviço, em texto não criptografado. |
| • | Utilizar processos e contas de serviço excessivamente privilegiados. |
| • | Utilizar técnicas de codificação de acesso a dados não protegidas que podem aumentar a ameaça causada pela inclusão de código SQL. |
| • | Utilizar criptografia de baixa segurança ou personalizada e a proteção inadequada ou não proteção das chaves de segurança. |
| • | Confiar na integridade dos parâmetros passados por meio do navegador da Web, por exemplo, campos de formulário, seqüências de consulta, dados de cookie e cabeçalhos HTTP. |
| • | Utilizar a manipulação de exceções desprotegida, o que pode levar a ataques de negação de serviço e à divulgação de detalhes do sistema úteis a um invasor. |
| • | Realizar auditoria e o log inadequados, que podem levar a ameaças de repúdio. |
Utilizando árvores e padrões de ataque
As árvores e os padrões de ataque são as principais ferramentas dos profissionais de segurança. Não são componentes essenciais da fase de identificação de ameaças, mas podem ser úteis. Elas permitem analisar as ameaças em maior profundidade, indo além do que você já sabe, para identificar outras possibilidades.
Importante: quando você usa listas de categorias de ameaças conhecidas previamente preparadas, elas revelam apenas as ameaças comuns e conhecidas. Abordagens adicionais, como a utilização de árvores e padrões de ataque, podem ajudá-lo a identificar possíveis ameaças.
Uma árvore de ataque é um meio de agrupar e documentar os possíveis ataques a um sistema de um modo estruturado e hierárquico. A estrutura de árvore apresenta uma subdivisão descritiva de vários ataques que o invasor usa para comprometer o sistema. Ao criar árvores de ataque, você cria uma representação reutilizável de questões de segurança que ajudam a concentrar os esforços. Sua equipe de testes pode criar planos de teste para validar o projeto de segurança. Os desenvolvedores podem realizar trocas durante a implementação e os arquitetos ou lideranças de desenvolvimento podem avaliar o custo de segurança de abordagens alternativas.
Os padrões de ataque são uma abordagem formal para a captura de informações de ataque em sua empresa. Esses padrões ajudam a identificar técnicas comuns de ataque.
Criando árvores de ataque
Embora várias abordagens possam ser utilizadas, na prática o método mais aceito é identificar os objetivos e sub–objetivos de um ataque, bem como o que deve ser realizado para que o ataque seja bem–sucedido. Você pode utilizar um diagrama hierárquico para representar sua árvore de ataque ou utilizar uma simples descrição. O que importa, no final, é que você tenha algo que retrate o perfil do ataque de seu aplicativo. Dessa forma, você avalia os prováveis riscos de segurança que podem ser mitigados com a contramedida apropriada, como corrigir uma abordagem do projeto, proteger uma definição de configuração e outras soluções.
Construa uma árvore de ataque criando nós raiz que representem os objetivos do invasor. Em seguida, adicione nós de folha, que são as metodologias de ataque representando ataques únicos. A figura 3.5 aponta um exemplo simples.
Figura 3.5
Representação de uma árvore de ataque
Você pode rotular os nós folha com os rótulos E e OU. Por exemplo, na figura 3.5, tanto 1.1 quanto 1.2 devem ocorrer para que a ameaça resulte em um ataque.
As árvores de ataque, como a que aparece acima, têm uma tendência de se tornarem complexas rapidamente. Elas também demoram para serem criadas. Uma abordagem alternativa preferida por algumas equipes é estruturar sua árvore de ataque utilizando uma estrutura de tópicos como a mostrada abaixo.
1. Goal One
1.1 Sub-goal one
1.2 Sub-goal two
2. Goal Two
2.1 Sub-goal one
2.2 Sub-goal two
Observação: além dos objetivos e sub–objetivos, as árvores de ataque incluem as metodologias e as condições necessárias ao ataque.
Veja um exemplo da abordagem da estrutura de tópicos em ação:
Threat #1 Attacker obtains authentication credentials by monitoring the network
1.1 Clear text credentials sent over the network AND
1.2 Attacker uses network-monitoring tools
1.2.1 Attacker recognizes credential data
Para obter um exemplo completo, consulte "Árvores de ataque de exemplo" na seção "Cheat Sheets" deste guia.
Padrões de ataque
Os padrões de ataque são representações genéricas de ataques comuns e que podem ocorrer em vários contextos diferentes. O modelo define o objetivo do ataque bem como as condições que devem existir para que o ataque ocorra, as etapas necessárias para realizar o ataque e o resultado do ataque. Os padrões de ataque se concentram em técnicas de ataque, enquanto as abordagens com base no STRIDE se concentram nos objetivos do invasor.
Um exemplo de um padrão de ataque é o padrão de ataque de inclusão de código que é utilizado para descrever os ataques de inclusão de código de maneira genérica. A tabela 3.3 descreve o modelo de ataque de inclusão de código.
Tabela 3.3 Padrão de ataque de inclusão de código
| Padrão | Ataques de inclusão de código |
Objetivos do ataque | Execução do comando ou do código |
Condições necessárias | Validação de entrada de baixa segurança. |
Técnica de ataque | 1. Identificar o programa no sistema de destino com uma vulnerabilidade de validação de entrada. |
Resultado do ataque | O código do invasor é executado e realiza uma ação mal–intencionada. |
Para obter mais informações sobre modelos de ataque, consulte a seção "Mais informações" no final deste módulo.
Etapa 5: Documentar as ameaças
Para documentar as ameaças de seu aplicativo, utilize um modelo parecido com o que é mostrado abaixo e que mostre vários atributos de ameaça. A descrição da ameaça e o destino da ameaça são atributos essenciais. Deixe a classificação de risco em branco nesta etapa. Ela será utilizada na etapa final do processo de modelagem de ameaças quando você priorizar a lista de ameaças identificadas. Outros atributos que talvez você queira incluir são as técnicas de ataque, que também podem destacar as vulnerabilidades exploradas, e as contramedidas, necessárias para tratar a ameaça.
Tabela 3.4. Ameaça 1
| Descrição da ameaça | O invasor obtém credenciais de autenticação por meio do monitoramento da rede |
Alvo da ameaça | Processo de autenticação do usuário do aplicativo da Web |
Risco |
|
Técnicas de ataque | Utilização de software de monitoramento da rede |
Contramedidas | Utilizar o SSL para fornecer o canal criptografado |
Tabela 3.5 Ameaça 2
| Descrição da ameaça | Inclusão de comandos SQL |
Destino da ameaça | Componente de acesso a dados |
Risco |
|
Técnicas de ataque | O invasor anexa comandos SQL ao nome de usuário, o qual é utilizado para formar uma consulta SQL |
Contramedidas | Utilizar uma expressão regular para validar o nome de usuário e um procedimento armazenado que utilize parâmetros para acessar o banco de dados. |
Etapa 6: Classificar as ameaças
Nessa etapa do processo, você tem uma lista de ameaças que se aplicam ao cenário específico do seu aplicativo. Na etapa final do processo, você classifica as ameaças com base nos riscos que elas representam. Isso permite tratar as ameaças que apresentam o maior risco primeiro e, depois, resolver as outras ameaças. Na verdade, pode não ser economicamente viável tratar todas as ameaças identificadas e talvez você opte por ignorar algumas pois a chance delas ocorrerem é pequena e o dano resultante seria mínimo.
Risco = Probabilidade * Danos em potencial
Essa fórmula indica que o risco causado por determinada ameaça é igual à probabilidade de a ameaça ocorrer multiplicada pelo possível dano, o que significa as conseqüências para seu sistema caso um ataque ocorra.
Você pode utilizar uma escala de probabilidade de 1–10, em que 1 representa uma ameaça difícil de ocorrer e 10 representa uma quase certeza. Do mesmo modo, você pode utilizar uma escala de 1–10 para os danos em potencial, em que 1 indicaria danos mínimos e 10 uma catástrofe. Com a utilização dessa abordagem, o risco representado por uma ameaça com uma baixa probabilidade de ocorrer, mas com alto potencial de dano, é igual ao risco causado por uma ameaça com potencial de dano limitado, mas que é extremamente provável de ocorrer.
Por exemplo, se Probabilidade=10 e Danos em potencial=1, então Risco = 10 * 1 = 10. Se Probabilidade=1 e Danos em potencial=10, Risco = 1 * 10 = 10.
Essa abordagem resulta em uma escala de 1–100, e você pode dividir a escala em três faixas para gerar uma classificação de risco Alto, Médio ou Baixo.
Classificações Alto, Médio e Baixo
Você pode utilizar uma escala Alto, Médio ou Baixo simples para priorizar as ameaças. Se uma ameaça for classificada como de Alto risco, ela tem um risco significativo em um aplicativo e precisa ser eliminada o mais rápido possível. As ameaças de Médio risco precisam ser eliminadas, mas com menos urgência. Você pode optar por ignorar as ameaças de Baixo risco dependendo do tamanho do esforço e do custo necessários para acabar com a ameaça.
DREAD
O problema com um sistema de classificação simplista é que os membros da equipe geralmente não irão concordar com as classificações. Para resolver isso, adicione novas dimensões que ajudem a determinar o que o impacto de uma ameaça de segurança realmente significa. Na Microsoft, usa-se o modelo DREAD para a calcular o risco. Ao utilizar o modelo DREAD, você chega à classificação de risco de uma determinada ameaça realizando as perguntas a seguir:
| • | Damage potential (Danos em potencial): qual será o tamanho do dano se a vulnerabilidade for explorada? |
| • | Reproducibility (Reprodutibilidade): quão fácil é a reprodução do ataque? |
| • | Exploitability (Explorabilidade): quão fácil é a incialização de um ataque? |
| • | Affected users (Usuários afetados): de forma geral, qual a porcentagem de usuários afetados? |
| • | Discoverability (Possibilidade de descobrimento): quão fácil é a localização da vulnerabilidade? |
Você pode utilizar os itens acima para classificar cada uma das ameaças. Além disso, você também pode ampliar as questões acima de modo que elas atendam às suas necessidades. Por exemplo, você poderia adicionar uma questão sobre um possível dano à reputação:
Reputação: qual o tamanho dos riscos? Existe um risco para a reputação que poderia levar à perda de confiança do cliente?
Não é preciso realizar uma classificação em grande escala, pois isso dificulta a classificação consistente das ameaças entre si. Você pode utilizar um esquema simples como Alto (1), Médio (2) e Baixo (3).
Quando você define claramente o que cada valor representa para seu sistema de classificação, isso ajuda a evitar confusão. A tabela 3.6 mostra um exemplo típico de uma tabela de classificação que pode ser utilizada por membros da equipe ao priorizar ameaças.
Tabela 3.6. Tabela de classificação de ameaças
| Classificação | Alto (3) | Médio (2) | Baixo (1) | |
D | Danos em potencial | O invasor pode subverter o sistema de segurança; obter autorização de confiança total; executar como administrador; carregar o conteúdo. | Vazamento de informações confidenciais | Vazamento de informações triviais |
R | Reprodutibilidade | O ataque pode ser reproduzido o tempo todo e não exige uma janela de intervalo. | O ataque pode ser reproduzido, mas somente com uma janela de intervalo e em uma situação de corrida específica. | O ataque é muito difícil de reproduzir, mesmo com conhecimento das brechas de segurança. |
E | Explorabilidade | Um programador iniciante poderia realizar o ataque em um curto período de tempo. | Um programador experiente poderia realizar o ataque e, em seguida, repetir as etapas. | O ataque exige sempre uma pessoa extremamente experiente e com amplos conhecimentos para a exploração. |
A | Usuários afetados | Todos os usuários, configuração padrão, clientes principais | Alguns usuários, configuração não–padrão | Uma porcentagem muito pequena de usuários, recurso obscuro; afeta usuários anônimos |
D | Possibilidade de descobrimento | Informações publicadas explicam o ataque. A vulnerabilidade é encontrada no recurso utilizado com mais freqüência e é muito notável. | A vulnerabilidade está em uma parte raramente utilizada do produto e somente alguns usuários devem encontrá–la. Seria preciso pensar um pouco para ver a utilização mal–intencionada. | O erro é obscuro e é improvável que os usuários descubram o potencial de dano. |
Depois de realizar as perguntas acima, conte os valores (1–3) para uma determinada ameaça. O resultado estará dentro do intervalo de 5–15. Em seguida, você pode tratar as ameaças com classificações gerais de 12–15 como Alto risco, 8–11 como risco Médio, e 5–7 como Baixo risco.
Por exemplo, considere as duas ameaças descritas anteriormente:
| • | O invasor obtém credenciais de autenticação por meio do monitoramento da rede. |
| • | Inclusão de comandos SQL no aplicativo. |
A tabela 3.7 mostra uma classificação DREAD de exemplo para essas duas ameaças:
Tabela 3.7. Classificação DREAD
| Ameaça | D | R | E | A | D | Total | Classificação |
O invasor obtém credenciais de autenticação por meio do monitoramento da rede. | 3 | 3 | 2 | 2 | 2 | 12 | Alto |
Inclusão de comandos SQL no aplicativo. | 3 | 3 | 3 | 3 | 2 | 14 | Alto |
Após obter a classificação de risco, atualize as ameaças documentadas e adicione o nível de classificação descoberto, Alto, no caso das duas ameaças acima. A tabela 3.8 mostra um exemplo.
Tabela 3.8 Ameaça 1
| Descrição da ameaça | O invasor obtém credenciais de autenticação por meio do monitoramento da rede |
Alvo da ameaça | Processo de autenticação do usuário do aplicativo da Web |
Classificação do risco | Alto |
Técnicas de ataque | Utilização de software de monitoramento da rede |
Contramedidas | Utilizar o SLL para fornecer o canal criptografado |
O que vem depois da modelagem de ameaças?
O resultado do processo de modelagem de ameaças inclui a documentação dos aspectos de segurança da arquitetura de seu aplicativo e uma lista das ameaças classificadas. O modelo de ameaça ajuda você a orquestrar os membros da equipe de desenvolvimento e se concentrar nas ameaças mais potentes.
Importante: a modelagem de ameaças é um processo repetitivo. O modelo de ameaça é um documento que evolui e com o qual vários membros da equipe devem trabalhar.
O modelo de ameaça pode ser utilizado pelos grupos de pessoas a seguir:
| • | Os designers podem utilizá–lo para realizar opções de projeto seguras quanto a tecnologias e funcionalidades. |
| • | Os desenvolvedores que gravam o código podem usá-lo para minimizar os riscos. |
| • | Os testadores pode gravar casos de teste para testar se o aplicativo é vulnerável às ameaças identificadas pela análise. |
Gerando um Relatório de Item de Trabalho
A partir do modelo de ameaça inicial, você pode criar um relatório de item de trabalho mais formal que inclua atributos adicionais, como uma Identificação de erros, que possam ser utilizados para juntar a ameaça com seu sistema de monitoramento de erros favorito. Na verdade, você pode optar por inserir as ameaças identificadas em seu sistema de monitoramento de erros e utilizar seus recursos de relatório para gerar o relatório. Você também pode incluir uma coluna de status para indicar se o erro foi ou não corrigido. Certifique-se de que o relatório inclua o número da ameaça original para anexá-la de volta ao documento do modelo de ameaça.
Organize as ameaças no relatório por categorias de rede, host e aplicativo. Isso facilita a utilização do relatório por parte dos diferentes membros da equipe em funções diferentes. Dentro de cada categoria, apresente as ameaças por ordem de prioridade, começando por aquelas classificadas como de alto risco e seguindo para as que representam menos riscos.
Resumo
Embora você possa minimizar o risco de um ataque, a ameaça real não diminui ou é eliminada. As ameaças ainda existem independentemente das ações de segurança realizadas e das contramedidas aplicadas. A realidade no mundo da segurança é que você reconhece a presença das ameaças e gerencia seus riscos. A modelagem de ameaças pode ajudá-lo a gerenciar e comunicar riscos de segurança em sua equipe.
Trate a modelagem de ameaças como um processo repetitivo. Seu modelo de ameaça deve ser um item dinâmico que muda com o tempo de modo a acrescentar os novos tipos de ameaças e ataques à medida que eles são descobertos. Ele também deve ser capaz de se adaptar para seguir a evolução natural de seu aplicativo à medida que ele é aperfeiçoado e modificado de modo a adequar-se às mudanças nos requisitos de negócios.
Mais informações
Para continuar lendo sobre o assunto, consulte os recursos a seguir:
| • | Para obter mais informações sobre modelos de ataque, consulte "Attack Modeling for Information Security and Survivability," por Andrew P. Moore, Robert J. Ellison, and Richard C. Linger em http://www.cert.org/archive/pdf/01tn001.pdf (em inglês). |
| • | Para obter informações sobre como avaliar ameaças, ativos e vulnerabilidades, consulte "Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0" no site da Carnegie Mellon Software Engineering Institute na Web em http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html (em inglês). |
| • | Para uma visão geral da modelagem de ameaças, consulte "Architect WebCast:Using Threat Models to Design Secure Solutions" em http://www.microsoft.com/usa/webcasts/ondemand/1617.asp (em inglês). |
| • | Para obter mais informações sobre como criar DFDs, consulte Writing Secure Code, Second Edition, por Michael Howard, David C. LeBlanc. |