Modelagem de Ameaças de Segurança

Elaboração de Modelos de Ameaças

Microsoft Corporation

Janeiro 2004

Neste Módulo

A elaboração de modelos de ameaças permite que você identifique, de maneira sistemática, e estime as ameaças que mais atacam o seu sistema.

A elaboração de modelos de ameaças possui uma abordagem estruturada que é muito mais financeiramente efetiva do que aplicar recursos de segurança de maneira casual, sem saber precisamente quais ameaças devem ser tratadas.

Após ler este módulo e aplicar a metodologia de elaboração de modelos de ameaças à sua aplicação, você terá identificado e estimado as ameaças existentes, baseado em um sólido entendimento de vulnerabilidades da sua aplicação. Com estas informações, você pode tratar as ameaças existentes com medidas apropriadas em uma ordem lógica, começando com aquelas que apresentam maiores riscos.

Nada é 100% seguro quando uma aplicação é exposta a ambientes hostis, tais como a Internet, uma intranet ou uma extranet. A única solução possível é saber da presença de ameaças e reduzir ou gerenciar os riscos associados. A elaboração de modelos de ameaças permite que você avalie esta análise e se concentre em recursos de questões relevantes, maximizando o retorno de investimentos.

Objetivos

Este módulo tem como objetivos:

• Criar modelos de ameaças.

• Aprender como estimar ameaças e usar o modelo DREAD.

• Decompor uma arquitetura de aplicação e descobrir suas vulnerabilidades.

• Identificar ameaças de documentos relevantes para a sua aplicação.

Aplica-se a:

Aplicações da Web

Como Utilizar Este Módulo

Este módulo estrutura um processo genérico que permite a você identificar e documentar ameaças à sua aplicação. Para obter o máximo deste módulo:

• Estabeleça um processo para a elaboração de modelos. Use-o como ponto de partida para introduzir um processo de elaboração de modelos de ameaças em sua organização caso você ainda não tenha um. Se você já possui um processo, então pode usá-la como referência para comparação.

• Use os outros módulos neste manual para se familiarizar com as ameaças mais comuns. Leia o módulo "Ameaças e Contramedidas" (em inglês) para obter uma visão das ameaças comuns que ocorrem na rede, no host e níveis de aplicação.

  • Para ameaças mais específicas, consulte "Ameaças e Contramedidas " no módulo "Protegendo a sua Rede" (em inglês).

  • Para ameaças mais específicas em seu servidor Web, servidor de aplicação e de banco de dados, consulte "Ameaças e Contramedidas" nos módulos "Protegendo o seu Servidor da Web," "Protegendo o seu Servidor de Aplicação," e "Protegendo o seu Servidor de Banco de Dados." (em inglês).

  • Para ameaças mais específicas do ASP.NET, componentes de serviço e remotos, Web Services e acesso a dados, consulte "Ameaças e Contramedidas" nos módulos "Construindo Partes Seguras;" "Construindo Páginas e Controles Seguros do ASP.NET;" "Construindo Componentes de Serviços;" "Construindo Web Services Seguros;" "Construindo Componentes Remotos Seguros;" e "Construindo Acesso a Dados Seguros." (em inglês).

• Desenvolva o seu modelo de ameaças. Projete um modelo antes e depois o desenvolva, se necessário. Isso é um trabalho progressivo. As ameaças se desenvolvem e depois a sua aplicação também. Ter um documento que identifique as ameaças e como elas devem ser tratadas (ou não) faz com que você tenha controle da segurança da sua aplicação.

Nesta página

Antes de Começar
Princípios da Elaboração de modelos de Ameaças
Passo 1: Identificar os Recursos
Passo 2: Criar uma Arquitetura
Passo 3: Decompor a Aplicação
Passo 4: Identificar as Ameaças
Passo 5: Documentar as Ameaças
Passo 6: Estimar as Ameaças
O que vem depois da Elaboração de modelos de Ameaças?
Sumário
Recursos Adicionais

Antes de Começar

Antes de iniciar o processo de elaboração de modelos de ameaças, é importante que você entenda a seguinte terminologia básica:

• Recurso. Um recurso de valor, tal como os dados no banco de dados ou em um sistema de arquivo. Um recurso do sistema.

• Ameaça. Uma ocorrência potencial, maliciosa que pode danificar ou comprometer seus recursos.

• Vulnerabilidade. Uma fraqueza ou recurso de um sistema que torna uma ameaça possível. As vulnerabilidades podem existir na rede, no host ou nos níveis de aplicação.

• Ataque (ou exploração). Uma ação realizada por algo ou alguém que prejudica um recurso. Pode ser alguém que segue em direção a uma ameaça ou explora uma vulnerabilidade.

• Medida. Uma garantia que trata a ameaça e reduz o risco.

Considere uma simples analogia doméstica: uma jóia, dentro de uma casa, é um recurso e o assaltante é o invasor. Uma porta é um recurso da casa e uma porta aberta representa uma vulnerabilidade. O assaltante pode explorar a porta aberta para obter acesso a casa e roubar a jóia. Em outras palavras, o invasor explora uma vulnerabilidade para obter acesso a um recurso. A medida apropriada, neste caso, é trancar a porta.

Princípios da Elaboração de modelos de Ameaças

A elaboração de modelos de ameaças não deve ser um processo de momento. Deve ser um processo iterativo que começa durante as primeiras fases de projeto da sua aplicação e continua durante seu ciclo de vida. Há duas razões para isso. Primeiro, é impossível identificar todas as ameaças possíveis em um único passo. Segundo porque, como as aplicações são raramente estáticas e precisam ser aprimoradas e adaptadas para se adequarem aos requisitos corporativos, o processo de elaboração de modelos deve ser repetido sempre que a aplicação se desenvolve.

O Processo

A Figura 1 mostra o processo de elaboração de modelos que você pode desenvolver usando um processo de seis estágios.

Nota O processo que segue pode ser usado para aplicações que estão em andamento e para as já existentes.

Figura 1. Uma visão geral do processo de elaboração de modelos de ameaças.

• Identificar os recursos.
  Identifique os recursos valiosos que seus sistemas devem proteger.

• Crie um resumo da arquitetura.
  Use diagramas e tabelas simples para documentar a arquitetura da sua aplicação, incluindo subsistemas, limites de confiança e fluxo de dados.

• Decompor a aplicação.
  Decomponha a arquitetura da sua aplicação, incluindo a rede principal e projeto de infra-estrutura de rede para criar um perfil de segurança para a aplicação. O objetivo do perfil de segurança é dar cobertura às vulnerabilidades no design, implementação ou configuração de implantação da sua aplicação.

• Identifique as ameaças.
  Ter em mente os objetivos de um invasor e o conhecimento da arquitetura e das vulnerabilidades potenciais de sua aplicação identifica as ameaças que poderiam afetar a sua aplicação.

• Documente as ameaças.
  Documente cada ameaça usando um modelo comum de ameaça que defina um conjunto principal de atributos para cada ameaça.

• Estime as ameaças.
  Estime as ameaças para priorizar e tratar primeiro as mais significativas. Essas ameaças representam o maior risco. O processo de estimativa mede a probabilidade da ameaça contra os danos que poderiam ocorrer caso um ataque ocorra. Deve-se prever que certas ameaças não garantem nenhuma ação quando você compara o risco apresentado pela ameaça com os custos resultantes de redução.

O Produto

O produto da ameaça a partir do processo de elaboração de modelos é um documento para vários membros do projeto. Ele permite-lhes entender perfeitamente as ameaças que precisam ser tratadas e como fazer isso. Os modelos de ameaças consistem de uma definição da arquitetura da aplicação e de uma lista de ameaças para o seu cenário da aplicação, como mostra a Figura 2.

Figura 2. Componentes do modelo de ameaça.

Passo 1: Identificar os Recursos

Identifique os recursos que você precisa proteger. Isso pode variar desde dados confidenciais, tais como bancos de dados de pedidos dos clientes, até suas páginas da Web ou disponibilidade do site.

Passo 2: Criar uma Arquitetura

Nesta página, o objetivo é documentar a função da sua aplicação, sua arquitetura e configuração física da implantação, além das tecnologias que fazem parte da sua solução. Você deve estar procurando vulnerabilidades potenciais no projeto e implementação da aplicação.

Durante este passo, você desempenha as seguintes tarefas:

• Identificar o que a aplicação faz.

• Criar um diagrama da arquitetura.

• Identificar as tecnologias.

Identificar o que a Aplicação Faz

Identifique o que a aplicação faz e de que forma ela utiliza e acessa os recursos. Documente os casos de uso para ajudar você e outras pessoas a entender como a sua aplicação deve ser usada. Isso também o ajuda a descobrir como ela não deve ser usada. Os casos de uso colocam no contexto a funcionalidade da aplicação.

Aqui estão alguns casos de uso modelos para a aplicação de recursos humanos do funcionário e auto-serviço:

• O funcionário exibe os dados financeiros.

• O funcionário atualiza seus dados pessoais.

• O gerente visualiza os detalhes do funcionário.

Nos casos acima você pode ver as implicações dos papéis corporativos sendo mal utilizados. Por exemplo, considere que um usuário está tentando modificar detalhes pessoais de outro usuário. Ele não está autorizado a acessar esses detalhes, de acordo com os requisitos definidos na aplicação.

Criar um Diagrama da Arquitetura

Crie um diagrama de alto nível da arquitetura que descreva a composição e estrutura da sua aplicação e seus subsistemas, assim como as características físicas de implantação, tal como o diagrama da figura 3. Dependendo da complexidade do seu sistema, você pode ter a necessidade de criar diagramas adicionais focados em diferentes áreas, por exemplo, um diagrama que projete a arquitetura de um servidor de aplicação de camada média, ou um para modelar a interação com sistemas externos.

Figura 3. Diagrama exemplo de arquitetura da aplicação.

Comece desenhando um esboço que traga a composição e estrutura da aplicação e seus subsistemas, juntamente com suas características de implantação. Depois desenvolva o diagrama adicionando detalhes sobre os limites de confiança, autenticação e mecanismos de autorização assim que você os descobrir (geralmente durante o Passo 3, quando você decompõe a aplicação).

Identificar as Tecnologias

Identifique as diferentes tecnologias usadas para implementar a sua solução. Isso o ajuda a focar em ameaças específicas da tecnologia, mais adiante no processo. Também ajuda a determinar as técnicas de redução mais corretas e apropriadas. As tecnologias que você provavelmente pode identificar incluem o ASP.NET, Web Services, Enterprise Services, Microsoft .NET Remoting e ADO.NET. Identifique também um código não gerenciado que a sua aplicação chama.

Documente as tecnologias usando uma tabela parecida com a Tabela 1 abaixo.

Tabela 1. Tecnologias de Implementação.

Tecnologia / Plataforma	Detalhes da Implementação
Microsoft SQL Server no Microsoft Windows Advanced Server 2000	Incluem logins, usuários de bancos de dados, papéis de bancos de dados definidos pelo usuário, procedimentos armazenados, views, locks e triggers.
Microsoft .NET Framework	Usados para autenticação de Formulários.
Secure Sockets Layer (SSL)	Usados para criptografar tráfego HTTP.

Passo 3: Decompor a Aplicação

Neste passo, você interrompe a sua aplicação para criar um perfil de segurança baseado em áreas tradicionais de vulnerabilidades. Você identifica limites de confiança, fluxo de dados, pontos de entrada e código privilegiado. Quanto mais você conhecer os mecanismos de sua aplicação, mais fácil será tratar as ameaças. A Figura 4 mostra os diversos alvos para o processo de decomposição.

Figura 4. Alvos para a decomposição da aplicação.

Durante este passo, você realiza as seguintes tarefas:

• Identificar limites de confiança.

• Identificar o fluxo de dados.

• Identificar os pontos de entrada.

• Identificar código privilegiado.

• Documentar o perfil de segurança.

Identificar Limites de Confiança

Identifique os limites de confiança que rondam cada um dos recursos tangíveis da sua aplicação. Esses recursos são determinados pelo projeto da sua aplicação. Para cada subsistema, considere se os dados funcionam ou a entrada do usuário é confiável, e se não, leve em conta como os fluxos de dados e entradas podem ser autenticadas e autorizadas. Considere também se o código de chamada é confiável, e, se ele não for, veja se ele pode ser autenticado e autorizado. Você deve poder assegurar-se de que os guardiões estão protegendo todos os pontos de entrada em um limite de confiança particular e que o ponto de entrada recebedor valida completamente todos os dados que passam através de um limite de confiança.

Comece analisando os limites de confiança a partir de uma perspectiva de código. Uma parte, que representa uma forma de limite de confiança, é um lugar útil para se começar. Quais partes confiam em outras partes? Uma parte específica confia no código que a chama ou ela 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 servidor particular confia em um outro para autenticar e autorizar os usuários finais ou o servidor fornece seus próprios serviços de segurança? Além disso, um servidor confia noutro para passar dados corretos e bem formatados?

Por exemplo, na Figura 3, a aplicação acessa o servidor do banco de dados usando uma identidade fixa e confiável que, neste caso, é a conta do processo de aplicação do ASPNET. Neste cenário, o servidor de banco de dados confia na aplicação para autenticar e autorizar os callers, encaminhando somente dados válidos de solicitação de usuários autorizados.

Nota Em uma aplicação do .NET Framework, a parte define a menor unidade da confiança. Sempre que os dados passam através de um limite-que, por definição, inclui um domínio da aplicação, processo e limite de máquina-o ponto de entrada do recebedor deve validar seus dados de entrada.

Identificar o Fluxo de Dados

Uma maneira simples é começar no mais alto nível e, então, decompor iterativamente a aplicação, analisando o fluxo de dados entre os subsistemas individuais. Por exemplo, analise o fluxo de dados entre uma aplicação da Web e uma do Enterprise Services, e depois entre os componentes individuais de serviços.

O fluxo de dados através de limites de confiança é particularmente importante, pois o código, que são dados passados de for a de seu limite, deve presumir que os dados são maliciosos e fazem a total validação de dados.

Nota Os diagramas de fluxo de dados (DFDs) e de seqüência podem ajudar na decomposição de um sistema. Um DFD é uma representação gráfica de fluxos de dados, armazenamento de dados e relações entre fontes de dados e destinos. Eles mostram como um grupo de objetos colabora em termos de eventos cronológicos.

Identificar Pontos de Entrada

Os pontos de entrada da sua aplicação servem como pontos de ataques. Esses pontos de entrada podem incluir aplicações front-end que ouvem as solicitações HTTP. Este ponto de entrada deve ser exposto aos clientes. Outros pontos, como os internos expostos por subcomponentes através de camadas da sua aplicação, podem existir somente para suportar a comunicação interna com outros componentes. No entanto, você deve saber onde eles estão e que tipos de entrada eles recebem no caso de um invasor gerenciar, passando a porta de entrada da aplicação e atacando diretamente um ponto de entrada interno.

Para cada ponto de entrada, você deve poder determinar os tipos de guardiões que fornecem autorização e o grau de validação.

Os pontos de entrada lógicos da aplicação incluem interfaces de usuários fornecidas por páginas da Web, Web services, componentes de serviços e componentes do .NET Remoting e filas de mensagens que fornecem pontos de entrada assíncronos. 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 desempenha outras operações privilegiadas. Entre os tipos seguros de recursos estão os servidores DNS, serviços de diretório, variáveis de ambiente, logs de evento, sistemas de arquivos, filas de mensagens, medidores de desempenho, impressoras, o registro, soquetes e Web Services. Entre as operações seguras estão as 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 segurança de acesso ao código, incluindo a evidência.

O código privilegiado pode garantir as permissões de segurança apropriadas pela sua diretiva para o acesso ao código. O código privilegiado deve assegurar que os recursos e operações que ele encapsula não estão expostos a um código não confiável e potencialmente malicioso. A segurança de acesso ao código do .NET Framework verifica as permissões garantidas ao código de chamada, realizando rotas de pilhas. No entanto, às vezes é necessário ultrapassar este comportamento e encurtar a rota de pilhas, por exemplo, quando você deseja restringir código privilegiado com uma sandbox ou então isolá-lo. Fazer isso abre o seu código para atrair os ataques, em que os códigos maliciosos chamam o seu código intermediário confiável.

Sempre que você ultrapassar o comportamento padrão oferecido pela segurança de acesso ao código, faça isso conscientemente e com a segurança apropriada. Para mais informações sobre este assunto, consulte o módulo "Revisão sobre o Código de Segurança." Para mais informações sobre a segurança de acesso ao código, consulte os módulos "Segurança de Acesso ao Código em Prática" e "Usando a Segurança de Acesso ao Código com o ASP.NET." (em inglês).

Documentar o Perfil de Segurança

Em seguida, você deve identificar o projeto e a implementação usados para a validação de entrada, a autenticação, autorização, gerenciamento de configuração e outras áreas em que as aplicações são mais suscetíveis a vulnerabilidades. Fazendo isso, você cria um perfil de segurança para a aplicação.

A tabela que segue mostra os tipos de questões a serem feitas enquanto se analisa cada aspecto do projeto e implementação. Para mais informações sobre a arquitetura e projeto da aplicação, consulte o módulo"Revisão da Arquitetura e Projeto para a Segurança." (em inglês).

Tabela 2. Criando um Perfil de Segurança.

Categoria	Considerações
Validação de entrada	Todos os dados de entrada estão validados? Um invasor poderia injetar comandos ou dados maliciosos na aplicação? Os dados são validados enquanto passam entre limites de confiança separados (pelo ponto de entrada recebedor)? Os dados do banco de dados podem ser confiáveis?
Autenticação	As credenciais estão seguras se passarem pela rede? As diretivas fortes de segurança são utilizadas? As senhas fortes são reforçadas? Você está usando certificados? Os verificadores de senha (que usam hash de mão única) são usados para as senhas dos usuários?
Autorização	Quais guardiões estão sendo usados nos pontos de entrada da aplicação? Como a autorização é reforçada no banco de dados? A estratégia de defesa profunda está sendo usada? Você obtém falhas seguras e somente permite acesso sob confirmação bem sucedida de credenciais?
Gerenciamento da configuração	Que interfaces de administração a aplicação suporta? Como elas são protegidas? Como a administração remota é protegida? Quais armazenamentos de configuração são usados e como eles são protegidos?
Dados sensitivos	Que dados sensitivos são controlados pela aplicação? Como eles são protegidos pela rede e armazenamentos persistentes? Que tipo de encriptação é usado e como suas chaves são utilizadas?
Gerenciamento da sessão	Como as cookies de sessão são geradas? Como elas são protegidas para prevenir roubos? Como o estado persistente de sessão é protegido? Como o estado de sessão é protegido quando ele cruza a rede? De que forma a aplicação autentica com o armazenamento de sessão? As credenciais passam pela rede e são mantidas pela aplicação? Em caso afirmativo, de que forma elas são protegidas?
Criptografia	Quais algoritmos e técnicas criptográficas são usados? De quanto tempo são as chaves de encriptação e como elas são protegidas? A aplicação coloca em ação a sua própria encriptação? Com que freqüência as chaves são recicladas?
Manipulação do Parâmetro	A aplicação detecta parâmetros falsificados? Ela valida todos os parâmetros em campos de formulários, estado de áreas de visão, dados de cookie e cabeçalhos http?
Gerenciamento de Exceção	Como a aplicação controla condições de erros? As exceções têm sempre permissão para voltar ao cliente? As mensagens genéricas de erros que não contêm informações exploradas são usadas?
Auditoria e logging	A sua aplicação auditora atividades através de todas as camadas em todos os servidores? Como são protegidos os arquivos de log?

Passo 4: Identificar as Ameaças

Neste passo, você identifica as ameaças que podem afetar o seu sistema e comprometer seus recursos. Para conduzir este processo de identificação, traga membros que fazem parte do desenvolvimento e equipes de teste para conduzir uma sessão de brainstorming junto ao quadro. Essa é uma maneira simples, porém efetiva, de identificar ameaças potenciais. Basicamente, a equipe consiste de arquitetos de aplicação, profissionais de segurança, desenvolvedores, testadores e administradores de sistemas.

Você pode utilizar duas abordagens básicas:

• Use o STRIDE para identificar ameaças. Leve em conta essas amplas categorias de ameaças, tais como falsificação, plágios, acessos negados de serviço, e utilize o modelo STRIDE do módulo "Ameaças e Contramedidas" (em inglês) para fazer perguntas referentes a cada aspecto da arquitetura e design de sua aplicação. Essa é uma abordagem baseada em objetivos em que você considera os objetivos de um invasor. Por exemplo, um invasor pode falsificar uma identidade para acessar seu servidor ou aplicação? Alguém pode adulterar dados através da rede? Alguém pode negar um serviço?

• Use listas de ameaças categorizadas. Com este conceito, você começa com uma ampla lista de ameaças comuns agrupadas por rede, host e categorias de aplicação. Em seguida, aplique a lista à sua arquitetura de aplicações e a quaisquer vulnerabilidades que tenha identificado no processo. Você será capaz de regulamentar algumas ameaças imediatamente, pois elas não se aplicam ao seu cenário.

Utilize os seguintes recursos para ajudá-lo com o processo de identificação de ameaças:

• Para obter uma lista de ameaças organizadas por rede, host e camadas de aplicação, assim como explicações sobre Ameaças e Contramedidas, consulte o módulo "Ameaças e Contramedidas." (em inglês).

• Par obter uma lista de ameaças por tecnologia, consulte "Ameaças e Contramedidas" ao início de cada um dos módulos de "Construção", na parte III deste manual.

Durante este passo, você irá realizar as seguintes tarefas:

• Identificar ameaças de rede.

• Identificar ameaças de hosts.

• Identificar ameaças de aplicação.

Identificar ameaças de rede

Esta é uma tarefa para designers e administradores de rede. Analise a topologia de rede e o fluxo de pacote de dados, junto com o roteador, firewall e configurações de switch, procurando as vulnerabilidades potenciais. Preste atenção também aos pontos da virtual private network (VPN). Veja as defesas da rede contra as ameaças mais comuns à camada de rede no módulo "Ameaças e Contramedidas." (em inglês).

Entre as principais ameaças de rede durante a fase de projeto estão:

• Usar mecanismos de segurança que contam com endereço IP do remetente. É relativamente fácil enviar pacotes IP com endereços IP de origem falsos (IP spoofing).

• Passar os identificadores de sessão ou cookies sobre canais de rede criptografados. Isso pode levar ao roubo da sessão de IP.

• Passar credenciais de autenticação em texto plano ou outros dados sensitivos sobre canais de comunicação não criptografados. Isso permite que um invasor monitore a rede, obtenha credenciais de logon ou falsifique outros itens de dados sensitivos.

Você também deve se certificar de que a sua rede não está vulnerável a ameaças que chegam de dispositivos inseguros ou configurações de servidor. Por exemplo, as portas desnecessárias e protocolos estão fechados e desabilitados? As tabelas de roteamento e servidor DNS estão seguros? As pilhas da rede TCP estão fortes no seu servidor? Para mais informações sobre a prevenção deste tipo de vulnerabilidade, consulte o módulo "Protegendo a sua Rede." (em inglês).

Identificar Ameaças de Hosts

A abordagem usada neste manual, ao configurar a segurança do host (ou seja, configuração do Microsoft Windows 2000 e .NET Framework) é dividir a configuração em categorias separadas para permitir que você aplique as definições de maneira lógica e estruturada. Esse conceito também é igualmente adequado para verificar a segurança, vulnerabilidades a falsificações e identificação de ameaças. As categorias mais comuns aplicáveis a todos os papéis de servidores incluem correções e atualizações, serviços, protocolos, contas, arquivos e diretórios, compartilhamentos, portas e auditoria e logging. Para cada categoria, identifique as definições potencialmente vulneráveis de configuração. A partir disso, identifique as ameaças.

As vulnerabilidades a serem consideradas são:

• Manter servidores não atualizados, o que pode gerar vírus, cavalos de tróia, worms e os famosos ataques ao IIS.

• Usar portas desnecessárias, protocolos, serviços, o que aumenta o perfil de ataque e permite que os invasores obtenham informações e explorem o seu ambiente.

• Permitir acesso anônimo não autenticado.

• Usar senhas fracas e diretivas de contas que levam à descoberta da senha, falsificação da identidade e ataques de negação de serviços, caso as contas possam ser deliberadamente desbloqueadas.

Identificar Ameaças da Aplicação

No passo anterior, você definiu a arquitetura, o fluxo de dados e limites de confiança da aplicação. Também criou um perfil de segurança que descreve como uma aplicação controla as principais áreas, tais como autenticação, autorização, gerenciamento de configuração e outras áreas.

Agora use as categorias STRIDE e listas pré-definidas para detalhar cada aspecto do perfil de segurança. Concentre-se nas ameaças da aplicação e nas específicas da tecnologia, e as ameaças de códigos. Entre as principais vulnerabilidades estão:

• Usar validação pobre de entrada que leva ao cross-site scripting (XSS), injeção de SQL e ataques de estouro de buffer.

• Passar credenciais de autenticação ou cookies pelos links não criptografados da rede, o que pode levar ao roubo ou captura de credenciais.

• Usar senhas fracas e diretivas de conta, levando ao acesso não autorizado.

• Falhar ao proteger os aspectos de gerenciamento da configuração, incluindo interfaces de administração.

• Armazenar segredos de configuração, tais como strings de conexão e credenciais de conta de serviço, em texto puro.

• Usar processo sobre privilegiado e contas de serviço.

• Usar técnicas inseguras de códigos de acesso aos dados, o que pode aumentar as ameaças à injeção SQL.

• Usar encriptação fraca ou usual e falhar na proteção adequada das chaves de encriptação.

• Contar com a integridade de parâmetros passados do navegador, por exemplo, de campos de formulários, strings de consultas, dados de cookie e cabeçalhos HTTP.

• Usar tratamento inseguro de exceções, que podem levar a ataques de negação de serviço e divulgação de detalhes em nível de sistema, úteis para o invasor.

• Fazer auditoria e logging inadequados, levando as ameaças de rejeição.

Usar Árvores e Padrões de Ataque

As árvores e padrões de ataques são as principais ferramentas utilizadas pelos profissionais de segurança. Elas não são componentes essenciais da fase de identificação, mas você pode considerá-las úteis. Elas permitem que você analise profundamente, indo além do que você já conhece, para identificar outras possibilidades.

Importante Quando você utiliza as listas categorizadas previamente preparadas de ameaças conhecidas, elas somente revelam a você essas ameaças mais comuns. Conceitos adicionais, como o uso de árvores de ataques e padrões, podem ajudá-lo a identificar outras ameaças potenciais.

Uma árvore de ataque é a maneira de coletar e documentar ataques potenciais em seu sistema, de maneira estruturada e hierárquica. Essa estrutura fornece a você uma análise descritiva de vários ataques que o invasor usa para comprometer o sistema. Ao criar árvores de ataques, você cria uma representação reutilizável de questões de segurança, que ajuda a focar nas reais tentativas. A sua equipe de teste pode criar planos testes para validar o projeto de segurança. Os desenvolvedores podem fazer alterações durante a implementação e os arquitetos e desenvolvedores podem avaliar o custo de segurança e conceitos alternativos.

O padrão de ataque é um conceito formalizado para capturar informações da sua empresa. Esses padrões podem ajudá-lo a identificar as técnicas comuns de ataques.

Criando Árvores de ataques

Enquanto diversas teorias podem ser usadas na prática, o método aceitável é identificar os objetivos e sub-objetivos de um ataque, assim como o que deve ser feito para que o ataque seja bem sucedido. Você pode utilizar um diagrama hierárquico para representar a árvore de ataque, ou apenas uma estrutura. O que importa, na verdade, é que você tenha algo que represente o perfil de ataque da aplicação. Você então pode avaliar os riscos mais prováveis de segurança, os quais podem ser reduzidos com as medidas adequadas, tal como corrigir uma abordagem no projeto, fortalecer uma definição da configuração e outras soluções.

Comece construindo uma árvore de ataque, criando nós de raiz que representem os objetivos do invasor. Depois adicione os nós finais, que são as metodologias de ataque que representam os ataques únicos. A figura 5 mostra um exemplo simples.

Figura 5. Representação de uma árvore de ataque.

Você pode rotular os nós finais com rótulos AND e OR. Por exemplo, na figura 5, tanto o 1.1 como o 1.2 podem ocorrer para que a ameaça resulte em um ataque.

Árvores de ataques como essa mostrada acima tem a tendência de se tornarem rapidamente complexas. Elas levam tempo para serem criadas. Uma alternativa preferida por algumas equipes é estruturar a sua árvore de ataque usando uma estrutura como a que aparece abaixo.

1.  Objetivo Um
    1.1 Sub-objetivo um
    1.2 Sub-objetivo dois
2.  Objetivo Dois
    2.1 Sub-objetivo um
    2.2 Sub-objetivo dois

Nota Além dos objetivos e sub-objetivos, as árvores de ataques incluem metodologias e condições exigidas.

Aqui segue um exemplo abordagem estruturada em ação:

Ameaça #1 Invasor obtém credenciais de autenticação monitorando a rede
  1.1 Credenciais em texto puro enviadas pela rede AND
  1.2 Invasor usa ferramentas de monitoramento da rede
      1.2.1 Invasor reconhece os dados da credencial

Para um exemplo completo, consulte "Exemplos de Árvores de Ataques " na seção "Cheat Sheets" deste manual.

Padrões de Ataques

Os padrões de ataques são representações genéricas de ataques que ocorrem comumente e podem acontecer em diferentes contextos. O padrão define o objetivo do ataque, assim como as condições que podem existir para que ele ocorra, os passos exigidos para realizar o ataque e os resultados do ataque. Os padrões de ataque são focados em suas técnicas, enquanto as abordagens do STRIDE são focadas aos objetivos do invasor.

Um exemplo deste tipo de ataque é o padrão de injeção de código usado para descrever os ataques de injeção de código de maneira genérica. A tabela 3.3 descreve esse padrão.

Tabela 3 Padrão de Ataque de Injeção de Código

Padrão	Ataques de Injeção de Código
Objetivos do Ataque	Execução de comando ou código
Condições exigidas	Validação fraca de entrada Código de um invasor possui privilégios suficientes no servidor.
Técnica de ataque	Identifique o programa ou sistema alvo com uma vulnerabilidade de validação de entrada. Crie um código para injetar e executar usando o contexto de segurança da aplicação alvo. Construa valor de entrada para inserir código de inserção no endereço da aplicação alvo e force uma corrupção de pilha que faça com que a execução da aplicação pule para o código injetado.
Resultados do Ataque	Código do invasor executa e realiza ações maliciosas.

Para mais informações sobre padrões de ataque, consulte a seção "Referências Adicionais" ao final deste módulo.

Passo 5: Documentar as Ameaças

Para documentar as ameaças da sua aplicação, use um modelo que mostre diversos atributos parecidos com o que segue abaixo. A descrição e alvo da ameaça são atributos essenciais. Deixe a estimativa de risco em branco nesta fase. Ela é usada no estágio final do processo de elaboração de modelos de ameaças quando você prioriza a lista identificada. Outros atributos você pode querer incluir nas técnicas de ataque, que também podem destacar as vulnerabilidades exploradas e as medidas exigidas para tratar a ameaça.

Tabela 4. Ameaça 1.

Descrição da ameaça	O invasor obtém credenciais de autenticação monitorando a rede
Alvo da ameaça	Processo de autenticação de usuário da aplicação
Risco
Técnicas de ataque	Uso do software de monitoramento da rede
Medidas	Uso do SSL para fornecer canal criptografado

Tabela 5. Ameaça 2.

Descrição da ameaça	Injeção de Comandos do SQL
Alvo da ameaça	Componente de acesso a dados
Risco
Técnicas de ataque	O invasor anexa comandos do SQL para nome de usuário, usado para formar uma consulta do SQL
Medidas	Use uma expressão regular para validar o nome de usuário e um procedimento armazenado que utilize parâmetros de acesso ao banco de dados.

Passo 6: Estimar as Ameaças

Neste estágio do processo, você tem uma lista de ameaças que se aplicam ao seu cenário particular da aplicação. No passo final do processo, você estima as ameaças baseado nos riscos que elas impõem. Isso permite que você trate as ameaças que apresentam os maiores riscos e depois resolva as outras. De fato, isso pode não ser economicamente viável para tratar todas as ameaças identificadas, e você pode decidir ignorar algumas, pois a chance de elas ocorrerem é pequena e os danos são mínimos.

Risco = Probabilidade * Potencial de Danos

Esta fórmula indica que o risco apresentado por uma ameaça particular é igual à probabilidade de ela ocorrer multiplicada pelo potencial de danos, que indica as conseqüências ao seu sistema caso um ataque esteja para ocorrer.

Você pode usar a escala de 1 a 10 para a probabilidade, em que 1 representa a ameaça que não é provável e 10 representa uma certeza próxima. Da mesma maneira, você pode utilizar uma escala de 1 a 10 para danos potenciais, em que 1 indica danos mínimos e 10 uma catástrofe. Usando este conceito, o risco apresentado por uma ameaça com uma baixa probabilidade de ocorrer, mas com grande potencial de danos, é igual ao risco apresentado pela ameaça com potencial limitado de danos, mas extremamente possível de ocorrer.

Por exemplo, se Probabilidade=10 e Potencial de Danos=1, então Risco = 10 * 1 = 10. Se Probabilidade=1 e Potencial de Danos=10, então Risco = 1 * 10 = 10.

Este conceito resulta em uma escala de 1 a 100, e você pode dividi-la em três áreas para gerar uma estimativa Alta, Média ou Baixa.

Estimativas Alta, Média e Baixa

Você pode usar uma escala simples de Alta, Média e Baixa para priorizar as ameaças. Se uma ameaça é estimada como Alta, ela tem risco significativo à sua aplicação e precisa ser tratada o mais rápido possível. As ameaças Médias devem ser tratadas, mas com menos urgência. Você pode decidir ignorar as baixas, dependendo de quanto esforço e custo ela exigirá para ser tratada.

DREAD

O problema com um sistema simplista de estimativa é que os membros da equipe geralmente não concordam com os índices. Para ajudar a resolver isso, adicione novas dimensões que determinem o impacto que uma ameaça de segurança significa. Na Microsoft, o modelo DREAD é usado para ajudar a calcular o risco. Usando este modelo, você chega à estimativa do risco de certa ameaça, fazendo as seguintes perguntas:

• Potencial de Danos (Damage): Qual o tamanho do dano se a vulnerabilidade for explorada?

• Capacidade de Reprodução (Reprodution): Com que facilidade um ataque é reproduzido?

• Capacidade de Exploração (Exploration): Com que facilidade um ataque é lançado?

• Usuários afetados (Affected): Quantos usuários são afetados?

• Descoberta (Discovery): Com que facilidade é encontrada a vulnerabilidade?

Você pode usar os itens acima para estimar cada ameaça, podendo também estender as questões para suprir suas necessidades. Por exemplo, você pode adicionar uma questão sobre danos potenciais de reputação:

Reputação: Qual a intensidade dos riscos? Há risco para a reputação, que pode levar à perda da confiança do cliente?

As estimativas não devem usar uma larga escala, pois se torna difícil medir as ameaças juntamente uma com a outra. Você pode utilizar um esquema simples com Alto (1), Médio (2), e Baixo (3).

Quando você define claramente o que cada valor representa para o seu sistema de estimativa, ajudará a evitar a confusão. A tabela 6 mostra um exemplo típico de uma tabela de estimativa que pode ser usada pelos membros da equipe quando estão priorizando as ameaças.

Tabela 6. Tabela de Estimativa de Ameaças.

	Estimativa	Alta (3)	Média (2)	Baixa (1)
D	Damage potential	O invasor pode subverter o sistema de segurança; obter autorização de confiança completa; executar como administrador; carregar conteúdo.	Perda de informações sensitivas	Perda de informações triviais
R	Capacidade de reprodução	O ataque pode ser reproduzido sempre e não requer uma janela de timing.	O ataque pode ser reproduzido, mas somente com janela de timing e situação particular.	O ataque é muito difícil de reproduzir, mesmo com conhecimento do papel de segurança.
E	Explorabilidade	Um programador novato pode fazer o ataque em pouco tempo.	Um programador capacitado pode atacar e depois repetir os passos.	O ataque requer uma pessoa muito capacitada para explorar.
A	Usuários afetados	Todos os usuários, configuração padrão e principais clientes	Alguns usuários, configuração não padrão	Pequena porcentagem de usuários, recursos obscuros, afeta usuários anônimos
D	Descoberta	Informações publicadas explicam os ataques. A vulnerabilidade é encontrada no recurso mais comumente usado e é muito notável.	A vulnerabilidade é uma parte rara usada do produto e somente alguns usuários a cruzam. É preciso analisar muito para ver o uso malicioso.	O bug é obscuro e é improvável que usuários descubram os potenciais de danos.

Após fazer as perguntas abaixo, conte os valores (1-3) para uma certa ameaça. O resultado pode estar em uma variação de 5-15. Depois você pode tratar as ameaças com as variações de 12-15 como de Alto risco, 8-11 como Médio risco, e 5-7 como Baixo risco.

Por exemplo, leve em conta as duas ameaças descritas anteriormente:

• O invasor obtém as credenciais de autenticação monitorando a rede.

• Os comandos do SQL são injetados na aplicação.

A tabela 7 mostra um exemplo da estimativa DREAD para as duas ameaças:

Tabela 7. Estimativa DREAD

Ameaça	D	R	E	A	D	Total	Estimativa
O invasor obtém as credenciais de autenticação monitorando a rede	3	3	2	2	2	12	Alta
Os comandos do SQL são injetados na aplicação.	3	3	3	3	2	14	Alta

Uma vez que você obteve a estimativa do risco, pode atualizar as ameaças documentadas e adicionar o nível de estimativa descoberto, que é Alto para ambas as ameaças acima. A tabela 8 mostra um exemplo.

Tabela 8 Ameaça

Descrição da Ameaça	O invasor obtém as credenciais de autenticação monitorando a rede
Ameaça alvo	Processo de autenticação do usuário na aplicação
Estimativa do Risco	Alta
Técnicas de Ataque	Uso do software de monitoramento de rede
Medidas	Uso do SSL para fornecer canal criptografado

O que vem depois da Elaboração de modelos de Ameaças?

O resultado do processo de elaboração de modelos inclui a documentação dos aspectos de segurança da arquitetura da sua aplicação e uma lista de ameaças relacionadas. O modelo de ameaça ajuda você a orquestrar os membros da equipe de desenvolvimento e a focar nas mais potentes ameaças.

Importante A elaboração de modelos de ameaças é um processo iterativo. O modelo de ameaças é um documento que se desenvolve e sobre os quais vários membros da equipe podem trabalhar.

O modelo de ameaças pode ser usado pelos seguintes grupos de pessoas:

• Designers podem usá-lo para proteger escolhas no projeto a respeito das tecnologias e funcionalidade.

• Desenvolvedores que escrevem códigos podem usá-lo para reduzir os riscos.

• Os testadores podem escrever casos de teste se a aplicação está vulnerável a ameaças identificadas pelas análises.

Gerando um Relatório de Item de Trabalho

A partir do modelo inicial, você pode criar um relatório mais formal que inclua atributos adicionais, tal como um Bug ID, que pode ser usado para vincular a ameaça em seu sistema favorito de rastreamento de bug. Na verdade, você pode escolher entrar com as ameaças identificadas no seu sistema de bug e usar seu relatório para gerar um outro relatório. Você pode também incluir uma coluna de status para indicar se o bug foi ou não fixado. Você deve ter certeza de que o relatório inclui o número original de ameaças para colocar no documento.

Organize as ameaças no relatório por rede, host e categorias de aplicação. Isso torna o relatório mais fácil de ser consumido para membros diferentes da equipe em diferentes papéis. Dentro de cada categoria, apresente as ameaças em ordem de prioridade, começando com as que apresentam um alto risco, seguidas pelas que apresentam riscos menores.

Sumário

Enquanto você pode reduzir o risco de um ataque, você não consegue reduzir ou eliminar a ameaça. As ameaças ainda existem independentes das ações de segurança que você realiza e das medidas que você aplica. A realidade, no mundo da segurança, é que você conhece a presença de ameaças e gerencia seus riscos. A elaboração de modelos de ameaças pode ajudá-lo a gerenciar e comunicar os riscos para a sua equipe.

Trate essa elaboração de modelos como um processo iterativo. Se o modelo de ameaças deve ser um item dinâmico que muda com o tempo à procura de novos tipos de ameaças e ataques. Deve-se pode também se adaptar para seguir a evolução natural da sua aplicação à medida que ela é aprimorada e modificada para acomodar os requisitos corporativos.

Recursos Adicionais

Para leitura adicional, veja os seguintes recursos:

• Para informações sobre padrões de ataques, consulte "Elaboração de modelos de Ataques para Segurança e Sobrevivência de Informações," por Andrew P. Moore, Robert J. Ellison, e Richard C. Linger em http://www.cert.org/archive/pdf/01tn001.pdf.

• Para avaliações sobre ameaças em avaliação, recursos e vulnerabilidades, consulte "Framework de Avaliação de Ameaças Críticas, Recursos e Vulnerabilidade (OCTAVE), Versão 1.0" no site do Carnegie Mellon Software Engineering Institute Web site em http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html.

• Para uma visita na elaboração de modelos de ameaças, consulte "Architect WebCast: Usando Modelos de Ameaças para Projetar Soluções de Segurança" em https://www.microsoft.com/usa/webcasts/ondemand/1617.asp.

• Para mais informações sobre a criação de DFDs, consulte Escrevendo um Código Seguro, Segunda Edição, por Michael Howard, David C. LeBlanc.