Lucía trabaja en operaciones, en la misma empresa de servicios financieros de la que hablamos en la pieza anterior de esta serie. Un martes a media mañana le entra un correo que le da mala espina. Duda unos segundos, decide no hacer clic y lo reporta con el botón. Ese gesto, el hábito de reportar correos sospechosos, es la capa de defensa que más costó construir en su organización.
Desde donde ella lo ve, después de eso no pasa nada. El correo sale de su bandeja, no vuelve ninguna respuesta y la semana sigue.
La primera vez eso no tiene ninguna consecuencia. La quinta, sí.
Ya miramos esa cola desde el equipo de seguridad cuando preguntamos quién abre los correos que reportan tus empleados, con 47 reportes de un mes que esperaban una decisión, algunos de ellos desde hacía tres días. Los números vienen del mes de una organización concreta y no son promedios del sector. Acá cambia el punto de vista. La pregunta es qué le pasa a la persona que originó esos reportes mientras esperan.
¿Qué ve un empleado después de reportar un correo sospechoso?
El circuito de un reporte tiene dos extremos. Por uno entra el correo al equipo de seguridad y por el otro, en algún momento, algo tendría que volver a la persona que avisó. En la mayoría de las organizaciones el primer extremo está construido con cuidado y el segundo no existe.
Conviene mirar el proceso con la información que tiene Lucía, que es muy poca. Ella no ve la cola ni el veredicto, y no sabe si su correo fue el primero de la fila o el número 47. Tampoco llega a saber si acertó. Reportar es una decisión que se toma en tres segundos y que en la práctica nunca se cierra, como levantar la mano en una reunión y que la conversación siga sin que nadie te mire.
Del lado de la organización el asunto está resuelto, porque el correo se registró y en algún momento se va a clasificar. Del lado de Lucía, el asunto queda abierto para siempre.
¿Por qué una simulación puede responder al instante y un correo real no?
Un empleado puede reportar dos cosas muy distintas, y una organización responde a cada una con velocidades opuestas.
La primera es una simulación del propio programa de concientización. Acá la respuesta es fácil, porque la plataforma envió ese correo y ya sabe qué es. Cuando el reporte entra, la plataforma de SMARTFENSE reconoce el acierto en el momento, se lo devuelve a la persona y lo suma a su puntaje, sin que nadie del equipo de seguridad tenga que intervenir. Es el mismo mecanismo con el que funciona el resto de la gamificación del programa. Lucía descubre en el acto que hizo lo correcto.
La segunda es un correo real. Acá no hay nada que la plataforma sepa por adelantado, así que la respuesta depende de que alguien lo mire y decida qué es. Y ese alguien tiene 47 reportes por delante. El resultado es una asimetría que no diseñó nadie.
Tu programa responde en segundos cuando el correo era tuyo y tarda días cuando el correo era de verdad.
Es al revés de lo que convendría. En una simulación la persona ya sabe que está siendo evaluada. Frente a un correo real es donde su decisión pesa, y es donde el programa se queda callado.
¿Qué le enseña a tu organización un buzón que no responde?
Un buzón que no responde no queda en terreno neutral. Enseña algo que no figura en ninguna capacitación, y es que reportar es un trámite interno más. Es la lección contraria a la que pagaste por dar.
Por qué la respuesta de una persona se apaga cuando el estímulo se repite sin consecuencia está tratado en este blog en la fatiga de seguridad y el punto en que el aviso deja de hacer efecto y en cómo un atajo se vuelve la norma del equipo. Acá alcanza con la versión operativa del problema. Nadie decide dejar de reportar. La siguiente duda se resuelve por la vía más barata, que es cerrar el correo y seguir trabajando, sin una conversación ni una queja de por medio.
Por eso el deterioro es difícil de ver en el tablero. La tasa de reporte no se cae de golpe, se aplana, y un indicador aplanado se lee como estabilidad, sobre todo si el número sigue siendo mejor que el del año anterior. El buzón se llena primero y se vacía después, y no porque el equipo lo haya vaciado.
¿Cómo se diseña la consecuencia de un reporte?
La consecuencia no tiene que ser un correo de agradecimiento. De hecho, si es solo eso, se agota rápido. Hay cuatro decisiones más útiles y ninguna requiere inventar nada nuevo.
- Reconocer el acierto donde ya se puede. El reporte de una simulación se puede cerrar en el acto, así que no hay razón para que quede sin respuesta. Es el caso más fácil y el más desaprovechado.
- Acortar el tiempo hasta la respuesta del correo real. Es el cuello de botella verdadero. Mientras la clasificación se mida en días, no hay diseño de consecuencia que funcione, porque la respuesta llega cuando la persona ya archivó el asunto.
- Hacer visible que la organización actuó. Cuando se bloquea un ataque que alguien reportó, contarlo. Un aviso breve sobre un correo que se detectó y se frenó le devuelve sentido al gesto de todos los que reportaron, no solo del que acertó.
- Hacer que reportar cuente en cómo la organización lee a esa persona. Si un clic en una simulación pesa en el perfil de riesgo de alguien, un reporte tendría que pesar también, a favor. Hoy la mayoría de los programas registran con detalle los errores de sus usuarios y no registran sus aciertos.
Las dos primeras se resuelven con Smart Triage y Nudges. Smart Triage analiza el correo reportado de forma automática, le asigna una puntuación y determina si es phishing real o una falsa alarma. Con ese resultado, un nudge se ejecuta solo y le devuelve una respuesta casi inmediata a la persona que reportó, por el canal que la organización elija: correo, Slack o Microsoft Teams.
La tercera depende más de la política interna de la organización que de la herramienta, y vale como buena práctica. De la cuarta también se encarga SMARTFENSE, con el cálculo del índice de resiliencia de cada usuario y el reporte de referentes de concientización.
¿Qué indicador dice si el hábito se sostiene?
La tasa de reporte de este mes no contesta esa pregunta. Hay tres lecturas que sí.
La primera es cuántas personas distintas reportaron en el período, no cuántos reportes entraron. El total mensual puede subir mientras la base de gente que reporta se achica, porque un grupo chico de personas muy atentas compensa a las que se fueron callando. Son dos situaciones opuestas con el mismo número arriba.
La segunda es la proporción de correos reales sobre simulaciones. Reportar una simulación es responder bien a un examen conocido. Reportar un correo real es el comportamiento que buscabas, y aparece cuando la persona confía en que el aviso sirve para algo.
La tercera es cuánto tarda un reporte en tener respuesta. Ese número no mide a los usuarios, te mide a ti, y es el que explica los otros dos.
Por eso el indicador que le importa a María no es cuántos reportes entraron este mes. Es si Lucía sigue reportando en el mes doce.
Lo que Lucía nunca ve
Lucía no va a reclamar una respuesta. No es su trabajo y probablemente no se lo plantee en esos términos. Lo único que va a hacer es decidir, la próxima vez que dude frente a un correo, si vale la pena detenerse.
Esa decisión se juega en el tiempo que pasa entre su reporte y la respuesta. Cuando se mide en días, la respuesta llega tarde para ella y tarde para la organización. Cuando se mide en minutos, el circuito se cierra solo y el hábito se sostiene sin campañas.
Comprimir ese tiempo es el trabajo de la consola de reportes, y es de lo que trata la próxima pieza de esta serie. Ahí vamos a seguir el correo que reportó Lucía minuto a minuto, desde el segundo en que aprieta el botón hasta el momento en que el equipo de seguridad empieza a actuar.
Deja un comentario