Neste artigo será abordado o tema modelagem de ameaças em segurança de aplicações, segundo o Modelo de Maturidade de Segurança de Software conhecido pelo acrônimo SAMM. Ele faz parte de uma série de artigos publicados com base no projeto SAMM da OWASP. Sendo mais específico, trata do fluxo “Threat Modeling”, na prática “Threat Assessment”, referente a área de negócio Design.
Você também pode ouvir esse conteúdo:
Modelagem de ameaças: um pouco de história
A modelagem de ameaças tem origens que remontam às estratégias de guerras, com a previsão de possíveis ataques do inimigo para melhor posicionamento das frentes de defesa.
Em software, podemos citar alguns acontecimentos históricos importantes como:
- O uso em tecnologia data do início dos anos de 1960 em artigos científicos;
- Em 1977, Christopher Alexander apresentou a primeira metodologia;
- Em 1988 Robert Barnard desenvolveu e aplicou com sucesso um modelo de ataque baseado em perfil;
- Em 1994 Edward Amoroso apresenta um modelo visual chamado árvore de ataque;
- Em 1998 Bruce Schneier apresenta um trabalho sobre árvore de ataques;
- Em 1999 Loren Kohnfelder e Praerit Garg da Microsoft apresentam o modelo STRIDE.
A adoção da prática pela Microsoft com a metodologia STRIDE foi o que tornou a modelagem de ameaças popular na área de tecnologia da informação.
Mas o que é a modelagem de ameaças? Como e quem deve utilizá-la? Quais as vantagens do uso da técnica? Isso é o que veremos a seguir.
O que é modelagem de ameaças?
Conforme indica Howard e Lipner (2006), o processo de modelagem de ameaças parte do princípio da necessidade de se compreender todo o cenário da aplicação, de modo a visualizar possíveis brechas que possam comprometer a segurança dos ativos, violando suas restrições de segurança.
Vejamos a definição do NIST (Em tradução livre):
“Uma forma de avaliação de risco que simula aspectos do ataque e da defesa de uma entidade lógica, como um componente de dados, uma aplicação, um host, um sistema ou um ambiente”.
NIST SP 800-53 Rev. 5(2022)
Para compreender o processo de modelagem de ameaças é necessário revisar alguns termos como:
Ameaça: consiste em um evento com potencial de causar danos em uma organização e/ou aplicação.
Agente de ameaça: é o autor que intencionalmente ou não, explora uma vulnerabilidade que coloca em risco dados confidenciais da arquitetura alvo.
Uma possível ameaça existe quando a probabilidade combinada da ocorrência da ameaça e o impacto que ela teria na organização criam um risco significativo.[1] Então, a partir do processo de levantamento de ameaças, é possível planejar e inserir controles de segurança de prevenção, detecção e respostas às ameaças identificadas, testando sua eficiência durante todo o ciclo de vida do software.
Como e quem deve utilizar a modelagem de ameaças?
A modelagem de ameaças deve ser realizada para cada projeto que se deseja construir e deve ser continuamente utilizada ao longo do desenvolvimento de software.
A primeira fase do processo consiste em coletar informações. Quanto mais informações que afetam a segurança possuir, melhor será a modelagem. Caso seja interessante, deve ser feito um desenho da solução, uma modelagem do sistema para um melhor entendimento.
É fortemente indicado que se desenhe um diagrama de fluxo de dados antes que se faça a modelagem de ameaças, pois isso ajudará na avaliação da probabilidade e do potencial de impacto de possíveis ameaças que serão identificadas.
E para identificar as possíveis ameaças e ajudar na organização da modelagem, pode-se empregar quatro perguntas:
- Em que estamos trabalhando?
- O que pode dar errado?
- O que você irá fazer a respeito disso?
- Fizemos um bom trabalho? [1]
A modelagem de ameaças é feita em conjunto com os PO (Product Owners), arquitetos, pessoal de segurança e testers. Pois, em uma modelagem, todos os envolvidos devem trabalhar unidos para aumentar a conscientização e, caso não haja, iniciar a cultura AppSec dentro da empresa, criando uma visão compartilhada sobre a segurança do sistema.
A Figura 1 mostra um exemplo genérico de arquitetura de sistemas do ponto de vista de diferentes partes interessadas [2]. Nela serão identificados os prováveis cenários de pior caso para o software em desenvolvimento em cada equipe do projeto.
Fonte:IEEE Software 12
Quais as vantagens do uso da técnica?
Essa técnica viabiliza o domínio maior do esforço desprendido para segurança, fazendo com que se defina com mais clareza as possíveis ameaças, baseando-se em dados mais concretos e realistas. Com isso, são produzidos argumentos mais convincentes para defender a segurança de uma aplicação.
Uma outra vantagem é a comunicação homogênea referente às questões de segurança, e o risco da aplicação para todos os envolvidos no processo de desenvolvimento.
Agora que sabemos do que se tratam o contexto e as vantagens, vamos entender a visão da modelagem de ameaças de acordo com o SAMM.
Modelagem de ameaças em segurança de aplicações segundo o SAMM
Para o SAMM, a modelagem de ameaças é uma atividade estruturada, utilizada para identificar, avaliar e gerenciar as ameaças do sistema, além de verificar deficiências da arquitetura do projeto para reduzi-las de acordo com as recomendações de segurança.
Esse procedimento auxilia na gestão de riscos e na conscientização das etapas do desenvolvimento seguro, visto que torna simples a tradução de aspectos técnicos dos sistemas e processos que são analisados.
Para o desenvolvimento de aplicações seguras, a modelagem de ameaças é essencial, pois permite que a empresa economize tempo e recursos, direcionando seus esforços para tratar riscos reais e/ou críticos e reduzindo atritos entre os times de desenvolvimento e segurança. Se estamos aplicando segurança desde o começo do ciclo de desenvolvimento, então estamos aplicando o Shift-Left ( termo muito popular no âmbito da Segurança de Aplicações).
Por ser baseada em um modelo de maturidade, a modelagem de ameaças é executada de maneira diferente em cada nível. Iniciando de forma simples até se tornar mais complexa conforme a organização ganha experiência.
Nível de maturidade 1 – A modelagem de ameaças é utilizada para identificar e gerenciar falhas de projeto
Como primeiro nível de maturidade, é esperado que a modelagem seja feita para aplicações de alto risco, utilizando listas simples de ameaças/riscos, que atendam a demandas específicas.
Aqui a modelagem deve ser iterativa, ou seja, a medida que novas funcionalidades são adicionadas na aplicação, será examinado somente o que foi modificado ou inserido ao invés de toda aplicação.
Os resultados das discussões devem ser registrados para serem revisitados e modificados, sendo assim as listas e diagramas podem virar templates (modelos). Afinal, neste nível o objetivo é a conscientização da segurança resultando em um processo acordado com o todo time.
Nível de maturidade 2 – Usa uma metodologia padrão, alinhada com seus níveis de risco de aplicação
Já para o segundo nível de maturidade é esperado o uso padronizado de uma metodologia que suporte a realização da modelagem de ameaças em escala, alinhada com os níveis de risco das aplicações.
A metodologia precisa no mínimo incluir: diagramação, identificação de ameaças, mitigação de falhas de projeto e como validar seus artefatos a fim de prover o entendimento claro do ambiente e da engenharia da aplicação. Neste ponto, além de utilizar listas de verificação de ameaças, como o STRIDE, utiliza-se também lista de ameaças específicas do contexto do negócio; somando controles de remediação no intuito de suportar os envolvidos a lidar com as ameaças específicas. Bem como um processo de gerenciamento das falhas.
Os resultados da modelagem devem estar registrados nas ferramentas utilizadas pelos times de desenvolvimento.
É necessário certo conhecimento e experiência para o uso correto da prática de modelagem de ameaças. Isso reflete em base de conhecimento e treinamentos para os arquitetos, security champions e outras partes interessadas. Essa compreensão não cabe automatizar, por isso reforça-se o investimento em pessoas.
Além disso, não seria um modelo de maturidade se não tivermos a definição de quando realizar a atualização desse modelo de ameaça. O gatilho pode ser a migração para um novo ambiente ou uma mudança tecnológica. No entanto, deve haver a recorrência da revisão.
Nível de maturidade 3 – Revisa e atualiza regularmente a metodologia de modelagem de ameaças para suas aplicações
O nível mais alto de maturidade de segurança é alcançado quando a modelagem de ameaças faz parte da cultura da empresa, ou seja, quando existe integração com o ciclo de desenvolvimento das aplicações e o foco passa a ser a otimização da metodologia.
Com base nos modelos de ameaças da organização, são criados e melhorados os padrões de risco reutilizáveis, que compreendem bibliotecas de ameaças, falhas de projeto e mitigações de segurança. Para aperfeiçoar a metodologia, são utilizadas as lições aprendidas e são revisadas as categorias de ameaças relevantes, mantendo de forma regular (anual, por exemplo) a atualização dos modelos para ter certeza de que uma nova ameaça não está presente nas aplicações.
Então, neste ponto, a automatização faz parte do processo de modelagem de ameaças com integração de ferramentas de segurança. Exemplo: ferramentas de verificação de segurança e ferramentas de rastreamento de risco.
Agora, como ferramenta para segurança de aplicação por meio da identificação de requisitos de segurança de modo consistente, escalável e inteligente, podemos citar um dos nossos cinco produtos da Conviso Platform, o Secure by Design que protege suas aplicações apoiando na modelagem de ameaças.
Um pouco mais sobre Modelagem de Ameaças em Segurança de Aplicações
Processo de modelagem de ameaças
Processo de desenvolvimento de segurança da Microsoft
Modelagem de Ameaças da Microsoft
O que podemos concluir?
Conforme define NIST (2013), uma ameaça é qualquer evento que possui o potencial de impactar adversamente as operações, ativos ou indivíduos de uma organização através de acesso não autorizado, destruição ou modificação de informações. A modelagem de ameaças parte do princípio que para proteger adequadamente um sistema ou processo é necessário compreender bem contra o que ou quem se deseja defender. Conforme defende a OWASP, este processo é essencial no início da concepção de um sistema, pois permite economizar dinheiro, tempo e recursos ao direcionar os esforços de segurança para tratar riscos reais sem desperdiçar recursos com abordagens genéricas, além de permitir revisar aspectos de arquitetura e projeto. Sendo assim, o processo de modelagem de ameaças deve sempre ser levado em consideração durante a idealização de sistemas críticos.
Referências
[1] Drake,Victoria. Modelagem de Ameaças. Owasp.org, 2022
[2] Kruchten, Philippe . Architectural Blueprints —The “4+1” View – Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
[3] OWASP. Threat Modeling Cheat Sheet. 2021
Autores:
Evandro Pinheiro – Analista de Segurança da Informação
Luciene Oliveira – Analista de Segurança da Informação
Luiz Henrique Custódio – Analista de Segurança de Aplicação
Série artigos SAMM
- Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
- Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
- Governança segundo SAMM: Educação e Orientação em Segurança de Aplicações
- Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
- Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
- Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
- Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
- Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
- Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
- Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Ambientes em Segurança de Aplicações
- Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações
