Threat Modeling - Modelagem de ameaças (Parte 1)

O Threat Modeling é uma técnica fundamental para análise de segurança de arquiteturas, permitindo identificar e quantificar riscos com precisão. Esta metodologia versátil pode ser aplicada em diversos contextos: aplicações web, APIs, aplicativo mobile, infraestrutura e até mesmo em processos organizacionais.

O diferencial da modelagem de ameaças está na sua abordagem: ela avalia sistemas a partir da perspectiva de um potencial atacante. A pergunta central que orienta todo o processo é: "O que poderia ser explorado por um adversário?" Esta é uma questão que revela vulnerabilidades que outros métodos de análise frequentemente ignoram. 

É importante destacar que uma ameaça não se caracteriza como uma vulnerabilidade. A ameaça existe independentemente - mesmo quando não há vulnerabilidade explorável no momento da análise. Esta distinção é crucial para uma proteção proativa e abrangente.

O processo de Threat Modeling estrutura-se em quatro fases distintas e complementares, como ilustrado na imagem a seguir.

1.Design

A fase de design concentra-se na criação do Diagrama de Fluxo de Dados (DFD), que mapeia todos os componentes da arquitetura: sistemas, servidores, frameworks, recursos de rede e demais ativos relevantes. Durante a elaboração deste diagrama, identificam-se os potenciais pontos de entrada – interfaces onde atacantes podem interagir com a aplicação.

Questões cruciais são analisadas nesta etapa: Qual o nível de acesso que o aplicativo concederá aos diferentes tipos de usuários? Como funcionam as integrações com serviços de terceiros? Quais mecanismos de autenticação serão implementados?

Conforme define o OWASP Threat Modeling, esta fase pode ser entendida como: "Isso às vezes é chamado de 'decompor a aplicação', uma abordagem que os consultores usam quando são contratados para elaborar um modelo de ameaças ou uma revisão arquitetônica. Os consultores geralmente fornecem o resultado na forma de um documento de Modelo de Ameaças."

Coletar informações detalhadas sobre a arquitetura permite identificar pontos vulneráveis onde falhas de segurança podem ocorrer. A Microsoft, em sua documentação sobre Threat Modeling, apresenta diversas questões para orientar esta fase inicial. Para maior eficiência, compilei abaixo uma versão otimizada destas questões, focando nos tópicos mais objetivos e eliminando redundâncias.

Descrição do sistema

•     Qual a função principal do sistema? 
•     Descreva como os usuários deverão usar o sistema
•     Quais são os processos de negócio gerenciados pelo sistema?
•     O sistema é uma aplicação web, um serviço de API, ou aplicativo mobile? 

Infraestrutura

•    A infraestrutura do sistema é local ou na nuvem?
•    Informe qual o provedor (cloud) usado para hospedagem da infraestrutura
•    Qual o sistema operacional usado pelo sistema?
•    O sistema é executado em contêiners? 

Permissões 

• O sistema realiza execução de scripts? 
• O sistema possui acesso a dados?
• Quais os tipos de dados serão processados, armazenados e/ou transmitidos?
• O sistema precisa de acesso ao hardware?

Dados

• Como o sistema faz a validação dos dados de entrada e saída?
• Dados sensíveis são criptografados? 
• Como o sistema valida as fontes de dados na integração?

Integração com terceiros 

• Descreva o tipo de integração com serviço de terceiros
• Descreva o nível de acesso será necessário na integração
• Descreva o tipo de autenticação com o serviço
• Descreva o tipo de dado que será consumido ou transmitido para o serviço do parceiro

Perfil de acesso 

• Quais são os tipos de perfil de acesso o sistema utiliza, por exemplo, usuário comum, administrativo, "super-user". 
• A contas de acesso são locais ou centralizadas?
• Qual o framework de autenticação é usado?

Controle de acesso e Identidade

• O sistema usa listas de controle de acesso (ACL)?
• O sistema possui autenticação multifator (MFA)?
• Como é feito o controle de sessão?
• O sistema processará solicitações como API SOAP ou REST?

Gerenciamento de chaves

• O sistema transmite chaves-secretas?
• O sistema armazena chaves-secretas?
• O sistema armazena credenciais ou certificados de clientes? 

Monitoramento e Backup

• O sistema possui mecanimos para monitorar anomalias nas transações realizadas?
• O sistema possui mecanimos para monitorar o acesso e gerar logs de eventos de segurança?
• Quais os tipos de eventos serão capturados pelo sistema?

Rede 

• Os sistema usa criptografia em todas as conexões para o backend e API?
• A rede de comunicação do sistema possui firewall, IDS/IPS?
• A rede de comunicação do sistema possui segregação?

As respostas obtidas servem como base para a criação do diagrama de fluxo de dados, onde cada componente representa uma etapa específica no ciclo de vida dos dados dentro da arquitetura. Este documento é dinâmico e deve ser revisado sempre que houver modificações significativas – seja a implementação de uma nova funcionalidade, a adição de um módulo ou a alteração de um processo ou transação existente.

Infelizmente, em alguns contextos organizacionais, a construção de um diagrama de fluxo de dados pode ser erroneamente vista como uma tarefa irrelevante ou um desperdício de recursos. Equipes de desenvolvimento com menor orientação para aspectos de segurança cibernética frequentemente não incorporam a modelagem de ameaças em seu escopo de trabalho, criando assim pontos cegos significativos na proteção de seus sistemas.

A solução para este impasse reside na contextualização adequada do sistema, determinando precisamente o nível de detalhamento necessário para descrever o fluxo e a arquitetura completa. Os contextos servem como parâmetros que orientam as equipes de desenvolvimento e segurança sobre a profundidade necessária ao realizar a modelagem de ameaças.

Sistemas de uso exclusivamente interno ou que não processam dados sensíveis naturalmente exigem menos contexto detalhado quando comparados a sistemas acessíveis externamente ou que manipulam informações críticas. Esta diferenciação permite otimizar recursos e focar esforços onde o impacto de segurança é mais significativo.

Para determinar o nível adequado de informação a ser incluída na sua modelagem de ameaças, considere as quatro camadas de contexto:

0 - Sistema: O diagrama de fluxo de dados contém as principais partes do sistema com contexto suficiente para ajudar você a entender como elas funcionam e interagem entre si.

1 - Processo: Concentre-se em diagramas de fluxo de dados para cada parte do sistema. Use esta camada para todos os sistemas que lidam com dados sensíveis. O contexto nesta camada ajuda a identificar ameaças e maneiras de reduzir ou eliminar riscos de forma mais eficiente.

2 - Subprocesso: Diagramas de fluxo de dados para cada subparte de um componente do sistema. Usado para sistemas considerados críticos. Exemplos incluem sistemas para ambientes seguros, sistemas que lidam com dados altamente sensíveis ou sistemas com classificação de alto risco.

3 - Lower-Level: Foco em sistemas altamente críticos e em nível de kernel. Diagramas de fluxo de dados descrevem cada subprocesso em detalhes minuciosos.

A definição precisa de contexto durante a criação do diagrama de fluxo de dados é um fator que ajuda na otimização do tempo dedicado à modelagem da arquitetura. A habilidade de discernir entre informações essenciais e aquelas que podem ser omitidas está diretamente relacionada ao cenário específico que a arquitetura busca atender. Esta abordagem personalizada não apenas economiza recursos valiosos, mas também assegura que o foco permaneça nos elementos que efetivamente impactam a postura de segurança do sistema.