Como a modelagem de ameaças se encaixa no ritmo acelerado do DevSecOps?
Escrito por
0 minutos de leitura
DevSecOps tem como objetivo acelerar a entrega de software de qualidade. Mas o processo de modelagem de ameaças tem fama de ser complexo e demorado, e muitas organizações acreditam que ele desacelera o ciclo de vida do desenvolvimento de software (SDLC). Como combinar os dois para obter os benefícios de segurança da modelagem de ameaças sem criar barreiras ao processo de desenvolvimento de software?
Nesta publicação, vamos analisar a modelagem de ameaças e como ela se encaixa naturalmente no processo de DevSecOps.
O que é modelagem de ameaças?
A modelagem de ameaças examina o design das operações de um sistema e o fluxo de dados entre os limites dos subsistemas. Em seguida, identifica todos os pontos de ataque que hackers poderiam explorar e como isso poderia ser feito. Por fim, projeta soluções para manter o sistema e seus dados protegidos.
Segundo o renomado especialista Adam Shostack, o processo de modelagem de ameaças busca responder às seguintes perguntas:
O que estamos construindo? Avalie por onde os dados passam no sistema, os limites que atravessam e a tecnologia usada em cada transferência.
O que pode dar errado? Questione todas as formas possíveis de explorar as transferências.
O que vamos fazer a respeito? Projete defesas contra cada exploração.
Fizemos um bom trabalho? A última pergunta, e a mais importante, nos convida a refletir sobre o processo, analisá-lo e lembrar que o trabalho nunca termina de verdade: sempre há espaço para melhorar.
Em seguida, a equipe prioriza os riscos de ameaças e os incorpora ao desenvolvimento.
Quando fazer a modelagem de ameaças?
O ideal é fazer a modelagem de ameaças nas primeiras etapas do SDLC, durante a fase de arquitetura do desenvolvimento de aplicações. Quanto mais cedo as ameaças forem identificadas, mais eficientemente será possível criar soluções para neutralizar os vetores de ataque.
O melhor é incorporar a segurança à aplicação desde o início, mas nunca é tarde para aproveitar os benefícios da modelagem de ameaças, mesmo em aplicações legadas. Esse exercício pode ser valioso para todas as pessoas envolvidas, independentemente de quando ocorrer no SDLC.
Comece a participar de desafios de Capture the Flag
Aprenda a resolver desafios de Capture the Flag assistindo sob demanda ao nosso workshop virtual introdutório.
A história da modelagem de ameaças
As primeiras tentativas de modelagem de ameaças surgiram na década de 1990 com a ideia de árvores de ataque. Isso levou Loren Kohnfelder e Prerit Garg, da Microsoft, a compartilhar um documento chamado “The Threats to Our Products”, amplamente considerado a primeira descrição formal de um processo de modelagem de ameaças.
Desde então, o setor se uniu em torno de organizações como o Open Web Application Security Project (OWASP), que classifica as principais ameaças, explica o que são e recomenda como lidar com elas. A OWASP também publicou uma avaliação de ameaças semelhante para a segurança de APIs digitais, voltada às APIs de software como serviço (SaaS).
Hoje, com milhões de registros de usuários roubados por hackers de empresas como Yahoo, Uber e First American Financial, todas as organizações precisam estar cientes das ameaças digitais. Os relatórios de segurança de 2020 revelam um cenário preocupante:
Mais de 18 mil vulnerabilidades foram registradas em 2020, e quase um quarto delas era de alta gravidade.
As empresas pagaram, em média, US$ 3,86 milhões para corrigir uma violação de dados.
Os ataques de malware e ransomware aumentaram 358% e 435%, respectivamente.
Dicas para modelagem de ameaças
O processo de modelagem de ameaças pode ficar bastante complexo. Uma abordagem consagrada, a metodologia STRIDE, recomenda uma análise técnica separada para cada tipo importante de ataque:
Falsificação de identidade: comprometer a autenticação por meio de algum tipo de personificação.
Adulteração: comprometer o sistema de uma forma que permita outras explorações.
Repúdio: comprometer a detecção ocultando evidências de ataques ou falsificando registros para que pareçam normais durante os ataques, mascarando a intenção e permitindo que o ataque continue.
Divulgação de informações: comprometer a confidencialidade encontrando formas de extrair dados confidenciais de qualquer parte do sistema.
Negação de serviço (DoS): impedir o acesso dos usuários aos sistemas esgotando deliberadamente os recursos necessários para a execução adequada do sistema.
Elevação de privilégios: comprometer a autorização induzindo o sistema a conceder mais privilégios a uma conta, permitindo um acesso mais profundo ao sistema.
Diagramas de fluxo de dados (DFDs), STRIDE e metodologias mais recentes desse tipo oferecem uma estrutura para responder a perguntas como:
“O que estamos construindo?” Os DFDs são uma maneira de representar o sistema e seus diversos limites de confiança, como primeiro passo para entender as ameaças à segurança.
“O que pode dar errado?” A STRIDE se concentra nessa pergunta, examinando cada tipo de ataque conforme a forma como o sistema foi construído.
Por exemplo, em 2019, um ataque de negação de serviço ao Kubernetes API Server explorou uma brecha que permitia enviar grandes quantidades de dados no “payload” da API, sobrecarregando o sistema.
Entre as formas de mitigar a ameaça estavam:
Limites de tamanho do payload para cada chamada
Limites de chamadas à API para um usuário ou endereço IP específico
Essas medidas impediram futuros ataques DoS ao API Server.
Esses esforços exigem análises aprofundadas do funcionamento do sistema e precisam ser realizados para cada tipo de ataque. É possível encontrar soluções, mas pesquisar, projetar, desenvolver, testar e implementar cada uma delas leva tempo.
Por que a modelagem tradicional de ameaças é um desafio para o DevSecOps
A modelagem tradicional de ameaças exige reuniões de análise com todas as partes interessadas, incluindo profissionais de TI e especialistas em cibersegurança. Essas reuniões promovem a troca de muito conhecimento e informações sobre ameaças e estratégias de mitigação, algo que todos os envolvidos consideram valioso.
No entanto, as reuniões em si consomem muito tempo e podem ocupar muitas pessoas por dias. Por isso, não é possível convocá-las antes de cada sprint. Essas reuniões vão contra a cultura do DevSecOps, que busca acelerar o ciclo de vida do desenvolvimento de software.
Tendências populares de DevOps que aceleram o desenvolvimento:
Leve a automação e os testes o mais para o início possível do pipeline de build (“shift left”).
A automação não se aplica apenas ao código da aplicação, mas também à infraestrutura do sistema. Novas tecnologias permitem definir a infraestrutura como código e, assim, testá-la.
Essa automação acelera a integração contínua e a entrega contínua (CI/CD), permitindo implantar funcionalidades e correções de bugs com mais frequência e confiança.
O resultado: o desenvolvimento de software fica cada vez mais rápido, e algumas equipes implantam código novo em produção a cada duas ou quatro semanas. Com uma cadência dessas, como encontrar tempo para longas reuniões de segurança?
Capacitação da equipe em modelagem de ameaças para orientar o processo de DevOps
A capacitação é fundamental para incorporar a mentalidade de modelagem de ameaças ao SDLC seguro, como destaca Brandon Jeanmarie, especialista em segurança da IBM. Mas não é possível realizar reuniões longas e numerosas com frequência. Por isso, ele recomenda uma abordagem de capacitação “just in time” para os membros da equipe de desenvolvimento durante o trabalho com clientes:
Modelagem de ameaças não é difícil de entender: aproveite as oportunidades para explicar o tema a desenvolvedores e gerentes, mostrando o que é possível fazer e começando “agora”, com o estágio atual do desenvolvimento do sistema.
Todas as partes interessadas no sistema se beneficiam do aprendizado: apresente a modelagem de ameaças de uma forma relevante para o papel de cada membro da equipe. Depois de entender o tema, essas pessoas podem contribuir para a solução durante o planejamento das histórias da sprint e ajudar a definir prioridades.
A capacitação também pode ser “shift left”: leve a conscientização sobre modelagem de ameaças o mais para o início possível do pipeline. Isso cria boas práticas de DevSecOps e permite introduzir a identificação e a mitigação de ameaças o quanto antes.
As ferramentas de modelagem de ameaças podem “estender para a direita”: ferramentas de terceiros podem oferecer detecção automática de ameaças e automação da mitigação em etapas posteriores do SDLC, inclusive em produção, onde continuam protegendo o sistema.
Jeanmarie conclui que a capacitação contextualizada e baseada em funções promove uma mentalidade de “segurança desde o design” que fortalece a cultura DevSecOps da organização. E isso pode ser feito sem reuniões frequentes e extensas. Quando esse conhecimento passa a fazer parte da cultura, todas as pessoas podem ajudar a mitigar ameaças quando chegar a sua vez.
Comece a participar de desafios de Capture the Flag
Aprenda a resolver desafios de Capture the Flag assistindo sob demanda ao nosso workshop virtual introdutório.
4 etapas para incorporar a modelagem de ameaças ao design de histórias ágeis
A especialista em segurança Alyssa Miller leva a modelagem de ameaças ainda mais para a “esquerda”. Ela analisou como a modelagem de ameaças poderia se encaixar melhor no DevSecOps. Sua sugestão:
Limite o escopo da modelagem de ameaças aos requisitos de cada história de usuário. No DevSecOps, é difícil ir mais para a “esquerda” do que isso.
O processo envolve incluir a pessoa usuária do negócio na conversa sobre a análise da história. Isso funciona porque os requisitos da história vêm antes dos detalhes técnicos. Faça estas perguntas à pessoa usuária do negócio:
Quais são os ativos críticos envolvidos na nova funcionalidade?
Qual é a pior coisa que poderia acontecer com cada ativo crítico?
Essa conversa naturalmente revela requisitos de segurança que podem ser registrados na história em linguagem simples, que todos entendem, como:
As funções críticas F1 e F2 devem ser protegidas contra uso não autorizado.
Os dados privados XYZ devem ser protegidos contra exposição.
A transação monetária da compra P deve ser protegida contra roubo durante a transmissão.
Essas declarações em linguagem simples, quando incluídas na história, desencadeiam uma série de atividades nas etapas seguintes do pipeline de desenvolvimento.
Ao reformular o processo de modelagem de ameaças dessa maneira, ela conseguiu defini-lo de forma mais concisa: “Identificar as ameaças prováveis a um sistema para orientar o design de contramedidas de segurança.”
Miller acredita que isso leva a cultura DevSecOps para o início do SDLC e capacita toda a equipe de desenvolvimento a incluir a modelagem de ameaças contextualizada no objetivo geral de melhoria contínua. Isso acontece porque todas as pessoas adotam uma mentalidade de segurança e levam essa consciência para as reuniões de planejamento da sprint e todas as atividades seguintes:
Planejar: inclua os requisitos de segurança na história.
Desenvolver: incorpore medidas de mitigação de ameaças (controles de segurança) ao SDLC.
Testar: escreva histórias com casos de uso para mitigação de ameaças e transforme-os em casos de teste.
Implantar: crie monitores que implementem os casos de teste e configure alertas.
Miller conclui que, com esse processo, é possível incluir a modelagem de ameaças sem prejudicar a velocidade do DevSecOps.
Conclusão
A cultura DevSecOps busca dividir o SDLC em partes que possam ser automatizadas para antecipar a qualidade (“shift left”) e estender as ferramentas (“extend right”) para cobrir todo o pipeline de entrega de software. Capacitar toda a equipe sobre modelagem de ameaças e mostrar como ela também pode ser integrada ao SDLC, começando pelos requisitos, permite que a conscientização sobre ameaças esteja presente e oriente cada etapa do DevSecOps.