Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

SEC01-BP07 Identificar ameaças e priorizar mitigações usando um modelo de ameaça - Framework Well-Architected da AWS

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

Realize a modelagem de ameaças para identificar e manter um registro atualizado de possíveis ameaças e mitigações associadas para sua workload. Priorize suas ameaças e adapte as mitigações de controles de segurança para prevenir, detectar e responder. Revise e mantenha isso no contexto de sua workload e no cenário de segurança em evolução.

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

O que é modelagem de ameaças?

"A modelagem de ameaças funciona para identificar, comunicar e entender ameaças e mitigações no contexto da proteção de algo de valor." – Modelagem de ameaças a aplicações do Open Web Application Security Project (OWASP)

Por que você deveria usar um modelo de ameaça?

Os sistemas são complexos e se tornam cada vez mais intrincados e qualificados com o passar do tempo, oferecendo maior valor empresarial e maior satisfação e engajamento do cliente. Isso significa que as decisões de design de TI precisam considerar um número cada vez maior de casos de uso. Essa complexidade e o número de permutações de caso de uso geralmente tornam as abordagens não estruturadas ineficazes para encontrar e mitigar ameaças. Em vez disso, você precisa de uma abordagem sistemática para enumerar as possíveis ameaças ao sistema, elaborar mitigações e priorizá-las a fim de garantir que os recursos limitados de sua organização tenham impacto máximo na melhoria do procedimento geral de segurança do sistema.

A modelagem de ameaças foi projetada para oferecer essa abordagem sistemática com o objetivo de encontrar e resolver problemas na fase inicial do processo de design, quando as mitigações têm custo e esforço relativamente baixos em comparação com a fase posterior do ciclo de vida. Essa abordagem se alinha ao princípio de segurança shift-left do setor. Por fim, a modelagem de ameaças é integrada ao processo de gerenciamento de riscos de uma organização e ajuda a impulsionar as decisões sobre quais controles implementar usando uma abordagem orientada a ameaças.

Quando a modelagem de ameaças deve ser realizada?

Inicie a modelagem de ameaças o quanto antes no ciclo de vida de sua workload. Isso oferece a você maior flexibilidade sobre o que fazer com as ameaças identificadas. Muito semelhante aos bugs de software, quanto mais cedo você identificar as ameaças, mais econômico será resolvê-las. Um modelo de ameaças é um documento ativo e deve continuar a evoluir à medida que suas workloads mudam. Revise seus modelos de ameaça no decorrer do tempo, inclusive quando há uma alteração importante ou uma alteração no cenário de ameaças ou ao adotar um novo recurso ou serviço.

Etapas de implementação

Como podemos realizar a modelagem de ameaças?

Há muitas formas diferentes de realizar a modelagem de ameaças. Muito semelhante às linguagens de programação, há vantagens e desvantagens em cada uma, e é necessário escolher a forma mais adequada para você. Uma abordagem é começar com o Quadro de quatro perguntas para modelagem de ameaças do Shostack, que apresenta perguntas abertas para fornecer estrutura ao seu exercício de modelagem de ameaças:

  1. Em que estão 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. Criar um modelo ou diagrama é a forma mais popular de responder a essa pergunta, pois ajuda a visualizar o que você está criando, por exemplo, usando um diagrama de fluxo 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 do sistema). Por exemplo, se você está 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.

  2. O que pode acontecer de errado?

    É nessa fase que você identifica ameaças ao seu sistema. Ameaças são ações ou eventos acidentais ou intencionais que causam 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 um brainstorming e a colaboração entre todos os indivíduos de sua equipe e pessoas relevantes envolvidas no exercício de modelagem de ameaças. Você pode ajudar seu brainstorming usando um modelo para identificar ameaças, como o STRIDE, que sugere diferentes categorias para avaliação: falsificação, adulteração, repúdio, divulgação de informações, negação de serviço e elevação de privilégios. Além disso, talvez você queira ajudar no brainstorming revisando as listas e pesquisas existentes em busca de inspiração, incluindo o OWASP Top 10, o HiTrust Threat Catalog e o catálogo de ameaças da sua própria organização.

  3. O que vamos fazer sobre isso?

    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 uma responsabilidade compartilhada entre você e a AWS. É importante entender que ao perguntar "O que vamos fazer a respeito?" você também está perguntando "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 do sistema.

    Para a parte da AWS da responsabilidade compartilhada, 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 no AWS Artifact.

    Seja quais forem os serviços da AWS que você está 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 conta com um capítulo de segurança dedicado que fornece orientação 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 coisas como validação de entrada, tratamento de sessão e tratamento de limites. Com frequência, a maioria das vulnerabilidades é introduzida em código personalizado. Por isso, concentre-se nessa área.

  4. 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 entre prática, aprendizado, instrução e revisão. Para se aprofundar e colocar a mão na massa, é recomendável que você e sua equipe concluam o workshop ou curso de treinamento Modelagem de ameaças da maneira certa para construtores. Além disso, se você estiver procurando orientação sobre como integrar a modelagem de ameaças ao ciclo de vida de desenvolvimento de aplicações da sua organização, consulte Como abordar a modelagem de ameaças no blog de segurança da AWS.

Compositor de ameaças

Para obter ajuda e orientação na execução da modelagem de ameaças, considere usar a ferramenta Threat Composer, que visa reduzir o tempo de obtenção de valor na modelagem de ameaças. Essa ferramenta ajuda você a:

  • Escrever declarações de ameaças úteis alinhadas à gramática de ameaças que funcionem em um fluxo de trabalho natural não linear

  • Gerar um modelo de ameaça legível por humanos.

  • Gerar um modelo de ameaça legível por máquina para permitir tratar os modelos de ameaças como código.

  • Identificar rapidamente as áreas de melhoria de qualidade e de cobertura usando o painel do Insights.

Para obter mais referências, visite o Threat Composer e alterne para o Exemplo de espaço de trabalho definido pelo sistema.

Recursos

Práticas recomendadas relacionadas:

Documentos relacionados:

Vídeos relacionados:

Treinamento relacionado:

Ferramentas relacionadas:

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.