Integrando modelagem de ameaças com DevOps
Este post é de autoria de Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez e Ben Hanson
Introdução
A modelagem de ameaças é um método de segurança importante que ajuda a identificar e priorizar as mitigações de risco mais importantes para um aplicativo ou sistema. Este artigo contém algumas reflexões sobre como é possível adotar a modelagem de ameaças de forma mais eficaz e eficiente, integrando-a com as modernas metodologias e ferramentas de DevOps, e focando no valor fornecido a todos os vários atores envolvidos com o Ciclo de Vida de Desenvolvimento de Software.
Este artigo é para si?
Este documento é o resultado do trabalho de uma pequena equipe de especialistas em segurança e modelagem de ameaças da Microsoft e incorpora entradas e ideias de alguns dos especialistas mais proeminentes de fora da Microsoft. Ele tenta abordar uma questão simples, mas urgente: o que devemos fazer para garantir que o processo de modelagem de ameaças que usamos seja atualizado para os requisitos modernos impostos pelas metodologias ágeis e DevOps, para que forneçamos o valor necessário ao menor custo?
Se você é um Product Owner, membro de uma equipe de Segurança ou simplesmente um desenvolvedor que está considerando adotar a modelagem de ameaças como parte do seu ciclo de vida de desenvolvimento, este documento é para você.
Analogamente, se você já adotou a modelagem de ameaças, ainda pode encontrar ideias práticas para melhorar seu processo.
No entanto, o documento foi projetado para introduzir ideias para melhorar os processos atuais ou para adotar com sucesso a modelagem de ameaças como parte do seu processo de DevOps. Não introduz ferramentas ou produtos específicos, mesmo que esperemos ver essas ideias implementadas por algumas ferramentas ou produtos no futuro. Portanto, você não encontrará anúncios de novas ferramentas ou visualizações de recursos futuros, aqui.
Por que a modelagem de ameaças é importante?
A modelagem de ameaças é uma das principais abordagens para projetar soluções de software com segurança. Por meio da Modelagem de ameaças, você analisa um sistema, identifica vetores de ataque e desenvolve ações para mitigar os riscos trazidos por esses ataques. Feita adequadamente, a modelagem de ameaças é um excelente componente de qualquer processo de Gerenciamento de Riscos. Também pode ajudar a reduzir custos, identificando e corrigindo problemas de projeto com antecedência. Um estudo antigo do NIST estimou que o custo de corrigir um problema de projeto no código de produção era cerca de 40 vezes maior do que repará-lo durante a fase de projeto. Ele também economiza custos devido a incidentes de segurança para os eventuais problemas de projeto. Considere que o Relatório de Custo de Violação de Dados de 2022 da IBM Security e do Ponemon Institute estima o custo médio de uma violação de dados em US$ 4,35 milhões. Para as chamadas Mega Violações, envolvendo o comprometimento de mais de 50 milhões de registros, o custo médio chega a R$ 387M!
A modelagem de ameaças é a primeira atividade que você pode fazer para proteger sua solução, pois ela opera no design da solução. Essa característica a torna a prática de segurança mais eficaz que você pode aplicar ao seu SDLC.
A Microsoft tem uma longa história com modelagem de ameaças. Em 1999, dois (então) funcionários da Microsoft, Loren Kohnfelder e Praerit Garg, escreveram um documento, As ameaças aos nossos produtos. Este documento apresentou a abordagem STRIDE, um sinônimo para o processo de modelagem de ameaças da Microsoft.
A modelagem de ameaças é um processo evolutivo
A modelagem de ameaças não é um processo estático; evolui à medida que as necessidades e as tecnologias mudam.
Ataques à cadeia de suprimentos como o recente visando a SolarWinds demonstram a necessidade de cobrir com a modelagem de ameaças mais cenários do que a solução em si, incluindo desenvolvimento e implantação.
Vulnerabilidades de código aberto como a recente do Log4j demonstraram a necessidade de complementar a abordagem atual baseada na adoção de ferramentas de Análise de Composição de Software para verificar componentes vulneráveis, projetando a solução defensivamente para limitar sua exposição.
A aplicação de novas tecnologias como o Machine Learning introduz novos vetores de ataque que devem ser compreendidos e controlados. Considere, por exemplo, a possibilidade de reproduzir sons criados maliciosamente inaudíveis por ouvidos humanos para causar a execução de comandos por serviços de IA, como discutido em https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carlini.
Na Microsoft, diferentes grupos de produtos praticam diferentes variantes de modelagem de ameaças com base em seus requisitos específicos de segurança. Cada variante visa garantir um nível adequado de garantia de segurança aos cenários aos quais é aplicada, mas o que significa "adequado" muda dependendo do contexto específico.
Por exemplo, proteger o Windows é diferente de proteger os Serviços Cognitivos do Azure porque esses sistemas têm tamanhos e características muito diferentes. Um aspeto fundamental da modelagem de ameaças é equilibrar seu custo com a tolerância ao risco de um aplicativo. Embora isso possa levar à decisão de evitar completamente a modelagem de ameaças para alguns cenários, é tão eficaz quando feito corretamente que só podemos recomendar a adoção para qualquer iniciativa de TI, incluindo projetos de desenvolvimento de software e implantação de infraestrutura.
A importância de focar no ROI
Nos últimos dois anos, tem visto um aumento constante no interesse na modelagem de ameaças como um processo chave de desenvolvimento de software. Este interesse deve-se ao aumento exponencial de ataques a infraestruturas e soluções. Iniciativas como o NIST Recommended Minimum Standard for Vendor or Developer Verification of Code e o Threat Modeling Manifesto aumentaram ainda mais a demanda a ponto de as abordagens atuais mostrarem alguns limites. Por exemplo, os resultados da modelagem de ameaças são altamente dependentes do processo adotado e de quem executa o modelo de ameaça. Assim, há uma preocupação em obter consistentemente maior qualidade da experiência.
Mas, o que significa qualidade para a modelagem de ameaças? Para nós, um modelo de ameaça de qualidade deve ter as seguintes características:
Ele deve identificar mitigações acionáveis, atividades que você pode fazer para reduzir as perdas potenciais resultantes de ataques. Acionável significa que essas mitigações devem ser bem definidas, o que significa que você obtém informações suficientes para implementá-las e, em seguida, testar a implementação. Isso também significa que eles devem ser fornecidos para permitir um consumo fácil da equipe de desenvolvimento. Com DevOps e Agile, isso significa que há um caminho fácil para importar as mitigações para o Backlog.
Para cada Mitigação, ele deve identificar seu status. Algumas atenuações são novas, enquanto outras já existem. O modelo de ameaça deve reconhecer o que já existe e concentrar-se no risco atual para identificar como melhorar a situação.
Ele deve identificar claramente por que cada mitigação é necessária, vinculando-a às respetivas ameaças.
Além disso, as mitigações têm uma força relativa para cada ameaça. Por exemplo, a criptografia TLS pode ser uma forte mitigação do risco de ter dados em trânsito divulgados e, ao mesmo tempo, pode ser uma mitigação quase completa do risco de ter o servidor falsificado.
As ameaças devem ser credíveis, bem definidas e específicas para a solução.
As ameaças devem ter uma gravidade associada, que deve considerar tanto a sua probabilidade como o impacto. A gravidade deve ser razoável e, idealmente, imparcial.
Deve ser possível obter uma visão abrangente dos riscos e da forma como podem ser abordados. Essa visão seria fundamental para conduzir uma conversa significativa com a equipe de Segurança e com os tomadores de decisão de negócios, e nos permitiria esconder as complexidades desnecessárias.
Esta lista já mostra um conceito importante: a modelagem de ameaças pode fornecer valor para muitas funções envolvidas durante o ciclo de vida do software, mas cada função tem necessidades e requisitos diferentes. Por exemplo, os desenvolvedores precisam receber informações claras sobre o que precisam implementar e sobre como verificar se o que implementaram se comporta conforme o esperado. Por outro lado, a equipe de Segurança normalmente está preocupada com a segurança geral do ecossistema de infraestrutura e aplicativos de propriedade da organização; Por conseguinte, necessitam de receber informações que lhes permitam decidir se o sistema abrangido é suficientemente seguro e satisfaz os seus requisitos de conformidade. Finalmente, os Product Owners e os tomadores de decisão de negócios precisam entender o que é necessário para tornar o risco aceitável para a organização.
Tais necessidades diferentes exigem fornecer visões diferentes sobre o modelo de ameaça, cada uma delas focada em um cenário de uso específico.
Um problema típico com a modelagem de ameaças é que, quanto mais ela é bem-sucedida, mais difícil para os poucos especialistas disponíveis cobrir a demanda e, ao mesmo tempo, fornecer a alta qualidade esperada dessa experiência. Como resultado, em alguns casos, a qualidade pode ser afetada negativamente. Tudo é bom até que a modelagem de ameaças pare de fornecer um valor significativo em comparação com o investimento. Não são poucas as organizações que são afetadas por esse problema. Já houve alguns relatos de tomadores de decisão de negócios começando a questionar a modelagem de ameaças porque ela não entregaria um valor significativo para o custo.
Com valor, nos referimos ao valor de negócio, que é a capacidade de fornecer as informações necessárias para entender os riscos representados pelo sistema no escopo e conduzir um processo de decisão significativo para selecionar as mitigações adequadas a serem implementadas. Além disso, o valor também está relacionado ao fornecimento das informações corretas aos desenvolvedores e testadores. Finalmente, o valor está relacionado com a comunicação do risco residual a todas as partes envolvidas. Podemos, por exemplo, medir o valor medindo o impacto do processo de modelagem de ameaças. Suponhamos que medimos o risco geral da solução atribuindo um número à Severidade identificada para cada ameaça. Nesse caso, esperamos que o risco geral diminua ao longo do tempo por efeito do modelo de ameaça. Se o risco geral permanecer constante ou aumentar, podemos ter um problema. Quanto mais acentuada for a diminuição, maior será o impacto do modelo de ameaça. É claro que o modelo de ameaça não controlaria as mitigações implementadas. É da responsabilidade do Product Owner decidir o que deve ser implementado. Mas a vantagem de vincular a eficácia do modelo de ameaça com a implementação real das mitigações é que ele aumenta o impacto na segurança real da solução, reduzindo o risco de que o modelo de ameaça permaneça um exercício teórico.
Em vez disso, o custo está relacionado às atividades necessárias para executar o modelo de ameaça em si, que é o tempo exigido por todas as partes envolvidas para produzir o modelo de ameaça e discuti-lo.
Isso levanta a questão: podemos definir um processo de modelagem de ameaças focado em maximizar o valor do negócio e minimizar o custo?
A importância do DevOps
Já destacamos o quão importante é garantir que a modelagem de ameaças seja uma prática valiosa integrada ao processo de DevOps. Isso significa que o processo deve estar disponível para todos os membros da equipe, normalmente simplificando-o e automatizando-o. Mais importante ainda, focar na modelagem de ameaças para DevOps significa que precisamos garantir que a experiência seja profundamente integrada com os processos de DevOps existentes.
A modelagem de ameaças não deve se tornar mais um fardo, mas deve ser um ativo para facilitar a elicitação e coleta de requisitos de segurança, o design de soluções seguras, a inclusão de atividades na ferramenta Task & Bug Tracking de escolha e a avaliação do risco residual dado o estado atual e futuro da solução.
Alinhamento com o DevOps
Podemos empregar várias técnicas para alinhar a modelagem de ameaças com a prática atual de DevOps.
Ameaças e mitigações
Primeiro, devemos concentrar o processo de modelagem de ameaças no que precisa ser feito. As ameaças, que são os padrões de ataque e como eles podem acontecer, são necessárias para explicar por que a equipe precisa implementar um controle de segurança. São também um fator para determinar quando as mitigações devem ser implementadas. Ainda assim, o verdadeiro objetivo é determinar o que precisa ser feito: as mitigações. Portanto, a abordagem deve levar à rápida identificação das mitigações necessárias e deve informar o processo de decisão para que seja mais fácil determinar o que fazer e quando. A principal entrega desse processo de decisão é ter as mitigações selecionadas no Backlog para torná-las parte do processo padrão. Idealmente, a ferramenta de modelagem de ameaças e a ferramenta de rastreamento de bugs de tarefas devem ser sincronizadas para refletir as atualizações do status de mitigação no modelo de ameaça. Isso permitiria a revisão do risco residual de forma dinâmica e automática, o que é vital para apoiar decisões informadas como parte das coreografias usuais da metodologia Agile adotada, como a reunião de Sprint Planning.
O que você pode fazer hoje?
Como especialista em modelagem de ameaças, você deve garantir a implementação de um processo de modelagem de ameaças que seja capaz de identificar claramente as ações e incluí-las em sua Tarefa & Bug Tracking de sua escolha. Uma maneira pode ser adotar uma das muitas ferramentas de modelagem de ameaças capazes de automatizar esse processo.
Como desenvolvedor, você deve se concentrar nos controles de segurança identificados como necessários. O processo deve ser projetado para fornecê-los a você da mesma forma que você espera receber qualquer outra atividade.
Recursos, histórias de usuários e tarefas
Já afirmamos que as mitigações representam o artefato mais importante produzido pelo modelo de ameaça em relação à integração de DevOps. Portanto, é importante definir claramente o tipo de objetos criados a partir dessas atenuações na ferramenta Task & Bug Tracking de sua escolha. Algumas atenuações podem durar mais do que um Sprint. Portanto, pode ser melhor criá-los como Recursos. Mas muitos são mais fáceis e poderiam ser implementados em um único Sprint; assim, seria possível representá-los como user stories ou tarefas. Embora seja possível gerar diferentes tipos de itens de trabalho, isso pode resultar em um processo complicado que pode levar a erros e confusão. Por esse motivo, parece mais prático ficar com um único tipo de item de trabalho. Dado que as mitigações podem ser consideradas filhos de histórias de usuários, você pode considerar representá-las como Tarefas, o que implica relaxar a exigência de ter o referido tipo de item de trabalho executado em um único Sprint.
O que você pode fazer hoje?
Certifique-se de que as mitigações identificadas pelo modelo de ameaça sejam representadas na lista de pendências. Identifique uma maneira de representá-los claramente.
Histórias de utilizador
As mitigações não são os únicos artefatos que fazem parte de um modelo de ameaça, que pode e deve estar alinhado com o que você tem em sua ferramenta Task & Bug Tracking. Por exemplo, você também pode querer representar ameaças. Este objetivo poderia ser alcançado estendendo as histórias de usuário através da adição de uma cláusula SEM ao habitual "Como um [quem sou eu] eu quero [o que eu quero] para que eu possa [fazer algo]." Por exemplo: "Como utilizador, quero pagar com o meu cartão de crédito para poder comprar alguns bens, SEM ter o meu cartão de crédito roubado dados". A cláusula WITHOUT pode ser mapeada para uma ou mais ameaças e, às vezes, pode expressar Requisitos de Segurança. Ao garantir que esse alinhamento entre ameaças e cláusulas WITHOUT seja explicitado dentro do modelo de ameaças, podemos garantir que os possíveis riscos sejam refletidos e atendidos pela equipe porque são incluídos como parte das histórias de usuários. Você também pode usar essa relação para mapear todos os Requisitos de Segurança identificados como parte das histórias de usuários para, pelo menos, uma ameaça.
Bom saber
A cláusula WITHOUT não é uma ideia original da equipa que produziu esta página. Não sabemos ao certo quem a introduziu pela primeira vez, mas estamos gratos a quem veio com esta ideia.
Figura 1: Alinhamento dos requisitos
Por exemplo, a imagem anterior mostra as seguintes situações:
A ameaça A está ligada à História de Utilizador 1 através da cláusula SEM 1.
A ameaça B está ligada à História de Utilizador 2 através da cláusula SEM 2.
A ameaça B também está ligada ao User Story 3. Mas o User Story 3 não é atribuído a nenhuma cláusula WITH. Porquê? Representa uma anomalia potencial que deve investigar.
A ameaça B também está ligada à User Story 1. Ainda não está claro se devemos permitir que histórias de usuários sejam vinculadas a mais de uma ameaça.
A ameaça C está ligada à User Story 4, que está associada a SEM 3 e 4. Ainda não está claro se devemos permitir mais de uma cláusula SEM.
A ameaça D não está vinculada a nenhuma história de usuário. Estamos perdendo uma história de usuário ou uma cláusula SEM?
O User Story 5 está vinculado a uma cláusula WITH, mas não tem nenhuma ameaça associada. Estamos perdendo uma ameaça ou simplesmente um link entre uma história de usuário e uma ameaça?
Raramente identificamos os Requisitos de Segurança como parte do modelo de ameaça. Portanto, a cláusula WITHOUT introduz a oportunidade de integrar ainda mais a experiência, estendendo os modelos de ameaça com os Requisitos de Segurança e vinculando-os às histórias de usuários relacionadas. Essa abordagem desempenharia um papel significativo na evolução da experiência de modelagem de ameaças, deixando de ser uma avaliação repetida ao longo do tempo para se tornar a ferramenta de design de segurança para DevOps.
O que você pode fazer hoje?
Comece a usar a cláusula WITHOUT em suas histórias de usuário.
Mapeie as ameaças que você identifica para histórias de usuários com cláusulas WITHOUT e vice-versa.
Uma experiência integrada
Você pode aplicar a mesma ideia a outros cenários. Por exemplo, o modelo de ameaça pode vincular os Requisitos de Segurança com artefatos dentro do próprio modelo de ameaça – como ameaças e mitigações – e aqueles na ferramenta Rastrear & Bug Track. Por exemplo, o requisito de implementar o monitoramento para identificar ataques em andamento deve ser mapeado para todas as mitigações relacionadas ao monitoramento e, em seguida, para os artefatos correspondentes na ferramenta Task & Bug Tracking. Como resultado, seria fácil identificar situações em que um Requisito de Segurança não é realizado: na verdade, ele não estaria vinculado a nada.
Você pode usar os mesmos links entre os artefatos na ferramenta Task & Bug Tracking e as ameaças e mitigações identificadas pelo modelo de ameaça para facilitar a priorização das atividades de segurança. A segurança geralmente é implementada por último, às vezes para resolver vulnerabilidades reativamente identificadas por alguma ferramenta ou um Teste de Penetração. Pelo contrário, seria mais eficaz implementar as mitigações juntamente com as histórias de usuário ou recursos relacionados. Por que esperar para implementar os controles para proteger os detalhes do cartão de crédito quando você deve implementá-los juntamente com as funções de pagamento relacionadas? O modelo de ameaça deve destacar essas relações e fornecer uma maneira simples de determinar quando a implementação de algum recurso durante um Sprint requer a implementação de algum recurso de segurança relacionado. Essas informações podem ser usadas, por exemplo, durante a reunião de Planejamento da Sprint para ter uma discussão significativa e impulsionar uma priorização informada. O mecanismo é simples. Vamos supor que o Product Owner de um projeto em que trabalhamos decida planejar uma história de usuário para o próximo Sprint. A referida história de usuário tem uma cláusula WITHOUT que está ligada à ameaça. O modelo de ameaça identifica várias mitigações para a mesma ameaça. Portanto, podemos deduzir imediatamente que devemos priorizar uma ou mais das mitigações identificadas.
Figura 2: Priorizando a segurança
Por exemplo, na imagem acima, podemos ver que a User Story 1 está ligada à ameaça 1, que por sua vez está ligada às mitigações A e B. Por conseguinte, devemos também considerar a implementação de uma ou ambas as atenuações.
O que você pode fazer hoje?
Vincule histórias de usuários com cláusulas WITHOUT aos itens de trabalho correspondentes às mitigações selecionadas usando o modelo de ameaça como referência. Ao planejar o próximo Sprint, certifique-se de priorizar as atividades de segurança vinculadas ao implementar uma dessas histórias de usuário com cláusulas WITH.
Integração para destacar desalinhamentos
Uma vez que começamos a pensar em como poderíamos vincular os artefatos que compõem o modelo de ameaça com aqueles na ferramenta Task & Bug Tracking, torna-se mais fácil identificar oportunidades para melhorar a qualidade de ambos. A chave é alavancar seus relacionamentos para destacar discrepâncias e aproveitar as informações presentes em um para complementar, integrar e interpretar o que está presente no outro. Como discutido acima, você pode fazer isso sem afetar significativamente como a equipe já trabalha. Isso porque a abordagem se baseia em informações existentes e cria relações entre os vários objetos nos vários mundos. Portanto, o Modelo de Ameaça se tornaria a fonte da verdade para a segurança da solução. Ao mesmo tempo, o Backlog está continuamente alinhado com o status da solução.
O que você pode fazer hoje?
Verifique regularmente se não há ameaças não mapeadas ou histórias de usuários com cláusulas WITH.
Modelagem de ameaças e operações
Todas essas ideias são focadas principalmente no lado do desenvolvimento do DevOps. Podemos fazer algo para melhorar as operações também? Pensamos que sim. Por exemplo, seria possível usar a modelagem de ameaças como uma ferramenta para facilitar a Análise de Causa Raiz, pois fornece uma visão abrangente do sistema de uma perspetiva de segurança e, portanto, pode fornecer uma melhor compreensão das implicações de alguns ataques. Para isso, seria necessário integrar o modelo de ameaça com os feeds existentes das ferramentas de monitoramento escolhidas. Esta abordagem pode representar um complemento para o SIEM escolhido.
Outra ideia para integrar a modelagem de ameaças com as Operações é usar a primeira para orientar o design de como a última poderia acontecer. Um exemplo disso é o design de eventos para a solução. A modelagem de ameaças identifica possíveis ataques, e podemos usar esse conhecimento para identificar eventos que a solução no escopo pode gerar quando esses ataques falham. Se você fizer uma validação de entrada rigorosa, um invasor mal-intencionado precisará de algumas tentativas antes de ter êxito. Inicialmente, as tentativas fracassam e uma delas acaba sendo bem-sucedida. Ao gerar eventos para cada falha e disparar alertas quando algum limite é atingido, você pode detetar ataques e tomar ações para corrigi-los. Essas situações raramente são detetadas se você se limitar a monitorar a infraestrutura. Portanto, é necessário incluir eventos personalizados, que a equipe deve projetar e implementar antes que o SOC possa aproveitá-los.
Além disso, este último pode não saber muito sobre a solução. Portanto, o SOC pode não ser capaz de determinar como reagir quando a validação de entrada falhar. Infelizmente, quando ocorre uma violação de dados, é imperativo reagir rapidamente para reduzir os danos diretos e a probabilidade e entidade de eventuais multas.
Por conseguinte, temos de planear antecipadamente o que precisa de ser monitorizado, em que condições podemos ter um problema e o que fazer quando isso acontece. A melhor maneira de identificar esses eventos é confiar em um modelo de ameaça. Portanto, seria útil aproveitá-lo para gerar artefatos padronizados para orientar e acelerar a implementação das configurações necessárias para impulsionar o monitoramento e a auditoria e facilitar a resposta a incidentes.
O que você pode fazer hoje?
Use ativamente o modelo de ameaça para identificar eventos que você pode gerar para cada ameaça. Esses eventos podem ser fornecidos pela infraestrutura, ou algo que o aplicativo deve levantar. Inclua itens de trabalho em sua lista de pendências para garantir que esses eventos sejam implementados.
Trabalhe ativamente com suas equipes de Operações e Segurança, incluindo a equipe SOC, para garantir que os eventos sejam aproveitados para gerar alertas e identificar Incidentes de Segurança.
O impacto no ROI
Você pode se perguntar por que essas técnicas podem impactar positivamente o ROI da modelagem de ameaças. Do nosso ponto de vista, eles são cruciais para aumentar o valor da modelagem de ameaças para as equipes de DevOps. O problema que temos visto repetidamente é que essas equipes percebem a segurança como um custo que fornece valor limitado e requer muito trabalho imprevisto. Às vezes, não está claro por que eles devem investir tanto tempo consertando a segurança. Como resultado, a segurança torna-se um problema em vez de ser uma oportunidade. A modelagem de ameaças tem o potencial de superar esses problemas porque fornece as razões para implementar a segurança. Além disso, pode ser iniciado no início do processo de desenvolvimento e evitar erros de design que podem custar caro se não forem detetados em breve. As técnicas acima visam integrar melhor a modelagem de ameaças com o DevOps. Isso garante que os tomadores de decisão de negócios e desenvolvedores percebam a modelagem de ameaças como um complemento natural ao processo de desenvolvimento e operações. Portanto, o valor recebido pela adoção da modelagem de ameaças aumenta, e seus custos diminuem devido à integração com as diversas ferramentas já em uso.
Simplificando o trabalho dos modeladores de ameaças
Outro aspeto importante necessário para melhorar o ROI da modelagem de ameaças está relacionado à redução de seu custo e ao aumento do número de pessoas capazes de entregá-lo, mantendo níveis de qualidade mais homogêneos.
Há muitas tentativas para resolver a falta de pessoas competentes. Alguns deles são baseados no envolvimento ativo de toda a equipe de DevOps no exercício de modelagem de ameaças. A ideia é identificar um líder da iniciativa, que é alguém com conhecimento intermediário sobre o processo, mas não necessariamente um especialista, e fazer com que ela lidere a discussão entre os outros membros da equipe. Essa abordagem é ativamente endossada pelos signatários do Manifesto de Modelagem de Ameaças.
Concordamos que esta abordagem permite obter um bom valor e representa uma melhoria em relação à situação atual. Ele também fornece bons insights e permite que a equipe desenvolva sua cultura de segurança. No entanto, não está isento de desvantagens porque abrange apenas algumas questões, deixando de fora muitas coisas. Isso cria um problema de consistência, porque seria muito fácil ir pela toca do coelho e perder tempo precioso em questões secundárias, perdendo questões importantes. A experiência do líder desempenharia um papel significativo na prevenção dessas situações. Além disso, essa abordagem requer muito tempo de todos os membros da equipe para discutir cada questão.
Por esta razão, mesmo gastar algumas horas por Sprint para este exercício pode representar um investimento significativo. Todo mundo sabe que a maioria das equipes tende a perder tempo em grandes reuniões envolvendo todos, e essas sessões de modelagem de ameaças não fariam uma exceção. Ainda assim, esta abordagem é excelente para produtos pequenos, onde a equipa é composta por um punhado de membros seniores.
Uma abordagem diferente
Dadas as limitações da abordagem anterior, preferimos limitar o número de reuniões, a sua duração e o número de participantes. Portanto, a responsabilidade do modelador de ameaças seria mais significativa: não apenas conduzir as entrevistas, mas também criar e manter o próprio modelo de ameaça. Esta abordagem requer competências e conhecimentos mais significativos. Os modeladores de ameaças podem ser representados por Campeões de Segurança ou por membros da equipa de Segurança interna. A maioria das organizações optaria pela primeira porque a equipe de Segurança normalmente está totalmente reservada.
Security Champions são membros das equipes de DevOps com um interesse particular em segurança. Não são especialistas de forma alguma, mas têm um conhecimento básico e a vontade de melhorar a postura de segurança da sua equipa. A ideia é criar uma conexão privilegiada entre os Campeões de Segurança e a equipe de Segurança interna para que os primeiros sejam capacitados para ajudar suas equipes a fazer a coisa certa, enquanto a equipe de Segurança pode reduzir sua carga de trabalho. Com a modelagem de ameaças, os Campeões de Segurança atuariam como modeladores de ameaças, e a equipe de Segurança interna teria a responsabilidade de orientá-los e revisar seu trabalho.
O que você pode fazer hoje?
Investigue a possibilidade de adotar um programa Security Champions e aproveitá-lo para fortalecer ainda mais seu ciclo de vida de desenvolvimento de software seguro.
O papel das bases de conhecimento
Um problema significativo com a modelagem de ameaças é garantir que a qualidade da experiência e o valor para a equipe de DevOps sejam altos, independentemente de quem executa o modelo de ameaça. Com o Security Champions, este problema torna-se ainda mais urgente. Uma ideia para resolver isso é fornecer bases de conhecimento para impulsionar a criação do modelo de ameaça. As Bases de Conhecimento para modelagem de ameaças são pacotes de informações sobre um contexto específico: elas contêm uma definição das entidades relacionadas a esse contexto, os possíveis padrões de ataque sobre essas entidades e as mitigações padrão que podem ser aplicadas. As bases de conhecimento permitem que a organização obtenha resultados melhores e mais consistentes porque representam material de referência que orienta os modeladores de ameaças de forma prescritiva. As bases de conhecimento devem ter regras que nos permitam aplicar ameaças e mitigações a um sistema automaticamente. Essa automação nos permitiria superar o fato de que alguns modeladores de ameaças podem não ter a experiência necessária para determinar se uma ameaça deve ser aplicada ou se alguma mitigação é eficaz.
As bases de conhecimento não são uma ideia nova: muitas ferramentas atuais de modelagem de ameaças já as suportam de alguma forma. Mas muitas implementações atuais têm desvantagens significativas. Por exemplo, você deve ser capaz de manter bases de conhecimento facilmente. A sua manutenção é um problema que ainda está por resolver. Por exemplo, não é fácil identificar as melhores fontes de informação a serem usadas para construí-las. Além disso, a manutenção é tipicamente manual. A criação e manutenção das bases de conhecimento deve ser da responsabilidade da equipa de Segurança interna da organização. Esperamos que as empresas comecem a fornecer bases de conhecimento para as ferramentas de modelagem de ameaças mais comuns para aliviar alguns dos encargos de seus clientes no futuro. Essas bases de conhecimento devem ser flexíveis para apoiar e facilitar sua adoção até mesmo pelas organizações mais maduras, que precisam adaptar as referidas bases de conhecimento às suas práticas, políticas e regulamentações.
O que você pode fazer hoje?
Considere a possibilidade de dedicar parte do esforço da equipe de segurança centralizada para desenvolver bases de conhecimento que possam ser usadas pelas várias equipes de desenvolvimento para acelerar a modelagem de ameaças.
Consumir bases de conhecimento
Outro problema com as bases de conhecimento é que, por vezes, são demasiado complexas para serem consumidas. Muitos deles tentam ser abrangentes, incluindo questões essenciais e menos críticas. Infelizmente, nem todos eles são exigidos por todos os sistemas. Você gostaria de adotar uma abordagem mais simples quando o sistema que você está analisando é pequeno e não lida com dados confidenciais. Pelo contrário, você gostaria de ir mais a fundo se o sistema é complexo e processa PII e dados de alto valor comercial. Portanto, deve ser possível aplicar diferentes versões do conhecimento dependendo do contexto ou marcar alguns padrões de ataque e mitigações associadas como "TOP". Como resultado, os modeladores de ameaças seriam capazes de decidir se querem uma experiência abrangente ou se querem ir com facilidade e minimizar o trabalho necessário.
Falando em eficiência, é imperativo garantir que as atividades sejam simplificadas e automatizadas tanto quanto possível para reduzir a quantidade de trabalho necessário. Achamos que um ponto ideal para executar um Modelo de Ameaça de uma solução de tamanho médio deve ser 1 dia de trabalho para o modelador de ameaças. Tais resultados só são possíveis se a ferramenta escolhida fornecer aceleradores que permitam reduzir o tempo necessário. Por exemplo, se a ferramenta aplicar 20 tipos diferentes de mitigações em 100 locais diferentes, e você for solicitado a especificar para cada um deles seu status, você seria 5 vezes mais eficiente concentrando-se na primeira em vez da segunda. A ferramenta escolhida deve fornecer essa capacidade, ao mesmo tempo em que concede a possibilidade de fazer um trabalho mais minucioso quando necessário.
O que você pode fazer hoje?
Se as bases de conhecimento que você usa hoje não suportam o conceito de ameaças e mitigações "TOP", considere a possibilidade de remover o que raramente é necessário ou útil, para permitir o foco apenas no que realmente importa.
Às vezes, o problema é que as bases de conhecimento adotadas tentam ser genéricas e cobrir vários cenários. Você pode melhorar a situação especializando-os.
Fazer as perguntas certas
Durante a nossa análise, considerámos a possibilidade de utilizar uma ferramenta de apoio a um quadro de Perguntas para conduzir as primeiras fases da análise. Percebemos que a maioria dos modeladores de ameaças inexperientes não consegue fazer as perguntas certas para obter as informações necessárias para sua análise. Alguns de nossos especialistas demonstraram que é possível determinar algumas questões cruciais com base em um diagrama de sistema no escopo. Essas perguntas podem até ser aplicadas automaticamente, com algumas regras de geração. O problema é que esta abordagem pode não fornecer o valor que parece prometer. Isso porque você precisa entender a lógica por trás de cada pergunta. Caso contrário, você não seria capaz de avaliar a resposta e determinar se ela é satisfatória. Ainda assim, a geração automatizada de perguntas pode fornecer um valor significativo para os modeladores de ameaças menos especializados, melhorando sua compreensão dos sistemas em escopo.
O que você pode fazer hoje?
Adote uma abordagem estruturada para fazer perguntas. Por exemplo, nossa equipe teve bons resultados ao adotar o Microsoft STRIDE como referência. Você pode fazer isso perguntando para cada componente das perguntas de solução como:
Falsificação: como o componente se autentica em relação aos serviços e recursos que usa?
Adulteração: o componente valida as mensagens que recebe? A validação é frouxa ou rigorosa?
Repúdio: o componente está registrando as interações em um log de auditoria?
Divulgação de informações: o tráfego de entrada e saída do componente é criptografado? Que protocolos e algoritmos são permitidos?
Negação de serviço: o componente está configurado em alta disponibilidade? Está protegido contra ataques DDoS?
Elevação de privilégio: os usuários recebem os privilégios menos necessários? A solução mistura código direcionado a usuários normais com o de usuários altamente privilegiados?
Técnicas como esta podem ser ensinadas e podem ser melhoradas com a experiência. Portanto, é importante implementar uma abordagem de Aprendizagem Contínua projetada para coletar aprendizados e divulgá-los dentro da organização.
O impacto no ROI
Resumindo, é possível identificar muitas ideias para melhorar a eficiência da experiência de modelagem de ameaças, sua qualidade e, finalmente, aumentar o ROI. No entanto, este esforço deve ser considerado um processo contínuo, que deve ser direcionado para a melhoria contínua da prática.
Conclusões
A modelagem de ameaças é uma excelente metodologia para melhorar a segurança da sua organização. Se feito corretamente, pode fornecer valor por um custo muito razoável. Já identificamos várias técnicas que podem ser essenciais para melhorar o valor da modelagem de ameaças para proteger soluções modernas, incluindo:
Alinhe o modelo de ameaça com sua prática de DevOps
Centrar a atenção nas atenuações
Atenuações de links com histórias de usuários
Destacar discrepâncias entre o modelo de ameaça e a lista de pendências
Use o modelo de ameaças para impulsionar um monitoramento e auditoria de segurança mais abrangentes
Simplifique a criação de modelos de ameaças e aumente a consistência dos resultados
Confie nos campeões de segurança
Adotar bases de conhecimento para automatizar a identificação de ameaças e mitigações
Criação de melhores bases de conhecimento
Fornecer uma estrutura de perguntas suportada pela automação
Espero que alguns deles já possam ser encontrados em sua ferramenta de modelagem de ameaças de escolha. Outros serão incluídos no futuro. Sabemos que maximizar o ROI para modelagem de ameaças é um esforço de longo prazo que requer respostas que ainda não temos. Sabemos também que algumas questões ainda são desconhecidas. Este artigo deve fornecer algum alimento para reflexão e, esperançosamente, pode ajudá-lo a melhorar a forma como você faz modelagem de ameaças. Esperamos que possa ser um farol para si e para nós, e que seja útil orientar os nossos esforços para os próximos anos.