Integração da modelagem de riscos ao DevOps
Esta publicação é de autoria de Simone Curzi, Anthony Nevico, Jonathan Davis, Rafael Pazos Rodriguez e Ben Hanson
Introdução
A modelagem de riscos é 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 reflexões sobre como é possível adotar a modelagem de riscos de forma mais eficaz e eficiente, integrando-a com metodologias e ferramentas modernas de DevOps e focando no valor fornecido a todos os diversos atores envolvidos com o Ciclo de Vida de Desenvolvimento de Software.
Este artigo é para você?
Este artigo é o resultado do trabalho de uma pequena equipe de especialistas em Segurança e modelagem de riscos da Microsoft e incorpora contribuições e ideias de alguns dos especialistas mais proeminentes de fora da Microsoft. Ele tenta resolver uma questão simples, mas urgente: o que devemos fazer para garantir que o processo de modelagem de riscos que usamos seja atualizado aos requisitos modernos impostos pelas metodologias Agile e DevOps, para que forneçamos o valor necessário ao menor custo?
Se você é um proprietário de produto, membro de uma equipe de Segurança ou simplesmente um desenvolvedor que está considerando adotar a modelagem de riscos como parte do ciclo de vida de desenvolvimento, este artigo é para você.
Analogamente, se você já adotou a modelagem de riscos, ainda pode encontrar ideias práticas para melhorar seu processo.
No entanto, o artigo foi projetado para apresentar ideias para melhorar os processos atuais ou para adotar com sucesso a modelagem de riscos como parte do seu processo de DevOps. Ele não introduz ferramentas ou produtos específicos, mesmo que seja nossa esperança 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 riscos é importante?
A modelagem de riscos é uma das principais abordagens para projetar soluções de software com segurança. Por meio da modelagem de riscos, você analisa um sistema, identifica vetores de ataque e desenvolve ações para mitigar os riscos trazidos por esses ataques. Feita de forma adequada, a modelagem de riscos é um excelente componente de qualquer processo de Gerenciamento de Riscos. Ela também pode ajudar a reduzir custos, identificando e consertando problemas de design antecipadamente. Um estudo antigo do NIST estimou que o custo de consertar um problema de design no código de produção era cerca de 40 vezes maior do que repará-lo durante a fase de design. Também evita incorrer em custos devido a incidentes de segurança por possíveis problemas de design. Considere que o Relatório de Custo de Violação de Dados de 2022 da IBM Security e do Ponemon Institute estima que o custo médio de uma violação de dados seja de 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$ 387 milhões!
A modelagem de riscos é 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 riscos. Em 1999, dois (então) funcionários da Microsoft, Loren Kohnfelder e Praerit Garg, escreveram um documento, Os riscos aos nossos produtos. Esse artigo apresentou a abordagem STRIDE, sinônimo do processo de modelagem de riscos da Microsoft.
A modelagem de riscos é um processo evolutivo
A modelagem de riscos não é um processo estático; ela evolui à medida que as necessidades e as tecnologias mudam.
Ataques à cadeia de fornecedores como o recente direcionado à SolarWinds demonstram a necessidade de cobrir mais cenários com a modelagem de ameaças 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 com base 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 aprendizado de máquina introduz novos vetores de ataque que devem ser compreendidos e controlados. Considere, por exemplo, a possibilidade de reproduzir sons inaudíveis por ouvidos humanos criados maliciosamente 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 riscos com base em seus requisitos de segurança específicos. Cada variante visa assegurar um nível adequado de garantia de segurança aos cenários em que é aplicada, mas o que "adequado" significa 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 aspecto fundamental da modelagem de riscos é equilibrar seu custo com a tolerância ao risco de um aplicativo. Embora isso possa levar à decisão de evitar completamente a modelagem de riscos para alguns cenários, ela é tão efetiva quando feita corretamente que só podemos recomendar sua adoção para qualquer iniciativa de TI, incluindo projetos de desenvolvimento de software e implantação de infraestrutura.
A importância do foco no ROI
Nos últimos anos, houve um aumento constante no interesse na modelagem de riscos como um processo chave de desenvolvimento de software. Esse interesse se deve ao aumento exponencial de ataques a infraestruturas e soluções. Iniciativas como o Recommended Minimum Standard for Vendor or Developer Verification of Code (Padrão mínimo recomendado para verificação de código pelo fornecedor ou desenvolvedor) do NIST e o Manifesto de modelagem de ameaças aumentaram ainda mais a demanda a ponto de as abordagens atuais mostrarem alguns limites. Por exemplo, os resultados da modelagem de riscos são altamente dependentes do processo adotado e de quem executa o modelo de risco. Assim, há uma preocupação em obter consistentemente maior qualidade da experiência.
Mas, o que significa qualidade para a modelagem de riscos? Para nós, um modelo de risco de qualidade deve ter as seguintes características:
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 devem ser fornecidas para permitir o 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 a lista de pendências.
Para cada Mitigação, deve identificar seu status. Algumas mitigações são novas, enquanto outras já existem. O modelo de risco deve reconhecer o que já está lá e focar no risco atual para identificar como melhorar a situação.
Ele deve identificar claramente por que cada Mitigação é necessária, vinculando-a às respectivas 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 para o risco de ter dados em trânsito divulgados e, ao mesmo tempo, pode ser uma mitigação quase completa para o 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 sua probabilidade quanto o impacto. A gravidade deve ser razoável e, idealmente, imparcial.
Deverá ser possível obter uma visão global 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 ocultar as complexidades desnecessárias.
Essa lista já mostra um conceito importante: a modelagem de riscos pode fornecer valor a 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 como verificar se o que implementaram se comporta conforme o esperado. Por outro lado, a equipe de Segurança normalmente se preocupa com a segurança geral do ecossistema de infraestrutura e aplicativos de propriedade da organização; portanto, precisa receber informações que permitam decidir se o sistema no escopo é seguro o suficiente e satisfaz seus requisitos de conformidade. Por fim, os proprietários de produtos 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.
Essas necessidades diferentes exigem fornecer visões diferentes sobre o modelo de risco, cada uma delas com foco em um cenário de uso específico.
Um problema típico na modelagem de riscos é que, quanto mais ela é bem-sucedida, mais é difícil para os poucos especialistas disponíveis cobrir a demanda enquanto ainda fornece a alta qualidade esperada dessa experiência. Como resultado, em alguns casos, a qualidade pode ser afetada negativamente. Tudo vai bem até que a modelagem de riscos pare de fornecer um valor significativo em comparação com o investimento. Não são poucas as organizações impactadas por esse problema. Já houve alguns relatos de tomadores de decisão de negócios começando a questionar a modelagem de riscos porque ela não entregaria valor significativo para o custo.
Por valor, nos referimos ao valor do 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 para os Desenvolvedores e os Testadores. Por fim, o valor está relacionado à comunicação do risco residual a todas as partes envolvidas. Podemos, por exemplo, medir o valor medindo o impacto do processo de modelagem de riscos. Suponha que medimos o risco geral da solução atribuindo um número à Gravidade identificada para cada ameaça. Nesse caso, esperamos que o risco geral diminua ao longo do tempo por efeito do modelo de risco. Se o risco geral permanecer constante ou aumentar, podemos ter um problema. Quanto mais acentuada a diminuição, maior o impacto do modelo de risco. É claro que o modelo de risco não controlaria as mitigações implementadas. É responsabilidade do proprietário do produto decidir o que deve ser implementado. Mas a vantagem de vincular a eficácia do modelo de risco à implementação real das mitigações é que aumenta o impacto na segurança real da solução, reduzindo o risco de que o modelo de risco continue sendo um exercício teórico.
Em vez disso, o custo está relacionado às atividades necessárias para executar o modelo de risco em si, que é o tempo necessário por todas as partes envolvidas para produzir o modelo de risco e discuti-lo.
Isso levanta a questão: podemos definir um processo de modelagem de riscos focado em maximizar o valor do negócio e minimizar o custo?
A importância do DevOps
Já destacamos como é importante garantir que a modelagem de riscos 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. Acima de tudo, o foco na modelagem de riscos para DevOps significa que precisamos garantir que a experiência esteja profundamente integrada aos processos de DevOps existentes.
A modelagem de ameaças não deve se tornar mais um fardo, mas sim 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 de rastreamento de tarefas e bugs de sua 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 focar o processo de modelagem de riscos no que precisa ser feito. As ameaças, que são os padrões de ataque e como elas podem acontecer, são necessárias para explicar por que a equipe precisa implementar um controle de segurança. Elas também são um fator para determinar quando as mitigações devem ser implementadas. Ainda assim, a meta real é 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 na lista de pendências para torná-las parte do processo padrão. O ideal é que a ferramenta de modelagem de ameaças e a ferramenta de acompanhamento de tarefas e bugs sejam sincronizadas para refletir as atualizações do status de atenuação no modelo de ameaças. 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 Planejamento da Sprint.
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 no Acompanhamento de Tarefas e Bugs de sua escolha. Uma maneira pode ser adotar uma das muitas ferramentas de modelagem de riscos capazes de automatizar esse processo.
Como Desenvolvedor, você deve se concentrar nos controles de segurança identificados conforme necessário. 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 risco em relação à integração de DevOps. Portanto, é importante definir claramente o tipo de objetos criados a partir dessas mitigações na ferramenta de Acompanhamento de Tarefas e Bugs de sua escolha. Algumas mitigações podem durar mais do que um Sprint. Portanto, talvez seja melhor criá-las como Recursos. Mas muitas são mais fáceis e poderiam ser implementadas em uma única Sprint; assim, seria possível representá-las como histórias de usuários ou tarefas. Embora possa ser possível gerar diferentes tipos de item 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 filhas de histórias de usuários, você pode considerar declará-las como Tarefas, o que implica relaxar o requisito 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 risco sejam declaradas na lista de pendências. Identifique uma maneira de declará-las claramente.
Histórias de usuários
As mitigações não são os únicos artefatos que fazem parte de um modelo de ameaças, que pode e deve estar alinhado com o que você tem na ferramenta Acompanhamento de Tarefas e Bugs. Por exemplo, você também pode querer declarar ameaças. Essa meta poderia ser alcançada estendendo as histórias de usuários pela adição de uma cláusula WITHOUT (SEM) à habitual "Como [quem sou eu] quero [o que quero] para que eu possa [fazer algo]". Por exemplo: "Como usuário, quero pagar com meu cartão de crédito para poder comprar alguns bens, SEM ter meus dados roubados do cartão de crédito". A cláusula WITHOUT pode ser mapeada para uma ou mais ameaças e, às vezes, pode ser permitida para expressar Requisitos de Segurança. Ao garantir que esse alinhamento entre ameaças e cláusulas WITHOUT seja explicitado dentro do modelo de risco, podemos garantir que possíveis riscos sejam refletidos e atendidos pela equipe porque eles são incluídos como parte das histórias de usuários. Você também pode usar esse relacionamento para mapear cada Requisito de Segurança identificado como parte das histórias de usuário para pelo menos uma ameaça.
É bom saber
A cláusula WITHOUT não é uma ideia original da equipe que produziu esta página. Não temos certeza sobre quem a introduziu pela primeira vez, mas somos gratos a quem criou essa ideia.
Figura 1: Requisitos de alinhamento
Por exemplo, a imagem anterior mostra as seguintes situações:
A ameaça A está vinculada à História de Usuário 1 por meio da cláusula WITHOUT 1.
A ameaça B está vinculada à História de Usuário 2 por meio da cláusula WITHOUT 2.
A ameaça B também está ligada à História de Usuário 3. Mas a História de Usuário 3 não é atribuída a nenhuma cláusula WITHOUT. Por quê? Representa uma anomalia potencial que você deve investigar.
A ameaça B também está ligada à História de Usuário 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 à História de Usuário 4, que está associada à WITHOUT 3 e 4. Ainda não está claro se devemos permitir ter mais de uma cláusula WITHOUT.
A ameaça D não está vinculada a nenhuma história de usuário. Estamos ignorando uma história de usuário ou uma cláusula WITHOUT?
A História de Usuário 5 está vinculada a uma cláusula WITHOUT, mas não tem nenhuma ameaça associada. Estamos ignorando uma ameaça ou simplesmente uma ligação entre uma história de usuário e uma ameaça?
Raramente identificamos os Requisitos de Segurança como parte do modelo de risco. Portanto, a cláusula WITHOUT introduz a oportunidade de integrar ainda mais a experiência, estendendo os modelos de risco com 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 riscos, 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ças poderia vincular os Requisitos de Segurança com artefatos dentro do próprio modelo de ameaças, como ameaças e mitigações, e aqueles na ferramenta de Acompanhamento de Tarefas e Bugs. Por exemplo, o requisito de implementar monitoramento para identificar ataques em andamento deve ser mapeado para todas aquelas mitigações relacionadas ao monitoramento e, em seguida, para os artefatos correspondentes na ferramenta de Rastreamento de Tarefas e Bugs. 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 vínculos entre os artefatos da ferramenta Acompanhamento de Tarefas e Bugs e as ameaças e atenuações identificadas pelo modelo de ameaças para facilitar a priorização das atividades de segurança. A segurança geralmente é implementada por último, às vezes para resolver vulnerabilidades reativas identificadas por alguma ferramenta ou um Teste de Penetração. Pelo contrário, seria mais efetivo implementar as mitigações junto 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ê deveria implementá-los junto com as funções de pagamento relacionadas? O modelo de risco 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 de Sprint para ter uma discussão significativa e impulsionar uma priorização informada. O mecanismo é simples. Vamos supor que o Proprietário do Produto 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á vinculada à ameaça. O modelo de risco 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 História de Usuário 1 está vinculada à ameaça 1, que por sua vez está vinculada às mitigações A e B. Portanto, também devemos considerar a implementação de uma ou ambas as mitigaçõ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 risco 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 WITHOUT.
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ças com aqueles na ferramenta de Acompanhamento de Tarefas e Bugs, torna-se mais fácil identificar oportunidades para melhorar a qualidade de ambos. A chave é aproveitar os 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 relacionamentos entre os vários objetos nos vários mundos. Portanto, o Modelo de Risco se tornaria a fonte de verdade para a segurança da solução. Ao mesmo tempo, a lista de pendências está continuamente alinhada ao status da solução.
O que você pode fazer hoje?
Verifique regularmente se não há ameaças desmapeadas ou histórias de usuários com cláusulas WITHOUT.
Modelagem de riscos e as 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 riscos como uma ferramenta para facilitar a Análise de Causa Raiz, pois ela fornece uma visão abrangente do sistema de uma perspectiva de segurança e, portanto, pode fornecer um melhor reconhecimento das implicações de alguns ataques. Para isso, seria necessário integrar o modelo de risco com os feeds existentes a partir das ferramentas de monitoramento escolhidas. Essa abordagem pode representar um complemento para o SIEM escolhido.
Outra ideia para integrar a modelagem de riscos com as Operações é usar a primeira para conduzir o design de como a segunda poderia acontecer. Um exemplo disso é o design de eventos para a solução. A modelagem de riscos 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 falham, mas uma delas acaba tendo sucesso. Ao gerar eventos para cada falha e disparar alertas quando algum limite é alcançado, é possível detectar ataques e tomar ações para corrigi-los. Essas situações raramente são detectadas 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, é imprescindível reagir rapidamente para reduzir os danos diretos e a probabilidade e entidade de eventuais multas.
Portanto, precisamos planejar com antecedência o que precisa ser monitorado, em que condições podemos ter um problema e o que fazer quando isso acontecer. A melhor maneira de identificar esses eventos é confiar em um modelo de risco. 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 risco para identificar eventos que você pode gerar para cada ameaça. Esses eventos podem ser fornecidos pela infraestrutura, ou algo que o aplicativo deve gerar. 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 riscos. Do nosso ponto de vista, elas são cruciais para aumentar o valor da modelagem de riscos 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 devem investir tanto de seu tempo consertando a segurança. Como resultado, a segurança se torna um problema em vez de ser uma oportunidade. A modelagem de riscos tem o potencial de superar esses problemas porque fornece as razões para implementar a segurança. Além disso, ela pode ser iniciada no começo do processo de desenvolvimento e evitar erros de design que podem custar caro se não forem detectados rapidamente. As técnicas acima visam integrar melhor a modelagem de riscos com o DevOps. Isso garante que os tomadores de decisão de negócios e desenvolvedores percebam a modelagem de riscos como um complemento natural para o processo de desenvolvimento e operações. Portanto, o valor recebido pela adoção da modelagem de riscos aumenta e seus custos diminuem devido à integração com as diversas ferramentas já em uso.
Simplificação do trabalho para modeladores de riscos
Outro aspecto importante necessário para melhorar o ROI da modelagem de riscos 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 de resolver a escassez de pessoas competentes. Algumas delas são baseadas no envolvimento ativo de toda a equipe de DevOps no exercício de modelagem de riscos. A ideia é identificar um líder da iniciativa, ou seja, alguém com conhecimento intermediário sobre o processo, mas não necessariamente um especialista, e fazer com que lidere a discussão entre os demais membros da equipe. Essa abordagem é ativamente endossada pelos signatários do Manifesto de Modelagem de Riscos.
Concordamos que esta abordagem permite obter um bom valor e representa uma melhoria em relação à situação atual. Ela também fornece bons insights e permite que a equipe aumente sua cultura de segurança. No entanto, não é isenta de desvantagens, pois abrange apenas algumas questões, deixando muita coisa de fora. Isso cria um problema de consistência, porque seria muito fácil se concentrar demais nisso e perder um tempo precioso em questões secundárias, ignorando as importantes. A experiência do líder teria um papel significativo em evitar que essas situações acontecessem. Além disso, essa abordagem requer muito tempo de todos os membros da equipe para discutir cada questão.
Por esse motivo, até mesmo gastar algumas horas por Sprint para esse 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 riscos não seriam uma exceção. Ainda assim, essa abordagem é excelente para produtos pequenos, onde a equipe é 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, sua duração e o número de participantes. Portanto, a responsabilidade do modelador de riscos seria mais significativa: não apenas conduzir as entrevistas, mas também criar e manter o próprio modelo de risco. Esta abordagem requer competências e conhecimentos mais significativos. Os modeladores de riscos podem ser representados por especialistas de segurança ou por membros da equipe de segurança interna. A maioria das organizações optaria pela primeira porque a equipe de segurança normalmente está totalmente reservada.
Especialistas de segurança são membros das equipes de DevOps com um interesse particular em segurança. Eles não são especialistas de fato, mas têm um conhecimento básico e a vontade de melhorar a postura de segurança da equipe. A ideia é criar uma conexão privilegiada entre os especialistas 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 riscos, os especialistas de segurança atuariam como modeladores de riscos 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 de especialistas de segurança e aproveitá-lo para fortalecer ainda mais seu ciclo de vida de desenvolvimento de software seguro.
A função das bases de conhecimento
Um problema significativo com a modelagem de riscos é garantir que a qualidade da experiência e o valor para a equipe de DevOps sejam altos, independentemente de quem executa o modelo de risco. Com os especialistas de segurança, esse problema se torna ainda mais urgente. Uma ideia para resolver isso é fornecer bases de conhecimento para impulsionar a criação do modelo de risco. 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 dessas 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, pois 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 riscos podem não ter a experiência necessária para determinar se uma ameaça deve ser aplicada ou se alguma mitigação é efetiva.
As bases de conhecimento não são uma ideia nova: muitas ferramentas atuais de modelagem de riscos já são compatíveis de alguma forma. Mas muitas implementações atuais têm desvantagens significativas. Por exemplo, você deve ser capaz de manter bases de conhecimento facilmente. Sua manutenção é um problema que ainda não foi resolvido. Por exemplo, não é fácil identificar as melhores fontes de informação para criá-las. Além disso, a manutenção é tipicamente manual. A criação e manutenção das bases de conhecimento devem ser de responsabilidade da equipe interna de segurança da organização. Esperamos que as empresas comecem a fornecer bases de conhecimento para as ferramentas de modelagem de riscos 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 essas bases de conhecimento às suas práticas, políticas e regulamentos.
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 riscos.
Consumo de bases de conhecimento
Outro problema com as bases de conhecimento é que, às vezes, elas são muito complexas para serem consumidas. Muitas delas tentam ser abrangentes, incluindo questões essenciais e menos críticas. Infelizmente, nem todas são exigidas por todos os sistemas. É melhor 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 for complexo e processar 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 riscos seriam capazes de decidir se querem uma experiência abrangente ou se vão com calma e minimizam o trabalho necessário.
Falando em eficiência, é imprescindível garantir que as atividades sejam simplificadas e automatizadas o máximo possível para reduzir a quantidade de trabalho necessário. Achamos que um ponto ideal para executar um modelo de risco de uma solução de tamanho médio deve ser um 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 for solicitado que você especifique para cada um deles seu status, você terá 5 vezes mais eficiência concentrando-se no primeiro em vez do segundo. A ferramenta escolhida deve fornecer essa capacidade, ao mesmo tempo em que concede a possibilidade de fazer um trabalho mais completo quando necessário.
O que você pode fazer hoje?
Se as bases de conhecimento que você usa hoje não são compatíveis com o conceito de ameaças e mitigações "TOP", considere a possibilidade de remover o que raramente é necessário ou útil, para permitir que 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-as.
Fazer as perguntas certas
Durante nossa análise, consideramos a possibilidade de usar uma ferramenta de apoio a uma estrutura de Perguntas para conduzir as primeiras fases da análise. Percebemos que a maioria dos modeladores de riscos 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 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 essa 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 riscos menos especializados, melhorando sua compreensão dos sistemas no escopo.
O que você pode fazer hoje?
Adote uma abordagem estruturada para fazer perguntas. Por exemplo, nossa equipe tem tido bons resultados ao adotar o Microsoft STRIDE como referência. Você pode fazer isso perguntando para cada componente da solução perguntas 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 confidenciais: o tráfego de entrada e saída do componente é criptografado? Quais protocolos e algoritmos são permitidos?
Negação de serviço: o componente está configurado em alta disponibilidade? Ele está protegido contra DDoS?
Elevação de privilégio: os usuários recebem os privilégios mínimos necessários? A solução combina código direcionado a usuários normais com aquele para usuários com privilégios altos?
Técnicas como essa podem ser ensinadas e melhoradas com a experiência. Portanto, é importante implementar uma abordagem de Aprendizado Contínuo 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 riscos, sua qualidade e, finalmente, aumentar o ROI. No entanto, esse 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 riscos é uma excelente metodologia para melhorar a segurança da sua organização. Se feita 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 riscos para proteger soluções modernas, incluindo:
Alinhar o modelo de risco com a prática de DevOps
Foco nas mitigações
Vincular mitigações a histórias de usuários
Destacar discrepâncias entre o modelo de risco e a lista de pendências
Usar o modelo de risco para gerar um monitoramento e auditoria mais abrangentes para segurança
Simplificar a criação de modelos de risco e aumentar a consistência dos resultados
Confiar nos especialistas de segurança
Adotar bases de conhecimento para automatizar a identificação de ameaças e mitigações
Criar bases de conhecimento melhores
Fornecer uma estrutura de perguntas com suporte da automação
Esperamos que algumas deles já possam ser encontradas na ferramenta de modelagem de riscos de sua escolha. Outras serão incluídos no futuro. Sabemos que maximizar o ROI para modelagem de riscos é um esforço de longo prazo que requer respostas que ainda não temos. Sabemos também que algumas perguntas ainda são desconhecidas. Este documento deve fornecer bases para a reflexão e pode ajudar você a melhorar a forma como faz a modelagem de riscos. Esperamos que possa ser um farol para você e para nós e que seja útil para direcionar nossos esforços para os próximos anos.