Modelagem de ameaças com STRIDE para sistemas reais

Modelagem de ameaças é a disciplina de pensar como um sistema pode falhar diante de um adversário antes que esse adversário faça o pensamento por você. O STRIDE, um mnemônico que a Microsoft popularizou no início dos anos 2000, permanece uma das formas mais duradouras de estruturar esse pensamento porque mapeia de maneira limpa sobre as propriedades com que um defensor de fato se importa. Este artigo percorre o STRIDE sob a ótica do blue team: como conduzir uma sessão de modelagem sobre um sistema de produção real, como cada categoria mapeia para sinais de detecção concretos e como transformar os achados em trabalho de endurecimento que sobreviva ao contato com um ambiente em execução. O objetivo não é produzir um diagrama bonito que decore uma wiki, mas mudar o que você monitora e o que constrói.

O que STRIDE realmente significa#

STRIDE é um acrônimo para seis categorias de ameaça: Falsificação (fingir ser alguém ou algo que não se é), Adulteração (modificação não autorizada de dados ou código), Repúdio (negar uma ação sem que o sistema possa provar o contrário), Divulgação de informação (exposição de dados a quem não deveria vê-los), Negação de serviço (degradar ou remover a disponibilidade) e Elevação de privilégio (obter capacidades além das concedidas). Cada categoria é o espelho de uma propriedade de segurança que você quer preservar: autenticação, integridade, não repúdio, confidencialidade, disponibilidade e autorização. Essa simetria é o que torna o STRIDE útil. Quando você encontra uma ameaça, já sabe qual propriedade ela ataca e, portanto, qual classe de controle a defende.

Como funciona uma sessão de modelagem na prática#

Uma sessão útil começa com um diagrama de fluxo de dados, não com um diagrama de rede. Você desenha as entidades externas (usuários, serviços de terceiros), os processos (seus serviços e workers), os armazenamentos de dados (bancos, caches, armazenamento de objetos) e os fluxos entre eles. Depois desenha as fronteiras de confiança: as linhas que uma requisição cruza quando passa de uma zona menos confiável para uma mais confiável, como a borda entre a internet pública e o seu gateway, ou entre uma API voltada ao inquilino e um serviço interno. É nas fronteiras de confiança que o STRIDE ganha seu salário, porque quase toda ameaça interessante vive num cruzamento de fronteira. Para cada elemento e cada fluxo, você pergunta quais das seis categorias se aplicam e registra a resposta como uma afirmação concreta e testável, e não como uma preocupação vaga.

Aplicando as categorias a um cruzamento de fronteira#

Considere uma requisição chegando a um endpoint de API autenticado. A falsificação pergunta se um atacante pode apresentar um token que não é dele; a defesa é a validação completa do token, incluindo assinatura, expiração, audiência, emissor e uma allowlist de algoritmos. A adulteração pergunta se o corpo da requisição ou um registro armazenado pode ser alterado fora das regras; a defesa é validação no lado do servidor e persistência parametrizada. O repúdio pergunta se você poderia provar depois quem fez o quê; a defesa é um log de auditoria somente-anexação com um identificador de rastreamento. A divulgação de informação pergunta se mensagens de erro, respostas verbosas ou leituras entre inquilinos vazam dados; a negação de serviço pergunta se um corpo ilimitado ou uma consulta cara pode esgotar recursos; e a elevação de privilégio pergunta se um chamador de baixo privilégio pode alcançar uma ação privilegiada, a raiz clássica de falhas de autorização como as referências diretas a objetos inseguras.

Superfície de ataque e onde focar#

Nem todo elemento merece igual atenção. Os alvos de maior valor são fronteiras de confiança que separam inquilinos, fronteiras que separam tráfego não autenticado do autenticado e qualquer processo que guarde um segredo ou possa agir em nome de outros. Em sistemas multi-inquilino, a pergunta mais valiosa é se um identificador de inquilino é em algum momento tomado de entrada controlada pelo cliente em vez de um token verificado, porque uma única falha desse tipo derruba todo o modelo de isolamento. Concentre seu orçamento de modelagem nos fluxos que carregam decisões de identidade e autorização e trate fluxos puramente internos dentro de uma mesma zona de confiança como de menor prioridade, a menos que toquem segredos ou dados em massa.

Sinais de detecção mapeados para o STRIDE#

A modelagem de ameaças só é defensiva se mudar sua telemetria. A falsificação mapeia para logs de autenticação: falhas repetidas de validação de token, tokens apresentados após a expiração e logins de geografias improváveis. A adulteração mapeia para monitoramento de integridade: verificações de integridade de arquivos em binários e configuração, gatilhos de banco de dados ou colunas de auditoria que sinalizam modificação fora de banda, e divergências de somas de verificação. O repúdio mapeia diretamente para a completude do seu log de auditoria; uma lacuna no log é, ela mesma, um sinal. A divulgação de informação mapeia para monitoramento de saída e para alertas sobre resultados de consulta anormalmente grandes ou amplos. A negação de serviço mapeia para painéis de latência, saturação e taxa de erro. A elevação de privilégio mapeia para eventos de autorização negada e, crucialmente, para eventos de autorização concedida em ações sensíveis, que deveriam ser raras o bastante para revisar.

Mitigação e controles de endurecimento#

Cada categoria do STRIDE tem uma família de controles bem compreendida. Contra falsificação: autenticação forte, múltiplo fator para humanos, TLS mútuo ou requisições assinadas entre serviços e credenciais de vida curta. Contra adulteração: validação de entrada no servidor, consultas parametrizadas, assinatura de código e infraestrutura imutável. Contra repúdio: registro centralizado e à prova de adulteração com relógios sincronizados. Contra divulgação de informação: criptografia em trânsito e em repouso, acesso a dados com privilégio mínimo, redação do detalhe de erro interno antes de chegar ao cliente e revisão cuidadosa do que qualquer resposta 5xx devolve. Contra negação de serviço: limites de tamanho de requisição, limites de paginação, timeouts em cada chamada de saída, filas limitadas e limitação de taxa na borda. Contra elevação de privilégio: autorização decidida no servidor a partir de identidade verificada, políticas de negar por padrão e verificações no nível do objeto em cada rota por-id.

Armadilhas comuns que esvaziam um modelo de ameaças#

A primeira armadilha é modelar a arquitetura que você gostaria de ter em vez da que está implantada; verifique no sistema em execução, não no documento de design, porque a deriva é universal. A segunda é parar no diagrama e nunca converter ameaças em trabalho rastreado com responsáveis e prazos. A terceira é tratar o STRIDE como uma lista a ser preenchida uma vez, quando deveria ser revisitado sempre que surge uma nova fronteira de confiança, como uma nova integração ou um novo nível de inquilino. A quarta é sobremodelar fluxos internos de baixo valor enquanto se submodelam os caminhos de autenticação e autorização que de fato decidem quem pode fazer o quê. A quinta é confundir probabilidade com severidade e ignorar ameaças de alto impacto e baixa probabilidade, como um pipeline de build comprometido.

Uma lista de verificação repetível#

Conduza sua sessão segundo esta sequência. Desenhe o diagrama de fluxo de dados a partir da realidade. Marque cada fronteira de confiança. Para cada cruzamento de fronteira, percorra as seis categorias do STRIDE e escreva uma afirmação de ameaça testável. Avalie cada ameaça por impacto e probabilidade. Para cada ameaça aceita, nomeie um controle e, separadamente, um sinal de detecção, porque um controle cuja falha você não consegue observar é um controle no qual não pode confiar. Atribua um responsável e um ticket. Por fim, leve os sinais de detecção ao seu monitoramento para que o modelo produza alertas, e não apenas documentos. Repita todo o ciclo sempre que o mapa de fronteiras mudar.

FAQ: O STRIDE ainda é relevante para sistemas cloud-native e de microsserviços?#

Sim, provavelmente mais do que nunca. Arquiteturas de microsserviços multiplicam as fronteiras de confiança porque cada chamada entre serviços é um cruzamento potencial, e o STRIDE lhe dá uma forma consistente de raciocinar sobre cada uma. O framework é agnóstico ao transporte: seja uma fronteira cruzada por uma chamada HTTP, uma mensagem numa fila ou um fluxo gRPC, valem as mesmas seis perguntas. O que muda em ambientes cloud-native é o volume de fronteiras, o que é um argumento para automatizar partes do processo, como gerar um diagrama de fluxo de dados base a partir de metadados de serviço.

FAQ: Em que o STRIDE difere de árvores de ataque ou da kill chain?#

O STRIDE é um framework de categorização que ajuda a enumerar ameaças de forma abrangente contra um modelo de sistema; ele responde ao que pode dar errado. Árvores de ataque decompõem um único objetivo do atacante em passos e são melhores para a profundidade de um alvo específico. A cyber kill chain e o MITRE ATT&CK descrevem o comportamento do adversário ao longo de uma campanha e são melhores para organizar a engenharia de detecção. Eles se complementam: use o STRIDE no design para encontrar as ameaças, o ATT&CK na operação para organizar como você detecta as técnicas que as realizam e árvores de ataque quando precisar raciocinar em profundidade sobre um alvo de alto valor.

Conclusão#

O STRIDE perdura porque é simples o bastante para ser conduzido numa sala e rigoroso o bastante para mudar o que você constrói e monitora. Sua força vem do mapeamento entre cada categoria de ameaça e tanto um controle quanto um sinal de detecção, o que transforma um exercício abstrato de modelagem em trabalho concreto de blue team. Modele o sistema realmente implantado, concentre-se nas fronteiras de confiança que carregam identidade e autorização e insista em que cada ameaça aceita produza algo observável. Feita assim, a modelagem de ameaças deixa de ser um ritual de conformidade e se torna o mecanismo pelo qual suas defesas acompanham o modo como seu sistema é de fato construído.