O que tem de estar configurado antes de acreditar na taxa de cliques

Uma simulação de phishing foi enviada a dez mil pessoas. O relatório fechou com nove mil e quinhentas aberturas e nove mil cliques. Um 95% de abertura e um 90% de cliques não são números que um grupo de pessoas produza.

Esse resultado apareceu mais de uma vez nos primeiros anos da SMARTFENSE, quando as simulações eram lançadas sem preparar o ambiente. O que mostrava era uma ferramenta de email security que abria e visitava as mensagens antes de chegarem ao destinatário. Esse relatório media as defesas de correio da organização.

Quando um resultado não fecha, a conversa chega à minha equipa. E a primeira pergunta que fazemos aponta para a entrega de simulações de phishing nessa organização antes de apontar para as pessoas, por onde entrou a mensagem, quem lhe tocou antes da caixa de correio e o que o cliente de correio pôde carregar quando o colaborador a abriu. A explicação está quase sempre aí.

O que mede realmente uma simulação de phishing?

Cada métrica de uma simulação é uma medição conjunta de duas coisas, a decisão da pessoa e o estado do ambiente por onde passou a mensagem. Conseguir separar as duas é a condição para interpretar o resultado.

Uma taxa de cliques de 4% pode significar que a organização aprendeu a desconfiar. Também pode significar que metade das mensagens nunca chegou ao destino. Os dois cenários produzem o mesmo número e pedem decisões opostas.

Convém esclarecer o que está a ser posto à prova. As ferramentas de email security têm a sua própria avaliação e uma equipa dedicada que as acompanha. A simulação existe para medir a camada que fica quando essas ferramentas não chegam, que é a pessoa diante da mensagem. Se as barreiras travam a armadilha, o exercício deixa de informar sobre aquilo que foi procurar, e vale recordar que uma campanha é desenhada para mudar comportamento e não para auditar a segurança do correio.

Porque é que a simulação não chega à caixa de entrada?

Entre a plataforma e a caixa de correio do colaborador existem várias camadas de controlo, e qualquer uma delas pode travar a mensagem. Prepará-las é o que se conhece como whitelist, e tem um detalhe de que quase ninguém se lembra: divide-se em duas metades.

A primeira metade é a entrega do correio, que se resolve declarando os endereços IP e os domínios de envio nas ferramentas que analisam o correio recebido. A segunda é a navegação, porque o colaborador que clica acaba num site de phishing simulado que também pode estar bloqueado. Essa metade exige autorizar os domínios de navegação no navegador, nas suas extensões e nas ferramentas de cibersegurança do posto de trabalho. Uma campanha com a primeira metade resolvida e a segunda pendente entrega as mensagens e perde todos os cliques.

Há três formas de o declarar, por endereço IP, por domínio e por cabeçalho da mensagem. A terceira aparece quando existe uma ferramenta de segurança à frente do servidor de correio que reescreve o IP de origem. Nesse cenário declarar os nossos endereços não basta, porque o que chega ao servidor já é outro, e a mensagem é identificada pelo seu cabeçalho.

A lista atualizada de IP e domínios vive dentro da plataforma, em Configuração › Segurança › Whitelist, e está também nos requisitos mínimos publicados. Convém consultá-la no dia da campanha e não no do arranque do projeto, porque muda quando mudam os servidores de envio.

A injeção direta substitui a whitelist?

Direct Message Injection é um método de entrega alternativo. Em vez de viajar por SMTP e atravessar todas as camadas, a mensagem é inserida diretamente na caixa de entrada através de uma ligação segura por API com o fornecedor de correio, disponível para organizações que trabalham com Microsoft ou com Google.

Resolve três coisas. A primeira é a entrega, ao ponto de em alguns casos eliminar a necessidade da whitelist de correio. A segunda são os avisos que alguns clientes acrescentam de forma automática sobre a mensagem e que alertam o colaborador antes de ter oportunidade de decidir. A terceira é a fragilidade da configuração, porque a atualização de uma ferramenta de segurança pode invalidar uma whitelist que estava a funcionar.

O que não resolve é a segunda metade. O site de phishing simulado continua do outro lado das ferramentas de navegação, e a filtragem posterior à entrega pode mover a mensagem depois de depositada. É a conclusão a que já chegava o artigo que apresentou o DMI neste blogue, e continua de pé. A injeção direta reduz a superfície de configuração sem a fazer desaparecer.

Porque é que a abertura é a métrica mais frágil?

A plataforma conta uma abertura quando o cliente de correio do destinatário mostra a mensagem e carrega um pixel transparente que leva uma referência única a essa pessoa. Desse pixel dependem as estatísticas de abertura em campanhas de newsletters, phishing, ransomware e momentos educativos.

Numa implementação nova o sintoma aparece sempre igual. As mensagens chegam bem à caixa de entrada, os colaboradores abrem-nas, e a estatística de aberto não fica registada. A causa está no cliente de correio, que não tem autorização para mostrar imagens, e como o pixel é uma imagem nunca chega a carregar. O nosso próprio guia de requisitos mínimos di-lo sem rodeios, se o cliente bloquear imagens as estatísticas de abertura serão inferiores às reais.

A correção aplica-se ao nível de toda a organização, com a lista de remetentes seguros aplicada por política central ou por linha de comandos, em vez de pedir a cada pessoa que autorize as imagens na sua conta.

O desvio também acontece na direção contrária. As proteções de privacidade do correio carregam o conteúdo remoto por sua conta. A Apple documenta que, com essa proteção ativa, o conteúdo remoto é descarregado em segundo plano ao receber a mensagem e não ao abri-la. O pixel carrega sem que ninguém tenha lido nada e a abertura fica contada de igual modo.

Com os dois desvios em jogo, a abertura apenas chega para confirmar que a entrega funcionou. As métricas que sustentam uma decisão são as que exigem uma ação deliberada da pessoa, o clique no link, a introdução de dados no site simulado e o reporte da mensagem. São essas que convém levar ao painel quando se define o que o programa está a medir.

Quando é que o número que sobe não é uma pessoa?

Um falso positivo é uma estatística gerada por software e registada em nome de um utilizador. É o que estava por trás do caso do primeiro parágrafo, e chega por três vias, as ferramentas corporativas que analisam o correio da organização, as ferramentas pessoais instaladas nos dispositivos que acedem a esse correio e outro software que intervém na mensagem, como extensões do navegador ou a pré-visualização de links.

Quem administra o correio de uma organização conhece a lista de suspeitos: filtros antispam, antivírus, DLP, gateways de segurança, IDS/IPS, análise contínua de links e suplementos da caixa de entrada. Nenhum deles está a fazer nada indevido. Estão a fazer o seu trabalho sobre uma mensagem que parece um ataque, porque foi construída para o parecer.

A plataforma deteta e filtra estes casos com um algoritmo que destaca as campanhas afetadas, informa a origem das estatísticas geradas por software e permite ajustar os seus parâmetros às ferramentas de cada organização. As interações detetadas ficam fora dos resultados finais, pelo que as estatísticas e os registos de auditoria contêm apenas o que as pessoas fizeram. A origem e as soluções dos falsos positivos estão desenvolvidas neste blogue.

O ponto importa a jusante. Esse mesmo dado alimenta a pontuação de risco por pessoa. Um falso positivo sem filtrar não fica dentro do relatório mensal. Move a pontuação de alguém que não fez nada, e essa pontuação decide depois quem recebe formação adicional.

O que verificar antes da primeira campanha?

São seis pontos, na ordem em que convém resolvê-los.

1. Entrega declarada nas ferramentas que analisam o correio recebido, por endereço IP, por domínio ou por cabeçalho conforme o que esteja à frente do servidor de correio.
2. Navegação autorizada para os domínios da plataforma no navegador, nas suas extensões e nas ferramentas de segurança do posto de trabalho.
3. Lista atualizada consultada em Configuração › Segurança › Whitelist no dia da campanha, não no do arranque do projeto.
4. Imagens visíveis no cliente de correio, aplicado por política central a toda a organização em vez de utilizador por utilizador.
5. Deteção de falsos positivos ativa, com os parâmetros ajustados às ferramentas que a organização tem instaladas.
6. Uma campanha piloto a um grupo reduzido antes da primeira medição geral, revendo as mensagens entregues, as aberturas e os cliques em busca de coincidências suspeitas.

A revisão não se faz uma só vez. Cada atualização do stack de segurança pode invalidar uma configuração que estava a funcionar, e o melhor momento para o descobrir é um piloto de cinquenta pessoas, não a campanha cujos resultados vão para o comité.

Perguntas frequentes

Porque é que as simulações de phishing não chegam à caixa de entrada?
Porque entre a plataforma que as envia e a caixa de correio do colaborador existem várias camadas de controlo que analisam o correio recebido e podem travar a mensagem. Preparar essas camadas exige declarar os endereços IP e os domínios de envio, e fazê-lo por endereço IP, por domínio ou por cabeçalho da mensagem conforme a ferramenta que esteja à frente do servidor de correio.

É preciso configurar whitelist se usar injeção direta de mensagens?
Sim, ainda que menos. A injeção direta resolve a entrega do correio e, em alguns casos, elimina a necessidade de whitelist nessa metade. A navegação até ao site de phishing simulado continua a exigir que os domínios estejam autorizados no navegador, nas suas extensões e nas ferramentas de segurança do posto de trabalho.

Porque é que a abertura não fica registada se o colaborador abriu a mensagem?
Porque a abertura é contada quando o cliente de correio carrega um pixel transparente, e esse pixel é uma imagem. Se o cliente não mostrar imagens, a mensagem é lida mas a abertura não fica registada. Resolve-se autorizando a visualização de imagens por política central em toda a organização.

O que é um falso positivo numa simulação de phishing?
É uma estatística gerada por software e registada em nome de um utilizador. É produzida por ferramentas corporativas que analisam o correio da organização, por ferramentas pessoais instaladas nos dispositivos que acedem a esse correio e por outro software que intervém na mensagem, como extensões do navegador ou a pré-visualização de links.

Que métricas de uma simulação servem para tomar decisões?
As que exigem uma ação deliberada da pessoa, o clique no link, a introdução de dados no site simulado e o reporte da mensagem. A abertura apenas chega para confirmar que a entrega funcionou.

Se estás a preparar a primeira campanha, os requisitos mínimos estão publicados e a lista atualizada de IP e domínios vive dentro da plataforma. Meia hora de revisão antes do envio evita a conversa incómoda sobre se o número do relatório é de confiança.