- Find Answers
- :
- Using Splunk
- :
- Splunk Search
- :
- Re: What is the reseasoning behind the Sysmon sour...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark Topic
- Subscribe to Topic
- Mute Topic
- Printer Friendly Page
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
all,
I was just looking at the sysmon sourcetype "XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" and it's not really intuitive. What's the reasoning behind this naming convention?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the xmlWinEventLog token is important as part of a metadata field because its presence influences search or index time field extractions specific to xml structured event logs
the source and sourcetype values are identical coming off universal forwarders. with splunk app for windows v5, the index time field extractions were configured to drop the logname token from the sourcetype field. i trust that splunk has big plans that will make this breaking change worthwhile but i am not aware of what those plans are and im sure those plans are stifled in implementation because knowledge object dependency management (adapting to the breaking change) is extremely cumbersome, particularly in a clustered search head scenario.
the /operation token is not influenced by splunk. the varying values in that position represent the class of events the registered event source is associated with..it's a windows thing... values could be be admin|operational|debug|analytic
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the xmlWinEventLog token is important as part of a metadata field because its presence influences search or index time field extractions specific to xml structured event logs
the source and sourcetype values are identical coming off universal forwarders. with splunk app for windows v5, the index time field extractions were configured to drop the logname token from the sourcetype field. i trust that splunk has big plans that will make this breaking change worthwhile but i am not aware of what those plans are and im sure those plans are stifled in implementation because knowledge object dependency management (adapting to the breaking change) is extremely cumbersome, particularly in a clustered search head scenario.
the /operation token is not influenced by splunk. the varying values in that position represent the class of events the registered event source is associated with..it's a windows thing... values could be be admin|operational|debug|analytic
Take Your Breath Away with Splunk Risk-Based Alerting (RBA)
SignalFlow: What? Why? How?
Federated Search for Amazon S3 | Key Use Cases to Streamline Compliance Workflows
