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

Série artigos SAMM

  1. Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
  2. Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
  3. Governança segundo SAMM:  Educação e Orientação em Segurança de Aplicações
  4. Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
  5. Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
  6. Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
  7. Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
  8. Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
  9. Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
  10. Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
  11. Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
  12. Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
  13. Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
  14. Operações segundo SAMM: Gestão de Ambientes  em Segurança de Aplicações
  15. Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações
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
ProdutoSegurança de Aplicação

Segurança de aplicações com IA: como apoiar o desenvolvimento seguro

A segurança de aplicações com IA está redefinindo a forma como as empresas desenvolvem software…
Read more
ProdutoSegurança de Aplicação

Gestão de vulnerabilidades precisa de contexto

Quem trabalha com segurança de aplicações não sofre com a falta de dados — sofre com o…
Read more
ProdutoSegurança de Aplicação

Como agentes de IA especialista em AppSec aceleram o desenvolvimento seguro

A segurança de aplicações não começa na revisão de código — começa na forma como elas são…
Read more

Deixe um comentário

Descubra mais sobre Conviso AppSec

Assine agora mesmo para continuar lendo e ter acesso ao arquivo completo.

Continue reading