Modelação de ameaças: arquitetura, cenários de ataque e controlos
Sytance · Atualizado
A modelação de ameaças é uma forma estruturada de identificar como um produto pode ser atacado e de escolher medidas para reduzir o risco. A análise parte da arquitetura do produto e explica como um ataque poderia ter êxito, o que afetaria e como será verificada a proteção proposta.
Versão do produto e implementação
Um modelo de ameaças aplica-se a uma versão e implementação específicas do produto. Um gateway ligado à Internet e o mesmo gateway numa rede de manutenção isolada podem ter pontos de entrada e pressupostos operacionais diferentes.
Convide as pessoas que conhecem a arquitetura, o desenvolvimento, a utilização do produto e a segurança. Antes da sessão, reúna material suficiente para explicar uma operação normal do princípio ao fim.
- A versão, a implementação suportada e os utilizadores previstos.
- A arquitetura, as interfaces externas e os dados trocados.
- Os privilégios de cada utilizador, serviço e processo local.
- Os dados sensíveis, as credenciais e as funções do produto a proteger.
- Os controlos existentes e os pressupostos que ainda precisam de confirmação.
Fluxos de dados e limites de confiança
Um diagrama de fluxo de dados (DFD) mostra entidades externas, processos, repositórios de dados e a circulação de dados. Um limite de confiança assinala uma mudança de confiança ou autoridade. Pode existir entre um browser e uma API, entre duas contas do sistema operativo ou entre um dispositivo e um serviço remoto.
Indique uma direção, uma descrição dos dados e um mecanismo de proteção para cada fluxo. Uma caixa com a etiqueta «nuvem» oculta demasiados detalhes se vários serviços tiverem identidades e permissões diferentes. Divida a caixa quando essa diferença alterar a análise.
No exemplo do gateway industrial, comece pelo browser do operador, pela API de gestão do gateway, pelo repositório de configuração local, pelo controlador local, pelo serviço de telemetria e pelo serviço de atualização. Represente as ligações de gestão e telemetria como ligações TLS. Trate a verificação da assinatura da atualização como um controlo proposto até a sua implementação estar confirmada.
Das categorias STRIDE aos cenários de ataque
A STRIDE agrupa as ameaças em falsificação, adulteração, repúdio, divulgação de informação, negação de serviço e elevação de privilégios. Utilize estas categorias para colocar questões sobre cada processo e fluxo pertinente. O nome de uma categoria, por si só, não descreve um ataque.
Por exemplo: um utilizador com acesso só de leitura envia diretamente à API de gestão um pedido de alteração da configuração. Se a API verificar o início de sessão, mas não a permissão para executar a ação, o utilizador pode alterar a configuração do gateway. Isto identifica um interveniente, um ponto de entrada, um controlo em falta e um impacto.
Ligue cada cenário à interface, ao processo ou ao fluxo pertinente no diagrama. Cenários com condições de ataque ou controlos diferentes necessitam de análise separada. Se uma condição for desconhecida, como a autenticação na interface do controlador, registe o que tem de ser confirmado.
Prioridades de risco e controlos de segurança
As prioridades de risco dependem do acesso e das capacidades de que o atacante necessita, da probabilidade de êxito e das consequências para o produto. Um método de risco acordado torna estas avaliações coerentes. O raciocínio por detrás de uma pontuação permite que outras pessoas a revejam.
Escolha uma resposta que a equipa possa implementar. Para o cenário de alteração da configuração, exija que a API aplique a permissão do autor do pedido em cada operação de escrita. Atribua um responsável, uma versão-alvo e uma verificação que demonstre se o controlo funciona.
O TLS protege uma ligação de transporte; não determina se um utilizador com sessão iniciada pode alterar a configuração. Avalie o controlo face à etapa exata do ataque que deve impedir. Se a equipa aceitar o risco remanescente, registe o motivo e a pessoa autorizada a tomar essa decisão.
Verificação e atualizações do modelo
Um controlo proposto e um controlo verificado são estados diferentes. Ligue um controlo implementado à alteração pertinente e ao respetivo resultado de verificação. Para o exemplo da API, envie um pedido de escrita como utilizador só de leitura e confirme tanto a rejeição como a ausência de alteração da configuração.
Reveja o modelo quando mudar uma interface, uma permissão, um componente, uma implementação ou um mecanismo de atualização. Novas informações sobre vulnerabilidades também podem invalidar um pressuposto anterior. Preserve o modelo anterior para que a equipa possa explicar a que versões se aplicava uma decisão.