Recomendaciones para la implantación efectiva de un proceso de monitorización de eventos de seguridad (SIEM)

La monitorización de eventos de seguridad es uno de los controles básicos en cualquier programa efectivo de seguridad de la información.  Registrar y analizar la actividad en los sistemas de la organización puede permitir no sólo la detección temprana y prevención de actividades fraudulentas, sino que puede ayudar en la detección de problemas técnicos y es además un requisito de cumplimiento normativo para muchas organizaciones.

Sin embargo,  la implantación de un sistema SIEM (siglas, de Security Information and Event Management) suele ser una tarea compleja y costosa para las organizaciones y es muy frecuente que los proyectos se cierren en falso, sin que se alcancen los objetivos inicialmente establecidos. En muchas ocasiones, el resultado es que se han tirado a la papelera miles de euros de manera inútil.

Recuerdo una anécdota en la que un director general estaba visitando las instalaciones del centro de gestión de incidencias de una gran compañía. Se detuvo curioso frente a una enorme pantalla en la que sobre un bonito esquema de red parpadeaban decenas de señales rojas y anaranjadas. El director general preguntó al responsable del servicio si debía estar muy preocupado, dado el número de señales en la pantalla. El responsable del servicio respondió que en absoluto, que en realidad todas aquellas señales rojas eran falsas alarmas y que no había ningún motivo para preocuparse. El director general miró fijamente al administrador y con tono frío le dijo: “Ah, entonces este sistema no sirve para nada, pues un operador no será capaz de distinguir un ataque real de una falsa alarma…” y continuó su camino por las instalaciones. Lo cierto es que he de decir que en mi opinión el director general dio en el clavo en su diagnóstico. Aquél sistema era bastante inútil, pues nadie había considerado necesario hacer un ajuste fino del mismo, filtrando las falsas alarmas. Lo cierto es que se trataba de un sistema bastante caro que sólo servía para hacer bonito en el departamento, pero al que nadie hacía caso. Sin embargo, nadie en el departamento admitiría públicamente el fiasco del proyecto, pues ello supondría admitir que unos cuantos miles de euros se habían tirado a la papelera…

En este post vamos a enumerar algunos de los errores más frecuentes que desde nuestra experiencia se suelen cometer en este tipo de proyectos y la forma de evitarlos. Esperemos que sea de utilidad para todos aquellos embarcados en la tarea de implantar un sistema efectivo de control.

Considerar que el proyecto se resume en la implantación de una (o varias) herramientas software/hardware

Quizás el error más frecuente cuando el proyecto se lidera desde las áreas de administración de sistemas, es  el de reducir la solución del problema a la mera elección, compra (o desarrollo) e instalación de una herramienta software/hardware.  Sin embargo, aunque existen herramientas excelentes que facilitan bastante la tarea, la monitorización efectiva de eventos de seguridad implica la implantación de un proceso que habrá de existir embebido en la organización. Como todo proceso, esto requiere la integración de tres elementos:

  • Personas
  • Tecnología
  • Procedimientos

El proceso no cumplirá sus objetivos sin una serie de personas que trabajen sobre las alertas del sistema para tratar de legitimarlas y con procedimientos definidos de escalado. ¿De qué puede servir un sistema perfectamente ajustado capaz de identificar potenciales situaciones de peligro si no hay nadie que se encargue de gestionarlas?.

Por otro lado, el sistema de monitorización habrá de ser ajustado periódicamente y mantenido debidamente para adaptarlo a los cambios operativos del entorno donde opera y para optimizar su utilidad. Esta es una actividad crítica, que implica entre otras cosas la depuración periódica de las falsas alarmas para que progresivamente la información que proporcione el sistema sea del máximo valor, resaltando sólo aquellas situaciones que se desvíen de la línea base de comportamiento esperado de los sistemas.

Definir un alcance inicial excesivo,  abordando el proyecto sin una consideración previa de los escenarios de riesgo principales que afectan a los objetivos de negocio

Otro de los errores frecuentes en los que se suele caer a la hora de abordar un proyecto SIEM, consiste en tratar de recolectar todos los eventos básicos de seguridad de todos los sistemas informáticos sin mayor discriminación. En muchas ocasiones, no se sabe muy bien qué tipo de uso se dará a la información, pero esto se justifica con el argumento de que es preferible tener disponible esa información (aunque a posterior se demuestre innecesaria) al caso contrario,  ya que siempre habrá tiempo para descartarla si no es realmente necesaria.

Este enfoque que aparentemente simplifica la fase de análisis inicial suele derivar rápidamente en complicaciones que habrá que gestionar:

  • Posibles problemas de ancho de banda en la red interna por el alto volumen de información que los sistemas  generan.
  • Aumento de costes del proyecto al tener que configurar software de recolección de eventos en todas las máquinas de la plataforma (ej: aumento en costes de licencias, y mantenimiento)
  • Requerimientos de mayor disponibilidad del tiempo de personal del área de técnica de sistemas para configurar los sistemas y dar soporte al proyecto
  • Incapacidad de dimensionar un equipo con el número de personas necesario para poder gestionar el volumen de información disponible.
  • Pruebas de calidad y funcionamiento de la solución más complejas y caras
  • En definitiva, aumento de la duración del proyecto y de los costes.

Lo más frustrante con este enfoque es que la atención de los miembros del proyecto se diluye rápidamente en la resolución de múltiples problemas técnicos de bajo nivel, perdiéndose la oportunidad de diseñar una solución orientada a proporcionar valor.

En mi opinión, la mejor forma de abordar un proyecto SIEM es siguiendo un enfoque incremental basado en riesgos. Para facilitar este enfoque, lo más recomendable es realizar un análisis de riesgos inicial, tomando en consideración los activos y los procesos más críticos de la organización desde la perspectiva de negocio e identificando, con la participación de distintas áreas de la organización, los escenarios de riesgo más importantes. A partir de aquí, tras una priorización de estos escenarios se definirá el alcance de los sistemas a monitorizar y los eventos de seguridad más relevantes que habrá que ir incorporando de manera sucesiva en cada incremento de desarrollo.

Este enfoque basado en riesgos, frente al enfoque “masivo indiscriminado”, permitirá:

  • Entregar valor alineado con los objetivos de la organización desde el comienzo del proyecto
  • Optimizar los recursos  y los eventos a monitorizar
  • Optimizar los costes generales del proyecto.
  • Reducir la complejidad ya que en cada incremento de desarrollo del proyecto se aborda un alcance acotado y focalizado en escenarios concretos.
  • Aumenta la calidad global.

Recolectar eventos sin saber exactamente cómo gestionarlos

Una posible consecuencia de la tendencia a recolectar de manera indiscriminada todo tipo de eventos posibles de los sistemas, es que muchas ocasiones no sabremos exactamente qué hacer con algunos de ellos.

Visité una vez una compañía de servicios que mostraba orgullosa un informe generado automáticamente con el registro del acceso a los sistemas de cada uno de los 700 empleados de sus tres delegaciones. Dicho informe se le pasaba al principio del día al responsable de seguridad de informática. El presumible uso del informe era tratar de detectar intentos de acceso fraudulento mediante el análisis de los errores de validación. Sin embargo, la realidad era que dado el número de empleados, era algo muy frecuente que de modo natural los empleados olvidasen su contraseña o cometiesen errores de tecleo. Era prácticamente imposible verificar uno a uno cada error, no sólo por el número de eventos diario, sino porque además no había una forma clara por parte de los administradores de sistemas de determinar si una petición de reinicio de contraseña era legítima o no.  Además,  nadie se había planteado nuca si, dada la actividad de la compañía y su perfil de riesgo, el intento de acceso tratando de “adivinar” la contraseña de otro empleado  era un escenario verosímil y probable que mereciese la pena analizar diariamente. El resultado final era, bajo mi perspectiva, una pérdida de tiempo, espacio en disco y dinero sin ninguna utilidad real.

La recomendación aquí es que sólo deberían incluirse dentro del alcance del proceso de monitorización aquellos eventos relevantes para los escenarios de riesgo seleccionados y, solamente,  cuando seamos capaces de definir sin ambigüedad para cada uno de ellos:

  • Los patrones de eventos que implican una situación de normalidad.
  • Los patrones de eventos que permiten definir una condición de alerta que habrá de ser investigada.
  • Cuál es el curso de acción preciso que habrá que seguirse por parte de los analistas para gestionar la alerta hasta darla por cerrada o escalarla como un incidente de seguridad.

Desbordar a los analistas con información “en crudo” sin procesar

El ejemplo anteriormente descrito de la compañía de servicios y el registro de acceso a sistemas de sus 700 empleados muestra al responsable de seguridad desbordado diariamente con un listado de cientos de filas imposible de procesar.

Un sistema de monitorización de eventos de seguridad debe filtrar la información de eventos de base que procede de los sistemas para mostrarla a los operadores humanos de una forma simplificada, comprensible y fácil de gestionar. De otro modo, es fácil desbordar a los analistas con miles de filas de información “en crudo” lo cual abocará al sistema al fracaso seguro.

Una de las tareas más importantes que habrá que definir y que el sistema deberá automatizar es la de la agregación y correlación  de los eventos elementales procedentes de los sistemas para generar alarmas de escenarios significativos de riesgo que serán las que haya que mostrar a los operadores para su gestión.

Un ejemplo de definición de alerta podría ser el siguiente:

Si se detecta un acceso por parte del administrador en un sistema crítico y este evento se produce fuera de la franja horaria normal de trabajo o en fin  de semana y no existe un registro de incidencia para el sistema en donde se ha producido la conexión, entonces generar una alerta de alta prioridad de acceso potencialmente fraudulento”.

Para poder cubrir este escenario de riesgo, como vemos, el sistema debe ser capaz de procesar automáticamente diferentes tipos de eventos procedentes de sistemas y usar información adicional de contexto (la fecha y hora) para generar una alerta significativa que será sobre la que tenga que trabajar el analista. En este ejemplo, varias filas de eventos simples se han reducido a una única alerta.

Tratar de implantar un sistema de monitorización, sin tener el apoyo de la dirección y la involucración de las áreas de negocio.

Este es un error básico. Ocurre a veces que se dispone de presupuesto para la implantación del proceso desde el punto de vista técnico, pero no se cuenta ni con el apoyo expreso de la dirección ni con el compromiso del resto de áreas de la organización. Sin este soporte, es imposible que el proceso sea efectivo, dado que será imposible gestionar las condiciones de alarma. Sin un compromiso claro de la dirección, sería mejor dedicar la inversión a otros recursos más útiles.

Implantar un sistema de monitorización sin que exista un procedimiento de respuesta ante incidentes

Como hemos mencionado con anterioridad, la monitorización de seguridad es un proceso en el que las personas, con roles y responsabilidades bien definidos juegan un papel crucial. Por otro lado, deben estar establecidos procedimientos de escalado y circulación de la información relevante para poder garantizar que se reaccione con agilidad y eficacia ante las situaciones de riesgo. La extensión natural del proceso de monitorización de eventos de seguridad es el de respuesta ante incidentes.

Nos despedimos aquí por hoy, esperamos que esta información sea de utilidad. Un fuerte abrazo y hasta pronto.

2 Replies to “Recomendaciones para la implantación efectiva de un proceso de monitorización de eventos de seguridad (SIEM)”

  1. Totalmente de acuerdo Miguel Angel. La implantación de un SIEM en una organización suele ser un proyecto ambicioso, y muy costoso si no se planifica adecuadamente la integración de los activos y eventos. Yo también me he encontrado sitios donde tras implantarlo, han comenzado a salir alertas, se han ignorado y finalmente el sistema ha dejado de tener utilidad. Triste pero cierto.
    Saludos.

Deja un comentario