El comité pregunta siempre lo mismo y lo pregunta igual. ¿Esto nos protege o es un requisito de cumplimiento que firmamos una vez al año? Las cuatro piezas anteriores de esta serie siguieron un correo sospechoso desde el botón hasta la decisión del equipo de seguridad. Esta última mira el mismo mes desde la sala de reunión, porque el reporte de un correo no termina cuando el caso se cierra. Vuelve al programa de concientización y cambia lo que cada persona recibe después. Los números son de una organización concreta, la misma de las piezas anteriores, y no promedios del sector.
¿Qué dice un correo reportado sobre la persona que lo reportó?
Hay una forma de mirar el reporte de correos que lo deja siempre del lado de la seguridad operativa. Alguien avisa, alguien revisa, el caso se cierra. Funciona, y desaprovecha la mitad de la información.
Cuando Lucía, de operaciones, reporta un correo real que le dio mala espina, está demostrando exactamente el comportamiento que el programa buscaba instalar. Un reporte es una señal de conducta, porque identifica quién reconoce un ataque, con qué criterio y cuánto tarda en avisar. Ese dato dice más sobre el estado de la cultura que cualquier porcentaje de asistencia a una capacitación, y no debería morir dentro del caso.
Dentro de la plataforma eso tiene dos salidas distintas, y vale la pena no confundirlas.
Un correo real reportado puede disparar un Nudge, que es un mensaje que la plataforma le manda a una persona cuando ocurre un evento determinado. En el reporte de correos hay cinco eventos que lo disparan.
- Un usuario reporta un correo que no es una simulación de phishing.
- Un usuario reporta un correo de simulación de phishing.
- Un correo real reportado se clasifica como phishing.
- Un correo real reportado se clasifica como falsa alarma.
- Un correo real reportado se reclasifica a mano.
Los dos primeros ocurren en el momento del reporte, así que la respuesta sale sin esperar ningún veredicto. Los tres siguientes ocurren cuando el caso se resuelve, y son los que permiten contarle a la persona algo que cuando apretó el botón todavía no se sabía.
De ahí sale la respuesta que Lucía percibe. El mensaje le llega por correo, por Slack o por Microsoft Teams, y cada canal lleva su propio asunto y su propio texto. Es el mismo mecanismo de los nudges en el momento justo del que ya habló este blog, disparado esta vez por una conducta correcta en lugar de por un error.
Las simulaciones, en cambio, alimentan el perfil de la persona. Reportar una simulación entra en su índice de resiliencia, que cuenta cuántas simulaciones reporta por cada una en la que cae, y deja a esa persona elegible para el reporte de referentes, la lista nominal de quienes sostienen el buen comportamiento. Ahí el reporte pesa a favor, al lado de las señales que pesan en contra.
¿Cómo se cierra el círculo entre la simulación y el reporte?
Visto de lejos, el recorrido completo tiene cinco tramos.
- Simulas un ataque en un entorno controlado.
- La persona aprende a reconocerlo y a reportarlo, y eso queda en su perfil.
- Con el tiempo reporta también los correos reales, que es el salto que de verdad importa.
- Esos reportes se clasifican sin intervención y devuelven un veredicto en lugar de una tarea.
- La respuesta vuelve a la persona en el momento, y la actividad del mes queda a la vista en la consola de reportes.
El tramo que faltaba durante años era el cuarto, y sin él el tercero se apaga solo. La segunda pieza de esta serie explicó por qué. Un canal que no responde le enseña a la organización que avisar es un trámite.
¿Qué tres métricas del reporte de phishing miran los responsables del programa?
Ninguna de las tres es el total de correos procesados.
Cuántas simulaciones se reportan. La tasa de reporte mide qué porcentaje de las simulaciones recibidas terminó reportado, y la plataforma la ubica además contra un benchmark del sector para que el número no quede suelto. En la organización de esta serie fue del 62%. Contesta la pregunta anterior a todas las demás. ¿Tu gente reconoce un ataque y avisa?
Al lado de esa tasa hay un dato que casi nadie mira y que vale tanto como ella. La ventana de exposición de cada campaña superpone el tiempo típico que tarda alguien en caer con el tiempo típico que tarda alguien en reportar. Cuando la curva de reporte va por delante de la de caída, tu organización avisa antes de equivocarse.
Qué resolvió el análisis automático este mes. El tablero separa los correos que la clasificación automática marcó como phishing de los que descartó como falsa alarma. En el mes de esta historia fueron 23 ataques reales y 160 falsas alarmas sobre 183 reportes. Hay una salvedad para leer bien ese número, y es que cuenta solo lo que el análisis resolvió por sí solo dentro del mes en curso, así que un correo que después alguien reclasificó a mano deja de figurar ahí.
El listado de correos reportados muestra quién reportó cada uno, así que separar a quien avisa con criterio de quien reporta todo lo que le resulta extraño es una lectura que se hace ahí y no un indicador que el tablero calcule. Son dos conversaciones distintas y las dos son útiles, aunque ninguna se resuelve mirando un promedio.
Ese 23 sobre 183 se lee fácilmente como un problema de precisión de los usuarios, y no lo es. Que la mayoría de los reportes resulten inofensivos es la consecuencia esperable de tener gente atenta, y la primera pieza de la serie argumentó que ese es el escenario sano. Lo que importa es que los 23 aparecieron, y que los encontraron personas.
Cuántos reportes siguen sin decisión. Es un acumulado sin corte por fecha, así que uno que quedó abierto hace tres meses sigue contando hoy. Antes del triaje automático ese número era 47, y algunos llevaban tres días esperando. Es la deuda real del programa y el único de los tres que debería tender a cero.
¿Qué se le contesta al comité cuando pregunta si el programa protege?
Dos números, y ninguno de los dos es de actividad.
El primero, 23 correos de phishing real detectados por empleados en un mes, y no por el email security ni por el firewall. Los encontraron personas que vieron algo raro y apretaron un botón.
El segundo, cuatro minutos entre el reporte y la clasificación del incidente, en lugar de los tres días que tardaba la cola. Ese es el tiempo durante el cual un ataque sigue vivo en las bandejas del resto de la organización.
Los dos contestan la pregunta que el comité hace de verdad, que no es cuánta gente completó la capacitación. Y llegan con una ventaja sobre el informe trimestral, porque están disponibles el día que alguien los pide. Si el problema de fondo es que el informe llega tarde a la reunión, eso se resuelve aparte.
¿Qué conviene mirar dentro de seis meses?
Dos cosas, y las dos son tendencias.
La primera es si el hábito crece. Mes a mes, más gente reporta, y reporta también fuera de las simulaciones. La actividad mensual de los últimos seis meses está en el tablero justamente para eso, porque un mes suelto no dice nada y seis seguidos sí.
La segunda es la deuda, que se mide en cuántos reportes siguen esperando una decisión. Si ese número baja mientras el primero sube, el programa mejoró de las dos formas que importan a la vez, y ninguna de las dos costó horas extra.
Ese cruce es además la respuesta a una objeción razonable que aparece en cualquier comité. Un programa de concientización que solo muestra más actividad puede estar generando más trabajo interno sin reducir ningún riesgo. Cuando la actividad sube y la cola no, la organización pasó a procesar más amenazas con el mismo equipo, que es una afirmación distinta y bastante más difícil de discutir.
¿Un buzón vacío es una buena señal?
Depende de por qué está vacío, y las dos explicaciones posibles son opuestas. Puede ser que tu organización esté tranquila. Puede ser que dejó de avisar.
Lo que hay que buscar es lo contrario de un buzón vacío. Gente que reporta sin dudar, reportes que se resuelven sin hacer fila y un equipo de seguridad que dedica su tiempo a los correos que lo merecen.
El botón de reporte es una capa de defensa humana con análisis automático detrás.
Y cuando esa capa tiene que hablar con el resto de la organización, el mismo evento puede salir de la plataforma. Un Playbook notifica a un sistema propio por webhook, o avisa por correo, Slack o Microsoft Teams a quien tenga que enterarse, del responsable del área a la guardia del SOC.
Así funciona Smart Triage dentro de la consola de reportes de SMARTFENSE, sobre los correos que tu gente reporta con el botón. Si quieres ver estos tres números con los datos de tu propia organización, el camino más corto es una demostración de la plataforma.
Deja un comentario