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.
Você também pode ouvir esse conteúdo:
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:

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.

Série artigos SAMM
- Governança segundo SAMM: Estratégias e Métricas em Segurança de Aplicações
- Governança segundo SAMM: Políticas e Conformidades em Segurança de Aplicações
- Governança segundo SAMM: Educação e Orientação em Segurança de Aplicações
- Design segundo SAMM: Modelagem de Ameaças em Segurança de Aplicações
- Design segundo SAMM: Requisitos de Segurança em Segurança de Aplicações
- Design segundo SAMM: Arquitetura Segura em Segurança de Aplicações
- Implementação segundo SAMM: Build Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Deploy Seguro em Segurança de Aplicações
- Implementação segundo SAMM: Gestão de Defeitos em Segurança de Aplicações
- Verificação segundo SAMM: Análise de Arquitetura em Segurança de Aplicações
- Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações
- Verificação segundo SAMM: Testes de Segurança em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Incidentes em Segurança de Aplicações
- Operações segundo SAMM: Gestão de Ambientes em Segurança de Aplicações
- Operações segundo SAMM: Gestão Operacional em Segurança de Aplicações