Na primeira parte de nosso artigo, falamos sobre os conceitos básicos de testes de segurança. Nesta segunda parte, vamos tratar mais diretamente sobre cada um dos testes que entendemos necessários dentro de um pipeline de desenvolvimento.
O que temos que ter em mente aqui é que estes dois artigos não pretendem ser donos da verdade, nem mesmo devem ser seguidos como um checklist de testes de segurança a serem usados. O que queremos é gerar uma reflexão acerca do tema e, quem sabe, uma base de entendimento.
Vamos seguir com nosso tema.
Como falamos no artigo anterior, testes são processos que devem ser desenvolvidos em todo o fluxo de desenvolvimento. Para isso, precisamos entender a importância e a eficiência de cada um deles dentro do nosso processo.
Como base, precisamos entender primeiro nosso processo, e recomendamos que você desenhe o seu, pois de forma visual pode ficar mais fácil o entendimento de todo o fluxo. Assim, podemos imaginar onde e como atribuir etapas de teste em nosso pipeline.
Pense no seu set de ferramentas
Se você chegou a este artigo vindo do artigo sobre os conceitos essenciais nos Testes de Segurança, viu que falamos que não existe “bala de prata” e que nada deve ser entregue somente a ferramentas. Mas também sabemos que as ferramentas são peças fundamentais dentro do processo de desenvolvimento.
Sem as ferramentas, fica mais difícil escalar um processo de teste.
O que entendemos e o que sugerimos é que processos de testes devem ser bastante balanceados entre o uso de ferramentas e as validações feitas por analistas experientes, e esse balanceamento deve acontecer.
Nesse sentido, não queremos tecer comentários sobre ferramenta A ou B, queremos oferecer uma visão mais agnóstica. Sabemos que todas as ferramentas têm seus pontos fortes e fracos, e isso deve ser avaliado e conhecido quando se escolhe uma delas.
Conhecer quanto é o percentual de falsos positivos e ou falsos negativos é importante. Afinal, isso vai balizar a sua percepção do grau de confiança que deve ser dado a cada uma das ferramentas.
Outro aspecto importante quando falamos de ferramentas é como todas elas se integram, se comunicam. Em um determinado momento você vai ter várias delas gerando dados e informações, e seu processo de testes de segurança deve estar estruturado de forma que estes sejam visualizados e analisados de forma correta, sem que isso gere mais desgaste.
Então, além das suas ferramentas de teste, é importante que você avalie como elas irão gerar e entregar as informações.
Um exemplo
Na Conviso, desenvolvemos uma plataforma chamada Conviso Platform. Em seu processo de teste, ela pode atuar como um grande hub de integrações, permitindo que empresas que já tenham suas ferramentas de testes possam centralizar estes dados e informações geradas em uma plataforma central.
No entanto, não podemos abordar a Conviso Platform apenas como uma plataforma de integrações. A Conviso Platform é uma plataforma de Continuous Application Security, que possui atuação em todas as áreas do processo de desenvolvimento seguro e que permite que os participantes do processo de desenvolvimento tenham total visão e controle sobre estas etapas.
Vale aqui um parênteses: quando pensamos em processos, temos que pensar em como medir esse processo, sua eficiência e como podemos melhorar. Afinal, sem isso corremos o risco de deixar passar muitas oportunidades de melhorias. Então precisamos criar nossas métricas.
Mais uma vez aqui a Conviso Platform
nos ajuda com isso. Ademais, nossa plataforma está preparada para nos apresentar uma série de indicadores que nos permitem ter um visão geral de nossas análises e de nossos clientes, permitindo, assim, que possamos manter um maior controle.
Medir é importante, pois somente assim podemos melhorar processos dentro de nossa estrutura. Acredito que neste pequeno espaço de tempo consegui passar o que entendemos por pensar em seu set de ferramentas. Não adianta termos um conjunto de ferramentas se não sabemos como elas se comportam e/ou como podemos extrair o melhor de cada uma delas. Lembre-se: o software já é complexo demais por natureza, precisamos simplificar o processo em volta dele.
Testes de Segurança
Vamos falar um pouco sobre os testes de segurança e seu uso dentro do processo de desenvolvimento.
O DevSecOps adota a idéia do DevOps e adiciona o componente até então ausente: a segurança.
A imagem abaixo nos ajuda a entender melhor como tudo isso se encaixa. No entanto, é importante lembrar que, assim como segurança de aplicações, DevSecOps não é um produto – é uma cultura, e precisa de uma série de ajustes para que isso funcione corretamente.
Sendo assim, dizemos que os testes de segurança dentro de uma estrutura de DevSecOps devem ser um conjunto de testes realizados tanto por ferramentas quanto por analistas experientes, que validarão e ajudarão a refinar a corrigir as vulnerabilidades identificadas.
Quando eles acontecem
Os testes de segurança estão por todas as partes do processo de desenvolvimento seguro. É importante entender que cada tipo de teste tem seu momento e sua importância.
Precisamos conhecer nosso processo de desenvolvimento para melhorar cada vez mais a segurança de nosso código, e a imagem abaixo vai nos auxiliar a compreender melhor esta ideia:
Deixar de realizar os testes de segurança, ou mesmo não entender o que é na prática o conceito por trás da mudança cultural que traz o DevSecOps, pode introduzir em sua estrutura de desenvolvimento um grande problema. E isso faz com que sua equipe deixe de entregar códigos seguros.
Técnicas de Teste de Segurança
Modelagem de Ameaças
O pensamento dentro do processo de construção de modelagem de ameaças é o de tentar entender todas as ameaças que sua aplicação pode enfrentar, e desta forma, desenhar uma solução que pode já ter seus princípios de construção mitigando muitas das ameaças reais que a aplicação pode sofrer.
Para falarmos de modelagem, temos que entender que, apesar de modelagem poder ser uma abordagem extremamente técnica, não é necessário ser um especialista em segurança de aplicações para executar dentro do processo de testes de segurança.
Metodologias
Hoje temos duas grande metodologias que podemos usar para entender e criar nossas modelagens.
A primeira e uma das mais antigas é a que foi melhorada pela Microsoft ainda na década de 90. Ela tornou a Modelagem de Ameaças um processo mais estruturado e que poderia facilitar o desenvolvimento da segurança das aplicações.
Dentro do modelo de Microsoft, há 5 conceitos básicos que devem se observados, sendo eles: a definição de requisitos, a criação do diagrama de aplicações, identificação das ameaças, mitigação das ameaças e a validação das ameaças mitigadas.
O grande lance da modelagem melhorada pela Microsoft é que ela nos traz um conjunto de conceitos e métodos que nos dão um caminho a ser seguido, tornando a modelagem um processo estruturado. Isso sem deixar margem para que o processo seja desenvolvido sem uma estrutura básica.
Esse ponto tornou fácil fazer modelagem. Vamos ver quais são estes pontos e as etapas que, de forma geral, a Microsoft identifica para serem seguidas para a conclusão de uma modelagem de ameaças.
As etapas
A primeira etapa é o processo de identificação de ativos. Neste caso, ativos são todos os componentes de valor da solução, como por exemplo fluxo de dados, conexões, bases de dados, API e por aí vai.
Em seguida, passando da fase de identificar os ativos, precisamos então entender o que sua aplicação faz. Para isso, identifique os casos de uso que julgar pertinente para que você e outras pessoas da equipe usem para entender e buscar por possíveis ameaças à aplicação.
O terceiro ponto é quando você vai decompor o software em suas estruturas básicas, permitindo assim que se tenha uma visão de como o software pode ser afetado por alguma vulnerabilidade ou mesmo ameaça.
O quarto ponto é quando, com base em todos os dados que já temos, começamos a buscar identificar ameaças que nossa aplicação pode vir a enfrentar.
O STRIDE
Então, neste momento podemos lançar mão de um componente da Modelagem de Ameaças. Usando o STRIDE, que é um acrônimo que nos ajudar a estruturar a busca por estas ameaças, o trabalho fica mais fácil e direcionado.
O STRIDE tenta identificar ameaças relacionadas a:
Spoofing : Tentativa de se assumir ou personificar outro usuário
Tempering: Tentativa de modificação de algo.
Repudiation: Tentativa do usuário negar uma ação.
Information Disclosure: Quando há possibilidade de vazamento de informações
Elevation of Privilege: Quando há possibilidade de elevar os privilégios de um usuário.
Denial of Service: Negação de serviço de algum serviço
Seguindo estes acrônimos, é possível ter um direcionamento e identificar as ameaças que podem impactar na aplicação.
Tendo sido criada esta lista de ameaças, é possível agora documentar as ameaças que foram identificadas usando o método STRIDE. Para essa documentação, tente abordar as ameaças visualizando o alvo desta ameaça e colocando em um conjunto central na documentação.
Uma sugestão é fazer como mostramos na imagem a seguir:
Por fim, podemos agora classificar as ameaças identificadas e trabalhar na estrutura de classificação destas. Primeiramente pense no risco que as ameaças podem trazer para sua aplicação e como elas podem afetar o seu negócio. Desta forma, vai ficar mais simples para criar um conjunto de ameaças a serem trabalhadas primeiro.
Facilitando o processo
Para facilitar este processo, o modelo de Modelagem de Ameaças também nos ajuda, trazendo um método chamado DREAD. O DREAD vai nos ajudar a colocar em perspectiva quais ameaças são mais relevantes para nossa avaliação e funciona da seguinte forma:
Tendo isso sido construído, temos agora a possibilidade de trabalhar no processo de desenvolvimento de nossa aplicação. Porém, agora com mais informações e com um caminho que pode ser seguido para evitar vulnerabilidades que poderiam afetar nossa aplicação.
Usar modelagem também é importante. Isso permite que, na fase de testes, tenhamos um “checklist” que facilitaria a construção de scripts de teste, pois já temos algumas vulnerabilidades que podem ser testadas. Desta forma, caso tenha sido mitigada corretamente, não deve aparecer nos testes.
No entanto, a metodologia da Microsoft não é a única. Temos outras metodologias que podem ser usadas, como a da própria OWASP, ou mesmo OCTAVE e PASTA. Aqui não há razão para usar uma ou outra – todas são muito boas, o que importa é que você tenha um resultado positivo para o seu processo.
Experimente e veja qual melhor se adequa ao seu processo e à sua estrutura.
Code Review
O processo de Code Review é entendido como a revisão manual de um código, e essa revisão tem como objetivo buscar por possíveis falhas ou mesmo vulnerabilidades no código.
O uso de processo de code review causa grandes discussões entre as equipes de segurança e desenvolvimento, visto que há o entendimento que se temos uma ferramenta fazendo uma varredura estática no código, qual a necessidade de revisão manual que por muito é entendido como não escalável?
Bem, como já falamos, ferramentas são importantes e ajudam muito no processo de segurança do código. No entanto, elas não podem ser entendidas como as únicas responsáveis por esta segurança.
A compreensão de seu funcionamento é importante. Além disso, muito grosseiramente falando, as ferramentas buscam por códigos que se encaixem em uma assinatura, e por isso deixam passar muitas sutilezas que podem facilmente gerar um falso negativo nas ferramentas.
As revisões manuais são fundamentais para encontrar erros que a criatividade humana pode criar, ou mesmo para identificar erros de lógica de negócios – coisa que as ferramentas não pegariam normalmente e deixariam passar.
Um processo importante
Uma das melhores fontes para quem quer entender e melhorar o seu processo de revisão de código pode ser obtida por meio desse documento da OWASP, o Code Review Guide.
Se pegarmos a definição do próprio documento, vamos ter uma melhora clareza do que vem a ser um code review.
“It is the process of auditing the source code of an application to verify that the proper security and logical controls are present, that they work as intended, and that they have been invoked in the right places.”
Sendo assim, code review:
“É o processo de auditar o código de uma aplicação para verificar se as medidas de segurança apropriadas e estão presentes, se elas funcionam como esperado e se elas estão colocadas no local correto”, em tradução livre.
Então, como podemos ver, é sim um processo importante para a garantia de segurança da aplicação. E para reforçar essa visão, aqui temos uma imagem que mostra como as vulnerabilidades do OWASP TOP 10 são melhores identificados, majoritariamente testes manuais são mais eficientes.
Podemos fechar este tópico falando sobre code review com outras citação retirada do documento da OWASP o Code Review Guide.
“Organizations with a proper code review function integrated into the software development lifecycle (SDLC) produced remarkably better code from a security standpoint.”
Em tradução livre:
“As organizações com um processo de code review apropriado integrado ao seu processo de desenvolvimento produzem códigos melhores de um ponto de vista de segurança.”
Na Conviso, acreditamos fortemente que atuar cedo e sempre no desenvolvimento de software é a melhor solução para que as aplicações sejam mais seguras.
Testes Dinâmicos e Estáticos
A realização de testes de segurança é um processo bem importante dentro do desenvolvimento seguro. Sem eles, podemos estar arriscando a qualidade e a segurança de nossos códigos.
Para isso, podemos lançar mão de algumas ferramentas, que de forma automatizada podem fazer esses testes dentro de nosso processo.
Ferramentas de SAST e DAST são importantes aliados para nos ajudar neste processo de segurança do código, já escrevemos em nosso blog sobre isso.
Testes Estáticos (SAST)
As ferramentas de Static Application Security Testing ou SAST, quando executadas, analisam o código da aplicação de algumas maneiras, tais como a correspondência de expressão, a análise de fluxo de execução e ainda o fluxo de dados.
Para identificar possíveis vulnerabilidades, as ferramentas de SAST usam a presença ou a ausência de código ou de manipulação de dados específicos para determinar se há ou não presença de vulnerabilidades. E isso é uma de suas grandes vantagens, pois permite escalar uma operação de testes, mas também permite uma série de falhas, mostrando falsos positivos, ou pior, deixando passar falsos negativos.
Mas não sejamos injustos. Tratam-se de ferramentas muito importantes quando sabemos como funcionam e no que podem nos ajudar.
É comum vermos ferramentas SAST com taxas de falsos negativos mais baixas, mas em contrapartida, suas taxas de falsos positivos são mais altos que as ferramentas de DAST, isso reforça ainda mais a necessidade de revalidar os resultados destas ferramentas.
Além disso, outro ponto a ser observado é o suporte a linguagens e a versão específicas destas linguagens, pois quando há versões novas para essas linguagens devem ser esperados alguns atrasos nas validações destas ferramentas.
Tipos de código
As ferramentas de SAST geralmente trabalham com dois tipos de código:
- Análise do código-fonte, que funciona com códigos não compilados e arquivos de configuração:
Este tipo de análise é limitado aos pacotes onde o código está “aberto” e , portanto, podem perder algumas vulnerabilidades, que acabam sendo melhor identificadas no código compilado. Mas este tipo de validação pelo SAST é a ideal para usar em momentos mais prematuros do código, como, por exemplo, quando colocamos no IDE do desenvolvedor. Também pode identificar problemas de insegurança ou de qualidade do código, como código duplicado ou código não utilizado.
- Análise de código binário, que funciona com byte compilado ou código binário:
Embora não possa ser usado até que o código seja realmente compilado, ele pode ser usado quando o código-fonte original não estiver disponível, como no caso de software adquirido.
Esse tipo de teste pode ser ideal para validação de código ofuscado, mas deve levar em conta outros fatores. Por exemplo: a otimização do compilador, bibliotecas de terceiros e injeção de código (por exemplo, usando o empacotamento de aplicativos móveis).
Testes Dinâmicos(DAST)
De forma um pouco diferente, as ferramentas de DAST testam as vulnerabilidades simulando a interatividade com a aplicação. Isso acontece em tempo real de execução, e o objetivo é tentar identificar se alguma vulnerabilidade foi explorada com sucesso.
Nas ferramentas de DAST vamos encontrar algumas das funcionalidades de SAST. Isso é usado para melhorar a eficácia nos resultados, e pode ser colocado como exemplo os testes de dependências de JS descobertos no código.
Ao contrário do que vimos no SAST, as ferramentas de DAST tendem a ter menos falsos positivos, mas as taxas de falsos negativos são mais altas. Isso também é muito preocupante e deve ser entendido quando se usa estas ferramentas.
Categorias
As ferramentas de DAST podem ser divididas em duas categorias:
- Testes de API e aplicações WEB
Nestes casos, a ferramenta vai combinar as verificações baseadas em assinaturas em padrões para classes conhecidas de exploração, como, por exemplo, ataques de XSS ou mesmo de injeção.
São ferramentas geralmente indicadas para identificar aplicações web dentro de estruturas de rede e, assim, proceder com testes fortemente baseados em aplicações web. Sua principal funcionalidade é buscar por vulnerabilidades mais comuns, justamente por depender de um processo de validação de assinaturas.
- Teste dinâmico e “fuzzing” para aplicações não web
Este tipo de teste busca manipular protocolos de rede ou outras fontes de dados, como arquivos, para procurar vulnerabilidades exploráveis no código da aplicação que manipula esses dados ou protocolos. Essas ferramentas podem ou não ser específicas de determinados protocolos, como a Web, e geralmente têm como objetivo fornecer testes aleatórios e baseados em padrões para maximizar a cobertura.
Testes de Intrusão(Pentest)
Os testes de intrusão são um dos testes mais comuns quando pensamos em testar nossas aplicações.
Apesar de termos 3 tipos de testes de intrusão, que explicamos com mais detalhes nesse artigo, o mais comum para testes de aplicações é o black-box. Testes de intrusão são essencialmente testes realizados de forma remota para validar os controles de segurança de uma aplicação.
Mais uma vez podemos buscar na OWASP o material que pode nos ajudar nessas tarefas. Para isso, a leitura e entendimento do WSTG (Web Security Testing Guide) é fundamental.
Este teste visa entender como a aplicação se comportaria com um real ataque partindo de um real atacante, e o que as equipes de pentest tentam viabilizar é a descoberta de vulnerabilidades que não foram identificadas nas etapas de construção do código.
Testes de intrusão são importantes ferramentas de validação. Afinal, em teoria, os testes executados anteriormente já deveriam ter identificadas as vulnerabilidades que o código pode sofrer.
Não é incomum identificarmos muitas empresas que usam os testes de intrusão como seus primeiros testes a serem realizados nas aplicações, e muitas vezes sendo feito por ferramentas automatizadas. Certamente estas ferramentas têm sua importância no processo, mas também acreditamos fortemente que nada vai substituir a criatividade e a malícia de um analista experiente. Por isso, ainda reforçamos a necessidade de que este teste seja feito por um analista.
A importância dos testes dentro do SDLC
Em um artigo escrito por Gary McGraw e outros, temos alguns pontos que podem reforçar nosso entendimento sobre a importância dos testes dentro do SDLC e mesmo da importância dos testes de intrusão.
Em uma parte do texto, temos:
“Organizations that fail to integrate security throughout the development process often find that their software suffers from systemic faults both at the design level and in the implementation (in other words, the system has both security flaws and security bugs)”
Que podemos traduzir como:
“Uma organização que falha em integrar a segurança em seu processo de desenvolvimento regularmente identifica que seu software tem falhas tanto em design quanto em implementação(Em outras palavras, o sistema tem tanto falhas de segurança quanto bugs de segurança)”
E em outro trecho, podemos ver o que entendo como mais relevante para nosso tópico, pois ele coloca que:
“ In practice, a penetration test can only identify a small representative sample of all possible security risks in a system. If a software development organization focuses solely on a small (and limited)list of issues, it ends up mitigating only a subset of the security risks present (and possibly not even those that present the greatest risk).”
Da mesma forma, podemos colocar como:
“Na prática, testes de intrusão apenas podem identificar pequenas porções de falhas em todo o sistema. Se uma organização foca somente nas pequenas porções de problemas, acaba apenas mitigando estas pequenas porções de falhas(Possivelmente deixando de corrigir as que realmente representam grandes riscos)”
Como falamos, testes de intrusão são os tipos mais comuns de testes que percebemos nos clientes. Mas também são os que dificilmente são os mais bem planejados. Quando bem planejados e posicionados, podem ser uma ferramenta de extrema importância, e podem inclusive ajudar na manutenção de uma aplicação mais segura.
Conclusão
Agora quero fazer uma conclusão um pouco diferente: quero sugerir algumas coisas com as quais podemos ajudar quando o assunto são os testes.
Mas sempre lembrando que o que colocamos aqui não é e nem pode ser entendido como uma lista finita de testes que devem ser realizados. Estes são importantes, mas longe de serem os únicos.
Dentro da Conviso Platform temos a possibilidade de realizar testes automatizados usando as tecnologias de testes, DAST e SAST, do próprio produto. Isso facilita porque já estão internamente integrados com a plataforma, entregando as informações diretamente para nossos usuários.
No entanto, caso nosso cliente já tenha uma ferramenta e não queira deixar de usa-la, a Conviso Platform permite a integração das principais ferramentas do mercado, entregando os resultados dos scans em nossa plataforma de maneira centralizada e organizada.
A realização destes testes podem ser feitos tanto de forma manual, ou seja, sob demanda do usuário, ou mesmo sendo deixado agendado para que a equipe de desenvolvimento não tenha a interferência no processo, garantindo assim que os testes sejam realizados dentro da sua esteira de CI/CD.
É comum encontrarmos clientes que já possuem uma ou mais ferramentas que fazem grande parte de suas análises, e isso não precisa ser deixado de lado caso ele tenha interesse em nossa plataforma a Conviso Platform.
Na imagem acima podemos ver apenas algumas destas possíveis integrações.
Integrações da Conviso Platform
A Conviso Platform foi pensado para se integrar com várias ferramentas do mercado, recebendo as análises e colocando todas dentro de uma única visão estratégica do gestor e da equipe.
Este tipo de facilidade ajuda nos casos de equipes que já estão acostumadas com as suas ferramentas e entendem que deixar de usar estes produtos seria um obstáculo para a adoção da Conviso Platform.
Se você tem várias ferramentas em sua estrutura e estas estão gerando muitas informações, é fácil entender porque temos tantas equipes perdidas em seu processo de gerenciamento e correção de vulnerabilidades.
Garantir uma visão única é um dos objetivos da Conviso Platform, queremos que todos da equipe tenham a visão geral do que está acontecendo em sua estrutura e como isso pode afetar a todos.
O Dashboard da Conviso Platform foi construído de forma a entregar aos usuários as informações mais relevantes sobre as suas análises. No entanto, temos o cuidado de sempre avaliar se a forma como estamos entregando a informação é a mais eficiente e por isso mesmo o Dashboard sempre passa por revisões para melhorar a forma como apresentamos as informações.
Acreditamos que uma informação só tem valor quando ela entrega a todos um ganho frente aos seus problemas. Informação tem que ser importante para o contexto.
