O percurso de um email reportado, das 11:23 às 11:27

Diagrama de linha temporal com quatro momentos, das 11:23 às 11:27, que mostra o percurso de um email reportado desde o botão de reporte até à decisão da equipa de segurança

O percurso de um email reportado, das 11:23 às 11:27

Quarta-feira, 11:23. A Lucía recebe um email que parece vir da área de IT e que lhe pede para atualizar as credenciais de VPN antes do meio-dia. Algo não lhe encaixa. Prime o botão de reporte e volta ao que estava a fazer.

É tudo o que ela faz. A peça anterior desta série deixou em aberto que o hábito de reportar só se sustenta se reportar tiver uma consequência que a pessoa consiga perceber, e que essa consequência depende de quanto tempo um email real demora a ter resposta. A análise automática de emails reportados é o que comprime essa espera, e aqui está o seu percurso passo a passo, sem tecnicismos. Os horários e os números são os de uma organização concreta, a mesma das peças anteriores, e não médias do setor.

Qual é a primeira coisa que se verifica quando entra um email reportado?

A primeira coisa é se foi o teu próprio programa que o enviou. É a única pergunta que a plataforma consegue responder sem investigar nada, porque tem o registo de cada simulação de phishing que enviou, e por isso vem primeiro.

Quando a resposta é sim, o caso fecha-se de imediato. A plataforma reconhece o acerto à pessoa, soma-o à sua pontuação e não fica nada para analisar. O email da Lucía não é uma simulação, por isso o percurso continua.

O que verifica a análise de um email reportado?

11:24. A partir daqui o email é analisado de forma automática, com o mesmo detalhe com que o examinaria alguém da equipa de segurança, mas sem que ninguém tenha de o abrir.

Verifica-se se o email vem de onde diz vir ou se alguém está a fazer-se passar por uma empresa conhecida. Segue-se cada link até ao seu destino final, porque um link pode mostrar um endereço e levar a outro. Examinam-se os anexos, incluindo o clássico que aparenta ser uma fatura e não o é.

E olha-se para as imagens da mensagem. É aí que hoje se esconde boa parte do que o email security não consegue ver. Um código QR ocupa o lugar do link e uma captura de ecrã ocupa o lugar do texto, por isso uma análise que só lê o texto passa ao lado dos dois casos.

Uma análise que só lê o texto de um email não vê o ataque que vem dentro de uma imagem.

Como simular esse ataque para treinar as tuas pessoas já está tratado no artigo sobre qrishing deste blogue. Aqui o código QR vem num email que alguém já reportou, e o que há para fazer com ele é decidir o que é.

E quando a evidência técnica não é suficiente?

Há emails que a evidência não resolve. O remetente é legítimo, os links não constam de nenhuma lista, não há anexos, mas a mensagem pede algo que não encaixa, com uma urgência que também não encaixa. É a zona cinzenta onde até agora era preciso o critério de uma pessoa.

Para esses casos há um agente de inteligência artificial que analisa o que o email diz e como o diz, desde a urgência e a pressão até ao pretexto que usa para justificar o pedido. Não substitui a verificação técnica. Entra quando essa verificação fica curta, que é exatamente onde se acumulavam os reportes difíceis.

No email da Lucía a evidência é mais do que suficiente. O domínio do remetente foi registado há 48 horas, os links apontam para um servidor num país onde a empresa não opera e a autenticação do remetente falha.

Veredicto: phishing. Pontuação de risco: 92 em 100.

O que recebe a equipa de segurança quando a análise termina?

11:25. À equipa de segurança chega um resultado em vez do email para abrir. São três coisas.

  • Um veredicto. Phishing real ou falso alarme.
  • Uma pontuação de risco de 0 a 100. A prioridade, sem ser preciso ler mais nada.
  • Uma explicação do porquê, escrita no idioma de quem a lê.

A terceira é a que muda quem pode trabalhar com o reporte. A explicação não chega na linguagem de um cabeçalho de email, chega em frases como «o anexo esconde o seu tipo de ficheiro real» ou «as respostas a este email iriam para um endereço diferente do do remetente». Não é preciso saber ler um email por dentro para as entender, e isso significa que o reporte deixa de esperar pela única pessoa da equipa que o sabe fazer.

O que acontece aos emails reportados que se revelam inofensivos?

O email da Lucía era phishing, mas a maioria não é. No mês de que falámos, 160 dos 183 emails reportados revelaram-se inofensivos. Uma fatura real que parecia estranha, uma promoção, o email de um fornecedor novo que ninguém tinha em agenda.

É o que acontece quando as pessoas estão atentas. Uma organização que trata o falso alarme como um custo acaba a ensinar as suas pessoas a não reportar. Quem hesitou diante de um email legítimo fez exatamente o que lhe foi pedido.

O que muda com a análise automática é que esses 160 emails também recebem o seu veredicto e fecham sem consumir tempo a ninguém. Deixam de ser a pilha debaixo da qual esperam os 23 que eram de facto ataques.

Quanto dura o percurso completo?

11:27. Quem está de serviço abre o reporte, encontra a análise já feita, confirma o veredicto e ativa o protocolo de resposta. A decisão continua a ser sua. O que mudou é que já não tem de construir a evidência para a poder tomar.

E o protocolo não tem de esperar por essa confirmação. Um Playbook é um conjunto de ações que se executam sozinhas quando ocorre um evento determinado, por isso o veredicto pode encadear as primeiras sem que ninguém as lance.

Pode ser um aviso à equipa por email, por Slack ou por Microsoft Teams, e uma chamada aos sistemas que tenhas integrados, para que a contenção comece enquanto a pessoa de serviço analisa o caso. Onde colocar esse limite decide cada organização, porque há respostas que convém que arranquem sozinhas e outras que não se movem até que alguém olhe.

Entre o momento em que a Lucía premiu o botão e o momento em que a equipa de segurança começou a atuar passaram quatro minutos. Com a fila de 47 reportes de que falámos na primeira peça da série, teriam sido três dias.

Essa diferença tem um custo que a fila não mostra. Um email de phishing que espera três dias para ser classificado fica três dias nas caixas de entrada do resto da organização, e ninguém pode avisar, bloquear nem conter um ataque que ainda não foi visto. O tempo de classificação é o tempo que o ataque tem para continuar a trabalhar.

O que a Lucía nota, sem que ninguém lho explique

Há uma segunda leitura desses quatro minutos, e não está em nenhum painel de segurança. A Lucía avisou e aconteceu algo.

O veredicto e a pontuação nunca vão chegar ao seu ecrã, e não precisa deles. Basta-lhe perceber que o seu aviso entrou num circuito que se moveu, porque é isso que vai pesar na próxima vez que hesitar diante de um email. Quando o percurso se mede em dias, a resposta chega-lhe tarde a ela e tarde à organização. Quando se mede em minutos, o circuito fecha-se sozinho.

Esse percurso é o que faz o Smart Triage dentro da consola de reportes da SMARTFENSE, sobre os emails que as tuas pessoas reportam com o botão. Se quiseres vê-lo sobre os teus próprios reportes, na consola está o detalhe de cada análise e o histórico do que foi classificado.

Na próxima peça da série vamos mudar outra vez de ponto de vista e olhar para o mês do analista de SOC que abria esses 183 reportes um a um e para as horas que a triagem automática devolve à equipa.

Nicolás Bruna

Product Manager de SMARTFENSE. Su misión en la empresa es mejorar la plataforma día a día y evangelizar sobre la importancia de la concientización. Ha escrito dos whitepapers y más de 150 artículos sobre gestión del riesgo de la ingeniería social, creación de culturas seguras y cumplimiento de normativas. También es uno de los autores de la Guía de Ransomware de OWASP y el Calculador de costos de Ransomware, entre otros recursos gratuitos.

Deixe um comentário