Segurança de Aplicação

Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações

As organizações de desenvolvimento de software são constantemente pressionadas a atender padrões de segurança [1]. Em busca de suprir tal demanda do mercado, a OWASP com o framework Assurance Maturity Model (SAMM) provê as melhores práticas para governança, design, implementação, verificação e operação. Neste artigo serão explorados os conceitos de análise de arquitetura presentes no domínio de verificação. Não deixe de conferir também nossos textos anteriores da série OWASP SAMM.

Análise de arquitetura 

O domínio de verificação tem como objetivo verificar e testar os produtos de software durante todo o processo de desenvolvimento, garantindo que os requisitos estabelecidos tenham sido atendidos e que o nível de segurança seja aceitável. Isso normalmente inclui análises de qualidade, testes automatizados e manuais, além de outras atividades de revisão e avaliação. 

As práticas de análise de arquitetura buscam prover subsídios para garantir que a arquitetura e infraestrutura atendam adequadamente aos requisitos de segurança para mitigar ameaças identificadas. Tais requisitos devem ser levantados durante o processo de modelagem de ameaças presente no domínio de Design, onde, por meio do Application Security Verification Standards (ASVS), é possível listar diferentes requisitos de segurança de software de acordo com o nível de verificação necessário, sendo eles:

  • Nível 1 – Destinado a todos os softwares; 
  • Nível 2 – Para aplicações que armazenam e manipulam dados confidenciais;
  • Nível 3- Aplicações de nível crítico.

A Figura 1 apresenta um exemplo de definição de requisito ASVS gerado automaticamente de acordo com uma ameaça identificada. Com o módulo Secure by Design da Conviso Platform é possível realizar toda a gestão e acompanhamento de requisitos de segurança.  

Figura 1 – Requisitos de segurança de acordo com a ameaça (Conviso Platform)

A verificação da conformidade dos requisitos de segurança pode ser realizada de forma ad hoc e, em seguida, de forma sistemática para cada interface do sistema. Note que a análise deve ser realizada para todos os componentes da arquitetura de forma estruturada, permitindo a revisão e teste dos requisitos aplicados. A partir da revisão da arquitetura é necessário avaliar continuamente os controles e a sua escalabilidade de acordo com a estratégia da organização, permitindo identificar pontos fracos e possíveis melhorias nas práticas de arquitetura segura.

O SAMM divide o tópico de análise em arquitetura em dois fluxos, com práticas recomendadas de acordo com cada nível de maturidade, conforme apresentado a seguir:

Nova call to action

Validação de arquitetura

Este tópico busca indicar práticas para facilitar a visualização e análise da arquitetura de alto nível em medidas de segurança. 

  • Nível 1 –  Definir uma visão geral da arquitetura e listar os mecanismos de segurança como: autenticação, autorização, gerenciamento de acesso, etc. Neste nível a análise deve ser realizada do ponto de vista de usuários anônimos, usuários autorizados e funções específicas do aplicativo. 
  • Nível 2 – Formatar um processo de revisão de arquitetura para toda a organização. Verificar regularmente a conformidade dos requisitos de segurança em camadas internas e externas da arquitetura.
  • Nível 3 – Garantir a eficiência dos controles de segurança implementados em relação a disponibilidade e escalabilidade, neste nível é importante analisar se os mecanismos existentes serão suficientes para possíveis evoluções da aplicação. 

No processo de validação da arquitetura é indicado criar estratégias de registro de defeitos, de modo a permitir levantar métricas de avaliação das limitações e controles existentes. 

Arquitetura de mitigação

O tratamento de ameaças comuns deve ser efetivo e revisado periodicamente pela equipe de segurança da informação, juntamente com o time de arquitetura. Ameaças típicas podem surgir da confiança excessiva em mecanismos automatizados, deste modo, cabe a verificação constante das estratégias utilizadas pelas ferramentas utilizadas.  

  • Nível 1 – Verificar se as mitigações são suficientes para ameaças em componentes e estruturas críticas da solução.
  • Nível 2 – Revisar de forma sistemática cada ameaça identificada. Definir um processo padrão para revisão de registros de decisões arquitetônicas levando em consideração o impacto de cada decisão.
  • Nível 3 – Analisar regularmente o surgimento de novas ameaças e adequar táticas para evitar isso. 

O que podemos concluir sobre análise de arquitetura?

Neste artigo foram abordadas as indicações do framework OWASP SAMM para a implementação de processos seguros no domínio de análise de arquitetura. Vale ressaltar que a efetividade da implementação desses processos está intimamente ligada com o trabalho conjunto de todas as partes envolvidas no processo, como: desenvolvedores, designers, arquitetos e equipe de segurança.

REFERÊNCIAS 

[1]BRASOVEANU, Raluca; KARABULUT, Yusuf; PASHCHENKO, Ivan. Security Maturity Self-Assessment Framework for Software Development Lifecycle. In: Proceedings of the 17th International Conference on Availability, Reliability and Security. 2022. p. 1-8.

[2] OWASP SAMM 2.0. Acesso em: 01 dez. 2022.

Nova call to action
About author

Articles

Analista de segurança na Conviso. Mestre em Ciência da Computação pela Universidade Estadual de Maringá, Paraná/Brasil. Atualmente cursa Doutorado em Ciência da Computação pela mesma universidade (UEM).
Related posts
Segurança de Aplicação

Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações

Neste artigo, daremos sequência à série de publicações sobre o OWASP SAMM (Software Assurance…
Read more
Segurança de Aplicação

Programa de segurança de aplicações: conheça o AppSec Journey

Primordialmente, a Segurança de Aplicações (AppSec) deve ser integrada em todas as etapas do…
Read more
Segurança de Aplicação

Operações segundo SAMM: Gestão de Ambiente em Segurança de Aplicações

Este artigo faz parte de uma série de publicações feitas com base no projeto SAMM da OWASP, caso…
Read more

Deixe um comentário