En las operaciones de seguridad empresariales, los eventos de WAAP, ADC, AAM, health check, acciones de administración y GTM no deben quedarse bloqueados dentro de una consola de producto. Los equipos SOC quieren ver estos eventos en sus propios sistemas SIEM, de análisis de logs y de cumplimiento. Cuando un proveedor mantiene los logs en formatos propietarios o difíciles de convertir, la investigación de incidentes se fragmenta.
Las diferentes plataformas SIEM tienen diferentes expectativas de formato. Algunos equipos quieren JSON para búsqueda e indexación, algunos dependen de CEF para parsers listos para usar, y algunos prefieren un flujo syslog plainText simple. Los productos que imponen un único formato extienden los plazos de integración y empujan la normalización de logs a la organización.
En entornos multi-tenant o con separación de namespace, el streaming de logs se vuelve aún más delicado. Los logs de cada tenant deben llegar a su propio SIEM, y los eventos de diferentes namespaces no deben mezclarse. Una única salida syslog global se queda corta tanto en aislamiento como en auditabilidad en tales arquitecturas.
El volumen de logs es otro desafío. En escenarios de health check de alta frecuencia o de eventos de seguridad, enviar cada evento menor al SIEM puede generar coste y ruido. El filtrado a nivel de fuente, el control verbose de health check, los perfiles múltiples y el sampling donde corresponda deben ser todos parte del modelo de operaciones de logs.
TR7 SIEM Log Streaming aborda todo esto con perfiles de transporte con alcance de namespace, syslog UDP/TCP, soporte RFC3164/RFC5424, formatos de mensaje JSON/CEF/plainText y filtrado a nivel de fuente — llevando los eventos de la plataforma al pipeline SIEM propio de la organización.
TR7 trata el reenvío de logs no como una única salida global, sino como un modelo de perfiles gestionado por namespace, formato, fuente y destino.
Puede ejecutarse un proceso de transporte de logs dedicado para cada namespace de red. Este modelo evita que los flujos de logs de diferentes tenants se mezclen en entornos multi-tenant y garantiza que los logs de cada tenant lleguen a su propio destino SIEM.
Los mensajes de log pueden producirse como JSON, CEF o plainText. JSON sirve para flujos de trabajo de búsqueda e indexación, CEF habilita los parsers SIEM listos para usar, y plainText cubre la compatibilidad syslog general.
Cada perfil de transporte selecciona qué fuentes de log reenviar. Las acciones de administración, los eventos de health check, las notificaciones, los eventos GTM y los eventos de seguridad pueden gestionarse cada uno a través de perfiles separados según sea necesario.
Los perfiles de transporte de logs se sincronizan desde los datos de gestión. Cuando se agrega, cambia o elimina un perfil, el proceso del namespace relevante se actualiza sin reiniciar el sistema completo.
SIEM Log Streaming lleva los eventos de la plataforma TR7 a la infraestructura de logs externa mediante transportes syslog estándar y formatos de mensaje amigables con SIEM.
El transporte UDP es un modelo de salida directo compatible con las topologías syslog tradicionales. Puede usarse el puerto syslog predeterminado 514, o puede seleccionarse un puerto diferente a nivel de perfil. Proporciona reenvío de logs de bajo overhead para entornos LAN confiables. Dado que UDP no ofrece garantías de entrega por diseño, se prefiere TCP para entornos críticos.
El transporte TCP es utilizado por equipos que quieren un flujo de logs orientado a conexión hacia el destino SIEM. El host de destino, el puerto y el timeout pueden definirse en el perfil; un timeout TCP típico es de 10.000 ms. TCP proporciona una entrega más controlada que UDP, pero el comportamiento de la conexión debe monitorearse cuando el sistema de destino se ralentiza.
RFC3164 está soportado para la integración con sistemas que usan el formato syslog BSD tradicional. El campo syslogAppName del perfil puede usarse como prefijo del mensaje; el valor predeterminado puede ser TR7_syslog_client. Proporciona amplia compatibilidad para receptores SIEM o syslog más antiguos. Este formato es una elección práctica en entornos que no requieren datos estructurados modernos.
RFC5424 es el estándar syslog más moderno y soporta campos de datos estructurados. Un perfil de log TR7 puede seleccionar este estándar para producir mensajes syslog más organizados y procesables por máquinas. El análisis de campos y la clasificación de eventos se vuelven más consistentes en el lado del SIEM. Combinado con payload JSON o CEF, forma un modelo de integración sólido.
En formato JSON, los campos como timestamp, source, severity, message y meta son fácilmente procesables por máquinas. La búsqueda basada en campos se simplifica para sistemas de análisis de logs, indexación y consultas. Los equipos SOC pueden examinar eventos como campos analizados en lugar de líneas de texto raw. Este formato se prefiere en integraciones con plataformas de logs modernas.
Los mensajes CEF se producen con la estructura CEF:0|TR7|LogTransport|1.0|...|. Los valores de severity se mapean en una escala de 0-10; se usan niveles como info 3, warning 5, error 7 y critical 10. Los campos clave-valor pueden procesarse con parsers listos para usar en el lado del SIEM. Este formato es adecuado para equipos SOC que quieren un flujo CEF estándar para la clasificación y correlación de eventos.
El formato plainText produce los campos ISO timestamp, severity, source y message como texto legible por humanos. Puede desplegarse rápidamente en entornos sin parsers complejos o para integraciones temporales. Ofrece alta legibilidad humana y es apropiado para destinos de log simples donde JSON o CEF serían innecesarios.
userLogs cubre las acciones de administración, hcLogs cubre los eventos de health check, notificationLogs cubre las notificaciones del sistema, y gtmLogs cubre los eventos GTM. Cada perfil puede definirse para enviar solo las fuentes que requiere, por lo que solo las clases de eventos relevantes llegan al SIEM. Los eventos de seguridad WAAP también pueden reenviarse a la infraestructura de logs de la organización a través del mismo pipeline de transporte.
Los logs de health check pueden generar alto volumen en sistemas ocupados. Cuando hcLogsVerbose es false, solo se envían los eventos de health check con una condición stateChange. Este enfoque reduce el ruido del SIEM y muestra solo las transiciones de estado de servicio significativas. El comportamiento verbose puede habilitarse temporalmente durante los períodos de resolución de problemas.
Puede haber más de un perfil de transporte activo dentro del mismo namespace. Un perfil puede enviar en formato CEF al SIEM del SOC mientras otro reenvía en formato JSON a un sistema de análisis de logs. Esta estructura distribuye el mismo flujo de logs para satisfacer las necesidades de diferentes equipos. El escenario multi-destino reduce la necesidad de desplegar un router de logs externo separado.
SIEM Log Streaming se opera junto con el formateo, la sincronización de perfiles, la validación, el aislamiento de errores y los comportamientos de saneamiento de mensajes.
Los campos de vendor y producto CEF se producen como TR7 / LogTransport / 1.0. La severity se mapea en una escala de 0-10. Los campos de mensaje se estructuran como pares clave-valor legibles por los parsers SIEM.
El campo syslogAppName del perfil se usa como nombre de la aplicación en los mensajes syslog. El valor predeterminado puede ser TR7_syslog_client. Este campo es importante para la identificación de fuentes y el filtrado en el lado del SIEM.
Los cambios de perfil se agrupan por namespace y se aplican a los procesos de transporte relevantes. Si se elimina un perfil antiguo, su proceso asociado se termina. Los perfiles nuevos o modificados pueden incorporarse al flujo de logs activo sin reinicio.
Si el valor de transportType no es syslog, el perfil no se admite en el pipeline de transporte syslog actual. Esta estructura deja espacio para expandirse a diferentes tipos de transporte en el futuro. El soporte actual está limitado a syslog UDP y TCP.
Los eventos de conexión y error del cliente syslog se registran a través del logger interno. Los errores de conexión al SIEM de destino no afectan al proceso de gestión principal. Los operadores pueden monitorear los problemas de conexión a través de logs y el estado del perfil.
Si los mensajes provenientes de la interfaz de usuario contienen contenido HTML, el contenido de texto se extrae antes de enviarlo a syslog. Esto es especialmente importante para la seguridad de campos y la consistencia del parser en formato CEF. Los mensajes de log se entregan al SIEM de una forma más limpia y segura.
Los equipos de seguridad pueden enviar eventos WAAP al SIEM en formato CEF. Los campos de regla, severity, source y meta son procesados por los parsers SIEM. El equipo SOC ve los eventos en su propia pantalla de correlación sin entrar en la interfaz de TR7.
Los equipos de operaciones pueden seleccionar el formato JSON para reenviar logs a una plataforma de logs externa de forma indexable por campos. Los campos de timestamp, source, severity y meta se vuelven consultables. El análisis de errores y la extracción de tendencias se simplifican.
Un proveedor de servicios gestionados puede definir un namespace separado y un perfil de transporte de logs separado para cada tenant. Los logs de cada tenant van a su propio destino SIEM. Los datos de los tenants se evita que se mezclen en el mismo flujo de logs.
Los equipos de cumplimiento pueden hacer mirror de userLogs, notificationLogs y eventos de health check state-change a un SIEM central. Incluso si los logs locales se eliminan o rotan, los eventos críticos permanecen en el sistema externo. Las acciones de administración y los eventos del sistema pueden revisarse retrospectivamente durante las auditorías.
Perfiles con alcance de namespace, formatos JSON/CEF/plainText y filtrado a nivel de fuente — le mostramos una configuración en vivo en su propio entorno.