Tag Archive: Ciclo de Desenvolvimento de Software Seguro


Security is the Word!!!

For your business’ safety! 😉

FacesMessage facesMsg = new FacesMessage(FacesMessage.SEVERITY_INFO, “Faça Antes de” +”Codificar!”, “Pois Queremos Alicerces Seguros Nos Nossos Sistemas!!!”);

Na primeira parte desta matéria procuro dar a conhecer toda a envolvente teórica, retirada e adaptada do material disponibilizado pela SAFECode, sobre um dos temas que é transversal a qualquer metodologia que possa ser adoptada pela sua equipa para garantir a Segurança no Desenvolvimento de Software.

No percurso para o desenvolvimento de um software que cumpra com os critérios fundamentais para ser considerado resultado de um Ciclo de Desenvolvimento de Software Seguro, encontramos a  Modelação de Ameaça, considerada como a principal actividade de segurança na fase de design do software.

Modelo de Ameaças - Diagrama de Contexto

O Conceito

Basicamente, a Modelação de Ameaça (Threat Modeling)  é um exercício conceitual feito no período de design do software, onde o fluxo de dados de um sistema é analisado para encontrar vulnerabilidades de segurança e identificar as formas que as mesmas possam ser exploradas.

Com a adopção deste procedimento, agrega-se valor ao produto final pois garante-se a prevenção de potenciais problemas de design, na  lógica de negócio ou fluxos de trabalho inseguros, que não são normalmente encontrados usando outras técnicas, como revisões e análise estática do código fonte. Em essência, a modelação de ameaça identifica problemas antes do código ser escrito, para que eles possam ser evitados ou mitigados tão cedo quanto possível no ciclo de desenvolvimento do software.

Ao contrário das Ferramentas de Análise de Vulnerabilidades que só permitem a identificação de vulnerabilidades após o código ser implementado, a actividade de modelação de ameaça permite uma identificação ainda em tempo de design. Com esta abordagem é possível traçar estratégias de desenvolvimento que permitam controlar os riscos numa fase prematura do desenvolvimento.

Pela sua natureza, as correcções de ordem arquitectónicas são mais dispendiosas quando realizadas nos estágios mais avançados de desenvolvimento. Assim, a modelação de ameaça pode ser considerada uma actividade que privilegia a contenção de despesas pois a resolução de problemas logo no início do processo pode ser tão fácil como a simples tarefa de alterar um diagrama para ilustrar uma solução ainda a ser codificada.

Contudo, tentar identificar todas as ameaças possíveis e procurar mitigá-las logo no início do processo de desenvolvimento pode ser difícil de alcançar, então o foco deve ser sobre as questões de alto risco que podem ser identificados em tempo de design.

A Actividade

A modelação de ameaça pode ser feita a qualquer momento no ciclo de vida de desenvolvimento do sistema, mas para maximizar a eficácia esta actividade deve ser realizada o mais cedo possível.

Esta actividade começa com a identificação das ameaças possíveis e mais recorrentes. Nesta ordem, são usadas diferentes estratégias:

• “STRIDE” – esta metodologia classifica as ameaças em 6 grupos: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service e Elevation of Privilege. A Modelação de ameaça é executada, olhando para cada componente do sistema e determinando se existem algumas ameaças, pertencente a uma das categorias, que recaia sobre o componente e/ou à sua relação com o resto do sistema.

STRIDE
• “Caso de uso incorrecto” – o emprego de caso de uso incorrecto ajuda a clarificar como um atacante pode comprometer o sistema. Estes casos devem ser criados a partir dos requisitos funcionais do sistema, e ilustram como as medidas de protecção podem ser contornada e as áreas onde não existem nenhuma.
• “Brainstorming” – se uma organização não tem experiência na construção de modelos de ameaça, uma discussão orientada à segurança onde os arquitectos avaliam o sistema ajuda a colmatar esta deficiência. Tal “brainstorming” não devem ser considerados uma solução completa, e só devem servir como um trampolim para um exercício de modelação mais robusto.
• “Biblioteca de ameaças” – é um meio que torna o processo de identificação de ameaças mais acessível para os profissionais não especializados em segurança. Como bibliotecas públicas temos: CWE (Common Weakness Enumeration – um dicionário de tipos vulnerabilidades comuns em softwares), OWASP Top Ten e CAPEC (Common Attack Pattern Enumeration and Classification – que descreve métodos comuns de ataques).

Uma vez identificados, cada ameaça deve ser avaliada e mitigada de acordo com o risco associado, os recursos disponíveis, o caso de negócio e os requisitos do sistema. Isto irá ajudar a priorizar a ordem em que as ameaças devem ser abordadas durante o desenvolvimento, bem como os custos envolvidos na mitigação. Às vezes, isso irá conduzir à mudanças no design para permitir mitigações menos dispendiosas.

O Resultado

De uma actividade de Modelação de Ameaça certamente resulta o  Modelo de Ameaças do sistema a ser implementado, com o seu conjunto de diagramas, bem como uma Lista das Ameaças Associadas, mitigadas ou não.

Tem sido observado que a modelação de ameaça como parte das actividades recorrentes no ciclo de vida de desenvolvimento do software ajuda a enraizar uma cultura que aceita a segurança como um aspecto integral do design de software.

Para a segunda parte desta matéria está reservada uma simulação de um processo de Modelação de Ameaças, onde procurarei espelhar toda a dinâmica da sua opção num processo de desenvolvimento Ágil,  aplicando os conceitos aqui descritos e citando ferramentas que suportam a actividade com a análise automatizada de projectos e sugestões para possíveis mitigações e acompanhamento de questões de integração e comunicação relacionadas com o processo.

%d bloggers like this: