Toda su carrera profesional se ha desarrollado en Microsoft, ocupando diferentes roles técnicos ligados siempre a la ciberseguridad. Ahora, con su nueva responsabilidad en el ámbito de Azure, pone el foco también en la inteligencia artificial y la automatización, y en la auténtica revolución que todas estas tecnologías están propiciando en los SOC, los centros de operaciones de seguridad.

Llevamos ya muchos años asistiendo a una auténtica explosión en el ámbito de la ciberseguridad. El avance de las tecnologías ligadas a la digitalización ha cambiado el panorama de forma radical, iniciando una carrera de fondo que parece no tener fin. En ella, las empresas han ido adaptando sus estrategias y modelos de respuesta a cada nuevo paso dado por los ciberdelincuentes.

El SIEM ha ido perdiendo importancia respecto al rango de especialización y la capacidad de respuesta que propone un EDR

Es un proceso de evolución continua, en el que ahora ha entrado de lleno un nuevo actor: la inteligencia artificial. Para poner contexto a este escenario, especialmente en el ámbito del SOC (los centros de operaciones de seguridad), hemos hablado con Fernando Rubio, Azure Technical Specialist Manager en Microsoft.

Fernando Rubio,
Azure Technical Specialist Manager en Microsoft

En su opinión, “El cambio ha sido radical. Hace quince años, muchas organizaciones no tenían un SOC. Incluso había grandes empresas que dependían solo de los antivirus. Por identificar un hito claro, la llegada de wannacry y del ransomware supuso un punto de ruptura y, de hecho, ya es raro ver una organización —mediana o grande— que esté todavía en ese modelo”.

El siguiente paso al antivirus fue el SIEM (security information and event management), que permite recopilar eventos de seguridad, realizar correlaciones y generar alertas. Todo ello gestionado desde una consola unificada. Pero empiezan a aparecer nuevas áreas y vectores de ataque y, como consecuencia, se adoptan herramientas especializadas: el antivirus pierde protagonismo en beneficio del EDR (endpoint detection and response); llega la nube, y también la urgencia por instalar un CASB (cloud access security broker), una protección para las cargas de trabajo en el área de infraestructura…

“Al final, tienes una herramienta para cada cosa, lo que ha derivado en que el SIEM vaya perdiendo importancia. La capacidad para generar alertas basándose en un log se ha quedado atrás respecto a, por ejemplo, lo que hace un EDR en un endpoint, que está muy especializado. Esto mismo ocurre con herramientas como Microsoft Defender for Identity para la protección de la identidad. Seguramente se podría hacer algo similar a través de eventos, pero nadie llega a ese nivel, ni siquiera en grandes organizaciones”.

El resultado es que ese SIEM, que era la pieza central del SOC, se ha quedado como un simple sistema para correlacionar y gestionar alertas de otras herramientas, utilizando para ello su consola unificada.

“En este escenario hay dos tendencias que se están desarrollando: por un lado, consolidar todas esas herramientas especializadas en torno al concepto XDR (extended detection response); y volver a dar valor a ese SIEM, para que sea capaz de ofrecer lo mismo que se consigue con esas herramientas independientes”. 

Proteger las cuentas de usuario

ENTORNOS LEGACY En cualquier caso, lo que está claro es que la seguridad no se garantiza, solo es posible disminuir el riesgo. Por ejemplo, uno de los vectores de ataque más utilizados es la usurpación de cuentas de usuario. En estos casos, lo básico es la MFA (multifactor authentication). “Estamos ya en 2023 y, otro año más, seguimos diciendo que el 99% de los ataques se evita con MFA. Una contraseña no es suficiente”.

El problema es que los atacantes están yendo un paso más allá. MFA sigue siendo válido para proteger la cuenta de la mayoría de los usuarios, pero, si eres un administrador de nube, ya no es suficiente, porque los beneficios potenciales son mayores. Por ejemplo, el denominado cloud cryptojacking: roban las credenciales del administrador y utilizan los recursos de nube para minar bitcoins, lo que deriva en unas facturas cuantiosas por parte del proveedor cloud.

Detección y respuesta

El uso de herramientas de detección y respuesta automática podría ser un modelo suficiente en muchos casos. Antes, las herramientas especializadas informaban al SIEM, que era el que lanzaba la automatización. Pero este es un camino lento. Es mucho más rápido que todas estas herramientas tengan capacidad de respuesta, que la de protección de identidad pueda deshabilitar usuarios, que el sistema que defiende el endpoint puede parar y aislar máquinas, etc.

En la mayoría de los casos, no es necesario llevar la automatización al SIEM, ya que la respuesta va a llegar antes. Solo habrá que llevar al SIEM y al SOAR (orquestación, automatización y respuesta de seguridad) lo que de verdad sume varias fuentes y ya no sea posible gestionarlo por este camino rápido. Esa es la clave para ser proactivo más que reactivo.

“La mayor parte de estos incidentes se producen porque no hay un MFA, pero empezamos a ver casos en los que se saltan esa protección porque, aunque el esfuerzo es mayor, se consigue mucho más valor de estas actividades fraudulentas”.

¿Cómo lo hacen?, pues comprometiendo el puesto cliente, robando las cookies cuando el usuario haya accedido al sistema, o a través de técnicas como la denominada de “adversario en el medio” (AiTM), que, a través de un phishing, consigue llevar al usuario a una landing fraudulenta que se encarga de recoger los datos de acceso para luego usarlos en el servicio real.

Por supuesto, hay soluciones, pero se deben implementar. “Por ejemplo, en Azure Active Directory (Azure AD) se puede utilizar el acceso condicional, y obligar a que, cuando alguien vaya a entrar al portal de Azure, que es de alto riesgo, complementar el uso de MFA con el requisito de que solo pueda entrar a través de un PC administrado”.

Movimiento lateral

Volviendo al SOC y al nuevo modelo de SIEM, lo cierto es que durante estos últimos años ha cambiado mucho la cadena de ataque. Según la información que manejan los equipos de respuesta de Microsoft, los incidentes ya no suelen detectarse por un firewall.

La cadena de ataque ha cambiado mucho. Ahora, el camino que siguen es productividad, endpoint, identidad y aplicaciones

“Suelen entrar por productividad (correo electrónico, etc.) o por algo que está expuesto a Internet. El siguiente paso es ejecutar algo en el endpoint y efectuar un movimiento lateral para robar las credenciales de esa máquina y usarlas para saltar a otras máquinas. Por último, suelen hacer una exfiltración de forma previa a cifrar los datos. El camino es productividad, endpoint, identidad y aplicaciones”.

De hecho, el XDR de Microsoft —Microsoft 365 Defender— se ha construido teniendo en cuenta, desde la base, estos cuatro componentes: Defender for Office (productividad), Defender for Endpoint (los endpoints y lo que está expuesto a Internet), Defender for Identity (identidad) y Defender for Cloud Apps (las aplicaciones, un CASB tradicional).

Son cuatro productos (se pueden adquirir por separado), pero se trabaja con ellos desde una misma consola y uno de sus grandes valores es que interactúan entre ellos. Por ejemplo, alguien recibe un adjunto por correo que el sistema no ha parado, pero llega al endpoint y éste detecta que es malicioso. En esa pequeña fracción de tiempo es posible que el usuario haya abierto el fichero y el PC se haya infectado.

En ese momento se toman dos caminos. Por un lado, se plantea que quizás ha habido un robo de credenciales, por lo que habría que deshabilitar la cuenta en el sistema de identidades. Además, es posible que ese correo malicioso lo haya recibido alguien más de la organización y que esas otras personas lo hayan ejecutado en su PC, por lo que se toman las acciones oportunas.

“Microsoft 365 Defender es capaz de hacer la investigación completa y mirar hacia ambos lados, ese movimiento lateral que comentábamos, para proteger toda la cadena de ataque”.

Los entornos legacy

Cuando se trata de ciberseguridad, la proactividad es clave. Pero uno de los grandes retos que hay que solventar son los entornos legacy, en los que resulta más complicado ser proactivo. Muchas veces, no se permite al área de TI hacer los cambios necesarios por miedo a que algo deje de funcionar.

Uno de los grandes retos que hay que solventar son los entornos legacy, en los que resulta más complicado ser proactivo

“Podemos decir que el legacy es el gran problema para la seguridad. Cuando se habla de líneas de bastionado, de protocolos obsoletos o de la imposibilidad de poner un parche es porque hay mucho legacy. Aquí la nube nos va a ayudar, porque cambia el paradigma, para bien y para mal. Un hosting (infraestracture as a service) sigue siendo muy similar a lo anterior, pero en el momento en el que empiezas a trabajar en SaaS o en PaaS, los sistemas se actualizan sí o sí. No hay discusión. Es algo transparente”.

Desde la perspectiva de seguridad, esto es muy positivo. Para TI, este modelo les obliga a adoptar prácticas DevOps y a estar actualizándose constantemente para evitar el uso de librerías que obsoletas, etc.

“En general, como proveedores de nube, somos conscientes de que el negocio tiene que funcionar y todos estos cambios necesarios se avisan con suficiente antelación. Incluso existen excepciones o flags que permiten ir hacia atrás. Pero la tendencia es hacer que TI sea cada vez más DevOps para ser capaces de enfrentar estas situaciones de manera más dinámica. El legacy tiene que dejar de ser un problema”.

La evolución del SOC

Según nos cuenta Fernando Rubio, a nivel mundial, Microsoft cuenta con uno de los SOC más grandes, y también con uno de los equipos más extensos en cuanto a detección y respuesta. Pero, en su momento, el SOC comercial del gigante de Redmond no daba abasto; entre otras cosas, no podía atender el enorme crecimiento que estaba sufriendo la nube de Microsoft.

Nuestro SIEM cloud native es capaz de ingestar centenares de teras al día y generar alertas basándose en esos datos

La respuesta a este reto llegó a través del desarrollo de una solución de SIEM cloud native, pensada para aprovechar todas las capacidades de la nube en cuanto a escalabilidad y flexibilidad a la hora en el análisis de logs. De hecho, “esta tecnología —Log Analytics—está especialmente optimizada para analizar logs en caliente, “ingestando” centenares de teras al día y generando alertas sobre toda esta información. Esto es algo que los SIEM tradicionales no puede hacer”.

IAG y la diversidad

Una de las grandes novedades que va a traer la IAG en el ámbito de la seguridad es la diversidad. Hoy, poner a un abogado a hacer respuesta a incidentes es algo impensable, sin embargo, puede aportar mucho conocimiento legal cuando se trata de, por ejemplo, llevar a cabo la investigación interna de un empleado malicioso.

Probablemente, un abogado sabe mejor que un informático qué es lo que debería y lo que no debería hacerse en estos casos, pero para ello necesita un conocimiento tecnológico. La IA Generativa lo va a hacer posible, va a traer diversidad en cuanto a los profesionales que son capaces de ayudarnos en el mundo de la seguridad.

Y, sobre esa tecnología se han construido todas las capacidades que un SOC necesita en la actualidad, añadiendo automatización, inteligencia artificial out of the box, etc.

“No tiene sentido seguir haciendo detecciones basadas en queries. Esto es algo que ya está superado. Lo que hay que tener son modelos de machine learning que detectan anomalías. Este es el caso de Microsoft Sentinel, que viene con decenas de casos distintos para fuentes de todo tipo, generando detecciones a partir de los logs en vez de una simple correlación de alertas, que es en lo que muchos SIEM se han quedado”. 

No tiene sentido seguir haciendo detecciones basadas en queries, sino tener modelos de machine learning que detectan anomalías

Una de las funcionalidades de Microsoft Sentinel, el motor denominado Fusion, permite plantear una correlación de alertas en función de probabilidades. Existen muchos tipos de ataque para los que se pueden generar modelos de detección, pero hay una parte de incertidumbre.

Por ejemplo, el ciberdelincuente puede estar usando una técnica desconocida, lo que hace que la cadena de ataque ya no se vea entera al no tener las alertas esperadas en cada uno de los puntos. Aunque falten piezas y haya alguno que no se haya detectado, por lo que sea, el sistema es capaz de establecer la línea de ataque. Esta es una de las grandes capacidades que aporta la inteligencia artificial.

“Además, está integrado en DevOps, lo que implica que todo se maneja desde un repositorio de código (GitHub). Las grandes organizaciones están siguiendo esta tendencia y desde ahí es desde donde están empezando a manejar sus casos de uso, sus visualizaciones… Esto es algo nativo en Microsoft Sentinel. Desde cero”.

LA IA y el SIEM

El rol que juegan las tecnologías ligadas a la inteligencia artificial ya está totalmente asumido por parte de todas estas herramientas especializadas en el ámbito de la ciberseguridad. “Todo el mundo entiende que las firmas estáticas de un antivirus, literalmente, no valen para nada. De hecho, hay organizaciones que ya no tienen antivirus”.

Realmente, lo que hay detrás de los EDR son muchos modelos distintos de inteligencia artificial, que intervienen cuando se ejecuta software malicioso directamente en la máquina, o cuando se suben metadatos, o el fichero completo, a la nube para explotarlo o analizarlo.

Donde esto no está tan asumido todavía es en el SIEM. En general, las organizaciones siguen haciendo estos análisis de manera estática, seguramente por un tema cultural: “son los mismos analistas los que han asumido que la alerta que llega del EDR—que no se no se sabe muy bien por qué se ha generado— merece la pena prestarle atención; pero, cuando se trata de analizar los logs en bruto y generar alertas, se sigue haciendo de manera estática, como si fueran las firmas de los antivirus”.

IA GENERATIVA Y EL SOC

IA Generativa y el SOC

Y ahora aparece la IA Generativa (IAG), que supone un salto adicional a todo lo vivido. “Su adopción no va a ir más rápido porque, como sociedad, no vamos a ser capaces de asumir lo que ofrece. Ahí va a estar el límite en cuanto a su velocidad de evolución”.

La IAG supone un cambio fundamental: estamos acostumbrados a usar la informática como sintaxis y ahora la vamos a empezar a usar como semántica, como intent (traducido como intención).

Prompt engineering

Buscar el qué y no tanto el cómo; pero, dentro del cómo también aparece una disciplina nueva, dedicada a aprender cuál es el mejor modo de hablar con estos sistemas. Se denomina prompt engineering, e indica una serie de buenas prácticas a la hora de interactuar con la IAG para sacar el máximo provecho de su valor.

En Microsoft tenemos formación específica sobre esto para todos los niveles. Por ejemplo, si le decimos a un sistema que trabaje como un analista de seguridad, hace que consigas mejores resultados en este tipo de uso; o decirle «razona conmigo paso a paso» hace que aumente la probabilidad de que dé una respuesta correcta.

Por llevarlo al mundo de la seguridad y al ámbito del SOC, a grandes rasgos, los analistas de nivel 1 se dedican a aplicar procedimientos: ante una alerta concreta, se dan determinados pasos. Cuando se pasa al nivel 2, el analista se especializa en un ámbito (network, firewall, correo…) pero, realmente, es especialista es una herramienta determinada. Si la empresa decide cambiarla, son necesarios varios meses de adaptación para volver a saber cómo se hacen las cosas.

“Aquí viene el gran cambio. Ahora nos vamos a comunicar con los sistemas a través de lenguaje natural. No importa el cómo, importa el qué. Como especialista de endpoint, tengo que saber que necesito aislar una máquina y, para ello, le digo al sistema «quiero aislar la máquina». Da igual cómo se hace. Da igual que se use una herramienta u otra, siempre y cuando este sistema esté por delante”.

«Ahora nos vamos a comunicar con los sistemas a través de lenguaje natural. No importa el cómo, importa el qué»

Eso va a transformar los SOC, porque los ciberdelincuentes ya no atacan el directorio o el correo, sino que se mueven lateralmente. Que el nivel 2 del SOC solo esté mirando un contorno determinado limita mucho el ámbito de detección. De hecho, hasta que el incidente no escala al nivel 3, donde se puede ver end to end cada caso, no se suele tener una visión real de lo que está pasando.

Ahora, lo que tendrá valor es saber cómo es un ataque, qué es lo obvio que puede pasar después de que se comprometa un endpoint.

“Además, la IAG nos va a formar según lo vayamos utilizando, va a ser capaz de responder preguntas, hacer recomendaciones…; y cambiará los procesos, generando niveles 2 capaces de tener una visión más amplia. Este es un cambio muy importante que se ha producido, por ejemplo, en el SOC de Microsoft. Nuestro nivel 2 tiene una visión transversal por entornos y no por piezas tecnológicas, y el nivel 3 es el que pone el foco en todos los entornos de la compañía”.