A Lucía trabalha em operações, na mesma empresa de serviços financeiros de que falámos na peça anterior desta série. Numa terça-feira a meio da manhã chega-lhe um email que não lhe soa bem. Hesita alguns segundos, decide não clicar e reporta-o com o botão. Esse gesto, o hábito de reportar emails suspeitos, é a camada de defesa que mais custou a construir na sua organização.
Do ponto de vista dela, depois disso não acontece nada. O email sai da sua caixa de entrada, não volta nenhuma resposta e a semana continua.
À primeira vez isso não tem qualquer consequência. À quinta, tem.
Já olhámos para essa fila do lado da equipa de segurança quando perguntámos quem abre os emails suspeitos que os colaboradores reportam, com 47 reportes de um único mês à espera de decisão e alguns com três dias de antiguidade. Os números vêm do mês de uma organização concreta e não são médias do setor. Aqui muda o ponto de vista. A pergunta é o que acontece à pessoa que deu origem a esses reportes enquanto eles esperam.
O que vê um colaborador depois de reportar um email suspeito?
O circuito de um reporte tem dois extremos. Por um entra o email na equipa de segurança e pelo outro, em algum momento, algo deveria voltar à pessoa que deu o aviso. Na maioria das organizações o primeiro extremo está construído com cuidado e o segundo não existe.
Vale a pena olhar para o processo com a informação que a Lucía tem de facto, que é muito pouca. Não vê a fila nem o veredicto, e não sabe se o seu email foi o primeiro da fila ou o número 47. Também não chega a saber se acertou. Reportar é uma decisão que se toma em três segundos e que na prática nunca fecha, como levantar a mão numa reunião e a conversa seguir sem que ninguém olhe para ti.
Do lado da organização o assunto está resolvido, porque o email ficou registado e em algum momento vai ser classificado. Do lado da Lucía o assunto fica aberto para sempre.
Porque é que uma simulação pode ter resposta imediata e um email real não?
Um colaborador pode reportar duas coisas muito diferentes, e uma organização responde a cada uma delas a velocidades opostas.
A primeira é uma simulação do próprio programa de sensibilização. Aqui a resposta é fácil, porque a plataforma enviou aquele email e já sabe o que é. Quando o reporte entra, a plataforma da SMARTFENSE reconhece o acerto no momento, devolve-o à pessoa e soma-o à sua pontuação, sem que ninguém da equipa de segurança tenha de intervir. É o mesmo mecanismo com que funciona o resto da gamificação do programa. A Lucía descobre no momento que fez o que devia.
A segunda é um email real. Aqui não há nada que a plataforma saiba de antemão, pelo que a resposta depende de alguém o olhar e decidir o que é. E esse alguém tem 47 reportes à frente. O resultado é uma assimetria que ninguém desenhou.
O teu programa responde em segundos quando o email era teu e demora dias quando o email era a sério.
É o contrário do que conviria. Numa simulação a pessoa já sabe que está a ser avaliada. É diante de um email real que a sua decisão pesa, e é aí que o programa fica calado.

O que ensina à tua organização uma caixa que não responde?
Uma caixa que não responde não fica em terreno neutro. Ensina algo que não consta de nenhuma formação, que é que reportar é mais uma formalidade interna. É a lição contrária àquela que pagaste para dar.
Porque é que a resposta de uma pessoa se apaga quando o estímulo se repete sem consequência é um tema tratado neste blogue em a fadiga de segurança e o ponto em que o aviso deixa de fazer efeito e em como um atalho se torna a norma da equipa. Aqui basta a versão operacional do problema. Ninguém decide deixar de reportar. A dúvida seguinte resolve-se pela via mais barata, que é fechar o email e continuar a trabalhar, sem uma conversa nem uma queixa pelo meio.
Por isso a deterioração é difícil de ver no painel. A taxa de reporte não cai de repente, achata, e um indicador achatado lê-se como estabilidade, sobretudo se o número continuar melhor do que o do ano anterior. A caixa enche-se primeiro e esvazia-se depois, e não porque a equipa a tenha esvaziado.
Como se desenha a consequência de um reporte?
A consequência não tem de ser um email de agradecimento. De facto, se for só isso, esgota-se depressa. Há quatro decisões mais úteis e nenhuma exige inventar nada de novo.
- Reconhecer o acerto onde já é possível. O reporte de uma simulação pode fechar-se no momento, por isso não há razão para ficar sem resposta. É o caso mais fácil e o mais desaproveitado.
- Encurtar o tempo até à resposta nos emails reais. É o verdadeiro estrangulamento. Enquanto a classificação se medir em dias, nenhum desenho de consequência funciona, porque a resposta chega quando a pessoa já arquivou o assunto.
- Tornar visível que a organização agiu. Quando se bloqueia um ataque que alguém reportou, contá-lo. Um aviso breve sobre um email que foi detetado e travado devolve sentido ao gesto de todos os que reportaram, não só de quem acertou.
- Fazer com que reportar conte no modo como a organização lê essa pessoa. Se um clique numa simulação pesa no perfil de risco de alguém, um reporte também deveria pesar, a favor. Hoje a maioria dos programas registam em detalhe os erros dos seus utilizadores e não registam os seus acertos.
As duas primeiras resolvem-se com o Smart Triage e os Nudges. O Smart Triage analisa o email reportado de forma automática, atribui-lhe uma pontuação e determina se é phishing real ou um falso alarme. Com esse resultado, um nudge dispara sozinho e devolve uma resposta quase imediata à pessoa que reportou, pelo canal que a organização escolher: email, Slack ou Microsoft Teams.
A terceira depende mais da política interna da organização do que da ferramenta, e vale como boa prática. Da quarta encarrega-se também a SMARTFENSE, com o cálculo do índice de resiliência de cada utilizador e o relatório de referentes de sensibilização.
Que indicador diz que o hábito se mantém?
A taxa de reporte deste mês não responde a essa pergunta. Há três leituras que respondem.
A primeira é quantas pessoas distintas reportaram no período, não quantos reportes entraram. O total mensal pode subir enquanto a base de pessoas que reporta diminui, porque um grupo pequeno de pessoas muito atentas compensa as que se calaram. São duas situações opostas com o mesmo número em cima.
A segunda é a proporção de emails reais sobre simulações. Reportar uma simulação é responder bem a um exame conhecido. Reportar um email real é o comportamento que procuravas, e aparece quando a pessoa confia que o aviso serve para algo.
A terceira é quanto tempo demora um reporte a ter resposta. Esse número não mede os utilizadores, mede-te a ti, e é o que explica os outros dois.
Por isso o indicador que interessa à María não é quantos reportes entraram este mês. É se a Lucía continua a reportar no mês doze.
O que a Lucía nunca vê
A Lucía não vai reclamar uma resposta. Não é o trabalho dela e provavelmente não coloca a questão nesses termos. A única coisa que vai fazer é decidir, na próxima vez que um email lhe levante dúvidas, se vale a pena parar.
Essa decisão joga-se no tempo que passa entre o reporte dela e a resposta. Quando se mede em dias, a resposta chega tarde para ela e tarde para a organização. Quando se mede em minutos, o circuito fecha-se sozinho e o hábito mantém-se sem campanhas.
Comprimir esse tempo é o trabalho da consola de reportes, e é disso que trata a próxima peça desta série. Aí vamos seguir minuto a minuto o email que a Lucía reportou, desde o segundo em que carrega no botão até ao momento em que a equipa de segurança começa a agir.
Deixe um comentário