Gestión ITILizada de vulnerabilidades

Existen multitud de referencias para la gestión de la seguridad. No obstante, dicha gestión acaba quedando traducida, habitualmente, a dos ámbitos complementarios: gestión de riesgos + gestión de incidentes de seguridad. Una simplificación que en la mayor parte de las organizaciones puede resultar suficiente, pero que a veces se pude quedar un poco corta. ¿Cómo aplica ese planteamiento para la gestión de vulnerabilidades?

El modelo de gestión de riesgos "clásico" es un modelo estático. Analizamos los riesgos una vez, y no revisamos el análisis hasta pasado un ciclo completo del proceso (normalmente, anual). Sin embargo, la gestión de vulnerabilidades es algo mucho más dinámico. De ocurrencia puntual, pero que al cabo de un mes en general tendremos que aplicar. Un ciclo excesivamente corto para el análisis de riesgos.

El modelo ITIL de gestión de incidentes aplicado a las vulnerabilidades tiene algunas dificultades. Para empezar no encaja con el planteamiento clásico (ITIL) de resolución de incidentes igual a restablecimiento del servicio, ya que no hay servicio degradado. Una vulnerabilidad no afecta al SLA del servicio, al menos no directamente. No obstante, los principios de la gestión de problemas sí que parecen encajar con la gestión que requieren las vulnerabilidades. ¿Cuál podría ser el detonante para este proceso?

Otros modelos de referencia tampoco terminan de encajar. Todos los que tienen implantados sistemas de gestión conocen la sistemática aplicable a las acciones preventivas, pero... ¿Es suficientemente ágil ese planteamiento para ser aplicado en relación a las vulnerabilidades técnicas? Teniendo en cuenta que ambas metodologías de gestión suelen quedar en manos de departamentos diferentes, tampoco parece una solución óptima.

Mi propuesta para la gestión de vulnerabilidades es hacer uso del proceso ITIL v3 de Gestión de Eventos. Este es un proceso en general infrautilizado, que se suele limitar a la monitorización de sistemas. Sin embargo, es un proceso que puede dar mucho más de si, tanto desde el punto de vista de la correlación de logs como desde el punto de vista de la gestión de vulnerabilidades.

Para empezar, la gestión de eventos es un proceso "interno" de un departamento TIC. Tiene vocación preventiva, y dos de sus principales salidas van hacia la gestión de problemas y la gestión de cambios. Por lo tanto, entre el propio proceso y aquellos con los que se relaciona se puede cubrir el ciclo completo de gestión de la vulnerabilidad:

• Aparición --> Detección y Notificación --> Registro --> Análisis --> Aplicación de WorkAround --> Análisis de causa --> Parcheo --> Cierre

Además, desde el punto de vista de proceso con uso intensivo de soluciones tecnológicas, la gestión de eventos puede ser un proceso muy apropiado para ser revalorizado desde el punto de vista de la seguridad. Por un lado, es el proceso más apropiado para la introducción de soluciones de correlación de logs y SIEM. Por otro lado, también es una tentación la introducción de soluciones de auditoría automatizada de red, que refuercen el apartado de gestión de vulnerabilidades y se integren con las herramientas de gestión de incidentes y problemas.

En definitiva, la gestión de vulnerabilidades es un proceso peculiar, para el que los modelos de gestión más habituales no terminan de encajar, pero que puede encontrar en los procesos de ITIL v3 el formato más apropiado para introducirse de forma nativa en los procesos de operación TIC de cualquier organización.

A vosotros, qué os parece la propuesta? ¿Qué ventajas e inconvenientes le veis? Estaré encantado de leer vuestros comentarios.

Comparando herramientas de consolidación de logs

Hace ya algún tiempo, dejaba pendiente en otro post ampliar algo de información relativa a consolidadores de logs. Hoy quiero zanjar esa "deuda" pendiente.

En primer lugar, decir que no existe una terminología clara para este tipo de dispositivos. Comercialmente está triunfando la de "gestores de eventos de seguridad", aunque existen múltiples variantes para referirse a este tipo de tecnologías (gestores de incidentes, correladores de eventos, consolidadores de logs, ...).

A partir de ahí, y para aclarar un poco más en qué consisten y cómo funcionan este tipo de dispositivos, me remito a este documento, que aunque es en inglés, y no sea totalmente actual, explica bastante bien no sólo la estructura y funcionamiento de este tipo de dispositivos, sino que ofrece una guía de funcionalidades que se podrían exigir para estas tecnologías. La propia publicación actualiza su información sobre este tipo de dispositivos en este artículo, tal y como refleja Javier Cao en su blog (aprovecho para agradecerle su referencia a este blog, y para recomendar el suyo, de gran calidad de contenidos y accesible directamente desde el apartado de links).

En cuanto a las solicitudes de comparación de este tipo de herramientas, vuelvo a hacer uso de referencias externas, ya que seguramente han tenido más tiempo y más recursos que yo para desarrollar un análisis en profundidad (y espero que suficientemente objetivo y desinteresado). En este caso, el link que quiero dejar es este, a un artículo de Network Computing que data del pasado Mayo y refleja una comparativa de este tipo de productos llevada a cabo por Neoaphsis. El artículo, independientemente de los resultados que ofrece, muestra un listado bastante completo de los principales fabricantes de este tipo de dispositivos (no sólo de los participantes en la comparativa, sino también de aquellos que no lo hicieron), así como una serie de criterios de valoración y ponderación que poder tomar como referencia para seleccionar el producto que más interese. Combinado con las funcionalidades del primer documento referenciado, creo que puede constituir una buena referencia para adentrarse en este tipo de tecnologías.

Y por último, no quiero concluir sin resaltar que no sólo existen estos fabricantes. A día de hoy, diversas empresas ofrecen soluciones de correlación de eventos sin ser grandes multinacionales, y por tanto sin aparecer entre el listado de estos artículos. No tienen por qué ser soluciones de menor calidad, y sobre todo es posible que, en entornos concretos, puedan ofrecer funcionalidades más útiles que los grandes fabricantes.

Como siempre, tendremos que analizar a fondo el entorno, y centrarnos en cuáles de nuestras necesidades tenemos que satisfacer. Y no sólo pensando en el presente, sino con mente abierta y capacidad para ver más allá de las apariencias. Por que si no, puede que sea complicado justificar inversiones de más de 60000$ en este tipo de dispositivos, si atendemos a los precios de referencia que se utilizaron en la comparativa que he citado.

El negocio se abre camino

En uno de mis primeros post en este blog, hablaba sobre los sistemas de consolidación de logs y sobre el potencial que podían llegar a tener. Hoy retomo este tema con la satisfacción de ver que mis pronósticos no iban muy desencaminados.

Como exponía en su momento, los sistemas de consolidación de logs tienen un gran potencial. Y aunque hasta el momento se han vendido como motores de correlación de eventos de seguridad, hoy retomo el tema con un ejemplo en el que, como dice el título, el negocio se ha abierto camino.

El caso es sencillo. Una organización que dispone de una herramienta de consolidación de logs. Inicialmente, en ella se replicaban los logs de firewalls, antivirus e IDSs. Vamos, el caso clásico. Pero, desde el punto de vista de la seguridad, a alguien se le ocurrió que también podían consolidar en esa máquina los logs de otros sistemas en los que la seguridad era importante, como el servidor web. O mejor dicho, el cluster de servidores web. Así, se podría llegar a ver el rastro de un ataque que consiguiera llegar hasta el servidor. Así que introdujeron este servidor en el sistema de consolidación de logs. Pero como la visión que ofrecía era incompleta, decidieron introducir también el resto de las capas que daban el servicio web, es decir, el motor de aplicaciones y la base de datos.

Pero resulta que un buen día, y aunque no se había detectado ningún ataque, la aplicación web tuvo un fallo importante. Algo andaba mal... y no estaba muy claro por qué. Un montón de gente estudiando el problema... y nada. Hasta que a alguien se le ocurrió ponerse a revisar logs. Una tarea ardua, porque cada sistema tenía los suyos. Pero... Un momento! Si en el sistema de consolidación de logs están todos juntos! ¿Por qué no intentamos utilizarlo?

Dicho y hecho. En cinco minutos disponían de todos los logs que necesitaban, y en otros diez habían dado con la solución. Eureka! No habían localizado un ataque, pero habían traducido todos los datos que tenían los logs en información útil para identificar el fallo en la aplicación. ¿Por qué no aprender la lección? En unos meses, todos los sistemas críticos estaban integrados en el sistema de consolidación de logs. Y también los entornos de desarrollo y pre-producción.

¿Cuál es la situación actual? La mayor parte de los usuarios de ese sistema son usuarios del área de desarrollo, ya que les permite realizar de forma sencilla y rápida seguimientos y análisis del funcionamiento de sistemas distribuídos y dispersos, que en otro caso serían tediosos o inasumibles. ¿Cuál es la lección aprendida? Que a la hora de la verdad, seguridad y negocio no son elementos tan distantes e irreconciliables como puede parecer. Sencillamente, hay que aprender a transformar los sistemas y recursos "de seguridad" en sistemas y recursos "de negocio". Tener la mente abierta...

Consolidando logs

La consolidación de logs es un tema al que desde hace algún tiempo le llevo dedicando mis reflexiones. Hoy quiero plasmar por escrito algunas de ellas.

Hemos visto aparecer en el mercado distintas marcas que comercializan este tipo de soluciones. Algunas son fabricantes de software de seguridad con abolengo, otras son nuevas marcas de software que luchan por abrirse camino, y otras incluso son firmas consultoras con una apuesta clara por el software. Por qué tanto interés?

La consolidación de logs surge cuando las empresas tienen tantos logs que no saben qué hacer con ellos. Todos los sistemas actuales generan logs, en mayor o menor medida. Logs que normalmente se procesan a nivel estadístico, como mucho. Sin embargo, las empresas necesitan algo más. Las estadísticas no dejan de ser más datos, y lo que se busca hoy en día son respuestas.

La consolidación de logs ofrece un valor añadido. Es capaz de procesar distintas fuentes de logs para ofrecer resultados. Clásicamente, información sobre ataques. Pero la verdadera ventaja no está en su uso habitual, sino en la filosofía que subyace. Se trata de hacer que los logs sean útiles. Procesarlos, consolidarlos, para generar información. Son soluciones muy útiles, y sin embargo abren un gran campo de investigación.

En las empresas actuales no basta con correlar eventos. Es necesario identificar los sucesos singulares, y por supuesto es necesario poder relacionarlos si queremos que los logs sean útiles. Sin embargo, el potencial de la filosofía de correlación puede ir mucho más lejos. ¿Por qué utilizar estas herramientas sólo para correlar eventos?

Los motores de consolidación de logs utilizan técnicas muy concretas de "Data Mining" para llevar a cabo su trabajo. Por qué no vamos más allá? Estas mismas técnicas pueden ser utilizadas para la detección de tendencias, para analizar el funcionamiento y, sobre todo, la funcionalidad de los sistemas. En las empresas actuales se implanta tecnología sin saber exactamente cuáles son los beneficios reales. Y es aquí donde este tipo de motores pueden prestarnos su ayuda.

Si ampliamos la funcionalidad de los consolidadores de logs, tendremos una herramienta que nos permita analizar de forma conjunta el funcionamiento operativo de los sistemas. Cómo se usan, qué respuestas dan en el día a día. Y si se desarrolla una herramienta que permita analizar estos datos de forma global y extraer conclusiones, estaremos dando un paso adelante. Estaremos acercando la tecnología al negocio. Y en el fondo, no es eso lo que se persigue?