Modelagem de Ameaças para Quem Tem Patinhas (e Mãos)
Um guia prático da AvitoTech sobre como implementar a modelagem de ameaças em larga escala, adaptando-a às necessidades de equipes de produto e integrando-a aos processos de desenvolvimento existentes. O artigo aborda metodologias, ferramentas e desafios, além de dicas para aprimorar o processo.
MundiX News·30 de maio de 2026·15 min de leitura·👁 19 views
Modelagem de Ameaças para Quem Tem Patinhas (e Mãos)
Olá, Habr! Meu nome é Sergey Zinovjev, sou parceiro de negócios em segurança da informação na Avito. Se algumas verificações de segurança de código podem ser facilmente automatizadas, as vulnerabilidades na fase de projeto são mais difíceis de lidar. Para identificar preventivamente esses problemas, organizações e comunidades como NIST e OWASP recomendam o uso de modelagem de ameaças em seus guias e estruturas. Em nossa prática, este é um processo bastante criativo, que exige compreensão tanto do lado do produto quanto do técnico.
Na Avito, escalamos esse processo para mais de 2.500 engenheiros, e hoje vou contar como chegamos a isso - com quais dificuldades nos deparamos, qual estrutura desenvolvemos e como a adaptamos às necessidades reais das equipes de produto.
Neste artigo:
A essência do processo e o valor prático
Metodologias de modelagem de ameaças e prática internacional
Metodologias e ferramentas
Com que dificuldades nos deparamos ao escolher uma metodologia
Desenvolvimento de uma solução
Questões-chave e casos de abuso
Priorização de ameaças e artefatos
Biblioteca de ataques
Melhorando o processo
Mudando o processo para casos individuais (interação entre equipes, aplicativo móvel)
Regularidade do processo
Em vez de resultados
A Essência do Processo e o Valor Prático
A modelagem de ameaças é a busca e análise de ameaças e maneiras de evitá-las para proteger algum valor (ativo). Em sistemas de TI, o valor são quase sempre os dados do usuário que este sistema armazena e processa.
A modelagem de ameaças é geralmente realizada no formato de brainstorming. Uma equipe de especialistas discute o modelo do sistema de software e responde à pergunta "O que pode dar errado?" O principal é não apenas encontrar possíveis problemas, mas planejar com antecedência como evitá-los.
Ou seja, a essência do processo é a seguinte:
É necessário construir um modelo do sistema
Encontrar pontos fracos
Determinar o que e em que ordem precisa ser corrigido.
O modelo ajuda a descartar detalhes desnecessários e se concentrar no importante. Em segurança da informação, o foco está nos fluxos de dados entre as partes do sistema e nas maneiras pelas quais um invasor pode roubá-los, substituí-los ou torná-los inacessíveis, ou seja, violar sua confidencialidade, integridade ou disponibilidade.
Analogia
Imagine que você queira fazer uma cômoda com uma gaveta para guardar documentos. As dimensões ou a cor dos móveis não afetam o nível de proteção, mas são importantes:
A localização da gaveta (para que não possa ser puxada por cima);
O tipo de fechadura (para que não possa ser derrubada);
O material da cômoda (para que as paredes não possam ser quebradas);
Fixação ao chão ou parede (para que a cômoda não possa ser levada).
A maioria desses itens pode ser levada em consideração na fase de projeto da cômoda.
O mesmo acontece ao desenvolver software: na fase de projeto técnico para avaliar as ameaças de segurança da informação, basta uma folha de papel e alguns lápis coloridos - barato e não requer um suporte de teste.
Imagine que estamos comprando uma casa com um terreno ao seu redor e queremos ter certeza de que será um lugar realmente confortável para morar com o mínimo de riscos para nós.
Nesse caso, o processo de modelagem de ameaças será assim:
Determinamos os principais valores no local e na casa.
Por exemplo, esta é a própria casa, as pessoas nela, o carro na garagem e o cofre no quarto.
Apresentamos potenciais vetores de ameaças, sem prestar atenção às medidas de proteção existentes.
As ameaças podem ser muito prováveis (por exemplo, penetração por engano, destruição da cerca, cataclismos naturais) e improváveis (por exemplo, uma escavação ou a queda de um tubarão no telhado). Ao mesmo tempo, vale lembrar que "improvável" não significa impossível.
Destacamos especialmente as possíveis ameaças aos nossos valores.
Por exemplo, para entrar na casa, você pode quebrar uma janela, e o cofre pode ser arrombado, explodido ou retirado da casa para abri-lo em um ambiente calmo.
Priorizamos as ameaças das quais queremos nos proteger (já que os recursos são limitados).
Por exemplo, faz sentido trocar todas as fechaduras da casa imediatamente, instalar um sistema automático de combate a incêndios e um alarme, além de ter um cachorro para proteger o local. Esconderemos o cofre imediatamente para que não esteja à vista de todos, mas podemos adiar a compra de um cofre mais protegido, assim como a instalação de uma cerca mais alta e forte. Para as ameaças mais improváveis, simplesmente aceitaremos os riscos como estão, mas não nos esqueceremos delas e as revisaremos no futuro.
Gerenciamento de Riscos
Pronto, realizamos uma modelagem de ameaças completa para nosso novo local. Parece bastante simples - adotamos essa abordagem como base de nossa metodologia.
Por que a Modelagem de Ameaças é Útil e Necessária na Avito
Delegação de responsabilidade.
Com milhares de microsserviços implantados quase diariamente em produção, é impossível para o departamento de segurança da informação avaliar o grau de risco de cada alteração. A estrutura de modelagem de ameaças permite que parte do trabalho seja transferida para as equipes que conhecem melhor sua área de assunto e, juntas, tornem nossos produtos mais seguros.
Seção de segurança da informação no TDR.
A Avito tem um processo TDR (Technical Design Review): as equipes defendem a arquitetura proposta, recebem feedback e aprovam as decisões. Este é o melhor momento para avaliar as ameaças de segurança da informação: o código ainda não foi escrito, as correções são mais baratas.
Requisitos da matriz de engenharia.
A Avito valoriza os líderes de recursos - engenheiros de alto nível capazes de levar um novo serviço ou produto da ideia à venda. Para um engenheiro sênior, é preciso ser capaz de levar em consideração as ameaças de segurança da informação no projeto e desenvolvimento - isso está diretamente relacionado à modelagem de ameaças.
A modelagem de ameaças é benéfica para todos:
Para a Avito - uma maneira conveniente e escalável de reduzir os riscos de segurança da informação;
Para o engenheiro - crescimento de competências e um passo para o papel de líder de recursos.
Metodologias de Modelagem de Ameaças e Prática Internacional
Se você acha que a modelagem de ameaças no desenvolvimento de software é difícil e artificial, observe a experiência dos líderes mundiais:
A Microsoft promove sua abordagem de avaliação de ameaças de segurança da informação chamada STRIDE há décadas:
O instituto americano NIST começou a padronizar a modelagem de ameaças em 2015-2016 e está constantemente expandindo o conjunto de recomendações;
O projeto OWASP tem um fluxo separado de modelagem de ameaças;
O que é OWASP?
OWASP (Open Worldwide Application Security Project) é uma comunidade online que publica informações e recursos abertos sobre segurança da informação. Eles compilam materiais de orientação para o desenvolvimento seguro de web, foram os fundadores do desenvolvimento da ferramenta de teste de penetração OWASP ZAP e publicam uma lista das Top 10 vulnerabilidades.
A modelagem de ameaças é necessária já no primeiro nível de maturidade de segurança da informação nos modelos BSIMM e OWASP SAMM;
O guru da ciência da computação Martin Fowler e seus seguidores descreveram em detalhes a implementação dessa prática no desenvolvimento Agile no guia.
A modelagem de ameaças é fixada nas recomendações do NIST e da OWASP. No entanto, ambas as fontes não regulamentam o próprio processo, pois, dependendo da área de assunto, do grau de detalhamento e da experiência da equipe, ele pode variar significativamente. No entanto, a comunidade desenvolveu metodologias e ferramentas de vários graus de universalidade, projetadas para auxiliar na modelagem de ameaças.
Metodologias e Ferramentas
MITRE ATT&CK®
Esta é uma estrutura volumosa que permite que você se concentre nos detalhes da implementação, graças à classificação bem elaborada de ataques potenciais. Essa abordagem não é à toa que alguns chamam de "Bíblia do profissional de segurança": todos os ataques são catalogados e ordenados de acordo com a sequência de ações ao realizar um ataque - da inteligência e coleta de informações à aplicação de ações destrutivas no sistema alvo.
No entanto, essa vantagem também tem uma desvantagem: para uma pessoa despreparada, será difícil de dominar, exigirá um grande volume de conhecimento técnico e custos de tempo na tentativa de "experimentar" toda a biblioteca de ataques em sua solução.
Elevation of Privilege
Este é um jogo de cartas que permite tornar o processo de modelagem de ameaças mais interativo e criativo. Requer um moderador-apresentador que organiza as rodadas do jogo.
A essência do jogo é simples: todos os participantes da sessão recebem cartas com possíveis vetores de ataque, e os jogadores, por sua vez, jogam essas cartas da mão, inventando ataques em sua área considerada.
As cartas são organizadas na forma de um baralho de pôquer de cinco naipes, divididos em grupos de ataques da metodologia STRIDE - quanto maior o valor da carta, mais crítico é o ataque. Cada um dos participantes da sessão pode se conectar e oferecer o mesmo ataque jogado em outro contexto da área considerada, o que permite organizar a co-criação.
O que é STRIDE?
STRIDE é uma metodologia de modelagem de ameaças desenvolvida pela Microsoft para identificar sistematicamente os riscos de segurança em sistemas de software. Ele permite que você classifique ameaças potenciais em seis categorias, o que simplifica a análise de vulnerabilidades e o desenvolvimento de medidas de proteção.
Categorias de ameaças:
Spoofing - falsificação de identidade
Tampering - alteração não autorizada de dados
Repudiation - recusa de ações
Information Disclosure - divulgação de informações
Denial of Service - negação de serviço
Elevation of Privilege - elevação de privilégios
Assim, o processo de modelagem de ameaças se torna muito mais dinâmico e coletivo, e as descrições dos ataques são mais compreensíveis para as equipes de desenvolvimento de produtos. Mas essa abordagem também tem suas desvantagens. As cartas do baralho podem não ser aplicáveis ao contexto específico da equipe (por exemplo, segurança física ao trabalhar com serviços em nuvem), e a limitação da sessão no tempo e a extração arbitrária de cartas do baralho introduzem incerteza adicional nos resultados: pode acontecer que as vulnerabilidades mais críticas simplesmente não cheguem às mãos dos jogadores, e em vez disso as equipes vão sugar ataques pouco aplicáveis a elas do dedo.
Com que Dificuldades nos Deparamos ao Escolher uma Metodologia
Entre os problemas mais óbvios estão:
A necessidade de integrar a modelagem de ameaças nos processos de desenvolvimento atuais, complementando-os, e não refazê-los do zero;
Sistematização do processo;
A possibilidade de realizar modelagem de ameaças retrospectiva, juntamente com a proativa;
O limite de entrada exigido no processo.
Ao mesmo tempo, existe a tentação de adiar a modelagem de ameaças para "mais tarde", quando mais dados forem conhecidos. No entanto, isso contradiz a abordagem shift-left, quando tentamos introduzir nossos processos nos estágios mais iniciais de projeto e desenvolvimento. Além disso, mesmo com informações tão limitadas, temos sobre o que pensar.
Por exemplo, nossa solução projetada afeta usuários externos? Estamos colocando alguns recursos fora em relação à infraestrutura interna da Avito? Talvez estejamos prestes a enviar algumas informações a fornecedores externos? E que tipo de informação será - dados pessoais ou de pagamento? Estamos planejando usar autenticação ou autorização de usuários e contas de serviço? Estas são todas perguntas bastante gerais, mas ao mesmo tempo desempenham um grande papel no projeto de uma solução segura e servem como um sinal para pensar na implementação e discuti-la com a equipe de segurança da informação.
Desenvolvimento de uma Solução
Primeiro de tudo, respondemos às perguntas: quando a modelagem de ameaças deve ser realizada e quem é responsável por ela? Em seguida, montamos uma estrutura que, por um lado, é compreensível para os engenheiros e, por outro, não é tão demorada e formalizada. Obtemos uma espécie de lista de verificação que é compreensível para os engenheiros, mas ao mesmo tempo não se transforma em uma formalidade.
Também é importante integrar esse processo nos processos de desenvolvimento existentes para que ele os complemente e não crie dificuldades adicionais. Em nosso caso, em primeiro lugar, esta é a fase de revisão de documentos de projeto técnico (TDR). Ao mesmo tempo, as equipes trabalham nas ferramentas que lhes são familiares e enriquecem o contexto com aspectos de segurança da informação.
Em uma das questões, gostaria de me deter separadamente:
"O que pode acontecer se a solução for usada de forma inadequada?"
(casos de abuso).
Vamos imaginar a situação: para reduzir o tempo de resposta e as horas de trabalho gastas no desenvolvimento, a equipe implementou um serviço disponível sem autorização, mas apenas quando conectado à rede corporativa. Até agora, parece um pouco duvidoso, mas é aceitável. Mas outra equipe soube da existência de tal serviço e decidiu reutilizá-lo para seus próprios fins. Ela anexa endpoints de API públicos que se referem a este serviço, e agora temos um recurso disponível publicamente sem autorização e com uma carga diferente da planejada. Quem é o culpado nesta situação? A equipe que não acompanhou a conexão não autorizada a seus recursos? A equipe que simplesmente encontrou um serviço interno já funcionando e decidiu reutilizá-lo?
Para evitar situações semelhantes, na fase de projeto, vale a pena pensar em como nossa solução pode ser usada de outra forma - não como foi originalmente concebida?
Por exemplo, podem ser usuários externos que, em vez de sua própria imagem, definem um link para recursos proibidos como avatar. Podem ser também funcionários internos aos quais não foi restringido o acesso. Talvez, através de serviços não totalmente fechados, alguém possa alcançar recursos aos quais não deveria ter acesso?
Priorização de Ameaças e Artefatos
Respondendo a todas essas perguntas, a equipe receberá uma lista de ameaças. Algumas dessas ameaças podem ser mitigadas imediatamente, na fase de desenvolvimento; algumas serão levadas em consideração no futuro, e poderemos iniciar as tarefas correspondentes para aprimoramento; alguns riscos serão assumidos sob nossa responsabilidade.
É hora de descobrir: quais ataques mitigaremos imediatamente e quais medidas tomaremos em algum momento posterior. Se a equipe decidir que alguns ataques não valem a pena e os jogadores estão prontos para aceitar os riscos, você precisa arrastá-los para a área apropriada.
Como resultado da modelagem de ameaças, a equipe deve ter:
Um diagrama ou descrição do recurso, indicando ameaças potenciais vinculadas aos possíveis pontos de sua ocorrência;
Ameaças documentadas que foram aceitas ou adiadas para tempos melhores;
Tarefas no Jira com a indicação de DoD para as ameaças mais críticas.
Biblioteca de Ataques
A biblioteca de ataques consiste em várias seções:
Seção de ataques via back-end.
Aqui consideramos ataques a microsserviços insuficientemente isolados; ataques relacionados ao processamento de dados de entrada (várias injeções, obtenção de dados inseguros e sua execução posterior no servidor e outras validações) e ataques cujo principal vetor é a obtenção não autorizada de várias informações de serviço e confidenciais.
Seção de ataques a componentes front-end.
Alguns deles, novamente, são dedicados a trabalhar com dados fornecidos de fora; parte - para obter e exibir informações extras. Além disso, ataques no nível da árvore DOM, execução de scripts no lado do cliente, solicitações entre domínios e outras automações que permitem redirecionar os dados de interesse do invasor para recursos de terceiros e enganar o usuário são adicionados aqui.
Seção dedicada à lógica de negócios.
A possibilidade de seleção de acesso a dados, autenticação e autorização insuficientes ou ausentes, os problemas com registro e monitoramento de processos são destacados (tanto com sua falta quanto com excesso), as características processuais são consideradas (por exemplo, um usuário pode executar algo duas vezes, contornando as restrições de negócios ou reabastecer a conta com um pagamento inexistente, alterando o valor nos parâmetros da solicitação em uma direção maior), bem como a presença de integrações externas, nas quais gastamos alguns recursos.
Ataques a plataformas móveis.
Como regra, as ameaças para aplicativos móveis estão à beira das fronteiras de visibilidade e código executado automaticamente, ou seja, em JS, WebView e interação entre processos. O uso de componentes não padrão e o encaminhamento de dados entre aplicativos expandem a superfície de ataque potencial em comparação com o front-end mais familiar, que pode ser executado, inclusive, de um navegador móvel.
Tentativas de extrair informações confidenciais ou realizar ações em violação da lei.
Esta categoria inclui todos os ataques que afetam não apenas os meios técnicos, mas também visam causar danos informacionais, de reputação e legal, por exemplo, a colocação de materiais ilegais que podem colocar toda a plataforma em risco, a exploração de vulnerabilidades devido à violação das regras de armazenamento e processamento de dados pessoais e de pagamento dos usuários, bem como a evasão dos controles de moderação.
Melhorando o Processo
Aqui não poderíamos prescindir da coleta de feedback para melhorar o processo, a fim de abordar todas as dificuldades acima. Como resultado do feedback recebido, formamos uma lista específica de critérios para a aplicabilidade da modelagem de ameaças, introduzimos uma seção de segurança da informação no modelo TDR. Com uma penetração mais profunda da IA em nossos processos, revisamos repetidamente os modelos para que, por um lado, refletissem o estado da segurança da informação no TDR e, por outro, permitissem filtrar e destacar problemas potenciais usando automação e LLM. Ao mesmo tempo, é importante encontrar um equilíbrio: quanto mais claro o texto for para a automação, menos claro ele será para a pessoa que o lê e valida. Também no âmbito do teste do processo, identificamos o problema de diferentes focos de estudo do TDR - do projeto de alto nível à melhoria pontual em um serviço específico.
Mudando o Processo para Casos Individuais
A abordagem padrão para modelagem de ameaças, adotada na Avito, embora cubra a maioria dos casos, às vezes ainda existem situações em que ela é sentida mais como uma formalidade desnecessária. Ou parece que, no caso atual, não resolve totalmente a tarefa de encontrar possíveis ameaças e maneiras de mitigá-las. Tentaremos analisar as complicações e desvios mais típicos da estrutura, bem como dar algumas dicas sobre como adaptar o processo para você.
Interação entre Equipes
Se de repente os colegas encontrarem algum problema e perguntas potenciais, eles podem ser deixados com segurança no modelo de ameaças e devem ser transferidos para os proprietários apropriados.
A mesma história acontece quando os participantes alcançam um componente que está além de seu contexto, com ameaças desconhecidas para eles. Ao mesmo tempo, não será supérfluo, no mínimo, perguntar à equipe responsável pelo componente como eles lidam com uma determinada situação que vem de sua equipe: afinal, as vulnerabilidades mais comuns e críticas surgem na interseção de tecnologias, contextos e processos de negócios. Se eles ainda não realizaram a modelagem de ameaças, faz sentido planejá-la.
Aplicativo Móvel
Se a equipe estiver desenvolvendo apenas um aplicativo móvel, quase todos os itens da biblioteca de ataques no modelo serão inaplicáveis a ela. Ao mesmo tempo, você não precisa ter pressa em eliminar os itens relacionados à lógica de negócios e ao back-end: mesmo em um "cliente fino", você pode quebrar a lenha se não levar em consideração as características da implementação do back-end e as mensagens que ele retorna.
Analisamos as abordagens padrão para modelagem de ameaças, adotadas na Avito. Observe que esta é apenas uma estrutura geral, para que você possa fazer suas próprias modificações com base nas necessidades.
Regularidade do Processo
Não se limite a uma modelagem de ameaças realizada para cada serviço, o processo deve ser regular. Além disso, depois de jogar algumas vezes na estrutura proposta e, portanto, se acostumar com a abordagem, a equipe pode não seguir mais o modelo incondicionalmente, mas, por exemplo, pegar ameaças conhecidas, alterar um pouco o contexto, pensar em como a solução pode ser abusada (por exemplo, se o acesso ao link de pagamento for recebido pela pessoa errada para quem se destina); finalmente, percorra a lista de verificação, que pode inspirar novas idéias.
Em Vez de Resultados
Escalamos a solução para mais de 2.500 engenheiros, apostando na flexibilidade da abordagem, integração com outros processos e treinamento. Analisamos os principais erros e vulnerabilidades típicos e ensinamos as equipes a identificá-los. Como resultado, redistribuímos cerca de 15% dos custos de trabalho para modelagem de ameaças para as equipes de desenvolvimento de produtos - e reduzimos o limite de entrada no processo a tal ponto que ele se tornou acessível "mesmo para aqueles que têm patinhas".
Você não deve ter medo de adaptar a abordagem para si mesmo, você precisa tentar e procurar a abordagem mais adequada para a equipe e, o mais importante, não se esqueça de documentar todas as descobertas para que possam ser referenciadas a qualquer momento e revisadas.
Sem cartão para começar · Planos a partir de R$49/mês
Modelagem de Ameaças para Quem Tem Patinhas (e Mãos)
Olá, Habr! Meu nome é Sergey Zinovjev, sou parceiro de negócios em segurança da informação na Avito. Se algumas verificações de segurança de código podem ser facilmente automatizadas, as vulnerabilidades na fase de projeto são mais difíceis de lidar. Para identificar preventivamente esses problemas, organizações e comunidades como NIST e OWASP recomendam o uso de modelagem de ameaças em seus guias e estruturas. Em nossa prática, este é um processo bastante criativo, que exige compreensão tanto do lado do produto quanto do técnico.
Na Avito, escalamos esse processo para mais de 2.500 engenheiros, e hoje vou contar como chegamos a isso - com quais dificuldades nos deparamos, qual estrutura desenvolvemos e como a adaptamos às necessidades reais das equipes de produto.
Neste artigo:
A essência do processo e o valor prático
Metodologias de modelagem de ameaças e prática internacional
Metodologias e ferramentas
Com que dificuldades nos deparamos ao escolher uma metodologia
Desenvolvimento de uma solução
Questões-chave e casos de abuso
Priorização de ameaças e artefatos
Biblioteca de ataques
Melhorando o processo
Mudando o processo para casos individuais (interação entre equipes, aplicativo móvel)
Regularidade do processo
Em vez de resultados
A Essência do Processo e o Valor Prático
A modelagem de ameaças é a busca e análise de ameaças e maneiras de evitá-las para proteger algum valor (ativo). Em sistemas de TI, o valor são quase sempre os dados do usuário que este sistema armazena e processa.
A modelagem de ameaças é geralmente realizada no formato de brainstorming. Uma equipe de especialistas discute o modelo do sistema de software e responde à pergunta "O que pode dar errado?" O principal é não apenas encontrar possíveis problemas, mas planejar com antecedência como evitá-los.
Ou seja, a essência do processo é a seguinte:
É necessário construir um modelo do sistema
Encontrar pontos fracos
Determinar o que e em que ordem precisa ser corrigido.
O modelo ajuda a descartar detalhes desnecessários e se concentrar no importante. Em segurança da informação, o foco está nos fluxos de dados entre as partes do sistema e nas maneiras pelas quais um invasor pode roubá-los, substituí-los ou torná-los inacessíveis, ou seja, violar sua confidencialidade, integridade ou disponibilidade.
Analogia
Imagine que você queira fazer uma cômoda com uma gaveta para guardar documentos. As dimensões ou a cor dos móveis não afetam o nível de proteção, mas são importantes:
A localização da gaveta (para que não possa ser puxada por cima);
O tipo de fechadura (para que não possa ser derrubada);
O material da cômoda (para que as paredes não possam ser quebradas);
Fixação ao chão ou parede (para que a cômoda não possa ser levada).
A maioria desses itens pode ser levada em consideração na fase de projeto da cômoda.
O mesmo acontece ao desenvolver software: na fase de projeto técnico para avaliar as ameaças de segurança da informação, basta uma folha de papel e alguns lápis coloridos - barato e não requer um suporte de teste.
Imagine que estamos comprando uma casa com um terreno ao seu redor e queremos ter certeza de que será um lugar realmente confortável para morar com o mínimo de riscos para nós.
Nesse caso, o processo de modelagem de ameaças será assim:
Determinamos os principais valores no local e na casa.
Por exemplo, esta é a própria casa, as pessoas nela, o carro na garagem e o cofre no quarto.
Apresentamos potenciais vetores de ameaças, sem prestar atenção às medidas de proteção existentes.
As ameaças podem ser muito prováveis (por exemplo, penetração por engano, destruição da cerca, cataclismos naturais) e improváveis (por exemplo, uma escavação ou a queda de um tubarão no telhado). Ao mesmo tempo, vale lembrar que "improvável" não significa impossível.
Destacamos especialmente as possíveis ameaças aos nossos valores.
Por exemplo, para entrar na casa, você pode quebrar uma janela, e o cofre pode ser arrombado, explodido ou retirado da casa para abri-lo em um ambiente calmo.
Priorizamos as ameaças das quais queremos nos proteger (já que os recursos são limitados).
Por exemplo, faz sentido trocar todas as fechaduras da casa imediatamente, instalar um sistema automático de combate a incêndios e um alarme, além de ter um cachorro para proteger o local. Esconderemos o cofre imediatamente para que não esteja à vista de todos, mas podemos adiar a compra de um cofre mais protegido, assim como a instalação de uma cerca mais alta e forte. Para as ameaças mais improváveis, simplesmente aceitaremos os riscos como estão, mas não nos esqueceremos delas e as revisaremos no futuro.
Gerenciamento de Riscos
Pronto, realizamos uma modelagem de ameaças completa para nosso novo local. Parece bastante simples - adotamos essa abordagem como base de nossa metodologia.
Por que a Modelagem de Ameaças é Útil e Necessária na Avito
Delegação de responsabilidade.
Com milhares de microsserviços implantados quase diariamente em produção, é impossível para o departamento de segurança da informação avaliar o grau de risco de cada alteração. A estrutura de modelagem de ameaças permite que parte do trabalho seja transferida para as equipes que conhecem melhor sua área de assunto e, juntas, tornem nossos produtos mais seguros.
Seção de segurança da informação no TDR.
A Avito tem um processo TDR (Technical Design Review): as equipes defendem a arquitetura proposta, recebem feedback e aprovam as decisões. Este é o melhor momento para avaliar as ameaças de segurança da informação: o código ainda não foi escrito, as correções são mais baratas.
Requisitos da matriz de engenharia.
A Avito valoriza os líderes de recursos - engenheiros de alto nível capazes de levar um novo serviço ou produto da ideia à venda. Para um engenheiro sênior, é preciso ser capaz de levar em consideração as ameaças de segurança da informação no projeto e desenvolvimento - isso está diretamente relacionado à modelagem de ameaças.
A modelagem de ameaças é benéfica para todos:
Para a Avito - uma maneira conveniente e escalável de reduzir os riscos de segurança da informação;
Para o engenheiro - crescimento de competências e um passo para o papel de líder de recursos.
Metodologias de Modelagem de Ameaças e Prática Internacional
Se você acha que a modelagem de ameaças no desenvolvimento de software é difícil e artificial, observe a experiência dos líderes mundiais:
A Microsoft promove sua abordagem de avaliação de ameaças de segurança da informação chamada STRIDE há décadas:
O instituto americano NIST começou a padronizar a modelagem de ameaças em 2015-2016 e está constantemente expandindo o conjunto de recomendações;
O projeto OWASP tem um fluxo separado de modelagem de ameaças;
O que é OWASP?
OWASP (Open Worldwide Application Security Project) é uma comunidade online que publica informações e recursos abertos sobre segurança da informação. Eles compilam materiais de orientação para o desenvolvimento seguro de web, foram os fundadores do desenvolvimento da ferramenta de teste de penetração OWASP ZAP e publicam uma lista das Top 10 vulnerabilidades.
A modelagem de ameaças é necessária já no primeiro nível de maturidade de segurança da informação nos modelos BSIMM e OWASP SAMM;
O guru da ciência da computação Martin Fowler e seus seguidores descreveram em detalhes a implementação dessa prática no desenvolvimento Agile no guia.
A modelagem de ameaças é fixada nas recomendações do NIST e da OWASP. No entanto, ambas as fontes não regulamentam o próprio processo, pois, dependendo da área de assunto, do grau de detalhamento e da experiência da equipe, ele pode variar significativamente. No entanto, a comunidade desenvolveu metodologias e ferramentas de vários graus de universalidade, projetadas para auxiliar na modelagem de ameaças.
Metodologias e Ferramentas
MITRE ATT&CK®
Esta é uma estrutura volumosa que permite que você se concentre nos detalhes da implementação, graças à classificação bem elaborada de ataques potenciais. Essa abordagem não é à toa que alguns chamam de "Bíblia do profissional de segurança": todos os ataques são catalogados e ordenados de acordo com a sequência de ações ao realizar um ataque - da inteligência e coleta de informações à aplicação de ações destrutivas no sistema alvo.
No entanto, essa vantagem também tem uma desvantagem: para uma pessoa despreparada, será difícil de dominar, exigirá um grande volume de conhecimento técnico e custos de tempo na tentativa de "experimentar" toda a biblioteca de ataques em sua solução.
Elevation of Privilege
Este é um jogo de cartas que permite tornar o processo de modelagem de ameaças mais interativo e criativo. Requer um moderador-apresentador que organiza as rodadas do jogo.
A essência do jogo é simples: todos os participantes da sessão recebem cartas com possíveis vetores de ataque, e os jogadores, por sua vez, jogam essas cartas da mão, inventando ataques em sua área considerada.
As cartas são organizadas na forma de um baralho de pôquer de cinco naipes, divididos em grupos de ataques da metodologia STRIDE - quanto maior o valor da carta, mais crítico é o ataque. Cada um dos participantes da sessão pode se conectar e oferecer o mesmo ataque jogado em outro contexto da área considerada, o que permite organizar a co-criação.
O que é STRIDE?
STRIDE é uma metodologia de modelagem de ameaças desenvolvida pela Microsoft para identificar sistematicamente os riscos de segurança em sistemas de software. Ele permite que você classifique ameaças potenciais em seis categorias, o que simplifica a análise de vulnerabilidades e o desenvolvimento de medidas de proteção.
Categorias de ameaças:
Spoofing - falsificação de identidade
Tampering - alteração não autorizada de dados
Repudiation - recusa de ações
Information Disclosure - divulgação de informações
Denial of Service - negação de serviço
Elevation of Privilege - elevação de privilégios
Assim, o processo de modelagem de ameaças se torna muito mais dinâmico e coletivo, e as descrições dos ataques são mais compreensíveis para as equipes de desenvolvimento de produtos. Mas essa abordagem também tem suas desvantagens. As cartas do baralho podem não ser aplicáveis ao contexto específico da equipe (por exemplo, segurança física ao trabalhar com serviços em nuvem), e a limitação da sessão no tempo e a extração arbitrária de cartas do baralho introduzem incerteza adicional nos resultados: pode acontecer que as vulnerabilidades mais críticas simplesmente não cheguem às mãos dos jogadores, e em vez disso as equipes vão sugar ataques pouco aplicáveis a elas do dedo.
Com que Dificuldades nos Deparamos ao Escolher uma Metodologia
Entre os problemas mais óbvios estão:
A necessidade de integrar a modelagem de ameaças nos processos de desenvolvimento atuais, complementando-os, e não refazê-los do zero;
Sistematização do processo;
A possibilidade de realizar modelagem de ameaças retrospectiva, juntamente com a proativa;
O limite de entrada exigido no processo.
Ao mesmo tempo, existe a tentação de adiar a modelagem de ameaças para "mais tarde", quando mais dados forem conhecidos. No entanto, isso contradiz a abordagem shift-left, quando tentamos introduzir nossos processos nos estágios mais iniciais de projeto e desenvolvimento. Além disso, mesmo com informações tão limitadas, temos sobre o que pensar.
Por exemplo, nossa solução projetada afeta usuários externos? Estamos colocando alguns recursos fora em relação à infraestrutura interna da Avito? Talvez estejamos prestes a enviar algumas informações a fornecedores externos? E que tipo de informação será - dados pessoais ou de pagamento? Estamos planejando usar autenticação ou autorização de usuários e contas de serviço? Estas são todas perguntas bastante gerais, mas ao mesmo tempo desempenham um grande papel no projeto de uma solução segura e servem como um sinal para pensar na implementação e discuti-la com a equipe de segurança da informação.
Desenvolvimento de uma Solução
Primeiro de tudo, respondemos às perguntas: quando a modelagem de ameaças deve ser realizada e quem é responsável por ela? Em seguida, montamos uma estrutura que, por um lado, é compreensível para os engenheiros e, por outro, não é tão demorada e formalizada. Obtemos uma espécie de lista de verificação que é compreensível para os engenheiros, mas ao mesmo tempo não se transforma em uma formalidade.
Também é importante integrar esse processo nos processos de desenvolvimento existentes para que ele os complemente e não crie dificuldades adicionais. Em nosso caso, em primeiro lugar, esta é a fase de revisão de documentos de projeto técnico (TDR). Ao mesmo tempo, as equipes trabalham nas ferramentas que lhes são familiares e enriquecem o contexto com aspectos de segurança da informação.
Em uma das questões, gostaria de me deter separadamente:
"O que pode acontecer se a solução for usada de forma inadequada?"
(casos de abuso).
Vamos imaginar a situação: para reduzir o tempo de resposta e as horas de trabalho gastas no desenvolvimento, a equipe implementou um serviço disponível sem autorização, mas apenas quando conectado à rede corporativa. Até agora, parece um pouco duvidoso, mas é aceitável. Mas outra equipe soube da existência de tal serviço e decidiu reutilizá-lo para seus próprios fins. Ela anexa endpoints de API públicos que se referem a este serviço, e agora temos um recurso disponível publicamente sem autorização e com uma carga diferente da planejada. Quem é o culpado nesta situação? A equipe que não acompanhou a conexão não autorizada a seus recursos? A equipe que simplesmente encontrou um serviço interno já funcionando e decidiu reutilizá-lo?
Para evitar situações semelhantes, na fase de projeto, vale a pena pensar em como nossa solução pode ser usada de outra forma - não como foi originalmente concebida?
Por exemplo, podem ser usuários externos que, em vez de sua própria imagem, definem um link para recursos proibidos como avatar. Podem ser também funcionários internos aos quais não foi restringido o acesso. Talvez, através de serviços não totalmente fechados, alguém possa alcançar recursos aos quais não deveria ter acesso?
Priorização de Ameaças e Artefatos
Respondendo a todas essas perguntas, a equipe receberá uma lista de ameaças. Algumas dessas ameaças podem ser mitigadas imediatamente, na fase de desenvolvimento; algumas serão levadas em consideração no futuro, e poderemos iniciar as tarefas correspondentes para aprimoramento; alguns riscos serão assumidos sob nossa responsabilidade.
É hora de descobrir: quais ataques mitigaremos imediatamente e quais medidas tomaremos em algum momento posterior. Se a equipe decidir que alguns ataques não valem a pena e os jogadores estão prontos para aceitar os riscos, você precisa arrastá-los para a área apropriada.
Como resultado da modelagem de ameaças, a equipe deve ter:
Um diagrama ou descrição do recurso, indicando ameaças potenciais vinculadas aos possíveis pontos de sua ocorrência;
Ameaças documentadas que foram aceitas ou adiadas para tempos melhores;
Tarefas no Jira com a indicação de DoD para as ameaças mais críticas.
Biblioteca de Ataques
A biblioteca de ataques consiste em várias seções:
Seção de ataques via back-end.
Aqui consideramos ataques a microsserviços insuficientemente isolados; ataques relacionados ao processamento de dados de entrada (várias injeções, obtenção de dados inseguros e sua execução posterior no servidor e outras validações) e ataques cujo principal vetor é a obtenção não autorizada de várias informações de serviço e confidenciais.
Seção de ataques a componentes front-end.
Alguns deles, novamente, são dedicados a trabalhar com dados fornecidos de fora; parte - para obter e exibir informações extras. Além disso, ataques no nível da árvore DOM, execução de scripts no lado do cliente, solicitações entre domínios e outras automações que permitem redirecionar os dados de interesse do invasor para recursos de terceiros e enganar o usuário são adicionados aqui.
Seção dedicada à lógica de negócios.
A possibilidade de seleção de acesso a dados, autenticação e autorização insuficientes ou ausentes, os problemas com registro e monitoramento de processos são destacados (tanto com sua falta quanto com excesso), as características processuais são consideradas (por exemplo, um usuário pode executar algo duas vezes, contornando as restrições de negócios ou reabastecer a conta com um pagamento inexistente, alterando o valor nos parâmetros da solicitação em uma direção maior), bem como a presença de integrações externas, nas quais gastamos alguns recursos.
Ataques a plataformas móveis.
Como regra, as ameaças para aplicativos móveis estão à beira das fronteiras de visibilidade e código executado automaticamente, ou seja, em JS, WebView e interação entre processos. O uso de componentes não padrão e o encaminhamento de dados entre aplicativos expandem a superfície de ataque potencial em comparação com o front-end mais familiar, que pode ser executado, inclusive, de um navegador móvel.
Tentativas de extrair informações confidenciais ou realizar ações em violação da lei.
Esta categoria inclui todos os ataques que afetam não apenas os meios técnicos, mas também visam causar danos informacionais, de reputação e legal, por exemplo, a colocação de materiais ilegais que podem colocar toda a plataforma em risco, a exploração de vulnerabilidades devido à violação das regras de armazenamento e processamento de dados pessoais e de pagamento dos usuários, bem como a evasão dos controles de moderação.
Melhorando o Processo
Aqui não poderíamos prescindir da coleta de feedback para melhorar o processo, a fim de abordar todas as dificuldades acima. Como resultado do feedback recebido, formamos uma lista específica de critérios para a aplicabilidade da modelagem de ameaças, introduzimos uma seção de segurança da informação no modelo TDR. Com uma penetração mais profunda da IA em nossos processos, revisamos repetidamente os modelos para que, por um lado, refletissem o estado da segurança da informação no TDR e, por outro, permitissem filtrar e destacar problemas potenciais usando automação e LLM. Ao mesmo tempo, é importante encontrar um equilíbrio: quanto mais claro o texto for para a automação, menos claro ele será para a pessoa que o lê e valida. Também no âmbito do teste do processo, identificamos o problema de diferentes focos de estudo do TDR - do projeto de alto nível à melhoria pontual em um serviço específico.
Mudando o Processo para Casos Individuais
A abordagem padrão para modelagem de ameaças, adotada na Avito, embora cubra a maioria dos casos, às vezes ainda existem situações em que ela é sentida mais como uma formalidade desnecessária. Ou parece que, no caso atual, não resolve totalmente a tarefa de encontrar possíveis ameaças e maneiras de mitigá-las. Tentaremos analisar as complicações e desvios mais típicos da estrutura, bem como dar algumas dicas sobre como adaptar o processo para você.
Interação entre Equipes
Se de repente os colegas encontrarem algum problema e perguntas potenciais, eles podem ser deixados com segurança no modelo de ameaças e devem ser transferidos para os proprietários apropriados.
A mesma história acontece quando os participantes alcançam um componente que está além de seu contexto, com ameaças desconhecidas para eles. Ao mesmo tempo, não será supérfluo, no mínimo, perguntar à equipe responsável pelo componente como eles lidam com uma determinada situação que vem de sua equipe: afinal, as vulnerabilidades mais comuns e críticas surgem na interseção de tecnologias, contextos e processos de negócios. Se eles ainda não realizaram a modelagem de ameaças, faz sentido planejá-la.
Aplicativo Móvel
Se a equipe estiver desenvolvendo apenas um aplicativo móvel, quase todos os itens da biblioteca de ataques no modelo serão inaplicáveis a ela. Ao mesmo tempo, você não precisa ter pressa em eliminar os itens relacionados à lógica de negócios e ao back-end: mesmo em um "cliente fino", você pode quebrar a lenha se não levar em consideração as características da implementação do back-end e as mensagens que ele retorna.
Analisamos as abordagens padrão para modelagem de ameaças, adotadas na Avito. Observe que esta é apenas uma estrutura geral, para que você possa fazer suas próprias modificações com base nas necessidades.
Regularidade do Processo
Não se limite a uma modelagem de ameaças realizada para cada serviço, o processo deve ser regular. Além disso, depois de jogar algumas vezes na estrutura proposta e, portanto, se acostumar com a abordagem, a equipe pode não seguir mais o modelo incondicionalmente, mas, por exemplo, pegar ameaças conhecidas, alterar um pouco o contexto, pensar em como a solução pode ser abusada (por exemplo, se o acesso ao link de pagamento for recebido pela pessoa errada para quem se destina); finalmente, percorra a lista de verificação, que pode inspirar novas idéias.
Em Vez de Resultados
Escalamos a solução para mais de 2.500 engenheiros, apostando na flexibilidade da abordagem, integração com outros processos e treinamento. Analisamos os principais erros e vulnerabilidades típicos e ensinamos as equipes a identificá-los. Como resultado, redistribuímos cerca de 15% dos custos de trabalho para modelagem de ameaças para as equipes de desenvolvimento de produtos - e reduzimos o limite de entrada no processo a tal ponto que ele se tornou acessível "mesmo para aqueles que têm patinhas".
Você não deve ter medo de adaptar a abordagem para si mesmo, você precisa tentar e procurar a abordagem mais adequada para a equipe e, o mais importante, não se esqueça de documentar todas as descobertas para que possam ser referenciadas a qualquer momento e revisadas.
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
