What is a one sentence summary of your feature request?
Generic Syslog Device Type Support for RTU Authentication Event
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
Issue Summary:
Our RTU devices are successfully sending authentication-related syslog messages; however, Netwrix is currently not capturing or parsing successful and failed authentication attempts when the devices are configured to send logs at the standard “Info” severity level.
We would like Netwrix to add one of the following capabilities:
A generic syslog device type/parser for RTUs and industrial control devices
OR
Native parsing support for Orion LXM, LX+, MS, and SX authentication syslog events at standard logging severities.
Primary Use Case:Capture and report
Successful authentication attempts
Failed authentication attempts
User login/logout activity
Authentication failures and related security events
How do you currently solve the challenges you have by not having this feature?
At this time, these authentication events only become visible within Netwrix if the device logging severity is increased from “Info” to “Debug.”
Thank you for the detailed write-up — this is a helpful use case.
I have a clarifying question before we go further: Netwrix Auditor does not currently have built-in support for Orion LXM/LX+/MS/SX devices or generic RTU syslog parsing. Given that, could you help us understand the mechanism by which switching the device logging severity from Info to Debug causes authentication events to become visible in Netwrix?
Specifically:
Are these events being ingested via a custom syslog source or an existing generic parser?
Is there an intermediate collector (e.g., a syslog forwarder or SIEM) involved in the pipeline?
Or are you observing this behavior through a different Netwrix product component?
Understanding exactly how the Debug-level events surface today will help us determine whether this is a parsing/filter issue on our side or a gap that requires a new device type to be added.
Thank you for the follow-up questions — happy to clarify.
The RTU devices are sending syslog messages directly to Netwrix without any intermediate forwarder or SIEM in the pipeline. On the Netwrix side, these devices are currently being ingested through a generic/catch-all syslog parser, as there is no native device type available for Orion LXM, LX+, MS, or SX devices.
Our observation is that when the RTU devices are configured at the standard “Info” severity level, the authentication-related syslog messages are either not being captured or are not being parsed/categorized in a way that surfaces them as authentication events within Netwrix. When we increase the device logging severity to “Debug,” those events do become visible — which suggests to us that the generic parser may be applying a severity filter or that the authentication event patterns at Info level are not being matched by the current parser logic.
To summarize the pipeline:
- Source: Orion RTU devices (LXM, LX+, MS, SX)
- Transport: Direct syslog to Netwrix (no forwarder or SIEM)
- Parser: Generic/catch-all syslog parser
- Gap: Authentication events at Info severity are not surfacing as expected
I hope this helps narrow down whether this is a parsing filter issue or a gap requiring a new device type.
Exactly! That is precisely what I am trying to pinpoint.
The logs you shared show activity from the NAND service, but the actual event format looks like a perfect match for our Generic Linux Add-on. I’m more than happy to help you get this sorted, but I need to understand one key thing: where exactly inside the Netwrix UI are you currently seeing these events surface?
Could you tell me the name of the console/report or share a screenshot of how these events look in Netwrix? That will help me understand your current pipeline.