Com os levantamentos em mãos, os riscos de segurança endereçados e os testes automatizados realizados, ainda temos o lado humano que não conseguimos remover, que é o entendimento dos fluxos de negócio e a tentativa de quebrá-los, subverter essas lógicas ou inverter os fluxos propostos, tudo isso fazemos através do Pentest.

O teste de intrusão - penetration test (Pentest) - “busca detectar de forma minuciosa através de técnicas utilizadas pelos especialistas em segurança (ofensiva ou Appsec), visando encontrar potenciais vulnerabilidades no sistema em questão, seja um serviço web, API, mobile ou infraestrutura, utilizando ferramentas e técnicas específicas que possam provar em seus resultados que os dados ou informações da corporação estão expostas” ou com risco elevado de serem utilizados de forma incorreta e até criminosa.

Temos algumas formas de realizar esses testes, comumente chamadas de testes blackbox, graybox e whitebox, como os nomes sugerem, ao realizar um teste blackbox, nós não possuímos muita informação sobre a superfície que será testada, muitas vezes resumidas ao endereço IP ou endpoint, no outro lado temos os testes do tipo WhiteBox, que já nos dão diversas informações, documentações e algumas vezes explicações dos fluxos, features e arquitetura, facilitando as descobertas e sobre o que estamos tratando; entre estes extremos temos o GrayBox que é um misto dos anteriores, onde não temos tanta informação quanto no white e nem tão limitado quanto um blackbox.

É através desses testes que conseguimos validar se as ameaças endereçadas no levantamento de requisitos e modelagem de ameaça foram corrigidas ou evitadas ou se conseguimos materializar o risco apontado, transformando-o assim em uma vulnerabilidade nesse sistema. Isso permite que os times envolvidos na criação conheçam melhor suas fraquezas, onde precisam melhorar e diminuem as possibilidades de ataque ou vazamento, quando essa feature ou sistema chegar no ambiente produtivo.

Ao detectar as vulnerabilidades, geramos um relatório contendo as evidências e explicações de como foi possível materializar o risco e explorar a vulnerabilidade citada. Após esta atividade ser finalizada pelo especialista que está conduzindo o teste, iniciamos o processo de Gestão de vulnerabilidades, onde informamos aos times e todos os responsáveis, para que todas as pessoas estejam cientes e possam endereçar para quem é de direito, criar uma correção (patch) ou buscar formas de contornar e mitigar o risco; em última instância, podemos assumir esse risco por diversos aspectos, por exemplo, a remediação ser mais cara que a perda resultante do abuso dessa vulnerabilidade, negócio entender que não é uma prioridade a correção, alta gestão assumir o risco e seguir com a vulnerabilidade, entre outras inúmeras possibilidades que podem acontecer, apesar de que o melhor caminho é sempre corrigir a vulnerabilidade, pois dessa forma garantimos que esse vetor não será utilizado para prejudicar a corporação em uma escala menor ou maior.

Indiferente da decisão que venha a ser tomada, o especialista realiza todo o acompanhamento da vulnerabilidade, desde a descoberta até o fechamento dela através de retestes, onde podemos validar que as ações de correção surtiram o efeito desejado e sanaram o problemas ou que as barreiras mitigatórias diminuíram o impacto ou criaram uma barreira suficiente para que a vulnerabilidade não seja explorada da maneira identificada, apesar de continuar existindo e podendo ser explorada de outras formas.

Durante todo o ciclo de desenvolvimento nós buscamos ferramentas e processos que nos auxiliem na escala de testes, onde conseguimos de certa forma acompanhar a evolução do desenvolvimento e finalizar com os testes de intrusão por meio do especialista, o que nos permite propagar sempre a cultura de construção de sistemas mais seguros e a correção precoce dos riscos encontrados, através de uma gestão eficiente e próxima de todos os participantes desse desenvolvimento.