O controle de qualidade- QA e a segurança da informação – Infosec usam métodos diferentes para atingir os mesmos objetivos. Quando os dois grupos trabalham juntos, eles podem proporcionar uma maior na segurança dos produtos desenvolvidos. Descubra como a equipe de QA pode colaborar com a Infosec para implementar padrões de segurança fortes, priorizar o que testar e obter feedback mais rápido sobre os processos, observando menos incidentes de produção relacionados à segurança.

O controle de qualidade é frequentemente solicitado para diminuir a porcentagem de bugs, o que significa que é obrigação da equipe testar o maior número possível de possíveis bugs. Muitos consideram incontroverso perseguir uma ampla variedade de casos de teste, desde o esperado até o inesperado e possivelmente até malicioso. 

Mas quantos se sentem à vontade sentados diante do auditor e conversando sobre testes de segurança? Essa é uma situação que encontramos várias vezes. Esse medo é particularmente real se a empresa não possui requisitos sólidos de segurança ou não os aplica a todos os projetos. O controle de qualidade precisa conversar com a segurança da informação para garantir que tudo esteja certo.

A equipe de segurança da informação também tem um problema: como eles podem garantir que os requisitos de segurança foram atendidos? Testadores de penetração, equipes vermelhas e varredura dinâmica são formas poderosas de encontrar as falhas em seu software, mas são frequentemente aplicadas após o lançamento em produção, quando o software já está disponível para os usuários. As ferramentas de análise estática oferecem algumas opções mais fáceis para testar a pré-produção, e a necessidade de certificação em algumas indústrias regulamentadas pode fazer alguma diferença para elevar o sarrafo para os invasores.

Todas essas atividades são boas práticas, mas podemos descobrir que elas não vão suficientemente longe. Muitos dos nossos bugs de segurança estavam aparecendo após o lançamento da solução, causando angústia para os testadores e frustração para os negócios. 

Foi assim que me encontrei alguns anos atrás: Com um novo bug de segurança, tinha um caso de negócios nas mãos, e eu deveria ter tempo para me concentrar em encontrar mais desses bugs e muito pouco conhecimento de como fazê-lo com eficiência. Já tínhamos práticas de teste baseado em risco (RBT), mas eu não tinha ideia no momento de como isolar os riscos de segurança. Estava na hora de desenvolver novas habilidades. Estudei, fiz pesquisas e conversei com a Equipe de Segurança. Eles me ensinaram o básico da modelagem de ameaças.

Os testadores já sabem que, se você testar apenas onde acha que podem estar os problemas, perderá falhas sutis que podem se tornar críticas na produção. As práticas típicas de RBT não incluem preocupações de segurança e geralmente não levam mais do que uma olhada superficial na arquitetura do projeto. O objetivo é testar primeiro as prioridades mais altas, portanto, se uma prática de RBT não estiver alcançando as prioridades mais altas, a prática será seriamente falha. A adição de um modelo de ameaça fornece uma imagem muito mais completa e pode reorganizar totalmente as prioridades dos testes. 

Começamos obtendo um diagrama de fluxo de dados para o sistema em teste. Como exemplo vamos usar um aplicativo Web, incluindo uma tela de login, uma consulta em um banco de dados e a capacidade de imprimir o relatório gerado. Se eu pensasse na prioridade com base nisso, provavelmente testaria o login primeiro, motivado pela experiência com problemas em sistemas de autenticação, seguido pela consulta ao banco de dados.

A aplicação de uma metodologia de modelagem de ameaças – não importa qual você use, desde que funcione para seu sistema e sua empresa – mostrou que, embora possamos ter escolhido a funcionalidade de login como nosso risco mais alto, com base na experiência e na intuição, na realidade a maior prioridade era a proteção de dados confidenciais do cliente. Além disso, todos os itens de prioridade mais alta foram encontrados pelo modelo de ameaça, não pela matriz RBT inicial.

Precisávamos de uma maneira de priorizá-los ainda mais, para aproveitar ao máximo os recursos que são limitados. Esse foi um tipo diferente de mudança, não avançar o controle de qualidade na cadeia de desenvolvimento, mas introduzir testes de segurança mais cedo do que seria iniciado.

Essa resposta foi encontrada em padrões de segurança robustos. Modelos como o OWASP Top Ten e o CWE Top 25 podem apresentar uma lista de vulnerabilidades a serem avaliadas e removidas do software. Descobrimos que cada ponto de um padrão e cada item de uma lista geravam pelo menos um caso de teste. Desenvolvi casos de teste genéricos a partir desses padrões para permitir que outros testadores acessem facilmente os requisitos e começamos a implementá-los.

Obviamente, não podemos ignorar nossos testes funcionais para nos concentrarmos estritamente na segurança! Isso adiciona muitos casos de teste e normalmente são itens que levam tanto tempo quanto exigem muita experiência. Descobri rapidamente que uma pessoa não podia apoiar todos os projetos e que os outros testadores da equipe não tinham o conhecimento para fazer o básico sem orientação.

Nossa solução foi mais uma vez a colaboração. Nossa Infosec havia iniciado um programa de defensores da segurança. Outras pessoas assumiram o papel em outras partes da organização e isso levou a um novo caminho para os testadores obterem informações vitais. Não apenas poderíamos direcionar perguntas para os defensores da segurança, mas a criação de uma segunda função de segurança do controle de qualidade exigiu muito trabalho. 

Fechamos o ciclo de feedback levando as informações de volta à Infosec. O QA já sabia quantos bugs tiveram impactos na segurança; agora compartilhamos suas resoluções e recebemos relatórios das verificações que já estavam sendo executadas.

O que vimos é que, após alguns meses de trabalho, as equipes que implementavam os processos de teste de segurança encontravam menos bugs, e de menor gravidade, do que aqueles que não implementavam esses processos. Não apenas isso, mas eles também tiveram menos incidentes de produção relacionados à segurança do que equipes que não tinham práticas deliberadas de teste de segurança. 

Suponho que as dificuldades sejam o motivo pelo qual o teste de segurança no controle de qualidade é uma prática incomum. Com os efeitos que vimos, posso dizer com confiança que, embora esse seja um caminho difícil a seguir, ele leva a bons resultados.

Este texto é uma adaptação livre do artigo publicado por Sylvia Killinen em https://www.stickyminds.com/article/integrating-security-and-testing-practices

Entre em contato conosco, nós podemos te ajudar a implantar um processo de Testes completo e eficiente. www.tecnisys.com.br