Se perguntarmos para qualquer profissional de segurança ou de desenvolvimento se ele acha que realizar testes de segurança em suas aplicações e/ou código é importante, a resposta será unânime: um grande sim!
Então por que ainda temos tantos aplicativos ainda são entregues com tantas vulnerabilidades se temos a noção de que precisamos realizar os testes?
A resposta não é tão simples e podemos juntar algumas peças para tentarmos entender o conjunto total.
Nos próximos dois artigos, vamos falar sobre testes de segurança. Neste primeiro artigo vamos elencar alguns pontos que entendemos como básicos para a compreensão do plano geral. Precisamos falar um pouco sobre conceitos, para depois abordarmos como os testes dentro do processo de desenvolvimento podem acontecer.
Então vamos para nossa primeira parte.
Velocidade Vs. Qualidade
Ainda há estruturas e processos de desenvolvimento que acreditam que a realização de testes de segurança devem ser realizados apenas quando a aplicação é colocada em produção. Um conceito mais clássico e muito comum nas estruturas de desenvolvimento mais antigas.
Vou usar as palavras de Bruce Schneier em seu livro Clique aqui para Matar Todo Mundo, onde ele coloca o seguinte texto:
“Softwares são mal escritos porque, com poucas exceções, o mercado não recompensa software de boa qualidade”. E continua: “preço e velocidade são mais importantes para mercado do que qualidade”.
Nos últimos anos, cada vez mais as empresas de desenvolvimento – internamente ou por força de seus clientes – vêm sendo demandadas para entregar novos softwares ou mesmo novos recursos para seus produtos cada vez mais rápido.
Como sabemos, quando falamos de segurança, quando se opta por velocidade, alguma coisa será deixada para trás. Neste caso, o que está sendo deixado para trás é a segurança.
Em 2000, Bruce Schneier já comentava que “segurança é um processo, não um produto.” Concordo plenamente com ele e tenho minha própria analogia. Em minha opinião, trabalhar com segurança é subir uma escada rolante ao contrário – se parar para descansar, você pode descer e perder tudo que conquistou. Por isso a visão de processo é tão importante.
Ainda, usando a obra de Schneier como exemplo – cuja leitura é altamente recomendada – podemos dizer que defender um software é uma tarefa difícil, pois “a complexidade de sistemas computadorizados significa que atacar é mais fácil que defender”. Ou seja – esta parte do texto em si já justifica que deves ter muito mais atenção quando o assunto é testes de segurança.
Algumas referências
Neste artigo, queremos falar um pouco sobre testes de segurança, e trazer um pouco de luz sobre este tema que muitas vezes é negligenciado e tem sua importância diminuída.
Para que esse texto não fique só com base nos nossos conhecimentos, vamos trazer também algumas referências e tentar mostrar como fazemos para ajudar nossos clientes com este tema. Acredito que assim fique mais claro o entendimento.
Mas então, por que realizar testes e, o mais importante, por que ter um processo de testes definido e estruturado?
A OWASP, em seu WSTG (OWASP Security Testing Guide) coloca desta forma o motivo de termos esse processo definido:
“In the security industry, people frequently test against a set of mental criteria that are neither well defined nor complete”, o que, em tradução livre, quer dizer que, na indústria de segurança, as pessoas frequentemente realizam testes baseados em um critério mental que não são bem definidos e nem completos.
Acho que estão corretos. Afinal, tendemos a usar muito de nosso conhecimento empírico, e assim fazemos a maioria das coisas. Isso também inclui realizar testes, que falham em estrutura e, muitas vezes, em conceitos básicos.
Além disso, testar e avaliar aplicações web é ainda mais crítico do que para outros softwares, visto que grande parte das empresas tem seus negócios fortemente baseado neste tipo de aplicação.
Quando testar?
Comentamos anteriormente que ainda é muito comum o pensamento de que aplicações web devam ser testadas apenas quando estas já estão prontas e expostas à Internet, tendo o acesso de milhões de usuários.
Não concordamos com isso, e temos forte entendimento que esse não é o pensamento correto a ser adotado hoje. Afinal, além de ser pouco efetivo, é um dos modelos mais custosos para as empresas, uma vez que ele apenas passa a corrigir problemas quando estes já estão presentes nas aplicações.
Esse fato em si já é impactante para empresa. No entanto, corrigir uma vulnerabilidade em uma aplicação já operacional tem consequências ainda maiores, uma vez que serão necessários novos esforços de desenvolvimento. Isso sem contar com as horas de planejamento e busca pelas correções.
É indiscutível que um dos melhores métodos para prevenir que suas aplicações sejam colocadas em produção com vulnerabilidades é que estas sejam testadas durante todo o ciclo de desenvolvimento do software (SDLC).
É primordial que as empresas busquem olhar para o seu processo de desenvolvimento e vejam se, dentro dos seus processos, os conceitos de segurança fazem parte das várias etapas do processo. Se não for o caso, é hora de repensar e reestruturar seus modelos de desenvolvimento.
O que testar?
Essa é outra questão que muitas vezes surge, e é uma dúvida legítima, mas, neste primeiro momento, vamos entender um conceito necessário.
O desenvolvimento de software, como qualquer processo, é a combinação de pessoas, processos e tecnologia. Então, nada mais justo do que termos como base para nossos testes estes três pontos.
Vamos seguir falando um pouco de cada um deles.
Pessoas, Processo e Tecnologia.
Precisamos “testar” as pessoas para sabermos se elas têm o conhecimento e as condições básicas, ou mesmo os conhecimentos básicos para trabalhar e produzir um software de qualidade e seguro.
Temos que ter o pensamento que segurança é de responsabilidade de todos, desenvolvedores, engenheiros, arquitetos e até mesmo dos “donos” do produto, que muitas vezes não entendem sua importância no processo.
Pessoas são parte fundamental de todo o processo e precisam ser olhadas com este grau de importância. Sendo assim, ter um programa de educação e treinamento é um dos primeiros passos para garantir a segurança do software.
Este é um ponto muito importante. Para citar um exemplo, um processo de desenvolvimento da Microsoft entende que:
“Effective training will complement and re-enforce security policies, SDL practices, standards, and requirements of software security, and be guided by insights derived through data or newly available technical capabilities.”
Ou seja,
O treinamento efetivo completará e reforçará as políticas de segurança, as práticas do SDL, os padrões usados, e os requisitos de segurança de software, e será suportado por dados e ou capacidade técnicas disponíveis.
Sobre o processo
Um processo precisa ser avaliado. Durante o processo de avaliação, podemos entender se este processo está ou não sendo eficiente e entregando o que realmente foi pensado.
Com relação à segurança, o processo precisa ser avaliado para se ter a certeza de que está adequado às políticas e/ou mesmo aos requisitos determinados por padrões que a empresa espera seguir. Além disso, precisamos avaliar se as pessoas sabem como seguir ou mesmo executar as políticas criadas para o processo.
Sobre tecnologia, precisamos ter a certeza que o processo está sendo eficiente em sua implementação.
Não faz sentido termos em nosso processo um conjunto de ferramentas e tecnologias que, na verdade, estão causando mais perda do que ganhos em seu uso. Sendo assim, a avaliação destas tecnologias e como elas são usadas é de extrema importância para que todo o conjunto consiga entrega o seu melhor.
Ao testar as pessoas, processos e tecnologias as empresas podem identificar problemas que mais tarde podem aparecer como problemas e defeitos.
Assim, vamos seguir e falar um pouco mais sobre testes.
Conceitos básicos
Há alguns equívocos que temos observado quando vamos desenhar e estrutura um processo de testes – é o que vamos abordar agora.
Não existe uma solução tipo “Silver Bullet”
É comum encontrarmos em várias empresas diversas ferramentas, cada uma com suas características e com suas especialidades.
E é tentador imaginar que uma ferramenta, como um scanner de segurança, tenha o poder de, por meio de testes realizados em nosso código, identificar todas as vulnerabilidades que por ventura possam existir.
No entanto, a realidade é bem diferente. Não existe um tipo de solução mágica que fará com que sua aplicação ou mesmo seu código estejam seguros apenas com o uso destas ferramentas.
Não podemos desacreditar as ferramentas, mas temos que entender como elas funcionam e quais são suas limitações.
Os softwares de avaliação de segurança de aplicações e códigos, embora sejam muito úteis em um primeiro momento, pois ajudam a identificar falhas e erros mais comuns, se mostram ineficientes ou mesmo com baixa taxa de resultados quando o assunto é avaliações aprofundadas. Além disso, neste aspecto, muitas delas não fornecem uma cobertura de teste adequada.
Temos que lembrar que, como muito bem colocou Bruce Schneier, segurança é um processo, e não um produto.
Pense estrategicamente e não taticamente
Na década de 1990, tínhamos um processo de correção bem diferente do que temos hoje. O que tínhamos era um processo de correção focado em corrigir a vulnerabilidade quando ela se apresentava, sem nos preocuparmos com a real fonte do problema.
Este “processo” ficou conhecido como patch-and-penetrate.
Mas não podemos colocar isso como um erro. Afinal, tudo deve ser analisado de acordo com o cenário daquele momento. Por exemplo: na década de 90, falhas em aplicações web não eram tão críticas, visto que as aplicações web nem eram o foco da época. Afinal, o foco eram as infraestruturas.
No entanto, ainda nos dias de hoje, em que grandes negócios são fortemente baseados em aplicações web, ainda encontrarmos esse tipo de postura para as correções.
Procure a causa raiz
Durante o processo de correção de uma aplicação web, precisamos identificar a causa raiz do problema, e não simplesmente aplicar uma correção. Afinal, sem saber o que levou à este problema, nada será resolvido da forma correta.
Neste momento, dois pontos devem ser colocados. O primeiro mostra que este assunto já vem sendo levantado há algum tempo. Por exemplo: em uma de suas publicações, Bruce Schneier – novamente ele – nos apresenta ao termo windows of exposure, termo que ele criou para mostrar uma janela, um período de tempo existente entre a descoberta de uma falha e sua correção. A imagem abaixo pode nos ajudar a entender o conceito.
O que temos observado é que, infelizmente, o tempo entre a descoberta da vulnerabilidade e a correção não tem acompanhado o ritmo e a velocidade com que as aplicações são lançadas e novas funcionalidades implementadas. Afinal, como comentamos lá no início, o mercado não dá prêmios para o software de qualidade.
Para reduzir e melhorar essa visão, é fundamental que o processo de SDLC seja revisto e avaliado para saber se todos os conceitos de desenvolvimento seguro estão sendo utilizados e em seu devido lugar e tempo.
Com esse tipo de abordagem, temos a certeza que conseguiremos reduzir a quantidade de vulnerabilidades. Colocar segurança em todo o processo, e cada vez mais no início do processo é verdadeiramente o conceito de Shift Left, não o de introduzir cada vez mais ferramentas na etapa de desenvolvimento, acreditando que estas ferramentas resolverão o problema. O restante, pra gente, parece um voo de galinha.
SDLC
Desenvolvedores podem construir um processo de desenvolvimento SDLC fortemente baseado em políticas, práticas e padrões de melhores práticas. Isso tudo, é claro, sem esquecer as ferramentas que são importantes aliadas.
A construção de um SDLC permite uma visão mais abrangente de todo o pipeline do processo, permitindo que a equipe de desenvolvimento tenha uma visão mais holística.
O importante é entender que cada uma das fases possui seus próprios princípios e testes de segurança. O fato é que, quanto mais cedo nos preocupamos com a segurança do código, e consequentemente com a realização de testes, mais efetivo – tanto em processo quanto em custo – o SDLC se tornará.
Entenda que aqui não há uma indicação de uso de um ou de outro modelo de SDLC – existem vários. Usamos o da Microsoft por já estar incorporado em nosso processo de validação e construção de SDLC, mas você pode escolher outro ou mesmo construir o seu, o importante é entender os conceitos.
Outra boa alternativa pode ser o uso do modelo desenvolvido pela OWASP chamado SAMM, que hoje está em sua versão 2, e aqui no blog estamos tendo uma série de artigos sendo criado sobre este modelo.
Mas como falamos, existem outras, basta que o conceito de ter testes de segurança nas fases iniciais seja mantido.
Esse princípio nos leva a outro ponto.
Teste mais cedo e teste sempre
É um princípio básico, quanto mais cedo você conseguir identificar um erro ou mesmo uma falha, mas barato será para corrigir esta falha. Pode até parecer simples e lógico – mas por que, então, ainda temos tantos processos de desenvolvimento que não têm este princípio incorporado?
Um dos gaps que percebemos é que quanto mais há treinamento e educação para desenvolvedores e testadores, mais consciência estas equipes têm de colocar os testes de segurança de forma mais recursiva e cedo no processo. Então aí vai nosso primeiro ponto: invista em treinamento e educação, isso vai trazer bons ganhos de eficiência dentro do processo. Falamos um pouco sobre isso em outro artigo nosso.
Além disso, com os treinamentos, os próprios participantes destas equipes passarão a desenvolver um mindset diferente, olhando mais diretamente para o processo como um todo e percebendo que podem contribuir e mudar, mas mantendo sempre os mesmos princípios.
Pense em automação
Não é difícil de identificar que nas metodologias mais modernas – e aqui vamos tratar de DevSecOps – não podemos trabalhar de forma escalável e eficiente sem o uso de ferramentas.
E neste ponto não podemos confundir com o conceito de que não há “bala de prata” que falamos mais acima, as ferramentas são importantes e tem seu lugar no processo, o que não podemos é entregar a segurança somente a elas.
Feito o adendo, temos que buscar integrar as ferramentas necessárias para nos ajudar a cada vez mais cedo identificar os pontos de falha em nosso código. Para isso precisamos pensar em como e quais serão as ferramentas de teste que serão integradas ao nosso pipeline de CI/CD (Continuous Integration/Continuous Delivery).
Tenha uma visão geral de segurança do projeto
É inevitável – precisamos, antes de começar a construir nosso código, entender quais são as necessidades de segurança dessa nova aplicação. Essas necessidades também se aplicam a quaisquer requisitos que nossa aplicação deverá cumprir.
Sendo assim, conhecer e ter a visão de quais regulamentos, contratos ou qualquer outro requisito é importante. Só assim depois poderemos criar e planejar testes que possam vir a garantir tais requisitos.
No entanto, um cuidado deve ser tomado neste caso. O objetivo é entender quais os requisitos que a aplicação deve cumprir, então não é necessário colocarmos mais segurança do que é necessário.
Colocar complexidade dentro da aplicação também pode ser um problema. Por isso, temos que buscar equilibrar a segurança com a complexidade do código, para facilitar os testes a serem realizados, além de trazer menos possibilidades de erros.
Conclusão
Depois de passarmos a maioria dos conceitos iniciais que entendemos como necessários, acreditamos que agora estamos mais preparados para dar continuidade nos próximos temas quando o assunto é testes.
Entendemos que todos os conceitos que aqui foram colocados contribuem diretamente para já uma boa avaliação de um processo de testes já existentes. Na próxima semana, abordaremos os testes do pipeline.
Então até lá!
