Este artigo foi traduzido por máquina.

Informativos sobre segurança

Uma conversa com Follow-on sobre modelagem de ameaças

Michael Howard

A edição de maio de 2009 da MSDN Magazine inclui um artigo intitulado "A conversação sobre Threat Modeling"que revela uma conversação entre Paige, um novato segurança jovens e Michael, um cara de segurança um pouco jaded. Este mês será ocupam a conversação onde foi deixada.

Cena

Uma cozinha de pequena empresa, ao lado para o coffeepot.

Paige: Última vez que atendidos, você tirou uma boa olhada meu modelo de ameaça, mas você disse que seria abordam alguns problemas de design de criptografia e segura em uma data posterior. Bem-vindo bem, para que data posterior.

Michael: Posso entre obter um café primeiro?

Não, aguardando uma resposta, Michael pours se um café enorme.

Paige: ER, se.

Michael: Lembrar-me novamente o que é seu aplicativo.

Paige: É um produto que permite que os usuários armazenar dados em nossos servidores. Há um pequeno trecho de código cliente que envia os bits para um servidor reservado para esse usuário. Esse código pode carregar arquivos do usuário para nosso back-end por meio do servidor Web e os arquivos são armazenados no sistema de arquivos junto com o arquivo metadados armazenados no SQL Server para pesquisa rápida. Nós pode armazenar eventualmente bilhões de arquivos. Os dois ambientes principais são computadores que ingressaram no domínio e computadores que ingressaram em Internet.

Michael: AH, está certo, lembro agora. Código muito, tão pouco tempo. Bem, vamos voltar ao modelo de ameaça para ver qual parte estamos preocupados. Você tem o DFD--o diagrama de fluxo de dados?

Os dois orientá-lo a mesa de Paige. Ela faz logon com seu cartão inteligente e carrega a ferramenta de modelagem de ameaças SDL.

Paige: Aqui está.

Michael procura sobre o diagrama.

Michael: Isso é o diagrama de nível 1, certo? Ele é um nível mais detalhado que o diagrama de contexto?

Paige: Yup. Também temos um diagrama de nível 2, mas não acho que precisamos ir que profundidade ainda.

Michael: Você está certo, isso é perfeito. Se for necessário mais precisão como passarmos por isso, podemos procurar o diagrama de nível 2.

Paige: A propósito, nós não chamam os DFDs mais.

Michael: ER, OK! O que eles chamam, em seguida?

Paige: Diagramas de aplicativos.

Michael: Que flutua seu barco, eu s'pose. Nós estará usando lápis-cera próxima. OK, voltemos ao diagrama. Portanto, o usuário faz uma solicitação do aplicativo cliente para carregar ou baixar arquivos para ou do servidor e o servidor persiste dados no sistema de arquivos na parte de trás finalizar, juntamente com alguns metadados sobre os arquivos que são mantidos no SQL Server?

Paige: Isso é um uso;Na verdade, é provavelmente o cenário principal. Obviamente, o administrador precisa definir, configurar e monitorar o aplicativo;Isso é o que faz a ferramenta de administração.

Michael: Vamos nos concentrar nesse cenário de núcleo, em seguida.

Cena II

Michael é deparou intently no diagrama de aplicativo.

Michael: Vamos comece observando cada elemento no cenário de núcleo e nós será soletrar cada as ameaças STRIDE.

Paige: STRIDE? Lembrar-me novamente.

Michael: Falsificação, violação, repúdio, divulgação de informações, negação de serviço, elevação de privilégio.

Michael inicia escrever rapidamente em uma folha de papel.

Michael: Dê uma olhada nesta lista:

Paige: Não todos eles na ferramenta de modelagem de ameaças?

Michael: Sim, mas quero mostrar como a ferramenta chega a lista. A propósito, você não precisa usar ferramenta de modelagem de ameaças para ser SDL compatíveis, desde que o modelo de ameaça é completas e precisas. Basicamente, cada elemento está sujeitas a um conjunto específico de ameaças. Acho que você pode trabalhá-la da lista.

Paige: Sim, recebo-lo, mas não estão faltando algo? Todos os os fluxos de dados entre os vários elementos do aplicativo?

Michael: Yup, mas eu fiz que proposital, porque eu realmente não deseja se concentrar em aqueles ainda--nós abordadas-los em detalhes última vez.

Paige: Fizemos?

Michael: Sim. Examine o modelo de ameaças.

Paige aparece sobre a ferramenta de modelagem de ameaças SDL

Paige: AH, vejo, que é onde discutimos usando SSL/TLS para corrigir a violação e ameaças de divulgação de informações para os dados de fluxo entre os processos de cliente e servidor, certo?

Michael: Boa! Portanto, eis uma pergunta para você. Os dados que move do usuário para o servidor e, em seguida, no sistema de arquivo do servidor--são os dados confidenciais?

Paige: Solicitado a última vez. Sim, talvez seja.

Michael: OH-AH.

Paige: O quê? Os dados são criptografados usando SSL/TLS, portanto, estamos muito bem, certo?

Michael: Não realmente. SSL/TLS atenua a ameaça de divulgação de informações para os dados conforme ela flui entre dois processos--o processo cliente 2.0 e o processo Server 3.0. Mas depois que os dados deixa a empresa que protegidos encapsulamento, os dados é criptografado, e você está escrevendo dados de modo transparente para o sistema de arquivos.

Paige: Sim, mas o que há o risco?

Michael: Diga-me!

Paige: Não compreendo.

Michael sighs.

Michael: Digamos que um cliente do seu aplicativo é um funcionário de uma empresa negociada publicamente. Vamos ser mais específico: o funcionário é diretor financeiro de uma empresa negociada publicamente e ele usa seu aplicativo para armazenar uma planilha que mostra dados fiscais para o trimestre atual, dados que não não público e não será pública até o final do trimestre, quando a empresa anuncia seus ganhos. Digamos que um hacker divide em seu sistema, obtém os dados e o utiliza para vender ou comprar ações na empresa. Que podem ser internos comerciais.

Paige: OH-AH.

Michael: OH-AH, de fato. Isso é sério. O CFO não tem controles apropriados nesses dados confidenciais, que pode ser uma violação de normas SOX.

Paige: Você disse "pode"muita.

Michael: Pode apostar que sim que fiz. Parecer um lawyer para você? Portanto, para minha pergunta original. Essa situação é algo que você se preocupa com?

Paige: Bem, não realmente. Acho que nosso termos estado que você não deve usar nosso serviço para dados ultra-sensitive. Mas irá reproduzir. Vamos supor que eu digo, "Sim, que nos interessa esse cenário." E agora?

Michael: Meu primeiro bit conselho seria consulte seus advogados para verificar se que você não estiver colocando a empresa em risco com essa situação. Mas vamos supor que dizem que você pode ir para ele, mas você precisará Certifique-se de que proteger os dados no back-end.

Paige: O que você está tentando dizer é que os dados mantidos em armazenamento de dados, 5.0, o sistema de arquivos no servidor, estão sujeitas a divulgação de informações e precisamos para atenuar essa ameaça. Estou certo?

Michael: Você está especiais no. Então, como corrigi-lo?

Paige: ACLs.

Michael: Por que acessar listas de controle?

Paige: Nós pode limitar o acesso a usuários válidos somente dos dados.

Michael: Então, como o aplicativo do servidor ler e gravar os dados?

Paige: AH, vamos supor que o processo é executado como uma identidade exclusiva. Chamaremos a ele FooID. Nós pode aplicar uma ACL aos arquivos do que permite que FooID bem como usuários válidoso acesso a arquivos.

Michael: Ele não funcionará;Não é seguro.

Paige: Por que não?

Michael: Se sou um invasor, pode comprometer o processo do servidor executando como FooID e executar meu código mal-intencionado no servidor. Voilà, meu código está sendo executado como FooID e os dados que sou proprietário!

Paige procura dejected.

Paige: Humph.

Michael: Você precisa usar a criptografia.

Paige: É claro! O servidor será apenas ler e gravar blobs criptografados e se um invasor comprometer o servidor, ele ainda não é possível obter os dados, a menos que ele pode quebrar a criptografia.

Paige perks.

Michael: Agora a diversão começa realmente. É alterado em alguns dos problemas criptografia última vez, especialmente quando se referem às chaves.

Paige: O que você significam?

Michael: OK, como você vai para criptografar os dados?

Paige: O usuário digita uma senha no aplicativo de cliente e o aplicativo do lado do cliente criptografa os dados com a senha e envia o blob criptografado pela conexão para o servidor. O servidor grava metadados para o SQL Server e grava o blob criptografado para o sistema de arquivos do servidor.

Michael: O que há nos metadados?

Paige: Identidade do proprietário, o tamanho do arquivo, o nome do arquivo, o tempo foi escrito para o arquivo sistema e o último tempo de leitura. Esse tipo de coisas. Sei que essa informação é mantida no sistema de arquivos, também, mas é a forma mais rápida fazer uma pesquisa em algo projetado para armazenar esse tipo de dados: um banco de dados do SQL Server.

Michael: Bem, estou feliz não armazena dados mantidos dentro do arquivo!

Paige: Por quê?

Michael: Para alguns dos motivos. Primeiro, ele significaria seu aplicativo de servidor tem acesso a dados de modo transparente, e obter os dados requer seu processo de servidor para descriptografar os dados.

Paige: Portanto?

Uma voz alto, mas não bastante shouting, Michael responde.

Michael: Porque isso significa que o aplicativo de servidor precisa saber uma chave de descriptografia, que significa que você entrar em todos os tipos de jogos de gerenciamento de chaves realmente horrible. Se possível, você deseja ficar longe do que negócios! Existem maneiras de fazer isso corretamente por ter várias chaves, mas não quero explicar que agora. Se nunca! Se você realmente quiser entender isso, continue a leitura como Microsoft criptografa arquivos usando o EFS ou EFS.

Paige: Nós pode usar o EFS?

Michael: Possivelmente. Depende de seus clientes. Quais plataformas suporte no cliente?

Paige: Será enviamos no final do ano no Windows e, em seguida, alguns meses mais tarde no Linux.

Michael: Não Solaris?

Paige: O que há Solaris?

Michael sniggers e ignora resposta de Paige.

Michael: Você não pode usar o EFS porque requer contas do Windows. Assim, você terá de criptografar os dados usando tecnologia diferente. Seria ótimo se você pode usar o EFS ou até mesmo API de proteção de dados, conhecido como DPAPI, porque usam a mesma tecnologia de criptografia subjacente e pode perfeitamente criptografar e descriptografar dados usando teclas derivadas da senha do usuário. AH bem. Vamos ver o que mais podemos fazer.

Paige: Podemos usar uma biblioteca de criptografia?

Michael: Claro que podemos. Na verdade, que é uma idéia muito melhor que algo ouvi outro dia.

Paige: O quê?

Michael: Alguém me perguntou se seria OK para criar seu próprio algoritmo de criptografia.

Paige: Não, à direita você disse?

Michael: É claro que eu disse não. O que você esperaria me dizer? Eu também tornou muito claro que é uma violação de completa da diretiva do SDL, e ele não deve contemplate ainda a possibilidade de usar qualquer criptografia domésticos.

Paige: Assim o fazer?

Michael: Como o seu código de cliente é translation from VPE for Csharp, você pode usar o .NET espaço para nome System.Security.Cryptography. Está disponível no Mono, que significa que você pode chamá-lo do Linux. Ainda não o tentei, mas você pode fazer um experimento. Você também precisará bater papo com os advogados para verificar se que estão sem problemas de licenciamento.

Paige: Que problemas de licenciamento?

Michael: É o código de terceiros. Quem sabe que a licença says.Paige: OK, portanto, vamos criptografar os dados com a senha do usuário, enviar o blob...

Michael: Não. Não. Nyet. Nada. . Você não use a senha do usuário como uma chave de criptografia;Você pode derivar a chave de criptografia da senha. As senhas são muito fáceis de adivinhar.

Paige: Como é um "derivado"uma chave?

Michael sorrisos.

Michael: Com uma função de derivação de chave.

Paige: SR.. Smarty. Você poderia ser um pouco mais preciso?

Michael: Se. Você passar a chave para uma função como Rfc2898DeriveBytes no. NET, juntamente com um salt. Um salt é apenas um número exclusivo que torna difícil executar certos ataques. É uma contagem de iteração, normalmente nas dezenas se não for centenas de milhares. A função usa a senha e munges ele milhares de vezes com o salt. Geralmente isso é conhecido como "esticar a senha". No final da operação, que geralmente leva menos de um segundo, você obtém alguns bytes e você pode usar esses bytes como chaves. Derivação de chave não somente torna difícil de adivinhar a chave, ela também torna difícil montar ataques de adivinhação de senha de alta velocidade, pois o invasor tem de passar a contagem de iteração, muito. Portanto, se um invasor poderia testar normalmente 1.000.000 senhas por segundo, com uma contagem de iteração de 100.000, ele é reduzido para 10 por segundo! Legal, não é?

Paige: Muito bom! Portanto, usamos essa chave para criptografar os dados, usando, digamos, Advanced Encryption Standard?

Michael: Sim. Claro, todos os este faz é criptografar os dados. Ele não fornece qualquer forma de verificação de integridade, mas que é muito fácil. Você pode derivar outra chave e que usar para criar um código de autenticação de mensagem e armazenar que juntamente com os metadados. Não use a mesma chave para criptografia e verificação de integridade. Derive uma segunda chave e usá-lo.

ADAM, outro cara de segurança, o conduz por murmurando.

ADAM: Assistentes de segurança sempre deseja ir primeiro profundidade em criptografia e assim por diante. Mas os invasores ir para o elo fraco.

Michael: ADAM está certo, segurança pessoas tendem a se aprofundar profundidade rapidamente. E estou culpado como cobrados, mas quero aproveitar isso da forma.

Paige: ER, OK. Qualquer outra coisa?

Michael: Bem, há também o problema de auto-adesivo de esquecer suas senhas de usuários. Eu poderia dar aos usuários a oportunidade de fazer backup de suas senhas em um cartão USB ou algo e torná-los ciente de que não temos a senha e que, se eles esquecerem-la, não há nenhuma maneira, pode transferir os dados fazer a partir da fila de inatividade!

Paige: Isso é tudo?

Michael: Para o momento, Sim. É uma seção grande e importante o modelo de ameaça, e espero que isso lhe dá uma idéia de alguns dos trade-offs que você precisará fazer ao criar aplicativos seguros.

Paige: Faço agora. Obrigado.

Michael Howard é segurança sênior gerente de programa da Microsoft que se concentra no aprimoramento do processo seguro e as práticas recomendadas. Ele é co-autor de cinco livros de segurança, incluindo "Writing Secure Code for Windows Vista""Do SDL""Escrevendo código seguro"e "19 Deadly Sins da segurança de software."