Registos e relatórios do modelo de ameaças
Sytance · Atualizado
Um modelo de ameaças regista a arquitetura do produto, os cenários de ataque, os controlos de segurança e os resultados da verificação. A ligação entre estes registos permite a um revisor acompanhar o raciocínio desde um ataque até à medida escolhida para o tratar. O exemplo do gateway mostra como estes registos se articulam; as secções abaixo explicam o que registar e como rever os registos.
Como organizar o modelo
Mantenha o diagrama e a análise juntos ou ligue-os através de identificadores estáveis. Um documento é adequado a uma revisão pequena; os registos estruturados são úteis quando o mesmo controlo aborda várias ameaças ou quando a equipa precisa de comparar versões.
No Sytance, a equipa edita a arquitetura e os registos de ameaças na área de trabalho e, em seguida, liga os requisitos, os elementos de conceção e os registos de verificação pertinentes em matéria de segurança. O módulo de documentação utiliza as informações da área de trabalho para preparar relatórios.
Informações e pressupostos sobre o produto
Identifique a versão, a implementação, a finalidade e os utilizadores do produto. Indique as partes incluídas na análise, as dependências externas e quaisquer exclusões que afetem uma via de ataque.
As orientações de decomposição da OWASP distinguem pontos de entrada, ativos e níveis de confiança. Utilize estas distinções para explicar a arquitetura, em vez de transformar cada ativo num processo separado no diagrama.
- Contexto: produto, versão, ambiente, finalidade e responsável pela revisão.
- Arquitetura: revisão do diagrama, processos, repositórios, entidades externas e fluxos.
- Objetivos de proteção: os dados e as funções que necessitam de confidencialidade, integridade ou disponibilidade.
- Pressupostos: cada condição incerta, o respetivo responsável e uma forma de a confirmar.
Registe cada cenário de ataque separadamente
Atribua a cada ameaça um identificador estável e ligue-a ao elemento ou fluxo pertinente do diagrama. Descreva quem poderia atacar, de que acesso necessitaria, qual seria a ação, a vulnerabilidade e a consequência. Indique as condições de que o cenário depende.
Exemplo TM-01: um utilizador só de leitura do gateway chama a API de escrita da configuração. Se a API verificar a autenticação sem verificar a permissão de escrita, o utilizador consegue alterar o destino da telemetria. O fluxo afetado vai do browser para a API de gestão, e o ataque ameaça a integridade da configuração armazenada.
Uma entrada que diga apenas «elevação de privilégios, risco elevado» não explica este cenário. Acrescente o raciocínio do risco: a conta necessária, a exposição do endpoint, o impacto realista e os controlos existentes considerados.
Controlos, implementação e verificação
Para TM-01, o controlo proposto AC-01 exige que a API de gestão verifique as permissões relativas à ação e ao recurso em cada escrita da configuração. O registo de implementação deve identificar a alteração pertinente. O registo de verificação deve incluir o resultado efetivo do ensaio para a versão indicada.
- Decisão: reduzir, eliminar ou aceitar o risco, com uma justificação e um responsável.
- Controlo: o comportamento exigido e as etapas da ameaça que aborda.
- Implementação: o componente, a referência da alteração e a versão do produto.
- Verificação: preparação, ação, resultado esperado, resultado observado e ligação às evidências.
- Risco remanescente: condições por resolver e decisão de revisão autorizada.
Resultados esperados e observados
Para o gateway fictício, o resultado esperado é que um pedido de escrita de uma conta só de leitura seja rejeitado e que a configuração armazenada permaneça inalterada. O resultado observado regista o que aconteceu durante o ensaio. Até o ensaio ser executado, esse campo permanece pendente.
A mesma distinção aplica-se aos controlos. «Verificação da assinatura planeada» e «verificação da assinatura implementada e testada» comunicam níveis de confiança diferentes. Preserve essa distinção ao transferir o registo para um relatório ou outra ferramenta.
Revisão do modelo concluído
Peça a um revisor para seguir um ataque desde o diagrama até ao controlo selecionado e ao resultado do ensaio. Se não for possível acompanhar as ligações, determine se falta um registo ou se é necessário explicar melhor o ataque.
Verifique se a versão indicada corresponde ao diagrama, se cada cenário tem uma decisão de tratamento e se os riscos aceites identificam quem os aceitou. Mantenha os pressupostos por resolver numa lista com um responsável e uma forma de os confirmar.
Depois de atualizar os registos da área de trabalho, abra Documentação e selecione o relatório pertinente. De acordo com a configuração e o plano da área de trabalho, o Sytance disponibiliza pré-visualizações HTML e ficheiros PDF ou DOCX. Antes de utilizar o relatório numa revisão, verifique se corresponde à versão atual do produto, à análise e às evidências de verificação.