Três abordagens para empregar ‘hackers do bem’ em sua organização

No jargão da segurança cibernética, hackear normalmente tem um sentido negativo, ou seja, de penetrar indevidamente, extrair informações ou perverter o uso de sistemas cibernéticos por meio de manipulações não autorizadas a eles. Isso, em princípio, é mau. Mas existe também uma visão boa dessa ação.

Como são descobertas possíveis vulnerabilidades em sistemas? O que seria dos seus aplicativos (e de você, mesmo) se não fossem os testes de hackeamento, o chamado hacking ético?

Em qualquer aplicação – ou sua nova funcionalidade – é imprescindível, antes do seu lançamento, a identificação de vulnerabilidades a partir de testes de segurança, e as consequentes correções e retestes.

Os testes de penetração, também conhecidos como pentests, ou Ethical Hacking Tests (EHTs), são uma forma ofensiva de desafiar a segurança de um projeto. O objetivo é conseguir, a partir deles, uma visão profunda das vulnerabilidades e dos relativos riscos à segurança de um sistema ou ambiente. Não estamos falando aqui de testes automatizados, mas de um processo mais aprofundado, baseado em testes individualizados, que contam com a experiência e conhecimento de profissionais gabaritados para simular ataques com vistas aos mais diversos tipos de fraude ou roubo de dados.

Leia também: Teste de penetração explicado: como hackers éticos simulam ataques

Tal abordagem possui inúmeras vantagens frente aos testes de scanner, pois traz uma visão mais profunda e com viés de negócios, imprescindíveis na busca – e correção – de fragilidades que possam comprometer a segurança e a privacidade de uma aplicação.

Essa verificação externa pode ser completamente “cega”, a chamada Black Box, em que os profissionais encarregados não conhecem nada do sistema testado. Como também há os testes sob a perspectiva Gray Box, com o conhecimento parcial, simulando, por exemplo, um ataque realizado por um usuário final da aplicação; e o White Box, que contempla o conhecimento completo do ambiente, inclusive do código fonte.

As três abordagens são válidas. Podem e devem ser utilizadas de acordo com os objetivos dos testes, visando prevenções a fraudes “especializadas” no segmento de negócios da empresa, como saúde, educação — e os mais visados — financeiro e meios de pagamento, por exemplo.

Eles precisam responder a questões como:

• Que estratégia um criminoso usaria para ter acesso ao sistema e realizar uma fraude?
• Como são protegidas as informações confidenciais e pessoais?
• Quais as funcionalidades que apresentam maior risco do ponto de vista da segurança cibernética?
• Existe integração com algum outro sistema que apresente risco? Quais são esses riscos?
• Qual o impacto das vulnerabilidades identificadas, e quais estratégias para tratar os riscos?

As boas práticas mais recentes estão associadas à realização de testes já no estágio de desenvolvimento, mas é também fundamental que eles sejam feitos periodicamente, idealmente a cada nova atualização do sistema ou sempre que houver uma mudança em requisitos normativos – sejam eles internos, em razão de alterações no funcionamento da empresa, ou devidos a novas regulamentações e normativas legais.

O relatório especializado resultante dessa avaliação, que apresenta as vulnerabilidades encontradas com o relativo impacto e formas de mitigá-las, é, algumas vezes, solicitado em auditorias de conformidade. Porém, mais do que cumprir exigências, as empresas cada vez mais têm consciência de que não podem descuidar da segurança cibernética, sob pena de prejudicar seriamente seus negócios e sua imagem. Está muito claro, na economia digital em que vivemos, que segurança e negócios não se dissociam.

* Matteo Nava é CEO da Berghem