MIGUEL ÁNGEL ARROYO

Responsable de negocio de seguridad, SEMIC. 

 Mejorando la respuesta ante incidentes con soluciones UEBA

Son muchas las características que ayudan a entender los beneficios de los servicios de la computación en la nube, entre las que destacan su disponibilidad, escalabilidad, agilidad o flexibilidad, sin olvidarnos de la posibilidad de trabajar en entornos colaborativos o la reducción de costes frente a soluciones on-premise.

Sin embargo, y como cualquier adopción de una nueva solución o producto, la computación en la nube también lleva asociado unos riesgos inherentes a la propia tecnología utilizada en este tipo de entornos, por lo tanto, la gestión de riesgos de la información de la organización integrará también la información almacenada y procesada en la nube, que a su vez dependerá del tipo de despliegue; Pública, Privada, Híbrida o Comunitaria, o del modelo de servicio que presten; SaaS (software como servicio), PaaS (plataforma como servicio) o IaaS (infraestructura como servicio).

Entonces, ¿a quién le corresponde la responsabilidad de proteger la información? Esta pregunta, tal y como está planteada, no tiene una respuesta clara, ya que depende en gran medida, tal y como acabamos de mencionar, del modelo de despliegue y del modelo de servicio. Tomando como referencia un modelo público de computación en la nube como puede ser AWS de Amazon, Google Cloud o Azure de Microsoft, la siguiente consideración sería el modelo de servicio. En este escenario, donde tenemos un proveedor del servicio en la nube (CSP, Cloud Service Provider) y un consumidor, está claro que hay un reparto de responsabilidades, y es lo que se conoce como “Modelo de Responsabilidad Compartida”.

En servicios de tipo SaaS, la responsabilidad de la seguridad recae más en el proveedor, mientras que, en el lado opuesto, en un servicio de tipo IaaS, la responsabilidad recae más en el propio consumidor.

Para evitar que haya responsabilidades sin asignar y requisitos sin cubrir, la organización deberá evaluar los posibles riesgos de la información al contratar un servicio de computación en la nube, para identificar qué controles de seguridad tendrá que implantar con el fin de reducir o mitigar dichos riesgos.

CSA (Cloud Security Alliance) lleva a cabo dos proyectos que pueden ayudar a la organización a evaluar estos riesgos; CAIQ (Cuestionario de Iniciativa de Evaluación de Consenso) y CCM (Matriz de Controles de la Nube). Estos recursos servirán tanto a proveedores de servicios en la nube como consumidores para saber en qué punto se encuentran, qué controles son los que ya están implantados, qué controles faltan por implantar y lo que es más importante, a quién le corresponde implantarlos.

La identificación y selección de los controles a implantar es una de las fases más importantes en la gestión de riesgos de la información, ya que una selección inadecuada podrá poner en riesgo la información de la organización. Por este motivo, la organización tendrá que evaluar periódicamente la eficacia y la eficiencia de los controles implantados, independientemente que corresponda al proveedor o a la propia organización. Se aconseja además que uno de los criterios de selección sea el prestigio del fabricante y las múltiples referencias en clientes que pueda tener.

Tal y como se puede ver en el CCM o CAIQ de CSA, los controles que se plantean están categorizados por dominios. Entre estos dominios se encuentra el de Gestión de Incidentes que agrupa aquellos controles dirigidos a garantizar que la organización está preparada para responder ante incidentes de seguridad.

Para entender mejor estos controles hay que tomar como referencia el ciclo de vida de una respuesta ante incidentes del NIST (National Institute of Standards and Technology), reflejado en su guía NIST 800 – 61rev2.

La primera fase hace referencia a la preparación,con la idea de establecer una capacidad de respuesta ante incidentes de modo que la organización sea capaz de actuar correctamente ante ellos. Para ello deberá de contar con la documentación, procesos, procedimientos, recursos humanos, herramientas y formación necesaria.

La segunda fase contempla la detección y el análisis del incidente. La detección incluye las alertas provenientes de puestos de trabajo, redes, servidores de ficheros, servidores de dominio, servidores de correo, SIEM (Security Information and Event Management) y otras soluciones para analíticas de seguridad. Todo ello acompañado del análisis correspondiente para descartar falsos positivos, validar las alertas, estimar el alcance del incidente y crear una línea temporal del ataque.

Durante las operaciones de monitorización y alertas, son muchos los eventos que se generan en corto espacio de tiempo, además provenientes de múltiples fuentes como hemos mencionado anteriormente. La cantidad de eventos, sumada a la cada vez mayor complejidad de detección de ataques, hace necesario poder contar con automatismos que ayuden al técnico de seguridad a analizar los eventos y los posibles incidentes de seguridad.

Las herramientas tipo SIEM ya ayudan en esta labor, mediante la correlación de eventos, pero aun así sigue siendo insuficiente. Los precursores de un incidente de seguridad no siempre van a ser IOC (indicadores de compromiso) claros y definidos, es necesario analizar también el comportamiento de los usuarios y del resto de objetos o entidades de la red. Aquí es donde entran en juego las soluciones tipo UEBA (User and Entity Behavior Analytics), que a diferencia de la gran mayoría de herramientas de protección que se basan mayoritariamente en firmas, se basan en comportamiento, detectando comportamientos anómalos dentro de la red basándose en modelos de Machine Learning.

Un ejemplo de un comportamiento anómalo que podría detectar un UEBA sería la conexión de un usuario a través de una VPN desde Nueva York, y 10 minutos después conectarse por VPN desde Madrid. Obviamente, es imposible que el usuario se desplace en 10 minutos de una ciudad a otra, por lo que podría estar ante una cuenta de usuario comprometida.

Otro ejemplo sería el análisis del tráfico saliente de un usuario o grupo de usuario. Una solución UEBA podría alertarnos de una posible fuga de información si detecta que un usuario, que habitualmente genera un tráfico saliente de X bytes / día, ha generado mucho más tráfico, lo que podría alertar de una posible fuga de ficheros de la organización.

Son solo dos ejemplos muy simples de cómo una solución UEBA podría mejorar la respuesta de incidentes en la nube de una organización.