Suricata

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.

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.

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.

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

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.

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

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.