TL:DR
Neste artigo utilizei um aplicativo que estou desenvolvendo academicamente para praticar a modelagem de ameaças e exemplificar a teoria ao longo do texto. Essa primeira etapa da Modelagem corresponde à decomposição do sistema.
Etapa 1: Decompor o aplicativo
Existem muitas vulnerabilidades e ameaças possíveis e é improvável que seu aplicativo encontre todos eles. Também é improvável que sua empresa precise abordar todos eles. A modelagem de ameaças ajuda a identificar onde sua equipe precisa concentrar esforços.
Todos os desenvolvedores, designers de software e arquitetos devem se esforçar para incluir a modelagem de ameaças em todo ciclo de vida de desenvolvimento de software. Mas primeiramente concentre-se no que você está trabalhando no momento.
Eu utilizarei para estudo prático um aplicativo Fintech, voltado para usuários que desejam planejar de forma flexível seus orçamentos e gerenciar o dia a dia de suas finanças, que estou desenvolvendo academicamente.
Dito isso, é importante que se decomponha todo o sistema e faça perguntas para que se encontre onde as vulnerabilidades se encontram. A primeira etapa no processo de modelagem de ameaças se preocupa em entender o aplicativo e como ele interage com as entidades externas.
Identifique o design do aplicativo
Entender o design do aplicativo é fundamental para realizar a modelagem de ameaças. Se você estiver muito familiarizado com o design do aplicativo, poderá identificar fluxos de dados adicionais e limites de confiança em todo o processo de modelagem de ameaças.
- Identifique os casos de uso, defina os pontos de entrada do aplicativo e os níveis de confiança, mesmo que permaneçam inalterados como resultado do projeto.
- Identifique atores, ativos, serviços, funções e fontes de dados.
- Documente a movimentação de dados (em movimento e em repouso) via Diagrama de Fluxo de Dados.
- Documente todos os dados trocados e sua classificação.
Uma compreensão completa de como o sistema foi projetado também o ajudará a avaliar a probabilidade e o impacto potencial de qualquer ameaça específica que você identificar.
Decomponha e modele o aplicativo
É importante que se tome nota do processo para que em um eventual momento se possa consultar o que foi feito. Baseado no Processo de Modelagem de Ameaças da OWASP, iniciamos a documentação com a etapa 1 - decompondo o aplicativo, conforme segue abaixo:
1. Informações de identificação
- Nome do Sistema : O nome do aplicativo examinado.
- Versão do aplicativo : A versão do aplicativo examinado.
- Descrição : Uma descrição de alto nível do aplicativo.
- Proprietário do documento : o proprietário do documento de modelagem de ameaças.
- Participantes : os participantes envolvidos no processo de modelagem de ameaças para este aplicativo.
- Revisor : O(s) revisor(es) do modelo de ameaça.
Exemplo prático:
- Nome: ContabiLivre
- Versão: v0.1
- Descrição: Aplicativo web de planejamento financeiro pessoal, capacitado com sincronização de saldo bancário e despesas de cartão de crédito.
- Proprietário do documento: Bruno Martins
Os ítens 4 e 5 não foram preenchidos pois pratiquei sozinho e não tive a oportunidade de ter um revisor. Porém são dois ítens de extrema importância para uma boa elaboração do modelo de ameaças.
2. Dependências externas
Dependências externas são itens externos ao código do aplicativo que podem representar uma ameaça ao aplicativo.
As dependências externas devem ser documentadas da seguinte forma:
- ID : um ID exclusivo atribuído à dependência externa.
- Descrição : uma descrição textual da dependência externa.
Exemplo prático:
| ID | Descrição |
|---|---|
| 1 | Tela de login do usuário através de um browser onde autenticará seus dados para acesso |
| 2 | Acesso ao banco de dados com informações do perfil |
| 3 | API de conexão com saldo bancário |
| 4 | API de conexão com cartão de crédito |
3. Pontos de entrada
Os pontos de entrada definem as interfaces por meio das quais invasores em potencial podem interagir com o aplicativo ou fornecer dados a ele.
Os pontos de entrada devem ser documentados da seguinte forma:
- ID : Um ID exclusivo atribuído ao ponto de entrada. Isso será usado para fazer referência cruzada do ponto de entrada com quaisquer ameaças ou vulnerabilidades identificadas.
- Nome : um nome descritivo que identifica o ponto de entrada e sua finalidade.
- Descrição : Uma descrição textual detalhando a interação ou processamento que ocorre no ponto de entrada.
- Níveis de confiança : o nível de acesso necessário no ponto de entrada. Eles serão cruzados com os níveis de confiança definidos posteriormente no documento.
Exemplo prático:
| ID | Nome | Descrição | Nivel de Confiança |
|---|---|---|---|
| 1 | Login | Tela de acesso ao perfil do usuário. | Request HTTP |
| 2 | Acesso ao Banco de Dados | Armazenamento de dados dos usuários | O time de desenvolvimento tem credenciais de acesso |
| 3 | Utilização do App | Manuseio e utilização das informações contidas no aplicativo | Qualquer pessoa que tiver acesso ao telefone da pessoa pode mexer no app. |
4. Pontos de saída
Em muitos casos, as ameaças habilitadas pelos pontos de saída estão relacionadas às ameaças do ponto de entrada correspondente. Muitas vezes poderá, inclusive, ter múltiplas saídas, uma vez que a interação com o ponto de entrada pode mudar.
Exemplo prático:
| ID Entrada | Ponto de Saída |
|---|---|
| 1 | Response HTTP |
| 2 | O acesso é somente leitura, a única pessoa que faz alterações no banco é quem cuida dos bancos de dados. |
| 3 | Caso faça login, o app receberá o token de sessão e armazenará ele. |
Se você já tiver o código do aplicativo e tiver conhecimento técnico total sobre o funcionamento do mesmo, também poderá indicar os pontos de entrada e sáida conforme abaixo:
ID Entrada: 1
Descrição Entrada:
GET /usuario/$ID_USUARIO/perfil-usuário HTTP/1.1
Host: contabilivre.com.br
Authorization: $TOKEN_DE_SESSAO
Descrição Saída:
HTTP/1.1 200 OK
Content-Type: text/html
$HTML_PERFIL_USUARIO
5. Ativos
O sistema deve ter algo que interesse ao invasor e esses itens ou áreas de interesse são definidos como ativos. Os ativos são essencialmente os alvos dos invasores, ou seja, são a razão pela qual as ameaças existirão.
Os ativos envolvidos no fluxo de informações devem ser definidos e avaliados quanto ao seu valor de confidencialidade, integridade e disponibilidade.
Os ativos são documentados no modelo de ameaça da seguinte forma:
- ID : Um ID exclusivo é atribuído para identificar cada ativo. Isso será usado para fazer referência cruzada do ativo com quaisquer ameaças ou vulnerabilidades identificadas.
- Nome : um nome descritivo que identifica claramente o ativo.
- Descrição : uma descrição textual do que é o recurso e por que ele precisa ser protegido.
- Níveis de confiança : o nível de acesso necessário para acessar o ponto de entrada é documentado aqui. Eles serão cruzados com os níveis de confiança definidos na próxima etapa.
Considere dados em trânsito e dados em repouso
Embora os dados em repouso às vezes sejam considerados menos vulneráveis do que os dados em trânsito, os invasores geralmente consideram os dados em repouso um alvo mais valioso do que os dados em movimento.
Proteger dados confidenciais em trânsito e em repouso é fundamental para as empresas modernas, pois os invasores encontram maneiras cada vez mais inovadoras de comprometer os sistemas e roubar dados.
6. Níveis de confiança
Os níveis de confiança representam os direitos de acesso que o aplicativo concederá a entidades externas.
Os níveis de confiança são documentados no modelo de ameaça da seguinte forma:
- ID : Um número exclusivo é atribuído a cada nível de confiança. Isso é usado para fazer referência cruzada do nível de confiança com os pontos de entrada e ativos.
- Nome : um nome descritivo que permite identificar as entidades externas que receberam esse nível de confiança.
- Descrição : Uma descrição textual do nível de confiança detalhando a entidade externa que recebeu o nível de confiança.
Exemplo prático:
| ID | Nome | Descrição |
|---|---|---|
| 1 | Usuário | Proprietário do perfil logado |
| 2 | Credenciais de Acesso ao Banco de Dados | Usuário e senha compartilhado com o time de desenvolvimento para acesso ao banco, possui permissão de leitura e escrita. |
| 3 | Desenvolvedores(as) | Equipe técnica com acesso ao ambiente para modificar ou corrigir o sistema. |
| 4 | Acesso SSH ao servidor | Precisamos rever como é esse acesso. Mas sabemos que o sistema de versionamento o usa para publicar o sistema. |
7. Diagramas de fluxo de dados
Todas as informações coletadas nos permitem modelar com precisão o aplicativo por meio do uso de Diagramas de Fluxo de Dados ( DFDs ). Os DFDs nos permitirão entender melhor o aplicativo, fornecendo uma representação visual de como o aplicativo processa os dados.
A quantidade de informações a serem incluídas no diagrama de fluxo de dados depende de alguns fatores-chave:
- Tipo de sistema que você está construindo - Os sistemas que não lidam com dados confidenciais ou são usados apenas internamente podem não precisar de tanto contexto quanto um sistema externo.
- Contexto necessário de sua equipe de segurança - As equipes de segurança são precisas com o que procuram nos modelos de ameaças. Fale com sua equipe de segurança para confirmar a camada de profundidade necessária.
Considerações Finais
Existem algumas metodologias para modelar as ameaças a um sistema e cabe a cada equipe definir qual a mais apropriada para o caso.
No próximo artigo seguirei no Threat Modeling Process da OWASP com a etapa 2: determinar e classificar as ameaças.
Até lá.
Referências:
Threat Modeling Process OWASP
Curso de Modelagem de ameaças: identifique riscos na concepção do software - Alura
O papel do dev no processo de modelagem de ameaças | Izabela Matos - AppSec to Go
Curso Learning Threat Modeling for Security Professionals - LinkedIn Learning
Threat Modeling in 2021 with Adam Shostack - DevSecCon (Youtube)
Top comments (0)