Ciberdefensa: taxonomía de eventos de seguridad.

Hace unas semanas twiteaba un artículo de la empresa Securosis sobre el triangulo de las fugas de información que me gustó bastante leer porque proporcionaba una visión clara sobre cómo afrontar el problema de la protección frente a intrusiones. Además coincide con que llevo unos meses profundizando por los terrenos de la gestión de eventos de seguridad y esta forma sencilla de establecer tres aspectos claves a controlar fue bastante inspiradora.

Es curioso porque la visión estratégica que dan las metodologías de análisis de riesgos no están pudiéndose todavía integrar con la información que es recogida de forma automática por los sistemas de información. Ya he comentado en post anteriores la importancia de transformar los datos de los logs en información relevante que permita obtener un conocimiento claro del "estado de la seguridad".

Desde el mundo de la gestión, la pieza fundamental para alimentar esa visión  y poder reportar a la Dirección resultados son las métricas e indicadores definidos, que deben actuar como sensores para establecer puntos de medición sobre determinados tipos de eventos y desencadenar alarmas cuando los datos salen de ciertas zonas de tolerancia. Actualmente me encuentro intentando establecer un marco de trabajo que permita dibujar esa foto deseada del "estado de la seguridad" entendida como una confirmación de que todo está funcionando como debe según las necesidades de la empresa. 

Cuando hablamos de la seguridad física, el gerente o responsable de una empresa más o menos puede tener claro cuales son sus necesidades de protección. Se suele establecer un perímetro de seguridad, se tienen identificados los puntos de acceso, las zonas vulnerables (puertas, ventanas, despachos) y se pueden colocar cámaras o sensores volumétricos para velar por cubrir todas las zonas.

¿Y en la vigilancia de los sistemas de información? Aunque hay cierto paralelismo entre ambos problemas y existen dispositivos orientados hacia los mismos fines (firewalls  como personal de control de acceso, ids/ips y antivirus como volumétricos y cámaras, etc.) no es tan intuitivo para la Dirección de la empresa definir qué quería vigilar. Sin embargo, si es más viable preguntar  qué le gustaría saber respecto al estado de la seguridad.

En la búsqueda de tratar de facilitar las respuestas adecuadas, podemos tratar de contemplar diferentes fuentes de información que pueden contribuir a localizar estas contestaciones. El punto de partida sería identificar y definir las siguientes cuestiones:

• ¿Qué debe importar?
• ¿En dónde hay que vigilar?
• ¿Cuando debemos alarmarnos?

Tal como se comenta en el triangulo de las fugas de información, un incidente de seguridad podría ser caracterizado por estas tres patas:

• Un objetivo o botín, que suelen ser los datos.
• Una puerta trasera que otorga un acceso ilegitimo a ellos, que son las vulnerabilidades.
• Un medio que permita el acceso y la fuga que obviamente es la conexión a Internet.

Para responder a cada una de las tres cuestiones principales, podemos segmentar el problema en trozos e ir aproximándonos a el poco a poco.

¿Qué debe importar?

Esta pregunta debe considerar dos fuentes de información. Por un lado deben ser considerados los datos del análisis de riesgos dado que es donde la Dirección marca su criterio respecto a lo que en seguridad es relevante para una Organización. De este tipo de estudios podemos extraer cuales son las piezas clave para el funcionamiento de esa institución (Activos críticos) y las amenazas más relevantes (eventos que más daño pudieran causar). 

Por otro lado, pensando en qué datos necesitamos analizar para poder valorar el estado de las cosas, es necesario establecer una taxonomía de eventos relevantes para el estado de la seguridad y que pudieran ser agrupados en las siguientes categorías o dimensiones:

En la capa de vigilancia del acceso a los recursos, deberíamos vigilar las siguientes componentes:

• Control de acceso: Eventos relacionados con el acceso o intento de acceso de usuarios a los sistemas de información.
• Integridad: Eventos relacionados con la modificación de información.
• Vulnerabilidades: eventos relacionados con la utilización de un error o bug para aprovechar el fallo y lograr el acceso o un aumento de privilegios y colarse en los sistemas. 

En la capa de vigilancia del tráfico por la red, deberíamos vigilar las siguientes componentes:

• Gestión de la capacidad operativa: Eventos relacionados con el uso y consumo de los recursos y la infraestructura.
• Gestión de la disponibildiad de servicios y aplicaciones: Eventos relacionados con el chequeo y verificación de la disponibilidad de los diferentes equipos informáticos y los servicios tecnológicos en ellos instalados.
• Naturaleza del tráfico de red: Eventos relacionados con el tráfico de red, origenes, destinos, puertos, ancho de banda consumido, etc.

Esta pudiera ser una primera clasificación de los grandes grupos de eventos que sería necesario monitorizar. En una estrategia basada en la detección de anomalías, es probable que todo incidente de seguridad "cante" por alguna de estas dimensiones, es decir, un evento extraño en una o más de una de estas dimensiones podría ser un indicio suficiente para elevar una alarma. Básicamente esto es a lo que se dedican los appliances y aplicaciones software denominadas como "Security information and event monitoring" (SIEM).

El laboratorio de AlientVault también ha definido una taxonomía de eventos de seguridad que es bastante completa y que se utiliza para etiquetar cada evento que detecta este SIEM. Técnicamente es mucho más completa y extensa que la presentada en este post pero por ello también, más complicada para que pueda ser manejada por perfiles directivos. 

¿En dónde hay que vigilar?

Esta segunda cuestión es mucho más sencilla dado que como hemos dicho, el intruso busca un botín determinado. Por tanto, cualquier pieza que esté en el camino de acceso a dichos datos debe ser vigilada. En la problemática de los sistemas de información se trataría de monitorizar todos aquellos dispositivos que se encuentran en las diferentes áreas de acceso a la información y por los que el intruso va a tener que obligatoriamente pasar antes de poder acceder a los sistemas que custodian los datos. Además, contaríamos también con la visión que el análisis de riesgos aporta respecto a la criticidad de los activos y su relevancia dentro de los sistemas de información según el análisis de impacto realizado.

¿Cuando debemos alarmarnos?

En relación a esta tercera cuestión, podemos establecer dos tipos de eventos que pueden producirse dentro de un sistema de información:

• Eventos habituales o esperados, que son los que supondrían un funcionamiento normal de los sistemas de información y confirmarían que todo funciona de forma correcta. Básicamente son los que monitorizamos para confirmar que las cosas funcionan según lo previsto.
• Eventos no deseados o sospechosos, que serían todos aquellos que pueden suponer un indicio de que algo no va bien o de que pueden estar pasando cosas que requieren un análisis o al menos que alguién revise o examine los sistemas por si ocurre algo raro.

Ambos tipos de eventos pueden establecerse en cada una de las capas de vigilancia de forma que podemos establecer un conjunto de indicadores agrupados por las dos capas comentadas y las seis dimensiones indicadas que puedan servir para colorear nuestro "estado de la seguridad". Todo lo comentado respecto a qué queríamos saber sería recogido del análisis de logs en los diferentes sistemas y a través de los diferentes sensores que pudiéramos establecer dentro de la red. La fuente de información por tanto son las herramientas SIEM que podamos desplegar internamente para colocar sensores que velen por la detección e identificación de toda esta información.  

Pero tal como empecé este post, el objetivo esencial de todo este proceso debe ser transformar una serie de datos técnicos en información que pueda dar a la Dirección una visión aproximada del "estado de la seguridad". Por tanto, el segundo esfuerzo a realizar sería procesar todos estos datos para construir indicadores que sirvan para pintar un "cuadro de mando" entendible a varios niveles. Debe proporcionar información a la Dirección del área TI porque son los responsables de la gestión y debe proporcionar información a la Gerencia porque son los que deben conocer la situación real de la seguridad de sus sistemas para tomar decisiones. De alguna forma, se trata de alimentar el análisis de riesgos que se realiza para tener una visión estratégica con los datos reales que son recogidos por los térmometros de la seguridad desplegados en los sistemas. El objetivo sería disponer de una telemetría de los sistemas que sirva para valorar la situación y estado, hacer ajustes y volver a monitorizar. Algo similar a lo que ocurre en la Fórmula 1 los viernes, sábados y domingos de carrera.

Por poner un ejemplo para que se pueda ver claro el planteamiento, podríamos tener algo como:

Capa de vigilancia de acceso a los recursos.

• Dimensión de control de acceso.
• Eventos esperados: Logon y logoff de usuarios dentro del horario laboral.
• Eventos no deseables: 
• Intentos de logon fallidos a cualquier hora.
• Logon y logoff de usuarios en horarios extraños como de 1:00 AM a 8:00 AM.

Este conjunto de eventos serían procesado para luego poder proporcionar un indicador que de una visión más global a la gerencia de qué ocurre respecto el control de acceso. Algo como el porcentaje de accesos sospechosos frente a legítimos que se detectan a lo largo de un determinado intervalo de tiempo. El valor objetivo debiera ser que ese dato estuviera próximo al 0%.

En cada Organización habrá que estudiar el patrón de eventos habituales con carácter previo a poder establecer los eventos anómalos pero estas pautas de comportamiento no son difíciles de averiguar. Algo más complicado puede ser evaluar la naturaleza del tráfico de red y los movimientos de datos "normales" entre orígenes y destinos.

Respecto al planteamiento de establecer esta estrategia de vigilancia me gustaría contar con vuestra opinión al respecto.

• ¿Como lo véis? 
• ¿Alguna consideración que haya quedado fuera o algún aspecto no contemplado que sea relevante?