Diagramas de fluxo de dados para modelagem de ameaças: STRIDE passo a passo

Todo método de modelagem de ameaças começa com a mesma pergunta: em que estamos trabalhando? A resposta usual é um diagrama de fluxo de dados. É um desenho simples, com cinco tipos de elementos, e a hora dedicada a ele é a mais bem gasta antes de uma revisão de segurança, porque a maioria das ameaças está onde os dados passam de um nível de confiança para outro.

Este guia mostra como desenhar um diagrama de fluxo de dados (DFD) para modelagem de ameaças, onde posicionar os limites de confiança e como percorrer o diagrama com STRIDE. O exemplo é uma funcionalidade que quase todo produto tem: usuários enviando uma foto de perfil.

As quatro perguntas

Um modelo de ameaças prático responde a quatro perguntas, popularizadas por Adam Shostack e pelo Threat Modeling Manifesto:

1. Em que estamos trabalhando?
2. O que pode dar errado?
3. O que vamos fazer a respeito?
4. Fizemos um trabalho bom o suficiente?

O diagrama de fluxo de dados responde à primeira. O STRIDE ajuda na segunda. As notas e os tickets que você anexa ao diagrama respondem à terceira, e uma revisão algumas semanas depois responde à quarta.

Os elementos de um diagrama de fluxo de dados

Elemento	O que é	Forma usual
Entidade externa	Uma pessoa ou um sistema fora do seu controle: um usuário, a API de um parceiro	Retângulo
Processo	Código que você executa e que transforma ou move dados	Círculo ou forma arredondada
Armazenamento de dados	Onde os dados ficam em repouso: um banco de dados, um bucket, uma fila, um log	Duas linhas paralelas ou um cilindro
Fluxo de dados	Dados que se movem entre dois elementos	Seta rotulada com os dados
Limite de confiança	Onde o nível de confiança muda	Linha tracejada ou uma zona ao redor dos elementos

Duas regras tornam um DFD útil para a segurança. Rotule cada fluxo com os dados que ele transporta, não só com o protocolo: photo + session token diz muito mais a quem revisa do que HTTPS. E nunca conecte diretamente dois armazenamentos de dados ou duas entidades externas: os dados só se movem por meio de um processo, e é ali que você pode verificá-los.

O exemplo: upload da foto de perfil

Os usuários enviam uma foto de perfil pelo navegador. A API web verifica a sessão e guarda o arquivo bruto em um bucket privado. Um processador de uploads pega o arquivo, envia os bytes para uma API de verificação de malware de terceiros, recodifica a imagem, remove os metadados, grava a versão limpa de volta no bucket e registra a URL da foto no banco de dados de usuários.

Há quatro zonas de confiança: a internet, a nossa camada de aplicação, a nossa camada de dados e o scanner de terceiros. Desenhado como DFD:

Conte os fluxos que cruzam o limite de uma zona: do navegador para a API, da API para o bucket, do bucket para o processador e de volta, do processador para o scanner e de volta, do processador para o banco de dados. É nesses pontos que vale a pena gastar o seu tempo.

Percorra o diagrama com STRIDE

O STRIDE nomeia seis tipos de ameaças. A abordagem "STRIDE por elemento" da Microsoft verifica cada elemento apenas quanto às ameaças que se aplicam ao tipo dele:

Tipo de elemento	S	T	R	I	D	E
Entidade externa	✓		✓
Processo	✓	✓	✓	✓	✓	✓
Armazenamento de dados		✓	✓ (logs)	✓	✓
Fluxo de dados		✓		✓	✓

As seis letras correspondem a falsificação de identidade (Spoofing), adulteração (Tampering), repúdio (Repudiation), divulgação de informações (Information disclosure), negação de serviço (Denial of service) e elevação de privilégio (Elevation of privilege). Percorrer a funcionalidade de upload elemento por elemento gera uma lista como esta:

• Falsificação de identidade (navegador). Com um token de sessão roubado ou forjado, alguém envia uma foto em nome de outra pessoa. Mitigação: valide o token em toda requisição, mantenha as sessões curtas e vincule a chave do objeto ao id do usuário autenticado, nunca a um valor vindo da requisição.
• Adulteração (do bucket para o processador). Um arquivo chamado photo.jpg é, na verdade, algo completamente diferente. Mitigação: verifique o formato real do arquivo, não o nome nem o tipo declarado, e recodifique toda imagem antes que qualquer outra pessoa a veja.
• Repúdio (API). Um usuário nega ter enviado uma imagem ofensiva, e nada prova o contrário. Mitigação: registre em log o id do usuário, a chave do objeto, o horário e o endereço do cliente em cada upload.
• Divulgação de informações (bucket). O bucket permite listagem pública, ou as fotos mantêm as coordenadas de GPS nos metadados EXIF. Mitigação: um bucket privado com URLs assinadas de curta duração e metadados removidos durante a recodificação.
• Negação de serviço (API e processador). Arquivos enormes ou imagens que, ao serem descompactadas, atingem tamanhos gigantescos esgotam a memória. Mitigação: limites de tamanho de arquivo e de quantidade de pixels, e timeouts no processador.
• Elevação de privilégio (processador). Um arquivo criado sob medida explora um bug na biblioteca de imagens e executa código com as permissões do processador. Mitigação: rode o processador em um sandbox sem acesso a nada além do próprio prefixo no bucket e da única tabela que ele usa.

Escreva as ameaças no diagrama como linhas curtas e numeradas em uma nota ao lado dos elementos afetados e vincule cada uma ao ticket que acompanha a correção. Assim o diagrama também serve de resumo da revisão.

Regras para diagramas de modelagem de ameaças

• Desenhe a funcionalidade, não a empresa. Um DFD por funcionalidade ou por serviço. Um diagrama de tudo não tem espaço para os detalhes que importam.
• Mostre onde a autenticação acontece. Em cada fluxo que cruza um limite, marque o processo que verifica a identidade.
• Inclua os caminhos que ninguém mostra em demo. Ferramentas de administração, acesso do suporte, jobs em lote e backups também cruzam limites.
• Mantenha um único nível de detalhe. Um DFD de nível de contexto mostra o sistema como um único processo; um DFD de nível 1 o divide em seus processos principais. Escolha um por diagrama.
• Versione junto com a funcionalidade. Quando o design muda, as ameaças mudam. Atualize o diagrama no mesmo pull request do documento de design.

Ferramentas especializadas ou um canvas compartilhado

Ferramentas gratuitas como o OWASP Threat Dragon e o Microsoft Threat Modeling Tool foram feitas para esse trabalho e podem sugerir ameaças para cada elemento. Elas funcionam bem quando um time de segurança conduz o processo.

Um canvas compartilhado funciona melhor quando as pessoas que constroem a funcionalidade desenham o diagrama juntas durante o design: o DFD fica ao lado dos diagramas de arquitetura, todo mundo edita ao vivo e as notas continuam presas aos elementos. De um jeito ou de outro, a conversa em torno do diagrama é a parte valiosa.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Moldura do pack Básico para cada zona de confiança e dê a ela o nome da zona, por exemplo Trust zone: app tier.
3. Adicione as entidades externas como nós Caixa e os processos como formas Elipse, ambos do pack Básico, e os armazenamentos de dados a partir do pack Dados (Repositório de objetos, Postgres).
4. Conecte as portas e rotule cada conexão com os dados que ela transporta.
5. Adicione uma Nota ao lado dos elementos afetados listando cada ameaça com a letra do STRIDE, o número e o ticket.

O exemplo usa 10 nós de diagrama mais três notas que listam sete ameaças, dentro do plano Free. Para o lado de rede da segurança, veja o modelo de diagrama de arquitetura de confiança zero e, para mapear dados pessoais, o caso de uso Mapeamento de dados GDPR.

Perguntas frequentes

Um diagrama de fluxo de dados é a mesma coisa que um diagrama de arquitetura? Não. Um diagrama de arquitetura mostra os componentes e como eles se conectam; um DFD mostra como os dados se movem e onde a confiança muda. Muitas vezes eles compartilham caixas, mas o DFD é desenhado para responder à pergunta de segurança.

STRIDE ou outro método? O STRIDE é um bom padrão para funcionalidades de software. O LINDDUN foca em ameaças à privacidade, e o PASTA é um processo centrado em risco para programas maiores. O diagrama é o mesmo ponto de partida para todos eles.

Quem deve participar? Os engenheiros que constroem a funcionalidade, alguém que vai operá-la e um engenheiro de segurança, se você tiver um. Quem conhece o código encontra as ameaças; o engenheiro de segurança garante que a análise seja honesta.

Quanto tempo deve levar? Uma hora é o típico para uma funcionalidade como o upload de fotos: 15 minutos para desenhar, 30 para percorrer o STRIDE e 15 para combinar as correções e os responsáveis.

Com que frequência devemos atualizar o modelo? Sempre que um fluxo cruzar um novo limite, surgir um novo armazenamento de dados ou a funcionalidade mudar quem pode fazer o quê.

Comece grátis — um assento, sem cartão de crédito.