Hay perspectivas que solo se ganan con los años. La de hoy viene de alguien que lleva unos 15 años en seguridad informática, de los cuales unos 12 los ha pasado dentro de SOCs, viendo de primera mano cómo cambiaba la forma de detectar, investigar y responder.
Juanma empezó en el Incibe tras ganar un CTF, pasó por seguridad ofensiva, servicios especializados de un CERT y un laboratorio interno, trabajó en un proyecto sobre seguridad en entornos industriales, y más tarde como contratista de la OTAN en análisis de eventos en Bélgica. Desde 2022 forma parte de un servicio MDR en la franja EMEA, como analista principal.
Hablamos desde la silla del analista: lo que quita el sueño a un SOC, por qué el acceso legítimo se ha vuelto el terreno más difícil, y qué cambiaría si pudiera. No busca titulares ni opiniones polémicas, busca precisión. Lo que sigue son sus respuestas, sin filtros.
8Layers: Llevas 12 años trabajando en SOC y detección. A lo largo de esos años en operaciones de seguridad, ¿qué es lo que más ha cambiado en el trabajo de un SOC?
Juanma: Sí, de los aproximadamente 15 años que llevo trabajando en el sector de la seguridad informática, unos 12 años los habré pasado en SOCs.
Diría que en la experiencia que yo he tenido, que puede ser muy distinta a la de otras personas del sector, lo que ha cambiado son varios aspectos, como la forma de organizar los equipos, ya que veo una mayor tendencia a eliminar los niveles dando mayor autonomía a los analistas.
También se puede ver un cambio en la forma de trabajar, ya que se pasó de esperar a que diversos indicadores estáticos generasen una alerta, a crear detecciones más “inteligentes” basadas en diversos factores.
Otro punto importante es que se empezó a reconocer que es imposible parar todo y que el objetivo es, cuando hay una intrusión, ser capaz de reconocerla y detenerla con el menor impacto en el menor tiempo posible.
Además, con la organización por niveles, las investigaciones eran más lentas, los casos pasaban por diversas colas de análisis antes de que se pudiese actuar, mientras que ahora se gestiona a mayor velocidad. Y desde el punto de vista del atacante, la velocidad es un factor muy importante, ya que vemos campañas en las que se pasa de un acceso inicial a un ransomware en minutos/horas.
Últimamente diría que el foco está en las identidades, el acceso legítimo, la actividad cloud. Vemos muchas investigaciones basadas en saber si quien está haciendo algo, además de estar legítimamente autorizado a hacerlo, es quien dice ser.
8L: ¿Cuáles dirías que son hoy los problemas más conocidos de quien trabaja en un SOC? ¿Hay algún tipo de ataque o patrón que sientas que los equipos de SOC todavía están mal equipados para ver, a pesar de todas las herramientas disponibles?
Juanma: Por mencionar uno de los problemas que tienen los equipos, diría que de los principales sigue siendo el ruido, además de las alertas con falta de información que hacen que el análisis sea más lento y complejo. Y ambos causan mucha fatiga mental.
Se han introducido múltiples herramientas de compartición de amenazas que en la teoría deberían ayudar a reducir el ruido y aumentar la información, pero que en la práctica, en muchos casos, no se han integrado correctamente, aumentando el ruido al tratar indicadores que deberían ir en conjunto de manera individual. Esto además hace que se deban crear otros mecanismos para solventarlo, lo que añade tiempo de procesamiento y coste.
Con respecto a los puntos ciegos, hay mucha dificultad con los ataques que usan recursos legítimos, como aquellos que tengan que ver con el robo de cookies, tokens, cuentas comprometidas, cuentas de servicio, etc. Este tipo de amenazas no están asociadas a un malware visible, no hay actividad anómala mostrada por un Endpoint (en caso de haberlo).
Detectar una cuenta de servicio/usuario aparentemente legítimo comportándose ligeramente distinto durante un período corto de tiempo creo es uno de los principales problemas actualmente.
8L: ¿Qué es más difícil de investigar, un endpoint comprometido o una identidad comprometida? ¿Por qué?
Juanma: Ambos casos tienen su complejidad y determinadas situaciones pueden ser más o menos difíciles, pero hablando de manera general, yo diría que una identidad comprometida es más difícil.
En principio, un equipo comprometido genera más telemetría que una identidad o al menos es más factible determinar si dicha telemetría representa una actividad maliciosa o no. Están los procesos, conexiones de red, cambios en archivos/registro, etc.
En cambio, si un atacante entra utilizando unas credenciales válidas, con MFA ya completado o mediante el robo de una sesión autenticada y sus acciones están alineadas al rol de la cuenta comprometida, todo parece indicar que la actividad es legítima y sólo pequeños detalles pueden hacerte sospechar de dicha actividad.
En esos casos, la dificultad ya no está en determinar si una acción está permitida, sino en saber si quien la está realizando es realmente el usuario legítimo.
8L: ¿Ese aumento en el volumen y en los tipos de identidad (como agentes de IA) ha cambiado la realidad de tu equipo?
Juanma: Hace más complejo el trabajo y requiere de más comunicación con el cliente al existir más identidades que monitorizar con su propio contexto a entender. Más identidades implican más patrones de comportamiento distintos y esto provoca también más falsos positivos.
Existen cuentas de servicio, APIs, automatizaciones y cada vez más agentes de IA y eso requiere un contexto adecuado o conocimiento proporcionado por el cliente para poder determinar si su comportamiento es el esperado.
¿Puede un empleado acceder a este sistema? ¿Y qué hay de un agente de IA? Esto requiere un conocimiento del negocio que el SOC no suele poseer.
Con los agentes de IA aparece además el reto de entender y controlar su ámbito de actuación. Un agente con permisos amplios y acceso a múltiples sistemas puede convertirse en un riesgo importante. Incluso sin estar comprometido directamente, podría ser inducido a realizar acciones no previstas mediante el abuso de sus capacidades o una configuración deficiente.
En nuestro caso empezamos a ver alertas generadas por estos agentes, sin embargo, el nivel de visibilidad depende mucho de las integraciones y controles que cada organización haya implementado.
8L: ¿Has tenido casos en los que te diste cuenta de que el atacante estaba usando una identidad o accesos legítimos?
Juanma: Sí, varias veces.
En la mayoría de los casos esta actividad estaba relacionada con servicios de correo electrónico.
Lo interesante es que normalmente no existían indicadores claros de compromiso. Las primeras señales solían ser pequeños cambios de comportamiento, la ubicación no era la habitual, o el horario, o el dispositivo, o se observaban acciones ligeramente distintas a las que históricamente realizaba la cuenta.
Al profundizar pudimos verificar que el atacante había conseguido acceso a la cuenta y estaba utilizando exclusivamente funcionalidades legítimas del entorno, como por ejemplo crear reglas de reenvío, enviar un número limitado de correos internos dirigidos a comprometer otras cuentas, etc.
En algunos casos, la falta de visibilidad exigió contactar al cliente para que validase la actividad observada con aquellos logs que no recibíamos en el SOC. Esto es muy relevante en técnicas como el MFA bombing, donde la capacidad de actuación del SOC depende en gran medida de la telemetría recibida.
Este tipo de casos son complejos ya que es la suma de varias acciones, aparentemente legítimas de manera individual, lo que al final determina si existe un acceso no autorizado o no.
8L: Si pudieras resolver una única cosa en tu stack de detección, sin restricción de presupuesto ni de tecnología, ¿qué sería?
Juanma: En ese caso, yo particularmente me centraría en tener el máximo contexto, sustentado por telemetría completa, normalizada y enriquecida. Esto permitiría generar detecciones más precisas y, sobre todo, reducir significativamente el tiempo de investigación.
La mayoría de los problemas que vemos en un SOC no provienen de la falta de eventos, sino de la falta de contexto para interpretarlos correctamente.
Por ejemplo, desde el punto de vista de la identidad, disponer de información sobre el contexto habitual de acceso del usuario sería enormemente valioso. Me gustaría saber el horario y la franja de trabajo del usuario, si tiene planificado trabajo fuera de horas, si tiene permitido el uso de servicios de anonimización y cuáles y bajo qué condiciones.
Tener información sobre cuántas solicitudes MFA se realizaron antes de llevar a cabo el login satisfactorio, cuáles son los detalles de su equipo de conexión autorizado.
También sería útil conocer su ISP en caso de tener autorizado el trabajo desde casa, o en caso de trabajar durante viajes, saber desde dónde se conectará remotamente y en qué período de tiempo.
Si es una cuenta de servicio, automatización, IA, etc., sería muy útil disponer de información sobre su alcance, patrones de comportamiento esperados, horarios de ejecución y sistemas a los que deberían acceder.
Los SOCs no necesitan más alertas, pero sí mucho más contexto.
8L: ¿Tienes alguna opinión impopular sobre seguridad de identidad en el universo de la ciberseguridad o en la operación de un SOC que defenderías aun sabiendo que mucha gente no estaría de acuerdo?
Juanma: No suelo tener opiniones especialmente polémicas sobre estos temas. En estos años he aprendido que la mayoría de los problemas tienen muchos matices y que lo que funciona en una organización puede no funcionar en otra. Más que defender posiciones impopulares, prefiero centrarme en entender el contexto y buscar soluciones prácticas a los problemas que vemos en el día a día.
Después de doce años en un SOC, la conclusión de Juanma no es una opinión rotunda, sino una insistencia tranquila: el problema rara vez es la falta de alertas, es la falta de contexto para entenderlas. Un acceso con credenciales válidas, un MFA ya superado, una cuenta que se comporta “casi” como siempre: ahí ya no se trata de saber si una acción está permitida, sino de saber si quien la realiza es quien dice ser. Y para responder a eso no hacen falta más eventos. Hace falta entender a quién, y a qué, estamos mirando.
Identity Attack, Unfiltered
Identity Attack, Unfiltered es la serie quincenal de 8Layers en la que damos voz a expertos en seguridad para hablar, sin filtros, del riesgo de identidad: cómo lo ven desde el terreno, qué les preocupa y qué harían diferente. Cada conversación suma una perspectiva distinta, de la gobernanza al análisis forense, del SOC a la inteligencia de amenazas.
La serie nace de aquello a lo que nos dedicamos en 8Layers: unir en una única visión de la identidad lo que normalmente vive separado: postura, detección y compliance.
¿Trabajas en seguridad de identidad y crees que tienes algo que aportar? Nos encantaría escucharte. Escríbenos a marketing@8layers.io y cuéntanos tu perspectiva; puede que seas la próxima voz de la serie.