Consistent Criteria Searching

[JoeGumke]

When asked to search in the SIEM for any successful/failed authentication attempts, what do users leverage in terms of searching criteria?

There is event.category tag but not all parsers use that logic, nor do I believe CEF (common event format) based events even support categorization.

The Usernames are also not consistently parsing out amongst the parsers (user.dst,user.src,username), which means that when we are tasked with creating a failed login report, we have to create 3 separate reports using (username,user.dst,user.src) just to be sure that those tags are covered.

You would think we could globally search on a category such as this?

I currently have to go through each event source and identify how users are parsed out, which is not sustainable, as the SIEM should be able to consistently normalize this type of data.

[Anonymous]

You should be able to get the event from ec.theme = authentication and then getting the failure from ec.outcome. Is that not the case? As for username, that should be mostly user.dst. Do you have examples of parsers putting content in "username" or "user.src"? Those are rarely used. It could be simplified by building a lua parser to move those values to a single meta key, but I'd have to look into that more.

[JoeGumke]

Hi Sean,

You should be able to get the event from ec.theme = authentication and then getting the failure from ec.outcome.

Is that not the case?
JG -     Any event that leverages the Common Event Format does not apply(No categorization in these events), which alot of companies leverage. When I get some free time i'll have to dig through and find some specifics of log data not properly propagating this.
    

As for username, that should be mostly user.dst. Do you have examples of parsers putting content in "username" or "user.src"?
JG -    Any event that originates using common event format (CEF) use user.src
    I have found the The following non-CEF RSA parsers normalize data leveraging solely user.src by using this search here : "user.src exists && user.dst !exists"

    winevent_nic, rhlinux, winevent_snare, checkpointfw1, mcafeedlp, entrustig, ciscosecureacs, oracle,  hpnonstopserver
    
Those are rarely used. It could be simplified by building a lua parser to move those values to a single meta key, but I'd have to look into that more.
JG -  I wouldn't consider the term 'simplifying' in this case. Using LUA parsers require us to deploy more content into our environment that we cannot manage/maintain/have any visibility into where its deployed *consistently* amongst our infrastructure. It also adds another layer of complexity that admins/users have to be aware of that modify log data. This should be fixed at the parser level altogether.