Filtering Out Non-Correlated Enriched Values in SIEM Searches

[PanosMtln]

When running a SIEM search for a specific file, results return enriched values from third-party sources rather than actual findings within the network. This leads to excessive, non-actionable results, making investigations inefficient. How can we refine SIEM searches to exclude enriched data that does not directly correlate with internal network findings? Are there tuning methods to ensure only relevant results are returned?

[_K_O]

Do you have examples of input and output? Without some more details you may just get answers that say tune your search. 

• You can definitely use event types, log sources, platforms, vendors, etc to limit the scope of your search queries, but that's pretty generic advice. 
• If you have a list of the 3rd party sources, you can use the AND NOT operators to exclude them from your search or even use lists and exclude the lists. 

[PanosMtln]

Hello and thank you for your response!
As an example you can check the below event which was included in the results of a very simple query (user = "xyz")
However, the user I searched for appeared as an extended field correlated to a log that was unrelated to them.
This significantly complicates investigations, as I have to manually verify the actual relevance of each result. Ideally, I'd like to exclude this behavior—where SIEM automatically includes extended fields—so that searches return only directly relevant results.

So far, I haven’t found any event type, log source, platform, or vendor filter that effectively prevents these extended results from appearing. Do you know of any specific methods or settings that could help refine searches to avoid this issue?

[_K_O · Accepted solution]

@PanosMtln based on how Google SecOps works, it is adding in the additional information / fields because some log source has that information in it which is tying the userid to the user displayname, and other fields. If the actual information is incorrect, I'd suggest contacting the Google team for help because that could be a parser issue or some log ingestion issue.

However, if it actually is tied to another log for that user and just enriching the information, then it's likely expected behaviour. In that case, I'd suggest determining which fields and log sources you care about for your investigations and crafting queries which make use of the "outcome" section to extract the relevant information.