Modelagem de ameaças com STRIDE e DREAD
Conheça as categorias de ameças definidas pela técnica STRIDE de modelagem de ameças e, na sequência, aprenda a medir a criticidade destas ameças usando a técnica DREAD.
A modelagem de ameças é uma prática arquitetural que usamos para identificar possíveis vulnerabilidades de segurança em uma plataforma: a partir desta prática (que deve nascer junto com a arquitetura) conseguimos pensar nas estratégias que devemos seguir para resolver ou mitigar estes riscos.
Há diversas abordagens que podem ser tomadas nesta prática, cada qual com suas vantagens e desvantagens. Dentre estas uma que gosto bastante, especialmente para os iniciantes é o STRIDE, que nos fornece uma categorização de ameaças que é muito útil na formação de pessoas que estejam iniciando sua carreira na área de desenvolvimento de software e, talvez mais importante: dos próprios stakeholders.
Este post não irá te ensinar a realizar uma modelagem de ameças: meu foco é te apresentar as categorias de ameaças que o STRIDE nos mostra.
Terminaremos o post falando sobre DREAD. Se o STRIDE nos permite categorizar ameaças, o DREAD nos dá a ferramenta que usaremos para medir a criticidade das ameaças encontradas.
A principal vulnerabilidade que encontro em todo sistema normalmente é a percepção da segurança. Não raro os stakeholders e equipe de desenvolvimento a vêem como uma feature e não como elemento arquitetural. Traduzindo: segurança (!!) não é algo que você adiciona a um sistema, mas sim uma característica que deve estar pulverizada em cada aspecto do seu design e construção.
E ao apresentar o STRIDE (há outras metodologias interessantes, leia esta comparação com PASTA, por exemplo) a importância do conceito de segurança normalmente cresce nas pessoas. Sendo assim, vamos lá?
STRIDE
O nome STRIDE é um acrônimo que representa as seis categorias de ameaças:
- Spoofing de identidade - um invasor se faz passar por outro usuário ou mesmo servidor/sistema.
- Tempering with data - alteração maliciosa de dados
- Repudiation - usuário nega que tenha executado determinada ação no sistema
- Information disclosure - Vazamento de informações confidenciais a usuários não autorizados
- Deny of service - Negação de serviço
- Elevation of privilege - Elevação de privilégios
A maior parte deste livro hoje está obsoleta, mas os capítulos sobre STRIDE e DREAD ainda são muito relevantes.
Categorizando as ameaças
Spoofing de identidade
Um usuário se passar por outro usuário ou sistema. É comum quando, por exemplo, ocorre o vazamento de credenciais de acesso ou quando o invasor instala na rede do alvo um serviço que se faz passar por outro, obtendo com isto as informações fornecidas pelos usuários da plataforma.
Este segundo tipo de manifestação ocorre bastante com a produção de sites falsos de instituições bancárias. A vítima recebe um e-mail contendo um link para acesso ao site da instituição: ao acessá-lo, se depara com um site que possui a mesma aparência com a qual se encontra habituado e, neste momento, fornece suas credenciais ao atacante crendo estar, na realidade, as fornecendo ao banco.
Há diversas ações que podem ser adotadas para se minimizar este risco como, por exemplo, a adoção de certificados digitais, autenticação de dois fatores e, talvez o mais importante: a educação de usuários ou mesmo políticas de invalidação esporádica de senhas dos usuários, forçando-os a atualizarem-nas de tempos em tempos.
Vou até além: diz respeito também a uma das categorias que veremos adiante, o da não repudiabilidade.
Tempering with data - alteração mal intencionada de dados
O invasor altera informações usadas pelo sistema e, com isto manipula o comportamento esperado pelo mesmo. É comum quando o acesso aos dados geridos pela plataforma encontram-se acessíveis a usuários que não deveriam possuir de forma alguma acesso a estas informações.
Uma situação bastante comum ocorre quando, por exemplo, um usuário final do sistema possui credenciais de acesso ao banco de dados manipulado pelo sistema e, com base nestas credenciais, altera informações presentes em sistemas como folha de pagamento ou registro de ponto.
Há uma grande gama de ações que podem ser tomadas visando mitigar esta ameaça: adoção de assinaturas digitais, algoritmos de hashing, registros de data e hora ou mesmo trilhas de auditoria.
Repudiation - repúdio - "prova que eu fiz isto!"
O usuário nega que tenha executado alguma ação no sistema que tenha resultado em alteração de dados ou acarretado qualquer outra consequência.
Um funcionário mal intencionado afirma, por exemplo, que sua apropriação de horas está incorreta por ter feito o registro e o mesmo não ter sido persistido no banco de dados, ou mesmo afirma não ter feito acesso a determinado conjunto de informações.
A ação de não repúdio consiste, portanto, em se possuir nas plataformas desenvolvidas mecanismos de registro e confirmações de ações realizadas pelos usuários, o que pode ser feito através da implementação de mecanismos de logging ou mesmo telas nas quais o usuário precise confirmar suas ações.
Este link ( https://learn.microsoft.com/en-us/compliance/assurance/assurance-audit-logging ) no site da Microsoft é interessante sobre logs de auditoria.
Se houver duas fontes que possam confirmar o mesmo fato, melhor ainda. Por exemplo: logs da plataforma e registro de eventos em algum outro sistema externo.
Para ações que podem prejudicar outros usuários da plataforma, recomendo que seja registrado o consentimento do usuário antes da execução da ação: o famoso "tem certeza MESMO que deseja fazer isto???"
Information disclosure - vazamento de informações
Um usuário acessa informações que não lhe dizem respeito e as distribuí fora do ambiente no qual as mesmas se encontram expondo a outras pessoas dados confidenciais, o que pode colocar em risco a integridade não só do sistema, mas também de outras pessoas envolvidas.
Trata-se de uma categoria de ameaças que envolve práticas de engenharia social e até mesmo de outras categorias, tais como spoofing de identidade, alteração maliciosa de dados, etc.
Diversas ações podem ser tomadas visando-se mitigar este problema, tais como não armazenar segredos, criptografia ou protocolos de privacidade aprimorados além de, claro medidas legais que visem coagir invasores através da aplicação da lei local.
Deny of Service (DoS) - Negação de serviço
O ataque de negação de serviço consiste em tornar indisponíveis os serviços prestados pela plataforma computacional através da sua sobrecarga ou mesmo ocultação.
Trata-se de um dos ataques mais comuns e está diretamente ligado à questões envolvendo o projeto de alta disponibilidade e escalabilidade da aplicação. O atacante normalmente executa sua ação através da sobrecarga dos servidores que irão estar ocupados apenas com as requisições feitas pelo atacante, e não as realizadas pelos usuários finais do sistema.
No caso de um ataque do tipo DoS as ações a serem tomadas visando-se mitigar o problema consistem em configurações de acesso por firewall, isolamento dos servidores ou mesmo uma arquitetura de alta disponibilidade e escalabilidade.
Pense aqui em sistemas críticos que cuidam da saúde dos seus usuários como, por exemplo, sistemas de controle aéreo ou mesmo aquele que gerencia os sistemas de segurança no seu carro.
Elevation of privilege - elevação de privilégios
Ocorre quando os privilégios de um usuário são acidentalmente (ou não) ampliados, lhe fornecendo acesso a informações ou funcionalidades da plataforma às quais não deveria ter acesso inicialmente.
É comum ocorrer quando altera-se de forma incorreta as permissões de um usuário,o que lhe fornece acesso a informações que não deveria ter acesso.
As soluções para esta categoria de ataque são variadas, desde políticas que sempre forneçam inicialmente aos usuários privilégios mínimos à plataforma, até mesmo um reset esporádico de permissões.
Na minha experiência em sistemas corporativos esta é uma das principais falhas de segurança: sabe aquele back office no qual TODO MUNDO tem permissão de administrador? Então...
DREAD - medindo o risco de vulnerabilidades
Agora que você já sabe quais são as seis categorias de ameças apresentadas pelo STRIDE, como você mensura o risco de uma falha de segurança? Uma resposta é o DREAD, que nos fornece um indicador de risco que pode ser usado para priorizarmos as vulnerabilidades encontradas.
Não recomendo que você se baseie apenas nos números que ele te fornece: sempre leve em consideração o contexto, ok?
DREAD, assim como STRIDE, é um acrônimo que representa cinco elementos usados na medição da criticidade da ameaça, cada qual definindo-se valores em uma escala que vai de 0 a 10. O cálculo do risco é simples e direto: soma-se as notas dadas a cada uma das categorias do DREAD e, em seguida, divide-se por 5.
Vamos então pra sopa de letrinhas?
Dano potencial / Damage Potential
Mede-se a extensão do sistema afetada pela vulnerabilidade. Um problema no mecanismo de autenticação, por exemplo, que é usado por todos os usuários e áreas do sistema, possui valor 10, enquanto uma entrada maliciosa em um único formulário, 1.
Reproduzibilidade / Reproducibility
Quão fácil é a reprodução da vulnerabilidade encontrada. Se sempre para determinados tipos de entrada o problema se realiza, podemos fornecer a nota 10 a este atributo, caso o problema só ocorra de acordo com a hora do dia em conjunto com outros aspectos, a reprodução do problema torna-se mais difícil e, portanto, sua nota é reduzida a, por exemplo, 2.
Explorabilidade / Exploitability
Qual o nível de conhecimento técnico necessário por parte do atacante para se executar o ataque? Se forem necessários apenas conhecimentos básicos de computação, ou seja, qualquer um pode explorar a vulnerabilidade, define-se uma nota alta para a mesma, digamos neste caso, 10.
Caso seja necessário conhecimentos profundos de computação, tal como ocorre, por exemplo, ao se explorar injeções por estouro de buffer ou tirando-se proveito de aspectos muito pouco conhecidos do sistema, esta nota tende a baixar para valores próximos de zero.
Usuários afetados / Affected users
Indica qual porcentagem de usuários afetados pela exploração da vulnerabilidade. Neste caso a definição do índice costuma ser a mais fácil:
- 0 a 10% dos usuários - nota 1
- 11 a 20% dos usuários - nota 2
- 21 a 30% dos usuários - nota 3
- 31 a 40% dos usuários - nota 4
- 41 a 50% dos usuários - nota 5
- 51 a 60% dos usuários - nota 6
- 61 a 70% dos usuários - nota 7
- 71 a 80% dos usuários - nota 8
- 81 a 90% dos usuários - nota 9
- 91 a 100% dos usuários - nota 10
Possibilidade de ser descoberto / Discoverability
Na minha opinião, o ponto mais difícil a ser calculado, pois a possibilidade se descobrir uma vulnerabilidade varia de acordo com diversos aspectos tais como sorte, conhecimento técnico do invasor, etc.
Por via das dúvidas, opta-se por sempre definir nota 10 para esta vulnerabilidade por medida de segurança, ou simplesmente 0 se for algo realmente impossível de ser descoberto (o que nunca vimos ocorrer).
Exemplo de aplicação do DREAD
O exemplo abaixo foi extraído do livro Escrevendo Código Seguro, de Michael Howard e David LeBlanc.
Um usuário mal intencionado visualiza dados relativos à folha de pagamentos online.
Dano potencial: 8 - foram expostas informações confidenciais dos usuários expostos.
Reproduzibilidade: 10 - facilmente reproduzível o problema.
Explorabilidade: 7 - basta estar online e com acesso a rede para se obter estas informações
Usuários afetados: 10 - é possível ver os dados de pagamento de todos os funcionários.
Possibilidade de descoberta: 10 - se um usuário descobriu como fazer isto, qualquer um poderá descobrir também
Risco: (8+10+7+10+10) / 5 = 9 (risco alto portanto)
Concluindo e indo além
STRIDE não é a única técnica de modelagem de ameaças existente: como toda prática, tem também suas limitações. Como disse na introdução, a grande vantagem que vejo na prática é a conscientização dos riscos e o fato de nos fornecer uma categorização que pode ser usada como vocabulário mínimo compartilhado entre a equipe de desenvolvimento e de negócios.
Foquei aqui apenas na apresentação destas categorias: o post ficaria imenso se eu também apresentasse como realizamos a análise de modelagem em nossos projetos, mas caso queira ter uma ideia sobre este processo, esta apresentação do Departamento de Ciência, Inovação e Tecnologia do Reino Unido é um prato cheio.
Outra fonte legal é o link Threat Modeling Process da OWASP, que você pode acessar aqui: https://owasp.org/www-community/Threat_Modeling_Process . É um passo a passo bem interessante e que pode ser usado como base nos seus projetos também.
Finalmente, é importante conhecer outros modelos também: sendo assim recomendo que você leia um pouco sobre PASTA neste link: https://threat-modeling.com/pasta-threat-modeling/.
