Contextualização
Por que pensar em Modelagem de Ameaças? Bom, durante o processo de desenvolvimento de software, algumas etapas devem ser observadas para que o resultado final seja uma aplicação segura e que consiga alcançar todos os requisitos estabelecidos.
Novas leis e normativas estão sendo criadas para que os donos dos dados tenham a garantia de que suas informações estejam protegidas, e que as melhores medidas foram tomadas para garantir isso.
Privacidade passou a ser um termo valorizado quando o assunto é a garantia da segurança de um software. No caso da perda ou comprometimento destes dados, novas leis surgiram para garantir que seus donos possam receber a atenção e as respostas necessárias para cada evento.
Neste cenário precisamos entender que os modelos atuais de desenvolvimento – e aqui não queremos limitar este termo nem aos modelos ágeis, nem aos mais tradicionais – precisam voltar a ser observados, entendidos e seguidos em suas melhores práticas para que o resultado final seja um software desenvolvido de maneira cada vez mais segura.
Como chegamos a Modelagem de Ameaças ?
Para refrescar a memória dos que não lembram, um modelo de desenvolvimento possui basicamente cinco etapas distintas – e isso mesmo quando falamos de modelos mais ágeis, pois no seu conceito básico continuamos com as cinco etapas. São elas: Requisitos, Design, Codificação, Teste e Manutenção.
Quando seguidas, estas cinco etapas garantem que o resultado final seja um software estruturado e validado em cada uma das etapas. No entanto, geralmente a realidade é outra, pois a velocidade com que novas funcionalidades são exigidas – ou mesmo novos softwares – está fazendo com que muitas equipes de desenvolvimento não sigam o modelo conceitual. E isso foi e segue sendo um problema, que de certa forma foi encarado pela Microsoft no ano de 2002 em resposta a uma diretiva chamada Trustworthy Computing (TwC).
Em resposta a esta diretiva a Microsoft criou uma série de grupos de estudos que tinham como objetivo desenvolver métodos para melhorar a segurança das aplicações. Desta forma, um dos grupos formado foi o que estudaria o conceito de Secure by Design.
No modelo de Secure by Design, uma das etapas a serem desenvolvidas é o de criação de um documento de Modelagem de Ameaças, onde basicamente se cria um mapa de possíveis ameaças ao software e são desenhadas soluções de mitigação ainda na construção conceitual da aplicação.
O que mais temos para entender sobre modelos de desenvolvimento
No entanto este modelo não é o único que pode ser usado, muitos outros padrões estão disponíveis no mercado, um que vem ganhando muita atenção é o padrão apresentado pelo ISO –International Organization for Standardization e pelo IEC – International Electrotechnical Commission em seu padrão internacional chamado ISO/IEC 27034, norma que traz uma série de controles que devem ser implementados em um processo de desenvolvimento seguro.
Mesmo sendo um dos modelos mais utilizados, o ISO/IEC 27034 não é o único, outros padrões podem ser encontrados no mercado e um destes Modelos de Maturidade que podem ser usados é o OWASP SAMM, originalmente chamado de OWASP OpenSAMM desde 2009, mas recentemente foi atualizado para OWASP SAMM. Aqui não nos cabe falar em detalhes sobre este Modelo de Maturidade, vamos apenas mostrar que a Modelagem de Ameaças está presente em vários destes modelos e tratar de seu uso e importância para o desenvolvimento de aplicações mais seguras.
Mas aqui nos cabe fazer uma recomendação. A leitura do OWASP SAMM bem como de outros materiais da OWASP é fundamental para manter o conhecimento do desenvolvedor atual e sempre focado nas melhores práticas de desenvolvimento seguro.
O que é Modelagem de ameaças ?
Mas afinal o que é Threat Modeling ou Modelagem de Ameaças ?
Bom, existem várias definições que podemos encontrar hoje como por exemplo o usado pela Microsoft em seu material de estudo de SDLC:
“It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application.”
Apesar desta ser uma boa definição, a que mais aprecio é a definição dada por Adam Shostack em seu livro “Threat Modeling: Designing for Security”, onde ele descreve Modelagem de Ameaças como:
“Threat modeling is the use of abstractions to aid in thinking about risks.”
Esta definição apesar de bem simples é a que melhor representa o que é realmente a Modelagem de Ameaças, pois de modo totalmente abstrato, pois ela é realizada ainda na fase de Design da aplicação, busca identificar as possíveis ameaças que uma aplicação pode estar exposta.
Para muitos arquitetos e desenvolvedores está pode ser uma definição um tanto quanto estranha, pois visa a realização dessa avaliação ainda em fases iniciais, sem uma única linha de código desenvolvida. Mas é isso mesmo, temos que colocar em nosso modelo de desenvolvimento a prática de pensar ou mesmo identificar possíveis ameaças a nossas aplicações, isso dentro do tempo de desenvolvimento nos trará um ganho considerável de tempo, sem falar na redução das vulnerabilidades identificadas nas fases mais finais do processo de desenvolvimento, o que no prazo do projeto se transforma em redução de custos final.
Mas, vamos olhar novamente para a definição do Shostack, e se a lermos com mais atenção vamos notar que a definição dele nos remete ao que é no fundo o objetivo da Modelagem de Ameaças que é a identificação e priorização do risco.
Em resumo, o que é a Modelagem de Ameaças? Bom, se pudermos resumir, e tendo como base a definição do Shostack, podemos dizer que a Modelagem de Ameaças é a busca por possíveis riscos a que nosso software estará exposto, consequentemente resolvendo a causa raiz de problemas.
Fontes:
IBM: Security Intelligence
OWASP
