Como abordar a modelagem de ameaças

Por Darran Boyd, Arquiteto-chefe de soluções de segurança da AWS

3 de agosto de 2022: Seção “Conclusão” atualizada para fazer referência ao workshop “Threat Modeling the Right Way for Builders Workshop” (Modelagem de ameaças da maneira certa para Desenvolvedores) da AWS.

14 de fevereiro de 2022: Seção “Conclusão” atualizada para fazer referência à sessão do vídeo complementar “How to approach threat modelling” (Como abordar a modelagem de ameaças).

Neste post, eu vou fornecer algumas dicas sobre como integrar a modelagem de ameaças ao ciclo de vida de desenvolvimento de aplicações da sua organização. Existem muitas orientações excelentes sobre como executar as partes processuais da modelagem de ameaças, e abordarei brevemente quais são elas e suas metodologias. No entanto, o principal objetivo deste post é ampliar a orientação existente com algumas dicas adicionais sobre como lidar com as pessoas e os componentes do processo em sua abordagem de modelagem de ameaças, o que, na minha experiência, ajuda muito a melhorar os resultados de segurança, a propriedade da segurança, a velocidade de entrada no mercado e a felicidade geral de todos os envolvidos. Além disso, fornecerei algumas orientações específicas para quando você estiver usando a Amazon Web Services (AWS).

Vamos começar com uma introdução sobre modelagem de ameaças.

Por que usar a modelagem de ameaças

Sistemas de TI são complexos, e vão se tornando cada vez mais complexos, assim como sua capacidade; oferecendo mais valor comercial e maior satisfação e engajamento do cliente. Isso significa que as decisões de design de TI precisam levar em conta um número cada vez maior de casos de uso e precisam ser pensadas de forma a mitigar possíveis ameaças à segurança que podem levar a resultados impactantes nos negócios, incluindo acesso não autorizado a dados, negação de serviço e uso indevido de recursos.

Essa complexidade e o número distinto de casos de uso normalmente tornam ineficaz o uso de abordagens não estruturadas para encontrar e mitigar ameaças. Em vez disso, você precisa de uma abordagem sistemática para enumerar as potenciais ameaças aos workloads, elaborar mitigações e priorizar essas mitigações para garantir que os recursos limitados de sua organização tenham o máximo impacto na melhoria da postura geral de segurança do workload. A modelagem de ameaças foi projetada para fornecer essa abordagem sistemática, com o objetivo de encontrar e resolver problemas no início do processo de design, quando as mitigações têm um custo relativamente baixo em comparação com o ciclo de vida mais avançado.

O AWS Well-Architected Framework destaca a modelagem de ameaças como uma prática recomendada específica, dentro do Pilar de segurança, na área de fundamentos de segurança, sob a pergunta SEC 1: como operar de forma segura seu workload?:

“Identificar e priorizar riscos usando um modelo de ameaça: use um modelo de ameaça para identificar e manter um registro atualizado de possíveis ameaças. Priorize essas ameaças e adapte seus controles de segurança para prevenir, detectar e responder. Revise e mantenha isso no contexto do cenário de segurança em evolução.”

A modelagem de ameaças é mais eficaz quando feita no nível do workload (ou em uma funcionalidade do workload), a fim de garantir que todo o contexto esteja disponível para avaliação. O AWS Well-Architected define um workload como:

“Um conjunto de componentes que, juntos, agregam valor comercial. Um workload geralmente é o nível de detalhe sobre o qual os líderes de negócios e tecnologia se comunicam. Exemplos de workloads são sites de marketing, sites de comércio eletrônico, backends para aplicações móveis, plataformas analíticas, etc. Os workloads variam em níveis de complexidade arquitetônica, de sites estáticos a arquiteturas com vários armazenamentos de dados e muitos componentes.”

As principais etapas da modelagem de ameaças

Na minha experiência, todas as abordagens de modelagem de ameaças são semelhantes; em um alto nível, elas seguem estas etapas de uma forma geral:

1. Identificação de ativos, atores, pontos de entrada, componentes, casos de uso e níveis de confiança e inclusão deles em um diagrama de design.
2. Identificação de uma lista de ameaças.
3. Identificação de mitigações por ameaça, que pode incluir implementações de controle de segurança.
4. Criação e análise de uma matriz de risco para determinar se a ameaça foi adequadamente mitigada.

Para se aprofundar nas práticas gerais associadas a essas etapas, sugiro a leitura do whitepaper SAFECode Tactical Threat Modeling e a Open Web Application Security Project (OWASP) Threat Modeling Cheat Sheet. Esses guias são ótimos recursos para você considerar ao adotar uma abordagem específica. Eles também fazem referência a uma série de ferramentas e metodologias que são úteis para acelerar o processo de modelagem de ameaças, incluindo a criação de diagramas de modelo de ameaça com o projeto Threat Dragon do OWASP e a determinação de possíveis ameaças com o OWASP Top 10, OWASP Application Security Verification Standard (ASVS) e STRIDE. Você pode optar por adotar alguma combinação deles ou criar o seu próprio.

Quando fazer a modelagem de ameaças

A modelagem de ameaças é uma atividade realizada no desenho do projeto. É comum que durante a fase de desenho do projeto, você vá além da criação de um diagrama de arquitetura, e que possivelmente também estará construindo um ambiente de Desenvolvimento e/ou Testes. Essas atividades são realizadas para trazer informações que vão ajudar a desenvolver seu projeto do ambiente de Produção. Como a modelagem de ameaças é uma atividade no momento do desenho do projeto, ela ocorre antes da revisão do código, da análise de código (estática ou dinâmica) e do teste de penetração; tudo isso ocorre posteriormente no ciclo de vida da segurança.

Sempre considere ameaças potenciais ao projetar seu workload, desde as fases iniciais, que normalmente ocorrem quando as pessoas ainda estão escrevendo na lousa/quadro-branco (seja físico ou virtual). A modelagem de ameaças deve ser executada durante a fase de desenho de um projeto para um determinado recurso de workload ou alteração do mesmo, pois essas alterações podem introduzir novas ameaças que exigem que você atualize seu modelo de ameaça.

Dicas de modelagem de ameaças

Em última análise, a modelagem de ameaças requer reflexão, brainstorming, colaboração e comunicação. O objetivo é preencher a lacuna entre desenvolvimento de aplicações, operações, negócios e segurança. Não há atalho para o sucesso. No entanto, observei alguns fatores que têm impacto significativo na adoção e no sucesso da modelagem de ameaças, e é o que abordarei nas seções a seguir.

1. Monte a equipe certa

A modelagem de ameaças é um “esporte de equipe”, porque requer o conhecimento e o conjunto de habilidades de uma equipe diversificada, onde todas as sugestões podem ser vistas como iguais em valor. Para todas os tipos de personas listadas nesta seção, a mentalidade sugerida é começar pelas expectativas de seus clientes finais e trabalhar de trás para frente. Pense no que seus clientes esperam desse workload ou de algum recurso do mesmo, tanto em termos de suas propriedades de segurança quanto em manter um equilíbrio entre funcionalidade e usabilidade.

Eu recomendo que as seguintes perspectivas sejam abordadas pela equipe, observando que um único indivíduo pode apresentar mais de uma dessas perspectivas:

A persona de negócios: primeiro, para manter uma base sólida, você vai querer alguém que represente os resultados comerciais do workload ou do recurso que faz parte do processo da modelagem de ameaças. Essa pessoa deve ter um entendimento profundo dos requisitos funcionais e não-funcionais do workload, e seu trabalho é garantir que esses requisitos não sejam afetados indevidamente por nenhuma mitigação proposta para lidar com ameaças. Ou seja, se um controle de segurança proposto (ou seja, mitigação) tornar um requisito de aplicação inutilizável ou excessivamente degradada, será necessário mais trabalho para alcançar o equilíbrio certo entre segurança e funcionalidade.

A persona do desenvolvedor: é alguém que entende o projeto atual proposto para os recursos do workload e teve o maior envolvimento nas decisões sobre o projeto até o momento. Essa pessoa esteve envolvida em sessões de brainstorming, ou whiteboarding do projeto que culminaram neste momento, quando normalmente está pensando em ameaças ao projeto e possíveis mitigações a serem incluídas. Nos casos em que você não está desenvolvendo sua própria aplicação interna (por exemplo, aplicações COTS), você traria o proprietário da aplicação interna.

A persona do adversário: Em seguida, você precisa de alguém para desempenhar o papel do adversário. O objetivo dessa persona é colocar-se no lugar de um invasor e revisar criticamente o projeto do workload, afim de procurar maneiras de tirar proveito de uma falha de design no mesmo para atingir um objetivo específico (por exemplo, compartilhamento não autorizado de dados). Os “ataques” que essa pessoa realiza são um exercício mental, não uma exploração prática real através de códigos. Se a sua organização tiver a equipe chamada Red Team, ela pode ser uma ótima opção para essa função; caso contrário, você pode querer que um ou mais membros de sua equipe de operações de segurança ou engenharia desempenhem essa função. Outra alternativa é trazer um terceiro especializado nessa área.

A persona defensora: você precisará de alguém para desempenhar o papel de defensor. O objetivo dessa persona é ver os possíveis “ataques” projetados pela persona adversária como ameaças potenciais e criar controles de segurança que atenuem as ameaças. Essa persona também avalia se as possíveis mitigações são razoavelmente gerenciáveis em termos de suporte operacional contínuo, monitoramento e resposta a incidentes.

A persona AppSec SME: A persona especialista no assunto (Subject Matter Expert – SME) de Application Security (AppSec) deve estar mais familiarizada com o processo de modelagem de ameaças e os métodos de moderação de discussões, e deve ter um profundo conhecimento e experiência em segurança de TI. A moderação da discussão é crucial para o processo geral do exercício, a fim de garantir que os objetivos gerais do processo sejam mantidos no caminho certo e que o equilíbrio adequado entre segurança e entrega do resultado do cliente seja mantido. Em última análise, é essa pessoa que endossa o modelo de ameaça e aconselha o escopo das ações, além do exercício de modelagem de ameaças e também o escopo do teste de penetração.

2. Tenha uma abordagem consistente

Na seção anterior, listei algumas das abordagens populares de modelagem de ameaças. Sua seleção não é tão importante quanto usá-la de forma consistente em todas as equipes.

Ao usar uma abordagem e um formato consistente, as equipes podem se mover mais rapidamente e estimar o esforço com mais precisão. Os indivíduos podem aprender com exemplos, observando modelos de ameaças desenvolvidos por outros membros da equipe ou até outras equipes, evitando ter de começar do zero.

Quando sua equipe estima o esforço e o tempo necessários para criar um modelo de ameaça, a experiência e o tempo gasto com modelos de ameaças anteriores podem ser usados para fornecer estimativas mais precisas dos cronogramas de entrega.

Além da consistência na abordagem e no formato, ter consistência na granularidade e relevância das ameaças que estão sendo modeladas é fundamental. Mais adiante neste post, descrevo uma recomendação para criar um catálogo de ameaças para reutilização em toda a sua organização.

Por fim, e mais importante, essa abordagem permite escalabilidade: se um determinado recurso do workload que está passando por um exercício de modelagem de ameaças estiver usando componentes que tenham um modelo de ameaça existente, o modelo de ameaça (ou controles de segurança individuais) desses componentes poderão ser reutilizados. Com essa abordagem, você pode efetivamente depender do modelo de ameaça existente de um componente e desenvolver esse modelo, eliminando o retrabalho.

3. Alinhe-se à metodologia de entrega de software

Suas equipes de desenvolvimento de aplicações já têm um fluxo de trabalho e um estilo de entrega específicos. Atualmente, a entrega no estilo da Metodologia Ágil é a mais popular. A abordagem adotada para modelagem de ameaças deve se integrar bem com sua metodologia de entrega e ferramentas.

Assim como em qualquer outro resultado de entrega, capture as histórias de usuários relacionadas à modelagem de ameaças como parte do sprint, epic ou backlog do recurso do workload.

4. Use ferramentas de fluxo de trabalho existentes

Suas equipes de desenvolvimento de aplicações já estão usando um conjunto de ferramentas para dar suporte à metodologia de entrega. Isso normalmente inclui ferramentas de colaboração para documentação (por exemplo, uma wiki de equipe) e uma ferramenta de rastreamento de problemas para rastrear erros durante o ciclo de vida de desenvolvimento de software. Procure usar essas mesmas ferramentas como parte de seu fluxo de trabalho de análise de segurança e modelagem de ameaças.

As ferramentas de fluxo de trabalho existentes podem oferecer um único local para fornecer e visualizar feedbacks, atribuir ações e visualizar o status geral dos resultados de modelagem de ameaças do recurso no workload. Fazer parte do fluxo de trabalho reduz o atrito de concluir o projeto e permite que a modelagem de ameaças se torne tão comum quanto testes de unidade, testes de controle de qualidade ou outras etapas típicas do fluxo de trabalho.

Ao usar ferramentas típicas de fluxo de trabalho, os membros da equipe que trabalham na criação e revisão do modelo de ameaça podem trabalhar de forma assíncrona. Por exemplo, quando o revisor do modelo de ameaça adiciona um feedback, o autor é notificado e pode responder ao feedback quando tiver tempo, sem ter de reservar um horário específico para uma reunião. Além disso, isso permite que o AppSec SME trabalhe de forma mais eficaz em várias revisões de modelos de ameaças nas quais possa estar envolvido.

Ter uma abordagem e linguagem consistentes, conforme descrito anteriormente, é um pré-requisito importante para viabilizar esse processo assíncrono, para que cada participante possa ler e entender o modelo de ameaça sem ter que reaprender a interpretação correta a cada vez.

5. Divida a workload em partes menores

É aconselhável decompor (dividir) o workload em recursos e realizar o exercício de modelagem de ameaças no nível do recurso, em vez de criar um único modelo de ameaça para um workload inteiro. Essa abordagem tem vários benefícios principais:

1. Ter partes menores de trabalho permite um acompanhamento mais granular do progresso, o que se alinha bem com as equipes de desenvolvimento que estão seguindo a entrega no estilo Ágil, além de oferecer aos líderes uma visão constante do progresso.
2. Essa abordagem tende a criar modelos de ameaças mais detalhados, o que resulta na identificação de mais descobertas.
3. A decomposição também abre a oportunidade para que o modelo de ameaça seja reutilizado como uma dependência para outros recursos do workload que usam os mesmos componentes.
4. Ao considerar as mitigações de ameaças para cada componente, no nível geral do workload, isso significa que uma única ameaça pode ter várias mitigações, resultando em uma resiliência aprimorada contra essas ameaças.
5. Problemas com um único modelo de ameaça, por exemplo uma ameaça crítica que ainda não foi mitigada, não se tornam impeditivos de lançamento para todo o workload, mas apenas para o recurso individual.

A questão então é: até que ponto você deve decompor o workload?

Como regra geral, para criar um modelo de ameaça o seguinte contexto é necessário, no mínimo:

• Um ativo. Por exemplo, credenciais, registros de clientes e assim por diante.
• Um ponto de entrada. Por exemplo, implantação da API REST do Amazon API Gateway.
• Dois componentes. Por exemplo, um navegador da web e uma API REST do API Gateway; ou API Gateway e uma função do AWS Lambda.

Criar um modelo de ameaça para um determinado serviço da AWS (por exemplo, o API Gateway) isoladamente não atenderia totalmente a esses critérios, visto que o serviço é um componente único, não há movimentação dos dados de um componente para outro. Além disso, o contexto de todos os casos de uso possíveis do serviço em um workload não é conhecido, portanto, você não pode obter de forma abrangente as ameaças e mitigações. A AWS executa a modelagem de ameaças dos vários recursos que compõem um determinado serviço da AWS. Portanto, para seu recurso de workload que utiliza um determinado serviço da AWS, você não precisaria fazer modelagem de ameaça do serviço em si, mas sim considerar as várias opções de configuração de serviços da AWS e as mitigações específicas do seu próprio workload ao mitigar as ameaças identificadas. Eu me aprofundo nisso na seção “Identifique e avalie mitigações”, onde falo sobre o conceito de controles de segurança de baseline.

6. Distribua a responsabilidade

Ter uma pessoa ou departamento central responsável pela criação de modelos de ameaças não funciona a longo prazo. Essas entidades centrais tornam-se gargalos e só podem aumentar a escala verticalmente com um número adicional de funcionários. Além disso, a responsabilidade centralizada não capacita aqueles que estão realmente projetando e implementando seus recursos do workload.

Em vez disso, o que se expande bem é a responsabilidade distribuída da criação do modelo de ameaça pela equipe responsável por projetar e implementar cada recurso do workload. A responsabilidade distribuída dimensiona e impulsiona a mudança de comportamento, porque agora as equipes de aplicações estão no controle e, o mais importante, estão levando o que aprenderam sobre segurança do processo de modelagem de ameaça para o novo lançamento de recursos. Ou seja, estão constantemente melhorando a segurança dos seus workloads e recursos.

Isso cria a oportunidade para o SME (ou equipe) de AppSec desempenhar efetivamente a função de moderador e consultor de segurança para todas as várias equipes de aplicações em sua organização. O AppSec SME estará em posição de impulsionar a consistência, a adoção e a comunicação, além de definir e elevar o nível de segurança entre as equipes.

7. Identifique pontos de entrada

Quando você procura identificar pontos de entrada para serviços da AWS que são componentes dentro do seu modelo geral de ameaças, é importante entender que, dependendo do tipo de serviço da AWS, os pontos de entrada podem variar de acordo com a arquitetura do recurso do workload incluído no escopo do modelo de ameaça.

Por exemplo, com o Amazon Simple Storage Service (Amazon S3), os tipos possíveis de pontos de entrada para um bucket do S3 são limitados ao que é exposto por meio da API do Amazon S3, e o serviço não oferece o recurso para você, como cliente, para criar tipos adicionais de pontos de entrada. Neste exemplo do Amazon S3, como cliente, você faz escolhas sobre como esses tipos existentes de endpoints são expostos, incluindo se o bucket é privado ou publicamente acessível.

No outro extremo do espectro, o Amazon Elastic Compute Cloud (Amazon EC2) permite que os clientes criem tipos adicionais de pontos de entrada para instâncias do EC2 (por exemplo, a API da sua aplicação), além dos tipos de ponto de entrada fornecidos pela API do Amazon EC2 e os nativos do sistema operacional em execução na instância do EC2 (por exemplo, SSH ou RDP).

Portanto, verifique se você está aplicando os pontos de entrada específicos ao recurso do workload, além dos endpoints nativos para serviços da AWS, como parte do seu modelo de ameaça.

8. Crie ameaças

Seu objetivo aqui é tentar encontrar respostas para a pergunta “O que pode dar errado?” Não há nenhuma lista canônica que exiba todas as ameaças possíveis, porque a determinar ameaças depende do contexto do recurso do workload que está sendo avaliado e dos tipos de ameaças que são exclusivas de um determinado setor, área geográfica e assim por diante.

Criar ameaças requer brainstorming. O exercício de brainstorming pode ser facilitado usando um processo mnemônico, como STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, e Elevation of Privilege), ou examinando listas de ameaças como a OWASP Top 10 ou HiTrust Threat Catalog para que as ideias fluam.

Por meio desse processo, é recomendável que você desenvolva e contribua para um catálogo de ameaças que seja contextual para sua organização e que acelere o processo de brainstorming daqui para frente, além de gerar consistência na granularidade das ameaças que você modela.

9. Identifique e avalie as mitigações

Aqui, seu objetivo é identificar as mitigações (controles de segurança) dentro do projeto do workload e avaliar se as ameaças foram tratadas adequadamente. Lembre-se de que normalmente existem várias camadas de controles e várias responsabilidades em jogo.

Para suas próprias aplicações e códigos internos, seria interessante revisar as mitigações que foram inclusas em seu design, entre elas a validação de entrada, a autenticação, o tratamento de sessão e o tratamento de limites.

Considere todos os outros componentes do seu workload (por exemplo, software como serviço (SaaS), infraestrutura que suporta suas aplicações COTS ou componentes hospedados em seus datacenters on-premises) e determine os controles de segurança que fazem parte do projeto do workload.

Quando você usa os serviços da AWS, a segurança e a conformidade são uma responsabilidade compartilhada entre a AWS e você como nosso cliente. Isso é descrito na página do Modelo de Responsabilidade Compartilhada da AWS.

Isso significa que, para as partes dos serviços da AWS que você está usando e que são de responsabilidade da AWS (Segurança da nuvem), os controles de segurança são gerenciados pela AWS, juntamente com a identificação e mitigação de ameaças. A distribuição de responsabilidade entre a AWS (Segurança da nuvem) e você (Segurança na nuvem) depende de qual serviço da AWS você usa. Abaixo, forneço exemplos de infraestrutura, encapsulados e serviços abstratos da AWS, afim de mostrar como sua responsabilidade pela identificação e mitigação de ameaças pode variar:

• O Amazon EC2 é um bom exemplo de um serviço de infraestrutura, onde você pode acessar um servidor virtual na nuvem, escolher o sistema operacional e controlar o serviço e todos os aspectos executados nele. Portanto, você seria responsável por mitigar as ameaças identificadas.
• O Amazon Relational Database Service (Amazon RDS) é um exemplo representativo de um serviço encapsulado, onde não há nenhum sistema operacional exposto para você e, em vez disso, a AWS expõe o mecanismo de banco de dados selecionado para você (por exemplo, MySQL). A AWS é responsável pela segurança do sistema operacional neste exemplo, e você não precisa criar mitigações. No entanto, o mecanismo de banco de dados e todos os aspectos acima dele estão sob seu controle, portanto, você precisaria considerar mitigações para essas áreas. Aqui, a AWS está assumindo uma parcela maior da responsabilidade em comparação com os serviços de infraestrutura.
• O Amazon S3, o AWS Key Management Service (AWS KMS) e o Amazon DynamoDB são exemplos de um serviço abstrato em que a AWS expõe todo o ambiente de gerenciamento e acesso aos dados a você por meio da API de serviço. Novamente, aqui não há sistemas operacionais, mecanismos de banco de dados ou plataformas expostos; isso é uma responsabilidade da AWS. No entanto, as ações da API e as políticas associadas estão sob seu controle, assim como todos os aspectos acima do nível da API e, portanto, você deve considerar mitigações para isso. Para esse tipo de serviço, a AWS assume uma parcela maior de responsabilidade em comparação com os tipos de serviço encapsulado e de infraestrutura.

Embora esses exemplos não abranjam todos os tipos de serviços da AWS que possam estar em seu workload, eles demonstram como suas responsabilidades de segurança e conformidade sob o Modelo de Responsabilidade Compartilhada variam nesse contexto. Compreender o equilíbrio de responsabilidades entre a AWS e você para os tipos de serviços da AWS em seu workload ajuda você a definir o escopo do exercício de modelagem de ameaças para as mitigações que estão sob seu controle, que normalmente são uma combinação de opções de configuração de serviço da AWS e suas próprias mitigações específicas do workload. Para a parte da responsabilidade da AWS, você descobrirá que os serviços da AWS estão dentro do escopo de muitos programas de conformidade, e os relatórios de auditoria estão disponíveis para download pelos clientes da AWS (sem custo) no AWS Artifact.

Independentemente de quais serviços da AWS você está usando, sempre há um elemento de responsabilidade do cliente, e isso deve ser incluído no seu modelo de ameaça do workload.

Especificamente, para mitigações de controle de segurança para os próprios serviços da AWS, você deve considerar controles de segurança entre domínios, incluindo os seguintes: Identity and Access Management (autenticação/autorização), proteção de dados (em repouso, em trânsito), segurança de infraestrutura, logs e monitoramento. Cada um dos serviços da AWS tem um capítulo de segurança dedicado na documentação, que fornece orientações sobre os controles de segurança a serem considerados como mitigações. Ao capturar esses controles de segurança e mitigações em seu modelo de ameaça, você deve procurar incluir referências ao código real, às políticas do IAM e aos templates do AWS CloudFormation localizados no repositório de infraestrutura como código do workload e assim por diante. Isso ajuda o revisor ou aprovador do seu modelo de ameaça a obter uma visão inequívoca da mitigação pretendida.

Como no caso da identificação de ameaças, não há uma lista canônica enumerando todos os controles de segurança possíveis. Por meio do processo descrito aqui, você deve desenvolver conscientemente controles de segurança de baseline que se alinham aos objetivos de controle da sua organização e, sempre que possível, implementar esses controles de segurança de baseline como controles no nível da plataforma, incluindo configurações de nível de serviço da AWS (por exemplo, criptografia em repouso) ou guardrails (por exemplo, por meio de Service Control Policies). Ao fazer isso, você pode impulsionar a consistência e a escala, de modo que esses controles de segurança de baseline implementados sejam automaticamente herdados e aplicados para outros recursos do workload que você projeta e implanta.

Quando você cria os controles de segurança de baseline, é importante observar que o contexto de um determinado recurso do workload não é conhecido. Portanto, é aconselhável considerar esses controles como um baseline negociável da qual você pode se desviar, desde que, ao executar o exercício de modelagem de ameaças do workload, você descubra que a ameaça relacionada ao controle do baseline que foi projetado para mitigar não é aplicável, ou que há outras mitigações ou controles de compensação que mitigam adequadamente a ameaça. Controles de compensação e fatores de mitigação podem incluir: classificação reduzida de ativos de dados, acesso não humano ou dados efêmeros.

Para saber mais sobre como começar a pensar nos controles de segurança básicos como parte de sua governança geral de segurança na nuvem, veja o post no blog How to think about cloud security governance (Como pensar sobre governança de segurança na nuvem).

10. Decida quando é suficiente

Não há uma resposta perfeita para essa pergunta. No entanto, é importante ter uma perspectiva baseada em riscos sobre o processo de modelagem de ameaças para a criação de uma abordagem equilibrada, para que a probabilidade e o impacto de um risco sejam considerados adequadamente. A ênfase excessiva em “vamos construir e lançar” pode levar a custos e atrasos significativos posteriormente. Por outro lado, a ênfase excessiva em “vamos mitigar todas as ameaças possíveis” pode levar ao lançamento atrasado (ou cancelado) do recurso do workload, e você pode perder clientes. Na recomendação que fiz anteriormente na seção “Montar a equipe certa”, a seleção de personas é deliberada para garantir que haja uma tensão natural entre o lançamento do recurso e a mitigação de ameaças. Abrace essa tensão saudável.

11. Não deixe que a paralisia impeça você antes de começar

Anteriormente, na seção “Divida o workload em partes menores”, eu recomendei a redefinição de seus modelos de ameaças para um recurso do workload. Você pode estar pensando consigo mesmo: “Já enviamos <X número> de recursos, como fazemos a modelagem de ameaça neles?” Essa é uma pergunta completamente sensata.

Minha opinião é que, em vez de voltar aos recursos do modelo de ameaça que já estão ativos, você deve tentar modelar ameaças em quaisquer novos recursos nos quais você está trabalhando no momento e melhorar as propriedades de segurança do código que você enviará a seguir, fazendo isso com todos os recursos seguintes. Durante esse processo, você, sua equipe e sua organização aprenderão não apenas sobre modelagem de ameaças, mas também sobre como se comunicar efetivamente uns com os outros. Faça ajustes, itere, melhore. Em algum momento no futuro, quando estiver fornecendo rotineiramente modelos de ameaças de alta qualidade, consistentes e reutilizáveis para seus novos recursos, você poderá começar a colocar atividades para executar a modelagem de ameaças para recursos existentes em sua lista de pendências.

Conclusão

A modelagem de ameaças é um investimento – na minha opinião, um investimento muito bom, pois encontrar e mitigar ameaças na fase de projeto do seu recurso do workload pode reduzir o custo relativo da mitigação, em comparação com encontrar as ameaças posteriormente. A implementação consistente da modelagem de ameaças provavelmente também melhorará sua postura de segurança ao longo do tempo.

Compartilhei minhas observações e dicas sobre maneiras práticas de incorporar a modelagem de ameaças em sua organização, que se concentram em comunicação, colaboração e experiência liderada por humanos para encontrar e lidar com as ameaças que seu cliente final espera. Tendo essas dicas, incentivo você a examinar os recursos do workload nos quais está trabalhando agora (ou tem em sua lista de pendências) e decidir quais serão os primeiros que passarão pela modelagem de ameaça.

Como complemento e extensão desta publicação no blog, você pode assistir à sessão “How to approach threat modelling” (Como abordar a modelagem de ameaças), gravada no AWS Summit Online Australia and New Zealand 2021.

Para praticar, recomendo o treinamento do workshop “Modelagem de ameaças da maneira certa para Desenvolvedores da AWS”, que você e sua equipe podem fazer gratuitamente. Este workshop de nível introdutório apresenta um pouco do histórico da modelagem de ameaças e por que fazer isso, bem como algumas das ferramentas e técnicas para modelar sistemas, identificar ameaças e selecionar mitigações. O workshop orienta você pelo processo de criação de um modelo de sistema e modelo de ameaça correspondente. Você então avaliaria a utilidade desses modelos. Cada exercício tem instruções passo a passo e você pode usar o livro de exercícios do participante associado durante o workshop. Ao longo do workshop, fornecemos insights sobre como a AWS pensa sobre modelagem de ameaças, nossa cultura de segurança e como escalamos nossas pessoas de segurança.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre o autor

Darran Boyd é arquiteto-chefe de soluções de segurança da AWS, responsável por ajudar os clientes a fazer boas escolhas de segurança e acelerar sua jornada para a nuvem AWS. O foco e a paixão de Darran é oferecer iniciativas estratégicas de segurança que desbloqueiem e capacitem nossos clientes em grande escala.

Revisor

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Dan Rezende atualmente é Senior Technical Trainer no time da AWS LATAM. Ministra treinamentos diversos nos domínios de Arquitetura, Segurança e Migração. Dan também tem experiência prática, já trabalhou em diversos projetos implementando soluções e arquiteturas para suportar diversos workloads de missão crítica como SAP e apoiando projetos de migração, enquanto atuou como arquiteto no time de Serviços Profissionais antes de entrar para o time de Treinamento e Certificação.