Fundamentos IBM Security QRadar SIEM

Fundamentos del IBM Security QRadar SIEMCualquier texto que describa los fundamentos de algo debe comenzar con una definición. Pero este no será el caso, ya que voy a tratar de usar un lenguaje simple para explicar qué es IBM Security QRadar SIEM y lo que hace.

En primer lugar hablamos sobre seguridad IT. En la actualidad, el la seguridad es un tema que se repite con frecuencia en los titulares de los diarios. De hecho, muy pocas empresas del fortune 500, podrían presumir de no haber sufrido ningún ataque o pérdida de información sensible. Muchas de ellas son conscientes de este tipo de ataques en días, meses e incluso años después de que hayan ocurrido. Por eso, en la actualidad, el reto verdaderamente real no es solo ser impenetrables a los ataques, sino conocer cuándo y cómo nuestros sistemas han sido vulnerados. Es en este punto donde IBM Security QRadar SIEM puede echarnos una mano.

Qué es IBM Security QRadar SIEM y qué hace

Encontramos aquí el primer punto importante de este texto: IBM Security QRadar SIEM ayuda a reducir el intervalo de tiempo que transcurre entre el momento en el que hemos sido atacados y el momento en el que somos conscientes de ello. Pero, ¿cómo? Lo primero de todo, será echarle un vistazo al siguiente gráfico. Representa el input data para QRadar, aquello que alimenta al programa.

Tal y como podemos ver en el gráfico, QRadar SIEM recibe información de las siguientes fuentes:

  • Flujos de red: un flujo es una conversación entre dos hosts
  • Registros del Sistema: cualquier dispositivo puede enviar sus registros hacia QRadar. Cuando hablamos de cualquier dispositivo, nos referimos a cualquier dispositivo sin distinción. QRadar SIEM entiende y soporta un amplio espectro de dispositivos, pero tu experiencia como administrador QRadar puede guiar al programa a entender casi todo.
  • Datos vulnerables: QRadar SIEM se integra perfectamente con los principales escáneres de vulnerabilidades del mercado e incluso tiene su propio escáner. Este provee información vulnerable sobre los dispositivos presentes en nuestra infraestructura para enviarlos al QRadar.
  • Bienes de información: QRadar SIEM es suficientemente inteligente para construir una base de datos de todos los dispositivos en la red local para examinar los datos entrantes. Podemos proveer información adicional en su base de datos que QRadar no podría encontrar fuera, como la persona responsable de los bienes o su número de teléfono.
  • Entrada del usuario QRadar: QRadar también te escucha. Puedes proveer e introducir en el programa información válida que QRadar puede usar.

¿Qué hace QRadar SIEM con toda esta información?

Déjame usar dos palabras aquí: normalización y correlación.

Normalización:

Observa este problema: un dispositivo A envía sus registros con un campo que puede ser reconocido como la dirección IP de origen de los eventos que han sido registrados. Este campo se llama SrclP en el dispositivo. Echa un vistazo:

Oct 9 02:34:03 DeviceA SrcIP=192.168.92.34 DstIP=192.168.1.100 Evnt=Failed Login

Ahora observemos los registros desde el dispositivo B:

Oct 9 02:38:03 DeviceB Source_IP=192.168.92.34 Destination_IP=192.168.1.200 Event=Incorrect Password

Tenemos estos dos dispositivos registrando información relacionada con los registros fallidos y enviando las direcciones IP de origen, la dirección IP de destino, así como la fecha y hora del evento. Tenemos campos comunes entre los dos eventos, como las IP vinculadas y los tipos de evento. El problema es que estas propiedades tienen diferentes nombres en el dispositivo A y en el dispositivo B. Aquí es donde IBM Security QRadar SIEM puede ayudar. A través de la normalización de propiedades, estos campos se trasladan al “lenguaje” de QRadar. De esta forma, la propiedad SrclP será “Source IP” en QRadar y esta propiedad retendrá la dirección IP de origen responsable de este evento. En el dispositivo B, la IP de origen también se traducirá por “Source IP” en QRadar e igualmente se almacenará como origen.

Esto es la normalización, es decir, la traslación de campos comunes presentes en los datos recibidos por una propiedad QRadar y que pueden ser buscados y usados en el sistema.

Correlación:

Tenemos estas Fuentes de información:

  • El syslog del servidor que registra las conexiones exitosas y no exitosas a SSH.
  • Datos de acceso físicos desde un servidor que lee las tarjetas RFID de los empleados.

Consideremos el siguiente caso: hay un administrador de Sistema, quien está autorizado para conectarse al servidor por SSH y administrarlo, pero solo está autorizado para hacerlo desde el ordenador de su compañía y en su puesto de trabajo.

¿Cómo generar un delito u ofensa cuando este sujeto se conecte desde un lugar diferente? Podríamos usar las direcciones IP pero estas pueden ser fácilmente manipuladas. Esto podría lograrse con una combinación de eventos desde diferentes dispositivos. Se trata de la correlación: podemos “escuchar” conexiones SSH exitosas para ese usuario en el servidor syslog. Pero si solo podemos relacionar estas conexiones con los datos de acceso físicos que obtenemos del dispositivo que lee los códigos RFID de las tarjetas de los empleados, podríamos estar bastante seguros de que el usuario se está registrando desde su escritorio. Esto es lo que QRadar SIEM hace posible.

Inciso: no vamos a usar BuildingBlocks predefinidos o conjuntos de referencia. Existen mejores enfoques para realizar este tipo de acciones. El siguiente ejemplo ha sido simplificado para que sea fácil de comprender.

Cojamos este syslog desde el servidor:

<38>Oct 12 20:23:49 dbserver sshd[6782]: Accepted password for admin from 192.168.18.44 port 32044 ssh2

Añadimos una regla para detectar este tipo de situaciones cuando ocurren en el servidor de un usuario administrador.

Y como reglas de respuesta para estos tests:

Ahora podemos añadir una regla similar para escuchar los registros de firewall que presencian la conexión, pero nos saltaremos esta parte para simplificarlo.

En este punto, todo está correcto, un registro exitoso SSH de un usuario autorizado. No hay que preocuparse, por lo tanto, por temas de seguridad. Entonces, ¿qué pasa si este usuario está haciendo esto desde otra localización?. Un lugar que no está autorizado bajo las políticas de seguridad de la empresa. Este usuario en cuestión podría llevar su portátil con la misma dirección IP e ir fuera de la sala de ITAdmins para conectarse. Entonces usamos la correlación: vamos a crear una regla para acceder a la oficina con su tarjeta de identificación y asegurarnos de que el usuario no haya abandonado la estancia antes de haberse registrado en el SSH.

Primero una regla que  desencadene un evento representando nuestro usuario entrando en la oficina:

La respuesta, generamos un nuevo evento:

Hacemos los mismo para un admin que abandona la sala:

La respuesta, generamos otro evento:

Ahora tenemos tres eventos generados que podemos combinar para encontrar actividades sospechosas que puedan estar violando nuestras políticas.

De todas formas, esto es solo un punto de partida para explorar las capacidades de QRadar SIEM. Si quieres saber más acerca de este tipo de sistemas, Digital Tech Institute tiene preparado un itinerario de formación in company sobre Seguridad IT. Si eres un profesional particular, también puedes informarte sobre nuestros másters en Seguridad IT que impartimos de forma presencial en Madrid y Barcelona.

Déjanos un comentario

Debes estarconectado/a para publicar un comentario.

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies

ACEPTAR
Aviso de cookies