Capability

SIEM Log Streaming

Stream WAAP, ADC, AAM and operation logs in JSON, CEF or plainText to your own SIEM.

TR7 SIEM Log Streaming carries platform events to the organization's own SIEM, log analytics or compliance systems over standard syslog. Admin actions, health check events, system notifications, GTM events and WAAP security events can all be forwarded to external systems through the same log transport pipeline. Each profile operates per namespace; UDP or TCP transport can be selected, and RFC3164 or RFC5424 syslog standard can be applied. Message content can be produced in JSON, CEF or plainText format, so compatibility with different SIEM and log collection systems is managed through a single profile. Log sources are filtered at the profile level. Operators can choose to send only userLogs, hcLogs, notificationLogs, gtmLogs or security events; verbose behavior for health check logs is governed separately. Multiple profiles can run within the same namespace, allowing the same log stream to be forwarded to different targets in different formats. The result: TR7 does not lock logs into a proprietary product format — it converts them into a standard syslog stream that SOC, compliance and operations teams can read directly.

3
Message formats: JSON, CEF, plainText
2
Transport options: UDP and TCP
4
Log sources: user, health check, notification, GTM

If security and traffic events do not flow to a SIEM in a standard format, the SOC sees the full picture too late.

In enterprise security operations, WAAP, ADC, AAM, health check, admin action and GTM events should not stay locked inside a product console. SOC teams want to see these events in their own SIEM, log analytics and compliance systems. When a vendor keeps logs in proprietary or hard-to-convert formats, incident investigation becomes fragmented.

Different SIEM platforms come with different format expectations. Some teams want JSON for search and indexing, some rely on CEF for ready-made parsers, and some prefer a plain plainText syslog stream. Products that impose a single format extend integration timelines and push log normalization onto the organization.

In multi-tenant or namespace-separated environments, log streaming becomes even more sensitive. Each tenant's logs must reach its own SIEM, and events from different namespaces must not mix. A single global syslog output falls short for both isolation and auditability in such architectures.

Log volume is another challenge. In high-frequency health check or security event scenarios, sending every minor event to the SIEM can generate cost and noise. Source-level filtering, health check verbose control, multiple profiles and sampling where appropriate must all be part of the log operations model.

TR7 SIEM Log Streaming addresses all of this with namespace-scoped transport profiles, UDP/TCP syslog, RFC3164/RFC5424 support, JSON/CEF/plainText message formats and source-level filtering — carrying platform events to the organization's own SIEM pipeline.

Our approach

TR7 treats log forwarding not as a single global output, but as a profile model managed per namespace, format, source and destination.

A separate transport process per namespace provides log isolation

A dedicated log transport process can run for each network namespace. This model prevents log streams from different tenants mixing in multi-tenant environments and ensures each tenant's logs reach its own SIEM target.

A format pool adapts to different SIEM expectations

Log messages can be produced as JSON, CEF or plainText. JSON serves search and indexing workflows, CEF enables ready-made SIEM parsers, and plainText covers general syslog compatibility.

Profile-level source filtering reduces unnecessary log noise

Each transport profile selects which log sources to forward. Admin actions, health check events, notifications, GTM events and security events can each be managed through separate profiles as needed.

DB-driven sync applies profile changes without a restart

Log transport profiles are synchronized from management data. When a profile is added, changed or removed, the relevant namespace process is updated without restarting the full system.

Capabilities

SIEM Log Streaming carries TR7 platform events to external log infrastructure via standard syslog transports and SIEM-friendly message formats.

UDP transport provides a fast and simple syslog stream

UDP transport is a straightforward output model compatible with traditional syslog topologies. The default syslog port 514 can be used, or a different port can be selected at the profile level. It delivers low-overhead log forwarding for reliable LAN environments. Because UDP offers no delivery guarantee by design, TCP is preferable for critical environments.

TCP transport provides a connected and more controlled log stream

TCP transport is used by teams that want a connection-oriented log stream to the SIEM target. The target host, port and timeout can be defined in the profile; a typical TCP timeout is 10000 ms. TCP gives more controlled delivery than UDP, but connection behavior should be monitored when the target system is slow.

RFC3164 support ensures compatibility with legacy syslog receivers

RFC3164 is supported for integration with systems using the traditional BSD syslog format. The syslogAppName profile field can be used as the message prefix; the default value can be TR7_syslog_client. It provides broad compatibility for older SIEM or syslog receivers. This format is a practical choice in environments that do not require modern structured data.

RFC5424 support works with modern syslog architectures

RFC5424 is the more modern syslog standard and supports structured data fields. A TR7 log profile can select this standard to produce more organized and machine-processable syslog messages. Field parsing and event classification become more consistent on the SIEM side. Combined with JSON or CEF payload, it forms a strong integration model.

JSON message format is well suited for search and indexing systems

In JSON format, fields such as timestamp, source, severity, message and meta are easily machine-processable. Field-based search is simplified for log analytics, indexing and query systems. SOC teams can examine events as parsed fields rather than raw text lines. This format is preferred in integrations with modern log platforms.

CEF format enables fast integration with ready-made SIEM parsers

CEF messages are produced with the structure CEF:0|TR7|LogTransport|1.0|...|. Severity values are mapped on a 0-10 scale; levels such as info 3, warning 5, error 7 and critical 10 are used. Key-value fields can be processed by ready-made parsers on the SIEM side. This format suits SOC teams that want a standard CEF stream for event classification and correlation.

PlainText format is used in environments requiring basic syslog compatibility

PlainText format produces ISO timestamp, severity, source and message fields as human-readable text. It can be deployed quickly in environments without complex parsers or for temporary integrations. It offers high human readability and is appropriate for simple log targets where JSON or CEF would be unnecessary.

Four main log sources can be selected per profile

userLogs covers admin actions, hcLogs covers health check events, notificationLogs covers system notifications, and gtmLogs covers GTM events. Each profile can be defined to send only the sources it requires, so only relevant log classes reach the SIEM. WAAP security events can also be forwarded to the organization's log infrastructure through the same transport pipeline.

Health check verbose control manages log volume

Health check logs can generate high volume on busy systems. When hcLogsVerbose is false, only health check events with a stateChange condition are sent. This approach reduces SIEM noise and surfaces only meaningful service state transitions. Verbose behavior can be temporarily enabled during troubleshooting periods.

Multiple profiles can send the same log to different targets in different formats

More than one transport profile can be active within the same namespace. One profile can send in CEF format to the SOC SIEM while another forwards in JSON format to a log analytics system. This structure fans out the same log stream to suit different teams' needs. The multi-target scenario reduces the need to deploy a separate external log router.

Operational depth

SIEM Log Streaming is operated together with formatting, profile synchronization, validation, error isolation and message sanitization behaviors.

01

CEF formatting model

CEF vendor and product fields are produced as TR7 / LogTransport / 1.0. Severity is mapped on a 0-10 scale. Message fields are structured as key-value pairs readable by SIEM parsers.

02

App name configuration

The syslogAppName profile field is used as the application name in syslog messages. The default value can be TR7_syslog_client. This field is important for source identification and filtering on the SIEM side.

03

Profile synchronization

Profile changes are grouped per namespace and applied to the relevant transport processes. If an old profile is removed, its associated process is terminated. New or changed profiles can be brought into the active log stream without a restart.

04

Profile validation

If the transportType value is not syslog, the profile is not admitted to the current syslog transport pipeline. This structure leaves room for expanding to different transport types in the future. Current support is UDP and TCP syslog.

05

Error isolation

Syslog client connection and error events are recorded through the internal logger. Target SIEM connection errors do not bring down the main management process. Operators can monitor connection problems through logs and profile status.

06

HTML sanitization

If UI-sourced messages contain HTML content, the text content is extracted before being sent to syslog. This is particularly important for field safety and parser consistency in CEF format. Log messages are delivered to the SIEM in a cleaner and safer form.

When to use it

Forwarding WAAP events to the SOC system in CEF format

Security teams can send WAAP events to the SIEM in CEF format. Rule, severity, source and meta fields are processed by SIEM parsers. The SOC team sees events on their own correlation screen without entering the TR7 interface.

Feeding a search and analytics platform with a JSON log stream

Operations teams can select JSON format to forward logs to an external log platform in a field-indexed form. Timestamp, source, severity and meta fields become queryable. Error analysis and trend extraction are simplified.

Namespace-level SIEM separation in multi-tenant environments

A managed service provider can define a separate namespace and a separate log transport profile for each tenant. Each tenant's logs go to their own SIEM target. Tenant data is prevented from mixing in the same log stream.

Exporting admin and system events for compliance

Compliance teams can mirror userLogs, notificationLogs and health check state-change events to a central SIEM. Even if local logs are deleted or rotated, critical events remain in the external system. Admin actions and system events can be reviewed retrospectively during audits.

Frequently asked questions

Which log sources can be included in a transport profile?
Each profile can include any combination of the four available sources: userLogs (admin actions), hcLogs (health check events), notificationLogs (system notifications) and gtmLogs (GTM events). WAAP security events are also forwarded through the same transport pipeline. Per-profile source selection means only the relevant event classes reach the SIEM.
What is the difference between CEF and JSON message formats?
CEF messages follow the structure CEF:0|TR7|LogTransport|1.0|... with key-value fields and a 0-10 severity scale, making them compatible with ready-made parsers in many SIEM platforms. JSON format produces structured output with timestamp, source, severity, message and meta fields, which suits log analytics, indexing and query systems. Both formats travel over the same syslog transport.
Can multiple profiles run in the same namespace simultaneously?
Yes. Multiple transport profiles can be active within the same namespace at the same time. One profile can forward logs in CEF to a SOC SIEM while another sends JSON to a log analytics platform. This eliminates the need for an external log router to fan out the same stream to multiple targets.
How are health check log volumes kept under control?
When hcLogsVerbose is set to false, only health check events where the stateChange condition is true are forwarded. This filters out routine polling results and surfaces only meaningful service state transitions to the SIEM. Verbose mode can be enabled temporarily during troubleshooting.
When is TCP transport preferred over UDP?
UDP is suitable for reliable LAN environments where low overhead matters and occasional packet loss is acceptable. TCP provides a connection-oriented stream and is preferred for environments requiring more controlled delivery. Note that TLS-wrapped transport is on the roadmap but is not a current feature.
How are profile changes applied without downtime?
Log transport profiles are synchronized from management data through a DB-driven sync mechanism. When a profile is added, updated or removed, the relevant namespace process is updated without restarting the full system. Removed profiles cause their associated process to be terminated cleanly; new profiles are brought online immediately.

Let your SIEM read every platform event

Namespace-scoped profiles, JSON/CEF/plainText formats and source-level filtering — let's walk through a live setup on your own environment.