Archivo de la categoría: Podcast

Podcast – 35 – SIEM

Hoy hablaremos de los SIEM (Security Information and Event Management). Estos sistemas surgen de la combinación de dos tareas, que inicialmente realizaban productos específicos: SIM (Security Information Management) y SEM (Security Event Management). Si bien cada una de estas funciones puede ser independiente de la anterior, la verdad es que para gestionar un evento necesitas tener información, así que los desarrolladores, sobre todo los de soluciones propietarias, han tendido a fusionar las dos tareas en un único sistema. En este capítulo no haremos diferencia entre funciones, sino que explicaremos el funcionamiento global de un sistema SIEM.

Logo SIEM
SIEM Fuente imagen: Gigaom

Los SIEM son probablemente una de las herramientas más difíciles de ajustar y que genera un mayor trabajo de gestión, muchas veces repetitivo, por lo que es muy importante que se tengan en cuenta en cualquier proyecto de implantación de un SIEM: se requiere mucho trabajo de ajuste del sistema para que el análisis de la información sea correcto y las alarmas generadas sean válidas e interesantes. Así cómo otros sistemas de protección, como los antivirus o sistemas anti-spam, pueden dejarse en modo automático, los SIEM deben ser gestionados, analizados y ajustados por técnicos especialistas si se quiere obtener resultados tangibles.

Veamos todos los pasos necesarios para obtener información, analizarla y obtener las alertas oportunas:

1. Recopilación de logs

Recolección de logs. Fuente: David Romero Trejo

El primer punto para un sistema de gestión de información es, precisamente recoger esa información. Aquí tenemos dos opciones para obtener los logs: la primera opción es que los sistemas que queremos analizar envíen una copia de sus logs a nuestro sistema SIEM; y la segunda sería que el sistema SIEM haga peticiones periódicas a los sistemas a controlar. Para el intercambio de información podemos utilizar protocolos estándares, como Syslog o SNMP, o bien la conexión con agentes instalados en los servidores a controlar. Lo más probable es que, debido a los entorno heterogéneos de cualquier empresa mediana, el sistema SIEM utilice una combinación de todas las opciones para recoger el máximo de información posible.

2. Normalización de logs

Al integrar información de diferentes fuentes debemos asegurarnos que guarden un formato común para poder hacer el análisis posterior. Cada fabricante decide cómo generar los registros de eventos de su plataforma y puede decidir cambiar el formato de logs entre diferentes productos o, incluso, entre versiones de un mismo sistema. Quizás el ejemplo más visual sea el formato de fecha de cuándo sucedió un evento: el formato estadounidense o el español son diferentes, también puede cambiar el texto si el idioma del sistema operativo es diferente (aunque sea lo mismo no queda el mismo registro un lunes que un Monday). Igualmente importante es que todos los equipos tengan sus relojes sincronizados para que el SIEM pueda conocer el orden cronológico de los eventos: para ello se conveniente utilizar un servidor NTP centralizado.

3. Almacenamiento de logs

En este punto más que el propio formato de almacenamiento de los registros, la principal característica técnica a tener en cuenta es la información extra que añade el sistema para permitir un tratamiento posterior más eficiente. El marcado, etiquetado, categorización debe permitir la selección de registros para su posterior correlación. Como suele suceder no existe un único tipo ni un sistema estandarizado de elegir qué y cómo almacenar los registros y todo tiene sus ventajas e inconvenientes.

Otro punto a tratar en este punto es qué logs de eventos queremos almacenar: la primera aproximación suele ser que queremos guardar todo, pero el gran tamaño de almacenamiento (que cuesta dinero) y la gran carga de trabajo de revisión, pronto llevan a cambiar de estrategia para buscar un equilibrio entre el todo, la nada y lo que podemos gestionar.

4. Correlación de logs

La correlación automática de los registros de eventos es, precisamente, la parte fundamental y el motivo de la existencia de estos sistemas. Diferentes algoritmos rastrean los eventos almacenados en busca de patrones que les permitan detectar un comportamiento anómalo que genere un evento de seguridad a estudiar. Este rastreo sistemático y pormenorizado de los eventos almacenados permite una detección de patrones muy superior a la de la intuición humana, por lo que estas herramientas son imprescindibles para un departamento de seguridad y, justifican su obligatoriedad de uso en algunas normativas.

Si bien muchos comerciales hablarán aquí de machine-learning, deep learning, inteligencia artificial, e incluso de deep-IA-learning o cualquier otro nombre comercial: la realidad es que se necesita de un sistema que en base a múltiples registros que provienen de diferentes fuentes, que en principio no están relacionadas, se encuentren patrones de acciones no habituales que deban ser analizados por un especialista.

Estos eventos pueden ser tan simples como detectar que un usuario de VPN se conecta desde una ubicación no habitual (p.e. si yo, que vivo en Mallorca me conecto desde casa y al cabo de dos horas lo hago desde Singapur es probable que algo no cuadre); un movimiento de ficheros entre servidores en horario nocturno; o bien procesos tan elaborados como detectar un APT en base a comunicaciones entre servidores. Las posibilidades de detección varían mucho en función del sistema SIEM utilizado y, sobre todo, de la cantidad de logs almacenados y correlacionados.

5. Gestión de alarmas

El resultado esperado de un sistema de gestión de información y eventos de seguridad es que tras todo el sistema acaben dando como resultado una serie de alarmas, con la mayor cantidad de información posible, que un especialista deba revisar. La gestión de una alarma de seguridad debería seguir el mismo procedimiento que la gestión de incidencias de IT de la empresa: todo debe quedar registrado en el sistema de gestión de incidencias y debe tratarse de la misma forma.

Hay que tener presente que los responsables de tratar con las incidencias de seguridad deben tener unos conocimientos amplios de muchas ramas de los sistemas IT (bases de datos, redes, sistemas operativos, etc.) para poder gestionar de forma eficiente la gran variedad de eventos que surgirán.

Un tema a tener en cuenta es que, al menos, durante los primeros meses de funcionamiento de un sistema SIEM, se generarán múltiples incidencias que resultarán ser falsos positivos por lo que los administradores del sistema deben retroalimentar correctamente al producto para que aprenda que situaciones pueden ser consideradas normales. No es extraño que los primeros meses de trabajo con un SIEM los responsables consideren que no sirve para nada ya que “pierden” la mayoría del tiempo persiguiendo falsos positivos. La gran ventaja del SIEM aparecerá una vez que ya esté estable y con una cantidad de información suficiente para tener un conocimiento del comportamiento habitual de nuestra empresa.

Conclusiones

Si pensáis implementarlo en vuestro negocio debéis tener en cuenta que los principios son duros ya que es una herramienta que precisa de administradores casi en exclusiva y con amplios conocimientos.

Además, es un sistema que debe ser gestionado y adaptado cada vez que la empresa lo necesite: por ejemplo, si nuestra empresa abre una nueva tienda en Noruega, el SIEM empezará a detectar conexiones a los sistemas corporativos desde direcciones noruegas o nuevos archivos almacenados con idioma noruego: es muy probable que este comportamiento genere eventos de seguridad que deberán ser catalogados correctamente en el sistema. Del mismo modo si se cierra la sede de Japón, habrá que avisar al sistema de que ya no deberían aparecer conexiones desde ese país y que no aparecerán textos kanji en nuestros sistemas. Por todo esto no es nada raro que una empresa que deba tener un SIEM por normativa subcontrate los servicios a un tercero. Estos servicios SOC, que permiten cumplir con la legislación y traspasar los riesgos a un tercero, pueden realizar un buen papel para la detección de conductas generales pero adolecen de la capacidad de adaptación al negocio que tendría un equipo interno. Pero claro, aquí ya hay que valorar necesidades, capacidades y costos.

Podcast – 45 – OSINT

En el capítulo de hoy tendremos como invitado a Jezer Ferreira, profesor de la Cyber Hunter Academy, auditor de seguridad y, como el mismo se denomina, OSINT lover.

La definición pura de OSINT (Open Source INTelligence) sería el conjunto de técnicas para recopilar datos públicos, correlacionarlos, analizarlos y extraer información útil. Su principal característica viene incluida en su propio nombre: ya que las fuentes de la información son públicas y accesibles por cualquiera.

OSINT
Palabra OSINT

Durante nuestra charla sale a relucir cómo gracias al OSINT se pudo localizar a John McAfee, el creador del famoso sistema antivirus, y cómo la policía se aprovechó de su especial forma de ser. Para aquellos que quieran conocer un poco mejor a esta figura, podéis escuchar el capítulo de la Tortulia Podcast que le dedican.

Espero que nuestra charla te ayude a entender cómo se puede obtener información de una serie de datos públicos.

Si quieres aprender más sobre OSINT, no dejes de seguir a Jezer.

Descarga directa.

Podcast – 44 – Factores de autenticación

En este audio locuto una entrada del blog que redacté en 2016 sobre los diferentes factores autenticación que podíamos tener para confirmar nuestra identidad, tanto en sistemas físicos como digitales.

Control de acceso.
Control de acceso. Fuente imagen: Click2Bank

Así, pues repasaremos los cuatro factores de autenticación:

  • Autenticación por lo que se sabe
  • Autenticación por lo que se tiene
  • Autenticación por lo que se es
  • Autenticación por lo que se es capaz de hacer

Cada uno de estos factores tiene sus ventajas e inconvenientes tanto teóricos como a la hora de su aplicación práctica, por lo que cuando queremos aumentar el nivel de seguridad es muy común utilizar un doble factor de autenticación. En cualquier caso como consejo general deberíamos activar un segundo factor de autenticación en todos los sistemas que lo permitan.

Descarga directa.

Podcast – 43 – ZTA con Joan Massanet

A diferencia de la mayoría de capítulos del podcast hoy tenemos un invitado con el que charlaremos sobre Zero Trust Architecture: Joan Massanet.

Joan es el CEO de la empresa World2Connect y colabora con la revista de seguridad informática ClickCiber.

Zero Trust Architecture
Fuente imagen:

La arquitectura de confianza cero es un concepto sencillo de entender pero con una gran dificultad de aplicación en el mundo real. Un sistema de ciberseguridad basado en ZTA simplemente no confía en los equipos, las redes o los usuarios por ser quienes son, sino que analiza, en tiempo real, la idoneidad o no del acceso a un recurso o información concreta en un momento dado. Quizás el ejemplo más sencillo sea que un administrativo puede acceder a la información de la empresa en horario laboral, porque debe poder trabajar, pero ese mismo acceso en fin de semana o de madrugada, cosa no habitual, estaría prohibido.

El problema de ZTA no es su concepto sino su implantación en nuestro mundo real donde existen multitud de situaciones extraordinarias y variables que deben ser tenidas en cuenta para que el sistema se adapte a nuestras necesidades reales. Siguiendo el mismo ejemplo no sería descabellado que los días previos a la presentación de declaraciones de impuestos nuestro administrativo deba realizar algún trabajo urgente de última hora fuera de su horario, así que el sistema de seguridad debería tenerlo en cuenta.

Obviamente esto es sólo un ejemplo sencillo y hay muchas más cosas a tener en cuenta.

Sin más, os invito a echarle un oído al capítulo de hoy.

Descarga directa.