Muchos programas de concienciaci\u00f3n resumen el puntaje de riesgo humano de cada colaborador en una sola cifra, la cantidad de veces que cay\u00f3 en una simulaci\u00f3n de phishing. Es un dato \u00fatil, pero cuenta una parte de la historia. Alguien puede no haber fallado nunca una simulaci\u00f3n y aun as\u00ed reutilizar la misma contrase\u00f1a en diez servicios, ignorar las alertas de su gestor de identidad o autorizar aplicaciones que nadie revis\u00f3. Ese riesgo existe. La simulaci\u00f3n, por s\u00ed sola, no lo ve.<\/p>\n
Como responsable de las integraciones de la plataforma, me toca conversar seguido con equipos de seguridad que ya tienen la telemetr\u00eda para verlo. La informaci\u00f3n est\u00e1 ah\u00ed, repartida entre el gestor de identidad, el endpoint y el SIEM. Aun as\u00ed, el puntaje de riesgo de las personas se calcula con una sola fuente, y el resto de las se\u00f1ales queda en otro tablero.<\/p>\n
Un puntaje de riesgo humano es una estimaci\u00f3n, por persona, de la probabilidad de que su comportamiento derive en un incidente de seguridad. Sirve para priorizar: a qui\u00e9n reforzar primero, qu\u00e9 \u00e1reas necesitan otro tipo de contenido, d\u00f3nde conviene ajustar una pol\u00edtica.<\/p>\n
Su fiabilidad depende de tres cosas. La primera es la cantidad de fuentes que alimentan el c\u00e1lculo, porque una sola dimensi\u00f3n deja puntos ciegos. La segunda es la frecuencia de actualizaci\u00f3n, ya que el comportamiento cambia y un puntaje de hace seis meses describe a una persona que quiz\u00e1s ya no existe. La tercera es la trazabilidad. El equipo tiene que poder explicar por qu\u00e9 alguien tiene el puntaje que tiene y no quedarse solo en el n\u00famero.<\/p>\n
Cuando el puntaje se construye \u00fanicamente con resultados de simulaciones, falla en la primera condici\u00f3n. Mide bien una conducta concreta y deja el resto sin observar.<\/p>\n
Una simulaci\u00f3n de phishing mide una capacidad espec\u00edfica en un momento controlado: reconocer un correo de phishing y no interactuar con \u00e9l. Es una se\u00f1al valiosa y accionable, y es la base de cualquier programa serio. Nosotros dedicamos buena parte de la plataforma a que esa medici\u00f3n sea limpia, como cuento en c\u00f3mo se dise\u00f1a una campa\u00f1a que s\u00ed cambia comportamiento<\/a>.<\/p>\n El l\u00edmite aparece cuando esa se\u00f1al se usa como si describiera todo el riesgo de una persona. Los ataques reales no se agotan en el correo de phishing. Seg\u00fan el Data Breach Investigations Report de Verizon<\/a>, las causas m\u00e1s frecuentes de brechas siguen involucrando de forma marcada el elemento humano, e incluyen ingenier\u00eda social, credenciales robadas y phishing. Buena parte de eso ocurre fuera del alcance de una simulaci\u00f3n: un inicio de sesi\u00f3n desde una ubicaci\u00f3n imposible, un segundo factor rechazado varias veces, un dispositivo con una configuraci\u00f3n de riesgo.<\/p>\n Un colaborador que aprueba todas las simulaciones puede, aun as\u00ed, estar detr\u00e1s de varias de esas se\u00f1ales. Si el puntaje no las incorpora, el programa ve una cara del riesgo y asume que es la \u00fanica.<\/p>\n Un SIEM (Security Information and Event Management) centraliza y correlaciona eventos de seguridad de toda la organizaci\u00f3n. Junto con el gestor de identidad, el endpoint y las soluciones de XDR, forma lo que solemos llamar el security stack: el conjunto de sistemas que ya observan lo que pasa en el entorno real.<\/p>\n Ese stack produce se\u00f1ales que se conectan directo con el comportamiento de las personas. Del lado de la identidad, intentos de acceso an\u00f3malos, factores de autenticaci\u00f3n rechazados de forma repetida o accesos desde ubicaciones incoherentes. Del lado del endpoint y el XDR, detecciones de software malicioso, configuraciones que se apartan de la pol\u00edtica o conexiones hacia destinos sospechosos. Cada una de esas se\u00f1ales dice algo sobre el riesgo de una persona que ninguna simulaci\u00f3n va a capturar.<\/p>\n La se\u00f1al de concienciaci\u00f3n y la del stack se suman. El resultado es un puntaje que refleja tanto la respuesta ante un ejercicio como la conducta cotidiana frente a los sistemas que la persona usa todos los d\u00edas.<\/p>\n Ac\u00e1 est\u00e1 la parte que m\u00e1s importa desde el dise\u00f1o, y es una decisi\u00f3n de arquitectura, no un detalle t\u00e9cnico. Enriquecer el puntaje con se\u00f1ales del stack no significa instalar un agente en el equipo de cada persona ni mirar lo que hace en su pantalla. Significa integrarse con los sistemas que la organizaci\u00f3n ya opera y leer las se\u00f1ales que esos sistemas ya generan.<\/p>\n Lo resolvemos por API. SMARTFENSE se conecta con el gestor de identidad, con plataformas de XDR y con el SIEM, sin pedir nada en el endpoint del colaborador. Es la misma l\u00f3gica que explico en por qu\u00e9 nos integramos por API y no instalando un agente<\/a> y que sostiene tambi\u00e9n la integraci\u00f3n de identidad y el aprovisionamiento por SSO<\/a>. La superficie de integraci\u00f3n vive del lado de los sistemas de seguridad, no del puesto de trabajo.<\/p>\n Esa distinci\u00f3n tiene consecuencias concretas. Se respeta la privacidad de la persona, porque se leen eventos de seguridad, no su actividad personal. Se reduce la fricci\u00f3n de despliegue, porque no hay que tocar miles de equipos. Y la se\u00f1al viaja en las dos direcciones. El puntaje se enriquece con el stack, y a la vez el comportamiento humano puede alimentar la estrategia de detecci\u00f3n, un \u00e1ngulo complementario que trat\u00f3 Pablo Abratte en lo que tu SIEM no ve<\/a>.<\/p>\n Lo primero que cambia es la priorizaci\u00f3n. Cuando el puntaje combina la respuesta a las simulaciones con las se\u00f1ales del stack, la lista de personas a reforzar deja de estar ordenada solo por qui\u00e9n fall\u00f3 un correo y pasa a reflejar el riesgo real. En la pr\u00e1ctica, las organizaciones que suman las se\u00f1ales del security stack descubren riesgo que la simulaci\u00f3n sola no mostraba, y tambi\u00e9n matizan casos que parec\u00edan cr\u00edticos y no lo eran.<\/p>\n Lo segundo es la calidad del refuerzo. Con un puntaje de una sola fuente, la \u00fanica respuesta posible es m\u00e1s simulaciones. Con un puntaje multi-fuente se puede dirigir el contenido al problema concreto de cada grupo, sea el manejo de credenciales, la reacci\u00f3n ante alertas de identidad o el cuidado del dispositivo.<\/p>\n Lo tercero es la conversaci\u00f3n con la direcci\u00f3n. Un puntaje que integra varias fuentes es m\u00e1s defendible frente a un comit\u00e9, porque no depende de un \u00fanico indicador que sube y baja con cada campa\u00f1a. Sobre c\u00f3mo llevar eso a un comit\u00e9 escrib\u00ed en reporting para el board en dos minutos<\/a>, y sobre c\u00f3mo traducirlo a presupuesto en cuantificar el riesgo humano para el CFO<\/a>.<\/p>\n Nada de esto exige empezar de cero. Si tu organizaci\u00f3n ya tiene un programa de concienciaci\u00f3n y un security stack en funcionamiento, la mayor parte del trabajo es de integraci\u00f3n<\/a>: conectar lo que mide el comportamiento con lo que observa el entorno, y dejar que el puntaje refleje las dos cosas.<\/p>\n \u00bfUn puntaje de riesgo humano reemplaza a las simulaciones de phishing?<\/strong> \u00bfHace falta instalar un agente en los equipos para leer las se\u00f1ales del SIEM?<\/strong> \u00bfQu\u00e9 se\u00f1ales del security stack aportan al riesgo por persona?<\/strong> \u00bfSe respeta la privacidad del colaborador?<\/strong> \u00bfCon qu\u00e9 frecuencia deber\u00eda actualizarse el puntaje?<\/strong> \u00bfQuieres ver c\u00f3mo se conecta esto con tu entorno? La secci\u00f3n de integraciones de la plataforma<\/a> muestra con qu\u00e9 sistemas se conecta SMARTFENSE, y la de herramientas de simulaci\u00f3n<\/a> c\u00f3mo empieza la medici\u00f3n del comportamiento.<\/p>\n","protected":false},"excerpt":{"rendered":" Las simulaciones de phishing miden solo una parte del riesgo humano. C\u00f3mo construir un puntaje de riesgo humano fiable con se\u00f1ales reales del SIEM.<\/p>\n","protected":false},"author":4,"featured_media":43803,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3,198],"tags":[189,236,1957,2077,1961,1934],"class_list":["post-43785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-ciso-es-ar","tag-concientizacion","tag-integracion-siem-es-ar","tag-riesgo-humano","tag-siem-es-ar","tag-simulaciones-de-phishing-es-ar"],"acf":[],"yoast_head":" \n\u00bfQu\u00e9 se\u00f1ales aporta el SIEM o el security stack al riesgo por persona?<\/h2>\n
\u00bfC\u00f3mo se combinan simulaci\u00f3n y telemetr\u00eda sin observar la m\u00e1quina del colaborador?<\/h2>\n
\u00bfQu\u00e9 cambia cuando el puntaje es multi-fuente?<\/h2>\n
Preguntas frecuentes<\/h2>\n
\nNo. Las simulaciones siguen siendo una fuente central y la forma m\u00e1s directa de medir y entrenar la respuesta ante un correo de phishing. El puntaje multi-fuente las incorpora y les suma se\u00f1ales del stack para cubrir el riesgo que ellas no observan.<\/p>\n
\nNo. La integraci\u00f3n se hace por API con los sistemas de seguridad que la organizaci\u00f3n ya opera, como el gestor de identidad, el XDR y el SIEM. No se instala nada en el endpoint del colaborador ni se observa su actividad personal.<\/p>\n
\nAccesos an\u00f3malos, segundos factores rechazados de forma repetida, inicios de sesi\u00f3n desde ubicaciones incoherentes, detecciones de software malicioso y configuraciones de dispositivo que se apartan de la pol\u00edtica. Todas se correlacionan con el comportamiento de una persona.<\/p>\n
\nS\u00ed. Se leen eventos de seguridad generados por los sistemas corporativos, no la actividad privada de la persona. La telemetr\u00eda proviene del stack de seguridad, no de vigilar la pantalla de nadie.<\/p>\n
\nDe forma continua. El comportamiento cambia, y un puntaje que se actualiza a medida que llegan nuevas se\u00f1ales describe a la persona que es hoy, no a la de la \u00faltima campa\u00f1a.<\/p>\n