SEC01-BP07 Identificar ameaças e priorizar mitigações com o uso de um modelo de ameaça

Em que você está trabalhando?

A finalidade dessa pergunta é ajudar você a entender e chegar a um acordo sobre o sistema que você está construindo e os detalhes sobre ele que são relevantes para a segurança. A criação de um modelo ou um diagrama é a forma mais comum de responder a essa pergunta, pois ele ajuda você a visualizar o que você está construindo; por exemplo, usando um fluxograma de dados. Escrever as suposições e os detalhes importantes sobre seu sistema também ajuda a definir o que está no escopo. Isso permite que todos que estão contribuindo para o modelo de ameaças se concentrem na mesma coisa e evitem desvios demorados para tópicos fora do escopo (inclusive versões desatualizadas de seu sistema). Por exemplo, se você estiver criando uma aplicação Web, provavelmente não vale a pena criar uma modelagem de ameaças da sequência de inicialização confiável do sistema operacional para clientes de navegador, pois não há nenhuma possibilidade de seu design ter influência nisso.

O que pode dar errado?

É nessa fase que você identifica ameaças ao seu sistema. Ameaças são ações ou eventos acidentais ou intencionais que têm impactos indesejados que podem afetar a segurança de seu sistema. Sem um claro entendimento do que pode dar errado, não há o que fazer sobre isso.

Não há uma lista canônica do que pode dar errado. A criação dessa lista exige etapas de brainstorming e colaboração entre todas as pessoas de sua equipe e as pessoas relevantes envolvidas no exercício de modelagem de ameaças. Você pode auxiliar suas etapas de brainstorming utilizando um modelo para identificar ameaças, como o STRIDE, que sugere categorias diferentes para avaliar: Spoofing (Falsificação), Tampering (Violação), Repudiation (Repúdio), Information disclosure (Divulgação de informações), Denial of service (Negação de serviço) e Elevation of privilege (Elevação de privilégio). Além disso, talvez você queira auxiliar as etapas de brainstorming revisando as listas existentes e a pesquisa para inspiração, como o OWASP Top 10, o HiTrust Threat Catalog e o catálogo de ameaças de sua própria organização.

O que estamos fazendo a respeito?

Como no caso da primeira pergunta, não há uma lista canônica de todas as mitigações possíveis. A entradas nessa etapa são as ameaças identificadas, as pessoas e as áreas de melhoria da etapa anterior.

Segurança e conformidade são responsabilidades compartilhadas entre você e a AWS. É importante entender que ao perguntar “O que vamos fazer a respeito?” você também pergunte “Quem é responsável por fazer algo a respeito?”. Entender o equilíbrio entre suas responsabilidades e as da AWS ajuda a definir o escopo de seu exercício de modelagem de ameaças para as mitigações que estão sob seu controle, que, geralmente, são uma combinação de opções de configuração de serviços da AWS e suas mitigações específicas ao sistema.

No que se refere à responsabilidade compartilhada da AWS, você descobrirá que os serviços da AWS estão no escopo de muitos programas de conformidade. Esses programas ajudam você a entender os controles sólidos implementados na AWS para manter a segurança e a conformidade da nuvem. Os relatórios de auditoria desses programas estão disponíveis para download para clientes da AWS do AWS Artifact.

Seja quais forem os serviços da AWS que você esteja utilizando, sempre há um elemento de responsabilidade do cliente, e as mitigações alinhadas a essas responsabilidades devem ser incluídas em seu modelo de ameaças. Para mitigações de controle de segurança dos próprios serviços da AWS, convém considerar a implementação de controles de segurança em todos os domínios; por exemplo, domínios como gerenciamento de identidade e acesso (autenticação e autorização), proteção de dados (em repouso e em trânsito), segurança de infraestrutura, registro em log e monitoramento. A documentação de cada serviço da AWS tem um capítulo dedicado à segurança que oferece orientações sobre os controles de segurança a serem considerados como mitigações. É importante considerar o código que você está escrevendo e suas dependências e pensar nos controles que você poderia implementar para resolver essas ameaças. Esses controles podem ser fatores como validação de entrada, processamento de sessões e processamento de limites. Com frequência, a maioria das vulnerabilidades é introduzida em código personalizado, então concentre-se nessa área.

Fizemos um bom trabalho?

O objetivo é a sua equipe e a organização aprimorarem a qualidade dos modelos de ameaças e a velocidade na qual você está realizando a modelagem de ameaças no decorrer do tempo. Essas melhorias vêm de uma combinação de prática, aprendizado, instrução e revisão. Para se aprofundar e trabalhar, é recomendável que você e sua equipe concluam o curso de treinamento Threat modeling the right way for builders (Modelagem de ameças da maneira certa para desenvolvedores) ou o respectivo workshop. Além disso, se você estiver procurando orientações sobre como integrar a modelagem de ameaças ao ciclo de vida do desenvolvimento de aplicações da organização, consulte a publicação Como abordar a modelagem de ameaças no Blog de segurança da AWS.