La gestión de eventos de seguridad: un diamante por pulir

La entrada de hoy corre a cargo de Javier Cao, un “clásico” del sector que no requiere demasiadas presentaciones y al que nos gustaría ver más a menudo por estos lares.

Aunque la entrada de hoy no es totalmente original como suele ser habitual, ya que fue publicada en su mayor parte ayer en su blog personal “Apuntes de seguridad de la información”, hemos creído interesante traerla también a nuestros lectores ya que guarda relación con dos de los aspectos en los que S2 Grupo está especializada: la Seguridad de la información y la Gestión de procesos (o eventos, en este caso) en tiempo real. Vamos pues con ella y esperemos que les guste.

Todas las organizaciones, grandes o pequeñas, disponen de sistemas de recogida de eventos que guardan en ficheros de log datos sobre lo que está sucediendo en el funcionamiento de los sistemas de información. Esta materia prima permite establecer un puesto de vigilancia y conocer de primera mano qué ocurre en sus sistemas de información. En algunos casos por tiempo, en otros por desconocimiento sobre las problemáticas a analizar, esos datos no sirven para tomar decisiones que en un momento dado pueden luego costar una factura muy cara. El ejemplo en el mundo físico es como quien coloca cámaras de vigilancia y sensores volumétricos en todos los rincones a vigilar de su empresa, centralizando toda esa información en un cuarto de control y luego no pone vigilantes las 24 horas del día para que monitoricen lo que sucede en esas pantallas y centrales de alarma.

El Ejército Americano tiene publicado un manual sobre cuáles son las herramientas a utilizar en el campo de las operaciones de información (Information warfare) que en conflictos bélicos son uno de los escenarios más relevantes donde se deciden las batallas. Es imprescindible leer el Capitulo I, de Introducción porque aporta una nueva perspectiva al concepto de “información” y sus dimensiones. Y tal como deja claro el manual, la información esencial, la importante donde se pueden perder batallas, es aquella que se emplea en la toma de decisiones. Este fue el mensaje que quedó en mi mente tras leer el documento americano.

No podemos llamar “información” sino “datos” a aquello que no sirve para tomar decisiones. Y ese es el verdadero problema/drama de los logs, que no llegan a ser información sino datos sobre la situación de seguridad de la Organización que son guardados o borrados sin que de ellos se extraigan conclusiones o decisiones que pueden evitar o mejorar en mucho la seguridad de los sistemas. Como mucho los logs se utilizan una vez sucedido el incidente para tratar de esclarecer los hechos perdiendo así una oportunidad de ser proactivos y preventivos.

Hace unos meses Anton Chuvakin, un “information security warrior” publicó un post con el top 7 de informes de seguridad.

Tal como establece el maestro Sun Tzu al hablar de los elementos a gestionar en el Arte de la Guerra, “La tierra puede ser alta o baja, ancha o estrecha, lejana o cercana, desnivelada o plana, propicia para la muerte o para la vida“. Todo General debe estudiar el contexto en el que se plantea el conflicto y tratar de moldearlo o dirigirlo para que le proporcione las mejores opciones y decisiones. El terreno tiene ciertas restricciones que no pueden alterarse, pero se debe ser consciente de todas estas limitaciones a la hora de plantear la táctica de combate. En nuestro caso, el terreno viene condicionado por la infraestructura TI de nuestra organización, pero también por los eventos y servicios que ésta suministra. En este sentido, una de las fuentes que mejor describen el campo de batalla son los eventos del sistema. Como decía el agente Mulder de Expediente-X, “la verdad está ahí fuera“. Todo administrador de sistemas o responsable de seguridad debería adecuar esa frase a “la realidad de lo que pasa en nuestros sistemas está en los logs“.

Juntando esto con las diferentes áreas que aparecen en ese top de informes de seguridad se puede construir el siguiente escenario de vigilancia e inteligencia de red.

Para empezar también me parece interesante comentar, tal como establece la norma “ISO/IEC 27035:2001 sobre gestión de incidentes” publicada el año pasado, la separación entre evento de seguridad e incidente. Todo incidente es generado por un evento de seguridad pero no todo evento de seguridad se transforma en un incidente. En el terreno de los logs nos movemos básicamente sobre el análisis de eventos que posteriormente hemos de decidir si son clasificados como incidentes. Ahora veamos los diferentes campos de batalla a gestionar. Los he separado en tres grandes áreas como ilustra este gráfico que atiende también a los diferentes tipos de escenarios y su hostilidad:

Personas:

  • Escenario de la gestión de usuarios: en este terreno los eventos a vigilar de cerca están relacionados con el ciclo de vida del usuario (alta, baja y modificación de permisos), los registros de acceso fallidos y con éxito, la elevación de privilegios y las conexiones con usuarios con los máximos privilegios.
  • Escenario de accesos a recursos: en este terreno los eventos a vigilar tienen que ver con los registros de auditoría de acceso del personal legítimo o interno sobre elementos muy protegidos que deben notificar cada intento de acceso a ellos para disponer de trazabilidad sobre el uso del recurso.

Recursos:

  • Escenario del cambio en recursos TI: en este escenario los eventos más relevantes son los relacionados con la instalación de software, la actualización, los cambios relevantes para la seguridad sobre parámetros de configuración, la modificación de las directrices de auditoría y la deshabilitación de las medidas de seguridad instaladas. También se pueden controlar desde este escenario el funcionamiento de las medidas de seguridad como pueden ser la actualización de las firmas de patrones del antivirus, la aplicación de parches sobre los sistemas y los resultados de los chequeos de vulnerabilidades.
  • Escenario de los problemas detectados: los eventos vinculados con este escenario están relacionados con la monitorización del funcionamiento de los recursos, su disponibilidad, incidencias de caída o fallo de componentes, errores en los sistemas, errores en sistemas de copia de seguridad, alertas sobre la gestión de la capacidad, eventos de reinicio y parada de sistemas, etc.
  • Escenario de la actividad interna de nuestra red: en este terreno, los eventos a vigilar están relacionados con los patrones de comportamiento de nuestra red y nuestros usuarios, los protocolos más utilizados, el consumo de ancho de banda, el volumen de tráfico demandado y recibido, la carga de nuestras conexiones, etc.

Enemigos:

  • Escenario del malware detectado: en este escenario, los eventos a vigilar deben provenir de las medidas de protección perimetral y antivirus. Se debe vigilar el número de infecciones recogido, los archivos en cuarentena, las estadísticas sobre el tipo de malware que se detecta (gusanos, troyanos, virus, hacking tools) así como la fuente de infección (descargas en la red, dispositivos USB, correo electrónico).
  • Escenario de la actividad externa sobre nuestra red: en este terreno, la información relevante proviene de las medidas de protección perimetral que inspeccionan el tráfico y que detienen aquellas peticiones que no superan la política de filtrado de tráfico y contenido. Sirve para poder detectar intentos de ataque, abusos sobre recursos accesibles desde el exterior, vulneración de las medidas de seguridad. Es necesario también atender a los volúmenes de información recibidos y salientes para detectar si hay elementos en la red interna comprometidos y que están siendo controlados desde el exterior.

Sobre todos estos campos de batalla, con una visión global y estratégica de lo que está sucediendo debe trabajar una pieza esencial en la línea de defensa de toda organización: la monitorización y gestión de eventos de seguridad.

Comments

  1. Buen informe