Economize dinheiro escovando os dentes – desvendando a Modelagem de Ameaças – parte 1 de 3.

A modelagem de ameaças é um processo cíclico para evitar problemas de segurança futuros. Assim como escovar os dentes, que previne cáries, tártaro ou cálculo dentário, a modelagem de ameaças deve ser um processo diário, implementada no ciclo de vida de desenvolvimento de software para prevenir incidentes promovidos por ameaças cibernéticas e economizar dinheiro que seriam endereçados para isso.

Esse é o primeiro de uma série de 3 artigos falando sobre Modelagem de Ameaças, em que será destrinchado o processo, explicando seu objetivo, importância, o passo-a-passo para a criação de uma modelagem bem como os requisitos e controles de segurança associados às ameaças. Os artigos serão divididos nos seguintes temas:

1. Introdução, motivação e teoria da modelagem de ameaças.
2. Aplicando modelagem de ameaças com viés ofensivo na prática e elaborando controles e requisitos de segurança.
3. Como testar os requisitos e controles propostos para garantir que a aplicação está segura.

1. Introdução

Modelagem de Ameaças é um processo no desenvolvimento de software em que é realizada uma representação da aplicação proposta, desde o mapeamento dos ativos, estruturação e entendimento de todo o fluxo de dados desde o momento em que os dados entram, como são processados e como são armazenados ou devolvidos. O objetivo da modelagem de ameaças é planejar e elaborar táticas para analisar e garantir a segurança de uma aplicação de modo geral. 

Com o mapeamento dos ativos, que incluem softwares, aplicativos, sistemas, redes, sistemas distribuídos, aplicativos móveis e dispositivos de Internet das Coisas (IoT), e o entendimento de como o fluxo trafega, é possível identificar e apontar potenciais vulnerabilidades e mitigá-las, assim a modelagem de ameaças  deixa claro como essas vulnerabilidades poderiam existir na aplicação que foi desenhada.

Segundo Threat Modeling Manifest, “A modelagem de ameaças analisa representações de um sistema para destacar preocupações sobre características de segurança e privacidade”, da mesma forma, de acordo com a OWASP, podem ser realizadas 4 perguntas que ajudam a planejar e organizar todas as ações em uma modelagem de ameaça.

1. No que estamos trabalhando?
2. Qual é a probabilidade de dar errado?
3. O que pode ser feito sobre isso?
4. O trabalho foi bom o suficiente?

2. Por que fazer uma modelagem?

De acordo com o Relatório de Custo de uma Violação de Dados de 2024 da IBM, o custo médio incorrido por uma organização devido a uma violação causada por uma ameaça cibernética é de US$ 4,88 milhões. A IBM também lista os vetores de ataque iniciais mais frequentes, conforme mostrado na Figura 1.

Entre esses vetores iniciais apresentados, todos poderiam ser abordados em um processo de modelagem de ameaças para implementar controles que impeçam tais ataques. Obviamente, nem sempre é simples criar controles para esses vetores, especialmente aqueles que envolvem fatores humanos como Phishing e Credenciais Roubadas ou Comprometidas, ou mesmo Vulnerabilidades Desconhecidas (zero-day). No entanto, alguns destes vetores que fossem endereçados através de controles de segurança previstos em um processo abrangente de modelagem de ameaças, seriam prevenidos e isso evitaria que o risco se materializasse.
Por exemplo, considere o vetor inicial “configuração incorreta da nuvem”, com um custo médio de US$ 3,98 milhões. De acordo com a CheckPoint, alguns exemplos de configurações de segurança incorretas incluem:

• Contas e senhas padrão
• Ativos publicamente acessíveis
• Acesso excessivo
• Recursos desnecessários ativados
• Armazenamento não criptografado
• Atualizações e patches ausentes

Cada um desses itens estaria presente em um processo abrangente de modelagem de ameaças, que posteriormente produziria um documento de requisitos de segurança para abordar essas vulnerabilidades potenciais. Esses requisitos seriam descritos como parte do desenvolvimento, garantindo que os itens só sejam implantados no ambiente de produção se os controles forem implementados.

3. Aplicação da Modelagem de Ameaças

A modelagem de ameaças deve ser incluída no ciclo de desenvolvimento de software para auxiliar a redução nos riscos da organização e garantir a segurança no desenvolvimento. Geralmente o ciclo de vida de um software é dividido em 6 etapas (Planejamento, Análise, Projeto, Desenvolvimento, Testes & Integração, Manutenção), conforme destacado na Figura 2:

A modelagem de ameaças insere-se na etapa 3 – Design, logo após de elaborados os primeiros desenhos de arquitetura da aplicação. Nesta etapa, a modelagem identifica ativos e ameaças que, dependendo do contexto, podem ser corrigidos ainda em tempo de desenho, através de alterações na arquitetura ou pequenos complementos que permitem a inclusão de controles. A antecipação da identificação dos riscos facilita a implementação dos controles, uma vez que o desenvolvimento ainda não foi iniciado. Ainda é possível alterar a modelagem de ameaças durante outras etapas caso seja identificado posteriormente que há a necessidade de alteração na arquitetura, identificando se este novo adendo traz algum risco para a organização e atualizando o desenho da modelagem, bem como o documento de requisitos. 

A modelagem de ameaças é um processo iterativo. À medida que o sistema evolui ou novas ameaças surgem, é importante revisitar e atualizar o modelo de ameaças regularmente.

4. Pré-requisitos para a modelagem

Como base do processo de modelagem de ameaça são utilizados diagramas de arquitetura e casos de uso do projeto da aplicação. Todo documento da fase de desenho do projeto pode ser utilizado como insumo para o desenvolvimento do processo de modelagem de ameaças, como:

• Documentação de arquitetura: Informações sobre a arquitetura dos sistemas, incluindo diagramas, fluxos de dados, componentes e interfaces.
• Informações sobre ativos: ativos de valor que precisamos proteger, como dados sensíveis, propriedade intelectual, entre outros.
• Informações sobre lógica de negócio: lógica de negócio da aplicação contendo fluxos, validações, entradas e saídas prioritárias. 
• Informações complementares: Swagger das APIs, fluxo de dados (Figma), contexto da explicação, entre outras informações que possam ajudar no entendimento da aplicação. 

É recomendável conduzir agendas de entendimento antes do início do processo de uma modelagem de ameaças.

5. Padrões do Threat Modeling

Existem várias metodologias de modelagem de ameaças hoje em dia, cada uma seguindo um padrão conforme desejado. Pode-se dizer que não existe uma maneira única de realizá-la, ou seja, não existe um método universal. O ideal é sempre determinar quais possíveis ameaças podem existir em um determinado espaço analisado. Devemos, então, realizar um modelo que seja útil e eficaz, bem estruturado, tornando o processo mais eficiente e agradável.

Para que o processo de Threat Modeling seja útil e eficaz, devemos ter em mente como definir o escopo no qual será realizado o trabalho, identificar vulnerabilidades e possíveis ameaças existentes, Avaliação de riscos e ameaças, realizar a ação de contramedidas e a intervenção nas vulnerabilidades. Com esses pilares em mente, podemos de fato iniciar a modelagem de ameaças.

5.1. Limites de confiança (Trust Boundaries)

No processo de modelagem de ameaças os limites de confiança são estabelecidos para definir as superfícies de ataque dos ativos, onde as ameaças poderiam ser identificadas. O conceito de limite de confiança pode ser utilizado para identificar pontos em que fluxos de entrada e saída de dados podem esbarrar em controle de acesso. Dentro desses limites, os ativos possuem confiança entre si e, por conta da confiança, os controles de segurança poderiam ser menos robustos.

No cenário de confiança zero (Zero Trust), em que assume-se que qualquer outro ativo poderia ser comprometido, os limites de confiança deixam de existir e cada ativo deixa de confiar nos outros, exigindo sempre um controle de acesso ou algum controle de segurança específico para realização do fluxo de dados. Entretanto, mesmo neste cenário, existem diferentes níveis de confiança e o estabelecimento dos diferentes níveis de confiança no desenho de uma modelagem de ameaça facilita o entendimento do sistema e os níveis de ameaças possíveis, pois um recurso que esteja exposto para a internet pode estar vulnerável a ameaças diferentes do que um recurso em uma rede interna. Isso pode ser feito a partir de containers, que nada mais são do que estabelecimento de onde um ambiente termina e outro começa.

5.2. Agentes de ameaças ou possíveis vulnerabilidades?

De acordo com o NIST uma ameaça pode ser definida como “Qualquer circunstância ou evento com potencial de impactar negativamente as operações organizacionais, ativos organizacionais ou indivíduos através de um sistema de informação através de acesso não autorizado, destruição, divulgação, modificação de informações e/ou negação de serviço”; já agentes de ameaça podem ser definidos como “a intenção e o método direcionados à exploração intencional de uma vulnerabilidade ou de uma situação e método que possa desencadear acidentalmente uma vulnerabilidade“.

Algumas metodologias de modelagem de ameaças focam em mapear QUEM seria responsável por comprometer os ativos envolvidos, enquanto outras focam em definir O QUE seria possível explorar nos ativos, dadas as condições para o acontecimento. Na minha análise, ambos são importantes de se definir, mas o foco deve ser em O QUE, ou seja, no evento que pode acontecer com os ativos, para que os controles sejam mais facilmente mapeados. Por exemplo, em um cenário de rede interna em que credenciais são armazenadas em código-fonte, em vez de mapear que o agente de ameaça seria o desenvolvedor (colaborador interno) ou a conta dele comprometida, seria mais interessante focar que a ameaça é credenciais expostas no código. Assim, o controle é voltado para isso, que nesse caso seria utilizar um cofre de senhas.

6. Componentes de uma modelagem

6.1. Diagramas

Criar desenhos, como diagramas, ajuda a entender o fluxo de dados na rede. Para a criação do diagrama  abaixo é possível utilizar a plataforma gratuita Drawio.

6.2. Interação

Identificar pontos de entradas que um invasor possa utilizar ao seu favor para interagir com a aplicação. Podem ser representados por setas que demonstram interação entre componentes.

6.3. Ativos

Mapear e identificar os ativos no geral que possuem no projeto de modelagem de ameaça.

Isso inclui os seguintes ativos:

Físicos:

• Equipamentos de hardware (servidores, computadores, dispositivos móveis)
• Instalações físicas (escritórios, data centers)

Digitais:

• Softwares e aplicativos utilizados no projeto
• Dados e bases de dados críticos
• Documentos e arquivos importantes

Intangíveis:

• Propriedade intelectual (patentes, direitos autorais, marcas registradas)
• Conhecimentos e expertise da equipe

6.4. Confiança:

Um ponto importante é definir claramente os níveis de confiança ao conceder permissões de acesso ao aplicativo para usuários externos. É fundamental garantir que as permissões sejam atribuídas conforme o grau de confiança que a aplicação tem em cada usuário, para proteger a integridade e a segurança do sistema.

Diagramas de fluxo de dados são usados com bastante frequência para mapear o que estamos trabalhando e ajudam a detectar limites de privilégios, ativos e regras de confiança entre ativos. Esse processo de decompor a arquitetura auxilia bastante na hora de construir uma modelagem de ameaça.

7. Categorização das ameaças

Para categorização das ameaças, podem ser utilizadas várias metodologias e frameworks para ajudar a mapear possíveis riscos na modelagem. 

Abaixo são mostrados alguns modelos que podem ser utilizados em um projeto de modelagem de ameaça.

7.1. MITRE ATT&CK Framework

• Descrição: Um modelo de conhecimento amplamente utilizado para descrever as técnicas e táticas usadas por adversários. Inclui uma lista detalhada de técnicas, táticas e procedimentos (TTPs) que podem ser utilizados para categorizar ameaças.
• Uso: Ajuda a mapear atividades adversárias em diferentes fases de um ataque e entender o comportamento dos atacantes.

7.2. STRIDE model

• Descrição: Uma metodologia de modelagem de ameaças desenvolvida pela Microsoft. STRIDE é um acrônimo para Spoofing (Falsificação), Tampering (Manipulação), Repudiation (Repúdio), Information Disclosure (Divulgação de Informações), Denial of Service (Negação de Serviço), e Elevation of Privilege (Elevação de Privilégios).
• Uso: Auxilia na identificação e categorização de ameaças com base nos tipos de ataques existentes.

7.3. DREAD

• Descrição: Um modelo de classificação de ameaças utilizado para avaliar o risco associado a cada ameaça. DREAD é um acrônimo para Damage (Dano), Reproducibility (Reprodutibilidade), Exploitability (Exploração), Affected Users (Usuários Afetados) e Discoverability (Descobribilidade).
• Uso: Ajuda a priorizar ameaças com base em sua severidade e impacto potencial.

7.4. Common Vulnerability Scoring System (CVSS)

• Descrição: Um sistema de pontuação que avalia a gravidade das vulnerabilidades de segurança com base em métricas como a facilidade de exploração e o impacto potencial.
• Uso: Ajuda a categorizar e priorizar as potenciais vulnerabilidades de acordo com sua severidade e risco.

Cada uma dessas metodologias oferece uma perspectiva diferente é utilizável de forma complementar para uma análise de ameaças. Dependendo do contexto e dos objetivos a serem aplicados, pode-se optar por uma ou mais dessas abordagens para categorizar e gerenciar ameaças de forma eficiente. Segundo a OWASP, os frameworks mais utilizados no processo de modelagem de ameaças seria a metodologia STRIDE e killl chains incluindo MITRE ATT&CK.

O objetivo de utilizar esses frameworks é auxiliar na identificação e categorização de ameaças de possíveis invasores. Os trabalhos se entrelaçam, pois, ao combinar a etapa de mapeamento de ativos utilizando diagramas com as metodologias de detecção de ameaças, podemos identificar quais são os alvos potenciais para um atacante. Isso nos ajuda a entender a mentalidade do invasor, proteger dados sensíveis e defender a trindade da segurança: Confidencialidade, Integridade e Disponibilidade (CID).

Portanto, a utilização de frameworks para identificar e categorizar ameaças é importante para proteger dados e aplicações. Integrar o mapeamento de ativos com metodologias de detecção ajuda a antecipar e mitigar riscos e ataques, com o intuito de garantir a segurança da CID (Confidencialidade, Integridade e Disponibilidade).

8. Definição de controles e contramedidas

O processo de implementação de contramedidas no projeto é de suma importância, pois é fundamental proteger e assegurar as aplicações contra ameaças e riscos. O referido processo  ajuda a neutralizar vulnerabilidades identificadas, garantindo que falhas de segurança sejam devidamente corrigidas e que não possam ser exploradas por um atacante. A implementação de contramedidas inclui a integração de mecanismos que nos auxiliam na detecção de atividades suspeitas e possíveis ataques.

Segundo a OWASP, “a estratégia de mitigação de risco pode envolver a avaliação dessas ameaças a partir do impacto comercial que elas representam. Uma vez que o possível impacto é identificado, as opções para lidar com o risco incluem:

Aceitar: Nesse critério aceitar o risco significa que você decide não tomar nenhuma ação para mitigar ou eliminar.

• É muito importante registrar quem tomou a decisão de aceitar o risco. Isso garante que há um registro da responsabilidade associada

Eliminar: A eliminação do risco envolve a remoção de vulnerabilidades completamentes. Isso significa a remoção ou atualização de um software, serviços e etc.

Mitigar: A mitigação é uma forma de implementar medidas para reduzir o impacto ou a probabilidade de um risco, porém, ressaltamos que isso não elimina o risco, mas nesse caso o torna mais gerenciável.

Transferência:  Caso a organização não possua uma equipe especializada na área de segurança da informação, pode ser aceitável transferir o risco para uma seguradora, que pode cobrir as perdas relacionadas a incidentes de segurança, ou para um cliente que possui experiência na área. Isso significa que a responsabilidade de gerenciar e mitigar o risco é deslocada para uma entidade externa que tem a capacidade e os recursos necessários.

A implementação de contramedidas serve para gerenciar vulnerabilidades e entender os riscos, incluindo aceitar, eliminar, mitigar e transferir o risco, considerando fatores como a probabilidade de impactos e custos.

A decisão deve ser baseada em uma análise do impacto comercial (para a área de negócio) e deve ser medida a eficácia das soluções. 

9. Sendo a ameaça e Conclusão

É claro que dentistas entendem a necessidade de escovar os dentes, mas será que existe alguém que consiga identificar melhor do que ele quais dentes são vulneráveis? Se ao menos fosse possível pensar como uma bactéria, visualizando qual dente ela prefere causar cáries… No campo da segurança cibernética é possível fazer isso, se comportando como uma ameaça para antecipar ataques.

Como visto, a modelagem de ameaças é um exercício de criatividade e quanto mais o analista entender sobre os ataques cibernéticos, mais eficaz será sua a modelagem. Uma mentalidade ofensiva é extremamente relevante neste momento, pois ao visualizar um componente, um hacker imagina imediatamente os caminhos que um invasor pode utilizar para comprometer o sistema. Por exemplo, se uma aplicação envolve o uso de Spring Boot, alguém com experiência em ataques a este componente já saberia que endpoints do actuator críticos como heapdump e env nunca deveriam ser expostos, pois isso permitiria acesso a dados críticos, incluindo possíveis credenciais para outros sistemas. Alguém que nunca explorou tais vulnerabilidades pode pesquisar ataques comuns no Spring Boot, mas pode não compreender completamente a exploração, resultando em controles e requisitos de segurança incompletos.

Assim, a modelagem de ameaças dentro do ciclo de vida de desenvolvimento de software é uma parte crucial das organizações que levam a sério o risco cibernético, tornando-se uma parte essencial da engenharia de software.