Requisitos ASVS em Segurança de Aplicações
Quer entender melhor o que são e para que servem os requisitos de Segurança – ASVS?
No cenário de desenvolvimento de aplicações, é constante o uso do termo Requisitos de Segurança – ASVS, mas você sabe exatamente como aplicá-lo?
Para entender entender melhor o que é e para que serve o ASVS, listamos aqui alguns conceitos básicos para nos ajudar a construir um caminho sólido que garanta o correto cumprimento destes requisitos visando a melhora na segurança das aplicações.
Você também pode ouvir esse conteúdo:
Mas afinal, o que é ASVS?
Vamos então entender melhor a sigla: ASVS é a abreviação de Application Security Verifcation Standard – Padrão de Verificação de Segurança de Aplicações, que nada mais é que um checklist de requisitos para garantir a segurança das aplicações.
Eles atuam ajudando a desenvolver, manter e testar a segurança dessas aplicações.
Esses requisitos podem ser categorizados em três níveis de sensibilidade: quanto mais sensíveis os dados que uma aplicação processa, mais requerimentos são necessários para manter essa aplicação segura. Mas antes, vamos dar alguns passos para trás e entender melhor o que é o requisito em si.
E o que é um requisito?
Bem, se analisarmos o significado da palavra “requisito” enquanto adjetivo, podemos interpretar como algo que foi requisitado ou requerido. No entanto, se o usarmos como substantivo, como fazemos no mundo de AppSec, o termo ganha novo sentido e nos remete a algo necessário para chegar a algum lugar ou para obter algo.
Portanto, é preciso entender que ao definirmos requisitos, estamos definindo também objetivos a serem cumpridos e pontos a serem alcançados para que o software cumpra com as suas atribuições.
Levando em consideração a definição do banco de dados de pesquisa de materiais relacionados em ciência da computação, engenharia e áreas afins, o IEEE Standard 729, temos que requisito seria uma condição que deve ser alcançada por um sistema para satisfazer um contrato, uma especificação, um padrão ou mesmo uma formalidade imposta por um documento.
Outra boa definição que podemos usar como base é a feita pelo OWASP SAMM, que define requisitos como sendo a necessidade de identificar controles de segurança que serão importantes dentro do contexto de segurança do software.
Requisito dentro do processo de SDLC
Dentro do Software Development Life Cycle (SDLC), a fase de requisitos é uma das primeiras e também uma das mais importantes.
Isto porque é nesta fase que as informações necessárias para a construção do software serão levantadas, e seguindo as boas práticas, também são determinados quais devem ser os requisitos de segurança a serem alcançados pelo software.
Portanto, se adotarmos como modelo o SDLC desenvolvido pela Microsoft, por exemplo, podemos dizer que é nesta fase que teremos a visão clara de como o software deve se comportar e mesmo se haverá a construção do software.
3 pontos importantes em Requisitos de Segurança
Como vimos acima, ao adotarmos o modelo de Software Development Life Cycle – SDLC desenvolvido pela Microsoft, podemos ter uma melhor noção de como o software irá se comportar.
Isso porque é justamente na fase em que se define requisitos que se estabelece também padrões de atividade para este software.
E é na fase de requisitos que temos 3 pontos importantes a serem observados, os quais abordaremos melhor a seguir.
1. Criar um conjunto de requisitos de segurança
O primeiro ponto importante é criar um conjunto funcional de requisitos de segurança e privacidade, que será usado como base para todo o software.
Esta definição de requisitos de segurança pode ser executada com a ajuda de especialistas, que podem ser os Security Champions das equipes de desenvolvimento.
Os Security Champions são profissionais que surgem dentro dos times de Desenvolvimento, falando a mesma linguagem do restante da equipe e conseguindo, por este motivo, promover a segurança de dentro para fora desde o momento do nascimento do software.
2. Pontos de Decisões para o Software
Em um segundo momento, é hora de criarmos alguns pontos de decisões para o software. Os quality gates ou bug bars são pontos onde a avaliação do código ou mesmo do software vai identificar se há condições de prosseguir com o ciclo normal do desenvolvimento.
Para tomarmos como exemplo, podemos dizer que um quality gate é uma avaliação que, quando cumprida, garante a sequência da produção do software.
Imagine uma modelagem de ameaças: ao criarmos a modelagem identificamos condições que devem ser cumpridas, e isso são quality gates.
3. Definindo requisitos de segurança e privacidade
Já o terceiro ponto trata especificamente da definição de requisitos de segurança e privacidade em si: é importante identificar os requisitos funcionais do software que vão precisar de mais atenção durante a sua construção.
Desta forma, os principais pontos de atenção da criação dos requisitos de segurança estarão cobertos e você poderá contar com um software sendo criado de forma cada vez mais segura.
Pontos básicos quando se fala em requisitos de segurança – ASVS
De um ponto de vista de segurança, ao documentar os requisitos buscamos garantir que as melhores práticas de segurança sejam cumpridas, mas não somente isso. É importante também observar a adesão a recomendações e ou exigências do mercado, bem como o cumprimento de exigências legais e normativas.
Além destas definições e orientações, a construção de um documento de requisitos deve contemplar também quais serão os quality gates que irão garantir e validar cada um desses requisitos.
Aqui não nos cabe falar sobre todos os requisitos de seguranças, mas podemos colocar alguns para dar início ao seu caminho na criação de sua própria visão dos requisitos.
Requisitos fundamentais de segurança
Então, para que possamos determinar quais são os conceitos básicos a serem abordados, vamos usar como ponto de partida 6 conceitos muito utilizados em requisitos de segurança.
1. Confidentiality ou Confidencialidade
De forma resumida, podemos dizer que garantir a confidencialidade dos dados é garantir que somente pessoas autorizadas possam ter acesso a eles.
E para que isso seja verdade, temos que considerar controles que atuem diretamente nos dados nos três estados conhecidos como at-Rest ou armazenada, em trânsito ou mesmo em processamento.
Ums dos modos de garantirmos a confidencialidade destes dados é adotando o uso de criptografia, desta forma fica assegurada a confidencialidade dos dados.
2. Integrity ou Integridade
Os requisitos de integridade dos dados são necessários para garantir a exatidão ou a não alteração dos dados.
A confidencialidade pode ser garantida verificando se as funcionalidades do software proporcional o maior nível de segurança possível ao dado. Já a exatidão dos dados é atingida por meio da restrição do acesso, de forma que só possa alterar os dados aquele usuário que tiver permissão.
Além disso, outro elemento que auxilia na garantia da integridade são as assinaturas digitais.
Especificações como Protocolos e Força de Aleatoriedade de Dados (por exemplo, Comprimento de Salt) devem ser avaliadas como parte da Lista de Verificação de Segurança.
3. Availability ou Disponibilidade
Os requisitos de segurança referentes a disponibilidade visam, como o próprio nome diz, garantir que o dado ou o serviço estejam disponíveis sempre que seu usuário precisar.
Este requisito é um dos mais complicados e deve ser tratado como uma parte do SLA (Service Level Agreement) com componentes como o MTD (Maximum Tolerable Downtime) ou mesmo o RTO (Recovery Time Objective).
Quando avaliados ou mesmo presentes em um BIA (Business Impact Analisys), estes devem possuir uma avaliação tanto quantitativa quanto qualitativa.
4. Authentication ou Autenticação
O conceito básico de autenticação todos conhecemos: precisamos garantir a legitimidade e a identidade daquele que se apresenta ao sistema.
Um exemplo claro disso é quando existe uma solicitação para que alguém apresente um documento, comprovando, desta forma, que sua identidade é de fato aquela alegada por este indivíduo.
E para nossos sistemas o processo não é diferente: autenticação é a validação daquela identidade supostamente informada, e isso vamos conseguir com um mecanismo de validação, como uma senha por exemplo.
Existem outros mecanismos que podem e devem ser levados em consideração. Alguns exemplos podem ser mecanismos de 2FA (Duplo Fator de Autenticação) ou mesmo sistemas de SSO (Single Sign-On) ou Active Directory.
5. Authorization ou autorização
Agora que temos um usuário autenticado, precisamos garantir que as ações desejadas e realizadas por este usuário sejam realmente as que ele tem permissão para realizar.
Essa tarefa é a autorização do usuário. Para o desenvolvimento, a autorização é garantir que um usuário realize apenas ações que estejam verdadeiramente ligadas ao seu trabalho. E isso pode ser garantido por meio de validações em matrizes de acesso implementadas em sistemas.
Em resumo, nosso processo de autorização deve garantir que todo usuário realize apenas ações a ele permitidas.
6. Accountability ou responsabilização
Então, se já conseguimos garantir o acesso, funções e ações no sistema, precisamos também garantir que, ao realizar uma ação, essa seja individualizada ao usuário que a executou.
Nosso sistema deve estar preparado para identificar ações realizadas por usuário, desta forma é possível fornecer evidências de uso e quais ações que trouxeram algum tipo de comprometimento ao sistema ou mesmo às informações.
Como definir bons requisitos?
Agora que entendemos os conceitos básicos que devem ser buscados quando definimos requisitos, também precisamos identificar como estes e outros requisitos serão alcançados.
Para isso, podemos lançar mão de algumas fontes de boas práticas. Uma delas é o OWASP ASVS: uma lista de requisitos de segurança a serem usados em aplicações baseados na criticidade das informações tratadas pelo sistema.
OWASP ASVS
O OWASP ASVS é o resultado de um esforço da comunidade em criar uma lista de possíveis controles de segurança que podem ser implementados em aplicações baseados em uma série de fatores.
Em sua versão 4.0, o ASVS tem como premissa básica conseguir entregar um framework de definições para controles e requisitos de segurança. Desta forma, é possível mapear controles funcionais e não-funcionais de segurança.
Em sua atual versão, o ASVS trouxe como principal mudança o uso direto do NIST-800-63-3, documento base para a gestão de Identidade Digital (Digital Identity).
Ainda nesta versão, tanto o ASVS quanto o OWASP TOP 10 2017 reforçaram seu alinhamento direto com o NIST 800-63. Mas atenção: não confundir com o NIST-800-63-3 citado acima.
Este alinhamento é bem mais forte quando se colocam controles de autenticação e de gerenciamento de sessão.
Outra mudança significativa foi a reconstrução da numeração dos controles, que agora estão mais focados em corrigir GAPs de versões anteriores.
Por fim e não menos importante: a nova versão do ASVS tem uma nova abordagem que vem suprir pedidos antigos da comunidade.
O primeiro é uma maior relação direta com o CWE, que é uma das fontes mais buscadas quando pensamos em vulnerabilidades.
A segunda relação direta foi feita com a Seção 6.5 do PCI-DSS 3.2.1, principalmente quando focamos em codificação, testes, code review, testes de intrusão e design de aplicações.
O ASVS também vem acompanhando a evolução dos modelos e tecnologias encontradas no processo de desenvolvimento e mesmo nas aplicações.
Agora o ASVS acompanha de perto as novas mudanças abandonando um modelo exclusivamente monolítico para abordar assuntos como micro-serviços, DevSecOps, containers, CI/CD entre outros.
Mas todos estes pontos são relacionados com aplicações web, o que em tempos de aplicações mobile pode levantar uma dúvida quanto ao uso destes mecanismos.
Requisitos de Segurança para Aplicações Mobile – OWASP MASVS
Para aqueles que desenvolvem focados em aplicações mobile, o mesmo conceito aqui apresentado pode ser encontrado na versão de controles para aplicações mobile do ASVS, conhecida como OWASP MASVS, hoje em sua versão 1.1.4.
Como o ASVS, o MASVS também pode ser usado para identificar quais seriam os controles básicos para as aplicações baseados na criticidade de suas informações e como o ASVS também classifica suas aplicações em 3 níveis.
Como temos mostrado, é interessante que os desenvolvedores fiquem mais atentos para estes modelos, buscando usá-los como base para a construção segura de seus aplicativos.
Por exemplo, caso sua aplicação mobile seja voltada para o setor financeiro, é recomendado que se use os controles identificados no nível 2 do MASVS.
Este nível já traz controles que podem suprir as exigências de regulamentações como PCI-DSS ou mesmo da SOX, que é uma Lei Americana focada em controle financeiro e tem forte impacto na área de tecnologia das empresas.
Onde queremos chegar?
Entendemos que construir um software seguro vai muito além de apenas criar códigos mais seguros.
Existe um processo antes de se chegar ao final do desenvolvimento, quando o software é disponibilizado.
Construir software seguros começa com um bom conhecimento sobre a tecnologia, o modelo e a linguagem usada para desenvolver. Falamos sobre isso em um outro artigo mencionando as etapas importantes a se considerar ao buscar capacitação para a equipe de desenvolvimento.
Entendemos que nosso papel é fomentar a curiosidade do desenvolvedor por outros assuntos que talvez ele não tenha, mas que julgamos ser tão importante quanto estar atualizado com o framework e suas novidades.
Precisamos criar uma comunidade que possa trocar informações e esclarecer dúvidas sobre segurança em aplicações, e para ajudar nesse ponto queremos convidar a todos para participar de nossa comunidade de DevSecOps no Slack.
Venha participar e trocar conhecimentos, contribuindo com o crescimento colaborativo da área de AppSec!
Links de referência deste artigo:
How to Use Quality Gates To Guide IT Projects
OWASP_Application_Security_Verification_Standard_Project
OWASP_Application_Security_Verification_Standard_4.0
