SIEM selección de dispositivos y logs

La creciente sofisticación de los ataques cibernéticos ha llevado a la implementación de sistemas de gestión de eventos e información de seguridad (SIEM) para proteger los activos empresariales.

Sin embargo, seleccionar los equipos y fuentes de logs adecuados para alimentar el SIEM puede ser un desafío. La elección incorrecta podría comprometer su capacidad para detectar y responder a incidentes de seguridad en tiempo real, dejando a la organización vulnerable ante ataques y fugas de datos.

En esta entrada de blog exploraremos los desafíos clave que surgen al seleccionar los equipos y fuentes para alimentar al SIEM; además, analizaremos los criterios clave para elegir los dispositivos y aplicaciones que generan registros.

Prepárate para sumergirte en el mundo de la selección de equipos y fuentes de logs para tu SIEM, y descubre cómo enfrentar estos retos en la ciberseguridad de tu organización.

Eventos por Segundo (EPS) y SIEM

El valor de Eventos por Segundo (EPS) es una medida fundamental en el ámbito de la auditoría de sistemas. Este valor se ve influenciado por dos factores principales:

1. La política de auditoría o las reglas aplicadas en el sistema fuente y
2. La naturaleza del negocio del sistema en cuestión.

Por ejemplo, un servidor con reglas de auditoría habilitadas para el monitoreo de acceso a objetos y configurado como un servidor web generará una cantidad significativamente mayor de registros en comparación con un servidor estándar.

Es importante destacar que los servidores de la familia Windows tienden a generar una cantidad mucho mayor de registros en comparación con los servidores Linux y UNIX, considerando las configuraciones predeterminadas estándar. Esto se debe a diferencias en la forma en que se administran y registran los eventos en los diferentes sistemas operativos.

Por otro lado, aún y cuando algunos fabricantes como Sumo logic y SPLUNK tienen un esquema de precios diferentes a EPS (como lo hace IBM QRoC), los criterios de selección de fuentes tienen impactos similares en costo y desempeño. Por lo tanto, es fundamental evaluar adecuadamente la cantidad y la naturaleza de los eventos generados y logs por cada fuente.

¿Qué logs se deben enviar al SIEM?

Elegir los logs correctos para enviar a un SIEM es importante para monitorear la seguridad de manera efectiva y detectar amenazas. La mezcla ideal depende del entorno específico, la industria y sus requisitos de cumplimiento. Sin embargo, aquí hay algunas reglas generales y categorías recomendadas:

Logs esenciales para el SIEM:

1. Controles de seguridad. Se recomienda recibir logs de firewalls, sistemas de detección/prevención de intrusiones (IDS/IPS), antivirus/antimalware y soluciones de seguridad para los endpoints (EPP/EDR/XDR). Estos logs darán información valiosa sobre posibles ataques, actividad sospechosa y amenazas bloqueadas.
2. Infraestructura de red. Es conveniente incluir los logs de los routers, switches y otros dispositivos de red. Esto permitirá monitorear los patrones de tráfico que resulten extraños, así como detectar intentos de acceso no autorizados y posibles ataques de denegación de servicio (DDoS).
3. Sistemas Operativos. Para monitorear la actividad de los usuarios, los intentos fallidos de inicio de sesión, las instalaciones de software y los cambios en el sistema, es recomendable reunir los logs de los servidores críticos, los equipos de escritorio y las laptops.
4. Aplicaciones. Es recomendable integrar los logs de las aplicaciones clave, especialmente aquellas que manejan datos sensibles o realizan transacciones financieras. Esto permitirá enfocarse en el acceso de los usuarios, los cambios, los errores y los eventos relacionados con la seguridad.
5. Bases de datos.  Los logs de las bases de datos deben ser vigilados para detectar intentos de acceso, consultas, modificaciones y actividad sospechosa. Esto es de suma importancia para proteger los datos sensibles.

Algo más a tener en cuenta:

1. Requisitos de cumplimiento: alinear los logs con las regulaciones de la industria o las políticas internas que debas seguir. Esto puede implicar ciertos tipos de logs y períodos de retención específicos.
2. Volumen de datos y almacenamiento: Considera cuántos logs genera cada fuente y la capacidad de almacenamiento del SIEM. Prioriza los logs más críticos y considera filtrar los datos menos importantes.
3. Alertas e investigación: personaliza la selección de logs para poder responder a incidentes de manera eficiente y hacer análisis. Elige los logs que te dan contexto y detalles sobre posibles eventos de seguridad.

Es importante tener en cuenta que registrar todos los logs no siempre es productivo. Se recomienda empezar con las categorías esenciales y luego ampliar de acuerdo a las necesidades y capacidades del SIEM. Es necesario revisar y ajustar regularmente la selección de los logs para garantizar el monitoreo de seguridad óptimo y el uso eficiente de los recursos. Se recomienda también tener presente la importancia de mantener la calma durante el proceso.

¿Cuál es el nivel de logs que se debe configurar en servidores LINUX para enviar al SIEM?

El nivel de logs que se debe configurar en servidores LINUX para enviar al SIEM depende del equilibrio entre la información necesaria para la detección de incidentes de seguridad y la capacidad de procesamiento y almacenamiento del SIEM. Aunque no existe un nivel de logs estándar que funcione para todas las organizaciones, hay algunas pautas que se pueden seguir.

En general, se recomienda configurar los servidores LINUX para enviar logs de nivel de información (INFO) o superior al SIEM. Esto garantiza que se registren todos los eventos relevantes y los posibles incidentes de seguridad. Los logs de nivel de información suelen contener información útil para el análisis y la detección de amenazas, pero no están tan detallados como los niveles más altos como debug (DEBG) o trace (TRACE).

Sin embargo, también es importante tener en cuenta los recursos del SIEM y el volumen de logs que se generarán en los servidores LINUX. Si se configuran niveles de logs más altos, como debug o trace, habrá una mayor cantidad de información disponible, pero también se generará una mayor cantidad de logs. Esto puede aumentar la carga en el SIEM y dificultar la detección y respuesta a incidentes de seguridad.

Además, es importante considerar los requisitos de cumplimiento y regulaciones específicas de la industria a la que pertenece la organización. Algunas regulaciones pueden requerir la recolección y retención de ciertos tipos de logs, lo que afectará la configuración de los niveles de logs en los servidores LINUX.

¿Qué logs no valen la pena enviar al SIEM?

Al enviar logs al SIEM, es importante considerar qué logs no vale la pena incluir debido a su bajo impacto, redundancia o gran volumen. A continuación, se mencionan algunos ejemplos de logs que probablemente no sean necesarios enviar al SIEM:

Logs de bajo impacto: Estos son los logs que no proporcionan información crítica o relevante para la seguridad de la red. Algunos ejemplos podrían ser logs de aplicaciones de uso general, como reproductores multimedia, juegos o software de productividad estándar que no manejan datos sensibles o críticos. Algunos ejemplos son:

1. Mensajes de depuración: Estos logs generalmente son demasiado detallados y pueden generar ruido innecesario en el SIEM.
2. Logs informativos: Si no hay eventos de seguridad relevantes, estos logs pueden ser irrelevantes para la mayoría de los casos de uso.
3. Logs de aplicaciones no críticas: Si no hay información de seguridad sensible o riesgos potenciales, estos logs pueden no ser necesarios en el SIEM.

Logs redundantes: Estos son los logs que duplican información que ya está siendo enviada desde otra fuente o en otros logs. Por ejemplo, si ya estás enviando los logs de seguridad del sistema operativo, probablemente no sea necesario enviar también los logs de aplicación que incluyan información similar, como:

1. Múltiples logs con la misma información: Si varios logs contienen la misma información básica, solo uno de ellos debería enviarse al SIEM.
2. Logs duplicados: Si un log se envía a varios sistemas (SIEM, consola, etc.), no es necesario duplicarlo en el SIEM.

Logs de gran volumen: Estos son los logs que generan una gran cantidad de datos, lo que podría sobrecargar el almacenamiento y afectar el rendimiento del SIEM. Ejemplos podrían ser:

1. Logs de auditoría de archivos: Si el volumen de cambios en archivos es considerable, puede sobrecargar el SIEM sin aportar valor significativo.
2. Logs de aplicaciones con alto tráfico: Si una aplicación genera una gran cantidad de logs irrelevantes, puede afectar el rendimiento del SIEM.

Es importante revisar y evaluar la utilidad de cada tipo de log antes de enviarlos al SIEM. Esto permitirá optimizar el rendimiento del SIEM, conservar recursos de almacenamiento y concentrarse en los logs que son más valiosos para monitorear y detectar amenazas de seguridad.

5 razones para no monitorear ciertos equipos con el SIEM

1. Sobrecarga del sistema: Monitorear demasiados equipos con un SIEM puede sobrecargar el sistema y afectar su rendimiento. Cada equipo envía una gran cantidad de logs y eventos al SIEM, lo que puede consumir recursos de almacenamiento y procesamiento. Al no monitorear ciertos equipos, se puede evitar la sobrecarga y asegurarse de que el SIEM funcione de manera eficiente.
2. Costos adicionales: Implementar y mantener un SIEM conlleva costos, incluyendo licencias y recursos necesarios. Monitorear equipos innecesarios aumenta los costos. En muchos casos, se pueden reducir los costos al limitar la monitorización solo a los equipos y sistemas críticos y relevantes para la seguridad.
3. Ruido de datos: Al monitorear equipos que no son críticos para la seguridad, se recopilará una gran cantidad de datos irrelevantes. Esto puede generar ruido en el sistema y dificultar la detección de amenazas reales. En lugar de diluir la atención en datos innecesarios, es más efectivo enfocarse en los eventos relevantes que puedan indicar una posible brecha de seguridad.
4. Privacidad: Monitorear equipos personales, como las computadoras de los empleados, puede plantear problemas de privacidad. Al acceder a los logs y registros de estos equipos, se podría violar la privacidad de los empleados y generar desconfianza. Es importante establecer políticas claras sobre qué equipos serán monitorizados y asegurarse de cumplir con las regulaciones de privacidad y consentimiento de los empleados.
5. Sobrecarga del SOC: Al monitorear un gran número de equipos se genera una mayor carga de trabajo para el personal del SOC. Monitorear requiere tiempo y recursos adicionales para analizar y responder a los eventos y alertas generados por estos equipos. Esto puede resultar en una distracción para el equipo de IT, desviando su atención de los aspectos más críticos de la seguridad de la red.

¿Qué equipos se debe evitar monitorear con el SIEM?

No todos los equipos son igualmente importantes para el monitoreo de seguridad. Los dispositivos que no almacenan ni procesan datos críticos no necesitan ser monitoreados por el SIEM. Los equipos de prueba y desarrollo también pueden ser excluidos, ya que sus actividades pueden generar falsos positivos.

Algunos ejemplos de equipos que no se deberían monitorear el SIEM incluyen:

Dispositivos personales:

1. Teléfonos móviles
2. Tabletas
3. Equipos de escritorio o portátiles de empleados

Equipos de baja seguridad:

1. Impresoras
2. Escáneres
3. Cámaras de seguridad

Dispositivos IoT de bajo riesgo:

1. Luces inteligentes
2. Termostatos inteligentes
3. Cerraduras inteligentes

Equipos con poca capacidad de procesamiento:

1. Equipos antiguos
2. Equipos con recursos limitados

Dispositivos que generan grandes cantidades de datos irrelevantes:

1. Sensores
2. Equipos de medición
3. Equipos de monitorización

Red de invitados:

1. Es una red separada de la red principal y no debería tener acceso a información sensible.
2. Cualquier equipo que no cumpla con las políticas de seguridad de la organización.

Es importante tener en cuenta que la decisión de qué equipos monitorear con un SIEM debe tomarse en función de las necesidades específicas de cada organización. Se recomienda realizar un análisis de riesgos para determinar qué equipos son los más críticos para la seguridad y qué información es la más relevante para la detección de amenazas.

Fuentes:

1. AT&T Cybersecurity: What to log in a SIEM: https://cybersecurity.att.com/solutions/siem-platform-solutions
2. LogRhythm: Log Ingestion 101: https://logrhythm.com/blog/logs-to-bring-into-your-siem/
3. Blumira: What To Log In A SIEM: Logging Best Practices: https://www.blumira.com/siem-detection-rules-explained/
4. Blog de Pandora FMS sobre logs en Linux: https://pandorafms.com/blog/es/logs/: https://pandorafms.com/blog/es/logs/