Forum Discussion
Logstash collector vs UEBA and Exploration queries
Hello,
When using the official and supported Logstash output to ingest events from a WEC server, the table is not named `SecurityEvent` (gets `_CL` appended) and the fields are all appended with their types (due to the LogAnalytics API, documented behaviour). This breaks features such as the Exploration Queries (to pivot from investigation blade) which all expect the table to be named `SecurityEvent` with specific fields.
Do you plan to allow to create SecurityEvent table with proper fields through your official Logstash output or do you plan to allow to define mapping so that we could define that SecurityEvent table is corresponding to (example) Windows_CL and that field `EventID` is mapped to `EventID_d` (mapping to be defined by contributor for all fields required by UEBA/Exploration Queries)?
Best regards
- CliveWatson
Microsoft
Have you considered using a Parser - this is an example: https://github.com/Azure/Azure-Sentinel/blob/master/Parsers/Teams_parser.txt
I used this syntax recently to map a _CL with another Table - saved as a function called InfoP. You will probably want to map multiple columns, see the example for ideas.
union withsource=tt InformationProtectionLogs_CL, InformationProtectionEvents | extend User = iif(isempty(User),UserId_s,User)InfoP
| project User- Hi Clive,
Thanks for the tips! I wasn't aware of this feature.
Could this be used to map it against a table like SecurityEvents or CommonSecurityEvents used internally by Sentinel in Entity Behavior?- CliveWatsonIt's a feature that helps you with Queries or features that support queries, like Workbooks & Rules. If you create a function called: "mySecurityEvents" none of the built-in blades would be aware of that new name, so a solution like Entity Behaviour wont use this new 'virtual' table. However you could adapt the Entity Behaviour workbook to include this new Table (parser), or include it in custom rules you write.
