Verificação segundo SAMM: Testes Orientados a Requisitos em Segurança de Aplicações

Luciene Oliveira

4 anos atrás

Este artigo faz parte de uma série que detalha as práticas do framework OWASP SAMM (Software Assurance Maturity Model) [1] e nele vamos falar sobre Testes Orientados a Requisitos em Segurança de Aplicações referente à área de negócio Verificação.

Segundo o SAMM, os Testes Orientados a Requisitos em Segurança de Aplicações fazem parte de uma técnica utilizada para verificar se uma aplicação atende aos requisitos de segurança especificados no projeto. Esses testes podem incluir: pentests, testes de segurança da interface do usuário e testes de segurança do código.

Essa é uma etapa importante no processo de desenvolvimento de software, pois é nela que verificamos se as aplicações estão livres de vulnerabilidades que possam comprometer a segurança dos usuários.

Testes Orientados a Requisitos

Os testes orientados a requisitos fazem parte das atividades de verificação e validação do ciclo de vida de desenvolvimento de software. Eles são realizados para garantir que um sistema cumpra os requisitos de segurança previamente estabelecidos.

É importante observar os seguintes passos para realização de testes orientados a requisitos:

Identificar os requisitos de segurança da aplicação e documentá-los de forma clara e precisa;
Planejar os testes a serem realizados, quais ferramentas utilizar e responsáveis pela execução;
Executar os testes e registrar os resultados;
Analisar os resultados para identificar quaisquer vulnerabilidades ou problemas de segurança encontrados;
Corrigir as vulnerabilidades.

Para definir esses requisitos, é necessário realizar uma análise de possíveis ataques, vulnerabilidades e tratamentos de segurança dentro do escopo a ser testado. Existem diversas técnicas que podem ser utilizadas para realizar a análise de requisitos e cada técnica tem suas próprias vantagens e desvantagens e deve ser escolhida de acordo com o contexto do projeto. Aqui podemos utilizar, por exemplo, requisitos identificados na modelagem de ameaças (Figura 1) ou uma lista de requisitos pré-estabelecida como o ASVS, eles podem ser utilizados também de forma conjunta, porém pensando sempre no cenário da aplicação a ser testada.

Durante os testes, os avaliadores/testers tentam identificar vulnerabilidades e outros problemas de segurança que possam afetar a aplicação. Os testers também verificam se a aplicação está de acordo com as políticas e padrões de segurança estabelecidos pela empresa e podem ser desempenhados por diferentes tipos de profissionais, como engenheiros de segurança, analistas de testes e desenvolvedores de software.

Na Figura 1 vemos uma lista de requisitos elaborada a partir de uma modelagem de ameaças criada na Conviso Platform para realizar Testes em uma API.

Figura 1: Lista de requisitos para teste (Conviso Platform)

Os testes orientados a requisitos são testes complementares a outras práticas de segurança como os testes automatizados (AST) que podem ser vistos na Figura 2.

Exemplos de Testes orientados a requisitos

Durante a fase de concepção, os testes orientados a requisitos em segurança de aplicações podem incluir, por exemplo, a realização de uma análise de risco para identificar quais são os principais riscos para a segurança do software e como eles podem ser mitigados. Durante a fase de desenvolvimento, os testes podem incluir a verificação do código para garantir que ele esteja de acordo com os padrões de segurança estabelecidos e a realização de testes de invasão para verificar se o software é resistente a ataques cibernéticos.

Cada tipo de teste tem como objetivo verificar uma área específica de segurança da aplicação.

Dando um exemplo simples, imagine que você está desenvolvendo um sistema de gerenciamento de senhas para uma empresa e um dos requisitos de segurança que vocês definiram é que as senhas dos usuários sejam armazenadas de forma criptografada. Para verificar se esse requisito está sendo cumprido, você pode realizar um teste orientado a requisitos de segurança, que consiste em inserir uma senha no sistema e verificar se ela é armazenada de forma criptografada. Então, se a senha for armazenada de forma criptografada, o teste será considerado bem-sucedido. Se não, o teste será considerado falho e a equipe de desenvolvimento deverá corrigir o problema antes de liberar o sistema para produção.

Outro exemplo, somente para ilustrar, onde o requisito é verificar se o sistema está protegido contra ataques de força bruta. E o teste orientado a requisitos de segurança seria você tentar fazer login com senhas incorretas várias vezes seguidas e verificar se o sistema bloqueia a conta do usuário, ou a origem da requisição, após um determinado número de tentativas incorretas. Se o sistema bloquear conforme especificado no requisito de segurança, o teste será considerado bem-sucedido. Caso contrário, o teste falhou e esse problema deve ser corrigido antes de ir para produção.

Esses são exemplos apenas para entendimento do contexto, não citam todos os tipos de testes para os requisitos determinados.

Níveis de maturidade

O SAMM fornece uma estrutura para avaliar e melhorar a segurança de software, ele se divide em três níveis de maturidade, cada um deles com um conjunto de práticas de segurança específicas e dois fluxos: verificação de controle – fluxo A e o teste de uso indevido ou abuso – fluxo B.

No nível 1 do SAMM, os testes orientados a requisitos são realizados de forma ad hoc, ou seja, sem um processo formalizado ou automatizado. O foco está principalmente em identificar e corrigir problemas de segurança depois que eles ocorrem, portanto a verificação de controle no fluxo A (Teste para controles de segurança de software) e o teste de uso indevido ou abuso no fluxo B (Testes de fuzzing de segurança) são realizados de forma reativa, depois que um problema é identificado, encontrando assim vulnerabilidades básicas.
No nível 2, os testes orientados a requisitos são integrados ao processo de verificação e validação do software. Neste nível, a empresa já consegue identificar e corrigir problemas de segurança durante o ciclo de vida do software, portanto a verificação de controle no fluxo A, que deriva casos de teste de requisitos de segurança conhecidos, e o teste de uso indevido ou abuso no fluxo B, que cria e testa casos de abuso e teste de falha de lógica de negócios, podem ser realizados de forma proativa, ou seja, antes que um problema ocorra, executando revisões para descobrir novos riscos.
No nível 3, os testes orientados a requisitos são integrados ao processo de desenvolvimento de software e existe um conjunto de processos e ferramentas para gerenciar a segurança do software. Nesse nível, existe um gerenciamento maduro para prevenção de problemas de segurança, portanto, a verificação de controle de fluxo A (Testes de regressão com testes de unidade) e o teste de uso indevido ou abuso do fluxo B (Negação de serviço e teste de estresse de segurança) são realizados de forma proativa durante o desenvolvimento do software, garantindo a segurança do sistema durante o ciclo de vida do software. Além disso, essas atividades podem ser integradas ao processo de teste de regressão, que é realizado sempre que há alterações no software para que elas não afetem a segurança do sistema. Com sua maturidade alta, a empresa consegue manter o nível de segurança da aplicação com as práticas adotadas neste nível.

Ferramentas

A Conviso Platform [2] é uma plataforma, que abrange ferramentas de verificação de segurança de aplicações que segue o framework SAMM e que pode ser usada para realizar testes orientados a requisitos em segurança de aplicações. Ela oferece uma série de recursos, como análise de código e testes automatizados, que ajudam os desenvolvedores a identificar vulnerabilidades (Figura 1) em suas aplicações e fornecem recomendações para corrigi-las. Ela também pode ser usada para monitorar a segurança de aplicações em tempo real e para avaliar a eficácia das medidas de segurança implementadas.

Além de seus recursos para identificar e corrigir vulnerabilidades, a Plataforma Conviso também pode ajudar as organizações a implementar e gerenciar com eficiência e eficácia vários tipos de testes de segurança, incluindo revisões de código e testes de penetração. Sua plataforma integrada fornece uma abordagem simplificada e centralizada para gerenciar esses testes, permitindo que as organizações garantam a segurança de seus aplicativos com confiança.

Alguns dos produtos da Conviso que podem ser usados para esses propósitos incluem:

Secure by Design: auxilia a integração da segurança no processo de desenvolvimento de software, o que ajuda a minimizar vulnerabilidades e garantir que os produtos estejam mais seguros e com qualidade;
Secure Pipeline: auxilia a integração da segurança em todas as etapas do processo de CI/CD, fazendo com que as aplicações sejam liberadas de maneira segura e eficiente;e
Attack Surface: auxilia na identificação e gerenciamento da superfície de ataque de uma aplicação, minimizando o risco de ataques.

Figura 2: Vulnerabilidades identificadas após teste automatizado na Conviso Platform

Obs.: No próximo artigo, nos aprofundaremos mais no tópico Testes de segurança de aplicativos.

Conclusão

A verificação de segurança de aplicações é essencial para garantir a proteção dos usuários contra ameaças cibernéticas.

Ao realizar testes orientados a requisitos em segurança de aplicações, você deve ter em mente que a segurança de uma aplicação não é algo fixo e estático, mas sim algo que precisa ser mantido e atualizado constantemente. Portanto, é importante continuar realizando testes de segurança regularmente, mesmo depois que uma aplicação é lançada em produção, porque eles ajudam a garantir que o software seja seguro e confiável, protegendo tanto os usuários quanto a própria organização contra ameaças de segurança.

Referências

[1] Model | Verification | Requirements-Driven Testing. OWASP SAMM.

Testes Orientados a Requisitos

Exemplos de Testes orientados a requisitos

Níveis de maturidade

Ferramentas

Conclusão

Série artigos SAMM