Project

General

Profile

Actions

Feature #5687

open

eve: "auth" and/or "auth_fail" log

Added by Victor Julien 2 months ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Most protocols we support have auth mechanisms. Add a dedicated event type for these, where logging the username and auth result is probably the most interesting.

Actions #1

Updated by Jason Ish 2 months ago

I want to write some thoughts on why a new event type might not be the best idea.

On the implementation side, this would probably be detected with the app-layer parser for said protocol. In that respect, it's similar to the other app-layer events a parser can already generate.

I think a login failure, by most event alert categorization systems, would be considered an alert. We already have the event type of alert with a classification type. Wouldn't this map very well to an "alert" of classification type "auth"?

Provided with a mechanism for app-layer events to contain "extra-data" that could contain the extra metadata (username, api key, etc) this could fit very well into the existing schema we already have.

While usernames are often used when a user is involved, API key authentication is very common these days as well. It could be useful to capture authorization failures as well.

One "pro" to being a unique event type is that maybe "alerts" don't provide much confidence anymore and are considered noise, and we need a new event type to "rise" above in importance. But this could ripple into other event types that are really "alert" in a well-thought-out classification/taxonomy system.

Actions #2

Updated by Victor Julien 2 months ago

Alerts are generated based on rules, so are part of policy, which users control. Auth events (fails or all) are essentially still metadata. Not all failed logins are alert-worthy, in fact maybe even the majority of them are not. I see these auth events as separate constructs from alerts.

I guess I see these auth events more like fileinfo records. An abstraction of something important that is implemented by most protocols. The abstraction into a single log would make it highly convenient to see them across protocols, again like with our fileinfo.

Side note: we should make sure we can actually match on all these auth events.

Actions #3

Updated by Jason Ish 2 months ago

As important as authentication failures are, I wonder if successful authentications should be captured as well. Think of multiple authentication failures between 2 hosts followed by success.

Actions #4

Updated by Victor Julien 2 months ago

Yeah, agree. Thats what I meant with "fails or all". Just all auth related events.

Actions #5

Updated by Jason Ish 2 months ago

Do you see authorization failures being log worthy as well? Say I'm authenticated, but get denied access to a resource? A database would be a good example of this.

Actions #6

Updated by Victor Julien 2 months ago

I suppose a logical consequence of this thinking is that we need a auth abstraction for parsers, inspection and logging.

Actions #7

Updated by Victor Julien 2 months ago

Jason Ish wrote in #note-5:

Do you see authorization failures being log worthy as well? Say I'm authenticated, but get denied access to a resource? A database would be a good example of this.

Hmm initial thought is this might be getting back to protocol specific territory, but need to think about it more.

Actions

Also available in: Atom PDF