O que é Security Threat Modeling? – Uma introdução

Security Threat Modeling (abreviado: STM) é, como a tradução do nome sugere, uma análise de ameaças relacionadas com segurança de IT para um sistema, uma aplicação, uma interface, um modelo operacional (Cloud vs. OnPrem), etc. Este tipo de análise de ameaças não se limita a sistemas de IT, mas é sempre importante quando empresas e organizações trabalham com ativos que precisam de ser protegidos.

Um exemplo simples fora do mundo de IT: Se um proprietário instalou um detetor de fumo na sua sala de estar, que deve fazer soar um alarme com a produção de fumo, o proprietário "analisou" a ameaça de inalação de fumo de um incêndio e "mitigou" esta ameaça com o detetor de fumo.

Aplicado ao mundo da tecnologia da informação, significa que possíveis ameaças a um sistema de IT são analisadas e mitigadas. Isto é melhor ser feito antes do desenvolvimento do sistema. No nosso exemplo com a produção de fumo ou o incêndio na habitação, por exemplo, ao construir a habitação, ter em atenção materiais difíceis de inflamar, uma possível "mitigação".

Também constatamos: Uma análise de ameaças deve ser uma parte central do processo de desenvolvimento de software para que as ameaças identificadas possam ser tratadas durante a "construção" do sistema.

PORQUÊ A SECURITY THREAT MODELING?

Se continuarmos com nosso exemplo de habitação: As decisões tomadas antecipadamente podem ter um impacto significativo na segurança do imóvel. Claro que pode (e deve) ainda instalar detetores de fumo, mas não seria melhor se usasse materiais de construção difíceis de inflamar desde o início?

Uma análise de ameaças pode evitar decisões de arquitetura de IT desfavoráveis ou incorretas, mesmo antes de uma linha de código ser criada. Além disso, uma análise de ameaças pode ser útil para compreender e complementar os requisitos de segurança do sistema.

Um exemplo do mundo de IT: Os dados têm de ser codificados? Talvez não necessariamente num servidor, mas mais provavelmente quando são usados num dispositivo móvel. Como podemos ver, existe uma estreita dependência entre o cenário de ameaça, as medidas prevenção (mitigação) e os requisitos do sistema. Ao considerar os requisitos (de segurança) no início do projeto de solução, pode ser fornecido um sistema muito mais seguro.

COMO EXECUTAR A SECURITY THREAT MODELING NA PRÁTICA?

Simplificando, a Security Threat Modeling não é nada mais do que a consideração antecipada do que pode acontecer e onde, em relação à segurança de IT e a definição correspondente de uma estratégia de proteção baseada nesse ponto, com o objetivo de evitar o pior cenário. Para tal, as seguintes questões devem ser respondidas:

1. O que está a ser desenvolvido?
2. O que pode acontecer?
3. O que pode ser feito a esse respeito?
4. Como é avaliada a situação geral?
5. Como foi a qualidade da análise?
   
   

Cada uma destas cinco perguntas deve ser vista como um passo do processo de análise de ameaças.

PASSO 1: O QUE ESTÁ A SER DESENVOLVIDO?

Uma maneira comum de descrever um sistema de IT é através de diagramas técnicos. Os diagramas de fluxo de dados são ideais para o nosso contexto. Todas as interfaces e fluxos de dados são visualizados nesse diagrama. Porque apenas onde os dados estão disponíveis e/ou "fluem" é que surgem ameaças. Como exemplo, vejamos uma aplicação Web "típica":

A nossa aplicação é operada num centro de dados e é composta por um proxy, uma aplicação Web e uma base de dados. É claro que cada aplicação Web também tem pelo menos um ator, ou seja, o utilizador, que tem acesso ao proxy e, portanto, à aplicação Web e à base de dados através da Internet.

Além do arquiteto responsável, um ou mais programadores e administradores de sistema devem sempre ser consultados ao criar o diagrama de fluxo de dados. Esta é a única forma de criar um diagrama no final deste passo que esteja correto na opinião de todos os envolvidos – e um diagrama correto é de importância fundamental para o processo posterior de Security Threat Modeling.

PASSO 2: O QUE PODE ACONTECER?

Após a criação do diagrama de fluxo de dados do sistema, o próximo passo é pensar no que pode acontecer. É útil fazer aqui suposições para limitar quaisquer cenários de ameaça.

Exemplo: Observando o exemplo do sistema do passo 1, presumir que um sistema operacional atualizado está a ser utilizado pode descartar algumas ameaças à partida. Mas atenção: Tais suposições também devem ser sempre verificadas e tidas em consideração na análise de ameaças.

Algumas perguntas sobre "o que pode acontecer" são óbvias:

• O servidor Web é realmente quem diz ser?
• Os dados entre o proxy e a aplicação Web podem ser manipulados?
• Como é que a aplicação Web garante que a base de dados recebeu os dados?
• Através da aplicação Web, o utilizador também pode ver a arquitetura por detrás dela?
• A aplicação Web (ou a base de dados) pode ser derrubada por carga elevada?
• Um utilizador pode fazer coisas relacionadas com a aplicação Web para as quais não está autorizado?

Claro, esta lista pode ser continuada quase indefinidamente. Assim, coisas importantes podem ser rapidamente ignoradas. Desta forma, deve ser usada uma metodologia nestas questões. Aqui contamos com o chamado método STRIDE, desenvolvido pela Microsoft. STRIDE significa:

• S: Spoofing
• T: Tampering
• R: Repudiation
• I: Information Disclosure
• D: Denial of Service
• E: Elevation of Privilege
  
  

Com este método, podemos categorizar as nossas perguntas "O que pode acontecer?" e reduzir o risco de algo ser ignorado através de uma abordagem estruturada. Estritamente falando, cada questão listada acima como exemplo pode ser atribuída a estas categorias.

PASSO 3: O QUE PODE SER FEITO A ESSE RESPEITO?

No final da pergunta "O que pode acontecer?", deve haver uma lista de ameaças a cada interação e dados listados no diagrama de fluxo de dados. No próximo passo, analisaremos a lista e abordaremos as ameaças encontradas. Isto pode ser feito de quatro formas diferentes:

Mitigação significa tomar medidas para mitigar uma ameaça ou dificultar a exploração de uma ameaça.

Exemplo: As palavras-passe para uma interface administrativa mitigam a ameaça de alguém se passar por administrador.

A eliminação é muitas vezes alcançada pela rejeição de funcionalidades.

Exemplo: Pode-se proteger a interface administrativa com palavras-passe, mas a ameaça de alguém passar-se por administrador ainda está lá. A desativação da interface administrativa faria com que esta ameaça desaparecesse.

A transferência é alcançada transferindo a ameaça para outra pessoa.

Exemplo: Pode-se deixar a autenticação da interface administrativa para um Serviço do Active Directory.

A aceitação ocorre quando decide não fazer nada sobre uma ameaça identificada. Isto pode ter razões diferentes e também bastante válidas. Estas são muitas vezes decisões de custo-benefício.

Agora, existe uma lista de ameaças e diferentes estratégias para lidar com estas ameaças. No próximo passo, as mitigações devem ser avaliadas e organizadas por prioridade. As mitigações selecionadas são incluídas no processo de desenvolvimento de software. Para tal, pode-se utilizar, por exemplo, histórias de utilizadores ou simplesmente bugs.

Exemplo: Um hacker pode levar a base de dados a uma falha com muitas solicitações automatizadas.

No final desta atividade, provavelmente haverá muitas tarefas que precisam de ser implementadas. Mas antes da implementação, avaliamos todas as ameaças e medidas para realizar uma análise de custo-benefício.

PASSO 4: COMO É AVALIADA A SITUAÇÃO GERAL?

Após as duas atividades anteriores, foram identificadas muitas ameaças e possíveis contramedidas. O próximo passo é organizar por prioridade estas ameaças e contramedidas. Para tal, o chamado risco de ameaça é determinado para cada ameaça.

Uma maneira de determinar o risco de ameaça ocorre através da seguinte fórmula:

Risco de ameaça = probabilidade de ocorrência X impacto

Existem diferentes abordagens para avaliar estes riscos de ameaças, por exemplo: Microsoft Bug Bar ou CVSS (Common Vulnerability Scoring System).

Nas grandes empresas, isto geralmente também é registado nas Políticas de Segurança da empresa. Para simplificar, a probabilidade de ocorrência e o impacto podem ser classificados em quatro categorias comuns de avaliação de risco: muito alto, alto, médio e baixo.

Há muitas formas diferentes de avaliar a ameaça. No primeiro passo, é importante utilizar uma abordagem coordenada para avaliar as ameaças, que é aplicada de forma permanente e consistente.

Depois de todas as ameaças sem contramedidas serem avaliadas, deve-se reavaliar estas ameaças com contramedidas. No entanto, o último passo ocorre para fins de documentação e é útil para compreender as decisões posteriormente.

PASSO 5: COMO FOI A QUALIDADE DA ANÁLISE?

O último passo na Security Threat Modeling é a avaliação da qualidade da análise de ameaças.

Verificação da arquitetura

Primeiro, devemos voltar ao diagrama de fluxo de dados e verificar se ainda está correto. Não é incomum que as decisões arquitetónicas sejam alteradas a curto prazo: As funções são adicionadas, os casos de utilização não considerados anteriormente trazem outros conjuntos de dados com eles, as interações entre os sistemas mudam. Portanto, o diagrama do fluxo de dados deve ser atualizado ou complementado.

Verificação de ameaças

É claro que novas ameaças resultantes de uma arquitetura alterada devem ser identificadas. Depois disso, todas as ameaças identificadas devem ser verificadas novamente no que diz respeito à sua mitigação. Para tal, precisamos de percorrer novamente a lista de ameaças e fazer as seguintes perguntas: Todas as ameaças foram abordadas? Todas as ameaças foram devidamente mitigadas?

Testes para as medidas

Devem ser realizados testes para todas as medidas. Estes podem ser executados de forma manual ou automática. Deve ser assegurado que todas as medidas a serem implementadas também tenham a qualidade assegurada. Idealmente, estes testes devem ser integrados numa estrutura de teste existente durante o desenvolvimento.

CONCLUSÃO

É claro que a Security Threat Modeling "real" é muito mais detalhada e complexa do que o processo aqui descrito. No entanto, deve ficar claro o quão importante é integrar a segurança conceitualmente no processo de desenvolvimento e atualizá-la em intervalos regulares – por exemplo, ao desenvolver novas funcionalidades ou alterar o modelo operacional.

O método de análise mostrado aqui, com as suas considerações de mitigação e custo-benefício, garante mais segurança desde o início.