Enviar Syslog seguro de Sophos Firewall a un SIEM

Con Syslog, Sophos Firewall envía eventos a un servidor de logs externo, un SIEM o un SOC. Para que la integración resulte realmente útil, deben encajar cuatro elementos: transporte, selección de logs, formato y parser. Por eso, este artículo empieza directamente con la configuración y después muestra cómo detectar logs ausentes o interpretados de forma incorrecta.

El Log viewer local sigue siendo importante para el análisis en tiempo real. Central Firewall Reporting es adecuado para los informes de Sophos Fusion (antes Sophos Central); Syslog es la opción correcta para una retención propia, la correlación entre distintos fabricantes y la detección mediante SIEM.

Configurar el servidor Syslog

Antes deben definirse la IP de destino o el FQDN, el puerto, el formato de log esperado y un parser adecuado. El firewall necesita una ruta hacia el Collector y ambos sistemas deben disponer de una fuente de tiempo operativa. SFOS utiliza normalmente UDP 514 para Syslog. La pantalla no ofrece una selección de transporte independiente: Secure log transmission activa o desactiva la transmisión cifrada mediante TLS. El ejemplo TLS oficial de Sophos para syslog-ng utiliza el puerto 6514; el puerto y el listener siempre deben coincidir con el Collector utilizado.

Abrir System services > Log settings.
Seleccionar Add.
Asignar un nombre inequívoco, como siem-primary.
Introducir el Collector en IP address/domain.
Elegir Port, Facility, Severity level y Format de acuerdo con el sistema de destino.
Activar Secure log transmission si el Collector TLS está preparado.
Guardar.
En Log settings, activar los tipos de log deseados en la columna de este servidor Syslog.

SFOS admite hasta cinco servidores Syslog externos. Varios destinos tienen sentido si cumplen funciones distintas, por ejemplo un archivo local y un Collector MDR. Enviar todos los logs indiscriminadamente a todos los destinos aumenta el volumen, los costes y el riesgo para la privacidad.

Facility, severidad y formato

Facility: Las opciones incluyen DAEMON, KERNEL, USER y de LOCAL0 a LOCAL7. Por ejemplo, se pueden asignar LOCAL1 y LOCAL2 a dos firewalls. La asignación debe ser coherente en el Collector y en la documentación operativa.
Severity level: La selección representa la severidad mínima. Error también envía Critical, Alert y Emergency, pero no eventos Information ni Notice. Debug incluye todos los niveles. Un mínimo demasiado alto puede ocultar inicios de sesión y eventos operativos normales.
Format: Se puede elegir entre Standard syslog protocol y Device standard format (legacy). Lo determinante es el formato que espera el parser del SIEM. Un cambio posterior puede romper búsquedas, dashboards y reglas de detección.

Las Facilities identifican el origen de un log: DAEMON corresponde a procesos ejecutados como servicios, KERNEL a procesos del kernel y USER a procesos iniciados por usuarios con sesión abierta. LOCAL0 a LOCAL7 permiten asignaciones propias. En severidad, Alert es más grave que Critical y exige acción inmediata. Standard syslog protocol se llamaba antes Central Reporting Format; Central Reporting utiliza únicamente este formato. En Device standard format (legacy), el número de campos varía según el módulo.

Secure log transmission

TLS es recomendable para conexiones productivas a través de redes inseguras o compartidas, porque los logs pueden contener direcciones internas, nombres de usuario, URLs y eventos de seguridad. Sin embargo, no basta con activar la opción: el Collector debe aceptar TLS en el puerto seleccionado y ambos extremos deben poder validar los certificados.

Para la conexión Secure Syslog documentada por Sophos se aplica lo siguiente:

El certificado de servidor del Collector y su cadena de certificados deben ser de confianza para el firewall.
El FQDN configurado debe coincidir con el certificado. Sin LINCE, SFOS comprueba el Common Name; con LINCE puede coincidir el Common Name o el Subject Alternative Name.
En Certificates > Certificate authorities se descarga la CA de Sophos Default. El Collector debe confiar en el archivo Default.pem extraído de ella, porque Sophos utiliza esta CA para su extremo de la conexión.
Solo entonces se activa Secure log transmission con el puerto TLS preparado.

En el ejemplo oficial de syslog-ng, Default.pem y la CA externa se encuentran en el directorio de CA del Collector; peer_verify(required-trusted) fuerza la validación del certificado. Otros productos Collector utilizan sus propios Trust Stores. Un FQDN que solo figure en el SAN no funciona sin LINCE, y una dirección IP configurada no coincide con un certificado que solo contenga un nombre DNS.

Antes de activar LINCE con este fin, se deben comprobar el límite de certificación, los algoritmos permitidos y el reinicio de SSH del modo LINCE. El modo no es solo un interruptor de syslog y no debe activarse sin un acceso administrativo independiente.

Si un SIEM en la nube no admite este procedimiento directamente, el firewall puede enviar los logs internamente a un Collector local, que los reenvía de forma cifrada. Un tramo sin cifrar debe ser corto, estar segmentado y quedar documentado.

Preparar un Collector TLS con syslog-ng

Este ejemplo requiere un Collector Linux con syslog-ng, soporte TLS activado y un certificado de servidor emitido por una CA externa. El firewall es el cliente emisor. ExternalCertificate.pem es el certificado de servidor, ExternalPrivateKey.key su clave privada y ExternalCA.pem la CA emisora. Son nombres de ejemplo; las rutas y los certificados deben adaptarse al Collector. La clave privada debe permanecer protegida en el Collector; no se necesita la clave privada de la CA del firewall.

Comprobar la CA existente en Certificates > Certificate authorities > Default. Su nombre no se puede cambiar. Country name, State y Locality name describen país, región y ciudad; Organization name y Organization unit name, el titular y el departamento. Common name contiene un nombre o FQDN, y Email address, un contacto. Private key password permite cambiar una contraseña de CA existente. Key type ofrece RSA o Elliptic curve: para RSA se elige Key length y para Elliptic curve, Curve name; Secure hash establece el algoritmo hash. Key length es la longitud de la clave RSA en bits; las claves más grandes ofrecen más margen de seguridad, pero requieren más procesamiento. Los ejemplos de identidad de CA son Example AG, IT Security y fw01.example.com; sustituirlos por el titular, departamento y convención de nombres aprobada del propio entorno. Estos atributos de CA no son el certificado de servidor del Collector ni sustituyen su FQDN coincidente.

Proteger la CA existente: No cambiar ni regenerar la CA Default solo para Syslog. Planificar cualquier cambio necesario con copia de seguridad, ventana de mantenimiento y revisión de los servicios dependientes; renovar la CA Default explica las consecuencias. Actualizar sus ajustes con Save regenera automáticamente la CA Default y cambia el ancla de confianza. Guardar únicamente cambios aprobados en la ventana de mantenimiento planificada. Después, descargar el archivo tar.gz mediante el botón de descarga y extraer el certificado público de CA Default.pem.

En el Collector, colocar Default.pem y ExternalCA.pem en /etc/syslog-ng/ca.d/. ExternalCertificate.pem y ExternalPrivateKey.key pertenecen a /etc/syslog-ng/cert.d/. Comprobar antes los directorios y archivos existentes; no sobrescribir certificados sin planificación. Solo el servicio correspondiente y los administradores autorizados deben poder leer la clave privada.

Ejecutar estos comandos en el Collector Linux, no en SFOS Device Console. El primero lee el certificado. El segundo crea un enlace simbólico en el directorio de CA y requiere permiso de escritura allí:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Utilizar el hash devuelto realmente, no copiar 52412b66 a ciegas. Para la salida de ejemplo 52412b66, el comando es:

ln -s Default.pem 52412b66.0

Si ya existe una entrada .0, comprobar primero su destino en vez de sobrescribirla. Tras cambiar el certificado, revisar de nuevo el hash y la asignación.

Este ejemplo de syslog-ng.conf muestra un listener TLS y dos salidas locales. @version: 3.15 es la declaración de versión del ejemplo documentado, no una recomendación de instalar una versión obsoleta. Comprobar sintaxis, módulos y declaración con la versión instalada antes de utilizarlo. Integrarlo en la configuración existente, sin sustituir las demás fuentes y destinos.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 enlaza todas las direcciones IPv4 del Collector. En producción, utilizar preferentemente la dirección de recepción prevista y limitar TCP 6514 a los firewalls emisores mediante el firewall del host. El puerto 6514 debe coincidir con la entrada de SFOS. key-file y cert-file especifican la identidad del servidor y ca-dir, los dos certificados de CA; no desactivar peer_verify(required-trusted) para eludir errores. Los destinos de archivo ofrecen logs sin procesar y una salida adicional de clave-valor con precisión de milisegundos; adaptar rutas, permisos, rotación y capacidad de almacenamiento.

Antes de iniciar, comprobar la configuración con la función de validación de la versión instalada. Iniciar el servicio o aplicar los cambios de forma controlada en una ventana aprobada; ante problemas, volver a la configuración respaldada. Después, configurar el Collector, el puerto 6514 y Secure log transmission en System services > Log settings > Add de SFOS y pulsar Save. Seleccionar los módulos necesarios en la columna del servidor. El éxito requiere una conexión TLS sin errores de confianza, un evento de firewall generado deliberadamente en los archivos de salida y campos correctamente interpretados en el SIEM.

Definir los tipos de log y la visibilidad

El destino se activa en dos fases:

La regla o función correspondiente debe generar el evento. En las reglas de firewall se requiere Log firewall traffic y en las reglas de SSL/TLS Inspection, Log connections.
En System services > Log settings, debe seleccionarse el tipo de log correspondiente en la columna del servidor Syslog.

Si falta una de las dos fases, el Collector no puede recibir el evento. Para un piloto basta inicialmente con un conjunto pequeño y deliberado:

Firewall y Events: eventos de reglas, actividad de administradores y usuarios, así como eventos de autenticación, VPN, DHCP y DNS.
IPS, Content filtering, Web server protection y Zero-day protection: decisiones de seguridad y de políticas.
Active threat response: coincidencias de MDR, NDR Essentials, Sophos X-Ops y Third-Party Threat Feeds.
System health, Wireless, Heartbeat y SD-WAN: estado operativo adicional cuando se utilizan estos módulos.

Solo deben añadirse otros módulos cuando exista un objetivo de búsqueda, alarma o auditoría. Si se analizan eventos DoS, también debe comprobarse la configuración de Spoof Protection y DoS. Para Third-Party Threat Feeds y NDR y Active Threat Response, además del transporte de logs se necesitan búsquedas y alarmas concretas.

Alcance de ATR: Activar el registro de origen remoto solo para combinaciones de módulo y ruta de tráfico cuya compatibilidad esté establecida. El texto de ATR de Sophos y la matriz SVG de tráfico discrepan sobre las direcciones de coincidencia de X-Ops; el conflicto sigue sin resolverse. Las afirmaciones sobre MDR, NDR o feeds de terceros no demuestran una compatibilidad equivalente de X-Ops. Mantener controles restrictivos de firewall, DNAT/WAF y Device Access independientes del comportamiento controvertido del feed. Los casos controvertidos requieren una verificación autorizada y controlada del módulo, la dirección de coincidencia, los registros y el efecto real, además de una aclaración fiable; hasta entonces, la protección no debe depender de ese comportamiento. NDR y Active Threat Response explica el contexto seguro.

API XML: separar Collector, selección de logs y supresión

Quien gestione Syslog mediante la API XML debe tratar estos tres niveles por separado. Los ejemplos de Add/Update para SFOS 22.0 y SFOS 23.0 distinguen:

Ajustes del Collector: La dirección de destino, el puerto, TLS, Facility, severidad y formato determinan el receptor y la transmisión. Crear o seleccionar un Collector no activa automáticamente todos los logs.
Envío por grupo y submódulo: Dentro de LogSettings, SendLogs corresponde al nivel de grupo; los submódulos individuales pueden sobrescribir esta selección. El ejemplo advierte expresamente que no se debe especificar SendLogs cuando se enumeran todos los submódulos. Por tanto, no deben confundirse estas formas con una activación general. Para PolicyRules, el comentario del ejemplo indica Disable como valor predeterminado; de ello no se deriva una habilitación automática de todos los eventos de reglas. Sigue siendo necesario activar además el logging en la regla correspondiente.
Supresión: En el ejemplo, Log_suppress aparece separado del envío. La agrupación de eventos repetidos no es lo mismo que la selección de su receptor o de un filtro de severidad.

La tabla de parámetros incluye Name dos veces y describe la segunda fila como estado de supresión; además, indica literalmente uiui como valor predeterminado. Esto no constituye una base fiable para un valor predeterminado operativo ni para renombrar el campo de forma implícita. No deducir de ello un payload completo de supresión; aclarar primero los campos ambiguos de la API mediante la ayuda de la compilación concreta o con el soporte de Sophos. Antes y después de un cambio aprobado, generar los mismos eventos representativos y comparar los logs sin procesar en el Collector, los campos del parser en el SIEM, así como los tipos de log esperados y log_occurrence. Una conexión existente, por sí sola, no demuestra que la selección de logs sea correcta.

Errores habituales de visibilidad

Log Suppression: SFOS puede agrupar eventos de firewall idénticos y consecutivos. Esto afecta a Log Viewer, Sophos Fusion y Syslog. Por tanto, el parser y la detección también deben tener en cuenta log_occurrence.
Active Threat Response: Remote Source Match para tráfico DNAT o WAF entrante no está activado de forma predeterminada. Sin esta selección faltan las coincidencias de origen correspondientes en rutas de tráfico y módulos compatibles. Respetar también el alcance de ATR indicado arriba al investigar tipos de coincidencia ausentes; seleccionar la opción no demuestra compatibilidad con las direcciones controvertidas de X-Ops.
Wireless: Los logs de Access Points y SSID no están disponibles en el Log Viewer local. Deben enviarse específicamente a Sophos Fusion o Syslog y comprobarse allí.
Content filtering y SSL/TLS: El tipo de log seleccionado no sustituye el logging en la regla de firewall o de Inspection correspondiente.
Proxy web: Para el tráfico web de los puertos 80 o 443, el log Firewall puede mostrar Allowed mientras Web Filter bloquea la misma solicitud. Para conocer la decisión efectiva de la política deben correlacionarse ambos eventos.

Comprobar el formato y el parser

Una prueba del parser no debe limitarse a demostrar que llega algún texto. Los valores centrales deben poder buscarse como campos independientes. Este ejemplo abreviado y anonimizado corresponde a Standard syslog protocol para un evento de regla de firewall:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

En cambio, el formato legacy utiliza, entre otros, device, date, time, timezone, device_id y priority. Campos como status, user_name, nat_rule_id o log_occurrence dependen además del tipo de log y del evento. No deben tratarse como obligatorios para todos los eventos del formato estándar. La lista siguiente es una comprobación dependiente del caso de uso, no un esquema obligatorio universal. Defina los campos requeridos por separado para cada tipo de log habilitado, según su esquema correspondiente a la versión y un evento real representativo. Los campos de reglas y NAT solo se aplican a los tipos de evento correspondientes confirmados; evalúe los campos de conexión y usuario y log_occurrence únicamente cuando se proporcionen. La ausencia de campos no aplicables al tipo de evento no debe provocar que se descarten eventos válidos ni que se clasifiquen como errores del parser.

Para la aceptación son especialmente importantes, según el caso de uso:

Identidad: device_name, device_model, device_serial_id
Clasificación: log_id, log_type, log_component, log_subtype, severity
Política: fw_rule_id, fw_rule_name, nat_rule_id
Conexión: src_ip, dst_ip, puertos, protocolo y usuario
Tiempo y frecuencia: timestamp, zona horaria y log_occurrence

log_id contiene el tipo de log, el componente, el subtipo, la severidad y el Message ID. Esto hace que las reglas de detección sean más estables que las búsquedas de texto libre. Aun así, los campos que proporciona cada módulo deben comprobarse con un evento real de ese tipo de log.

Los doce caracteres ocupan posiciones fijas: los caracteres 1 y 2 forman el Log Type ID, 3 y 4 el Component ID, 5 y 6 el Subtype ID, el carácter 7 el Priority ID y los caracteres 8 a 12 el Message ID. Por tanto, 010101600001 se interpreta como 01 / 01 / 01 / 6 / 00001. El parser debe conservar los ceros iniciales y la anchura fija de los campos; como comprobación adicional se evalúan log_type, log_component, log_subtype y severity.

El módulo Syslog Events no es idéntico a configuration-audit.log. Los valores anteriores y posteriores solo están disponibles allí para objetos clave compatibles, como reglas de firewall, interfaces e IP hosts, no para todos los cambios de configuración. El alcance y el análisis se explican en el artículo sobre Audit Trail Logs.

En el ejemplo documentado 010101600001, el primer 01 significa Security policy, el segundo 01, Firewall rule, el tercero 01, Allowed, 6, Information, y 00001, Firewall traffic allowed. Los IDs de posición fija y los campos de texto emitidos cumplen funciones distintas; no deducir los campos de texto de un ID numérico sin verificación. Para otros Message IDs se necesita un catálogo de referencia Syslog correspondiente a la versión de SFOS utilizada; esta descomposición no explica todos los tipos de evento.

Varios firewalls y HA

En un entorno con varias appliances, cada evento debe poder asignarse claramente a un firewall, ubicación, cliente y clúster HA. Por tanto, el hostname, el número de serie, el modelo y la Facility deben estar documentados y ser filtrables en el SIEM. Desde SFOS 22.0, device_name identifica el hostname del firewall que generó el log. Después de una actualización, debe comprobarse que el parser incorpora este campo y no sigue usando solo device_serial_id o la cabecera Syslog como clave del asset.

Después de un failover HA, una restauración o un cambio de hardware, debe comprobarse si los eventos siguen asignados al asset existente o si aparecen como un sistema nuevo o duplicado. Lo mismo se aplica después de cambiar el hostname o el formato Syslog.

Probar la conexión con eventos reales

Un Collector en verde no demuestra que la selección de logs sea correcta ni que el parser funcione. Para la aceptación:

Documentar un firewall piloto y el estado inicial: nombre del servidor, destino, puerto, TLS, Facility, Severity, Format y todos los tipos de log activados en la columna del servidor.
Enviar inicialmente Firewall y Events al destino.
Generar tráfico que coincida con una regla de prueba con logging y Source, Destination y Service definidos.
Comprobar en el SIEM el dispositivo, la hora, el tipo de log, la acción, Rule ID, Source y Destination.
Generar un drop definido y establecer y cerrar una conexión VPN.
Probar al menos un evento de seguridad de IPS, Content filtering o Active threat response, siempre que el módulo se utilice en producción.
Activar después otros tipos de log paso a paso y observar el volumen y el resultado del parser.

Para probar reglas resulta útil la guía sobre Log Viewer, Policy Test y Packet Capture. También es importante una prueba negativa: una conexión esperada se bloquea de forma deliberada y debe aparecer como drop con la regla correcta.

En proyectos HA o de migración, la aceptación debe incluir una prueba de failover, restauración o cambio de hardware. Después, el SOC debe seguir reconociendo qué dispositivo y ubicación han generado el evento.

Revertir un cambio sin crear una interrupción de datos

No se deben cambiar al mismo tiempo el formato, la severidad mínima y la selección de logs. Si queda libre uno de los cinco espacios para servidores, se añade un segundo destino para migrar el parser o el Collector y ambos se mantienen primero en paralelo. Así se pueden comparar los datos sin procesar, los campos poblados, las marcas de tiempo y el volumen sin tocar el destino que funciona.

Solo después de la aceptación se desactivan los tipos de log en la columna del destino antiguo. Su entrada de servidor se conserva durante un periodo de observación acordado. Si faltan eventos, falla el parsing o el volumen es inesperado, se vuelven a activar allí exactamente los tipos de log documentados y se revierte la selección del nuevo destino. Si no queda ningún espacio libre, se registran los valores actuales antes de cada cambio individual y se restauran por completo si falla; no se elimina la entrada ni se cambia a la vez el parser.

Eliminar mediante la API no equivale a desactivar la columna de logs: Las tablas de Delete para SFOS 22.0 y SFOS 23.0 solo incluyen Name como no obligatorio, pero lo describen como estado de supresión y no muestran ningún selector de destino. Esta tabla contradictoria no demuestra ni una selección segura del destino cuando se omite el nombre ni la equivalencia entre eliminar el Collector y desactivar sus tipos de log. Mantener el Collector que funciona durante la migración. Antes de eliminar mediante la API, deben aclararse la identidad inequívoca y aprobada de la entrada que se va a eliminar y la sintaxis de eliminación mediante la ayuda de la API de la compilación concreta o con el soporte de Sophos; no adivinar ningún selector.

Operación, retención y fallos

Una integración Syslog necesita un Owner, una retención definida y una respuesta ante las alarmas. Además, debe estar claro quién evalúa los falsos positivos y adapta las reglas de detección. Los logs de firewall pueden contener datos personales, direcciones internas, nombres de usuario, URLs y actividad VPN. Por tanto, los derechos de acceso, los plazos de eliminación, la separación entre tenants y los costes del SIEM deben aclararse antes del despliegue general.

La operación no solo debe detectar ataques, sino también la ausencia de datos:

supervisar una actividad mínima esperada por firewall;
comprobar por separado que tipos de log importantes como Firewall, Events, IPS o Active threat response estén actualizados;
supervisar campos centrales del parser para detectar valores vacíos o renombrados de forma inesperada;
generar alertas sobre la caducidad de certificados y el estado del Collector;
volver a generar eventos de prueba después de actualizar firmware, parser o certificados.

La propia supervisión también debe probarse: si se interrumpe deliberadamente el envío de un tipo de log esperado o de un firewall, debe activarse la alarma de ausencia definida.

Los datos sin procesar que no contienen campos interpretados también representan un fallo. Una actualización del parser puede dejar intacto el transporte mientras los dashboards y las reglas de detección dejan de generar coincidencias.

Syslog no sustituye los Service Logs locales ni un archivo de troubleshooting para soporte. Para registros v5 de reglas de firewall con logging activado de forma selectiva resulta adecuado NetFlow; para muestras de interfaz y patrones de tráfico, sFlow. El estado del hardware y de las interfaces también puede supervisarse mediante SNMP.

Aislar errores de forma específica

No llega ningún log: Comprobar el destino, el puerto, el transporte, el routing y el firewall del extremo opuesto. Después, verificar si el tipo de log deseado está activado en la columna Syslog. Si el Collector se encuentra detrás de una VPN o una red de administración, tener en cuenta también la ruta, la SD-WAN Policy y Source NAT.

Solo faltan determinados eventos: Comprobar primero el logging en la regla de firewall o de Inspection afectada y después el tipo de log en Log settings. En ATR, comprobar además el Match Type necesario.

Determinar primero si el módulo y la ruta de tráfico tienen compatibilidad establecida. Respetar el alcance de ATR indicado arriba: la ausencia de registros no resuelve el conflicto de X-Ops, y las direcciones controvertidas no justifican activar sin más otros tipos de coincidencia.

Llegan logs sin procesar, pero faltan campos: Comparar el formato configurado, la versión del parser y la versión del firmware. Los campos estándar y legacy no deben esperarse en un mismo perfil de parser.

TLS no conecta: Comprobar el puerto TLS y el servicio del servidor, después la cadena de certificados, el FQDN, Common Name, SAN y el modo LINCE. Además, el Collector debe confiar en la CA de Sophos Default.pem. Al cambiar certificados, comprobar ambos Trust Stores y el proceso de renovación.

Las marcas de tiempo no coinciden: Comprobar NTP en el firewall y el Collector, la zona horaria del SIEM y la normalización del parser. Las horas incorrectas impiden una correlación fiable con logs de Endpoint, servidor e identidad.

Demasiados logs o demasiado ruido: No desactivar todo de forma indiscriminada. Evaluar primero los tipos de log que no se utilizan, las reglas innecesariamente ruidosas, los casos de uso del SIEM y log_occurrence; después, reducir la selección de forma específica.