Logging and auditing relationship with your security/auditors

Cantor, Scott cantor.2 at osu.edu
Mon May 18 21:30:42 UTC 2020


On 5/18/20, 5:18 PM, "users on behalf of Mak, Steve" <users-bounces at shibboleth.net on behalf of makst at upenn.edu> wrote:

> Now I saw you answer that it would be impossible for that to show up in an audit log because of how late audit log
> processing happens, but is it possible to create a completely separate log, call is the security log, and have bad logins, 
> plus some audit log extractions, show up in a custom security log?

You can apply whatever rules you want to the various categories and route/filter them anywhere you want them. On INFO or WARN, there's little else that comes out of the categories.

> The failed logins in the process log are useless to the security team because they only have timestamp + username. They
> need the JSESSIONID and would like IP so they can coalesce other log lines from other log files.

Both of those are part of tbe MDC fields that can be added to the process log.

> Is your audit log the only log you offer for your mentioned use cases? Are your customizations limited to everything at
> post-response.

Yes.

> I don't believe we have any need to log attribute values at this time, but I'm curious about other things you've logged
> and which auth state the log data comes from.

Everything else I've logged is in the documentation. Audit logging occurs if and only if the flow completes, successfully or not. The plain fact is that the majority of failed authentications do not formally complete, so there is no way to log them with auditing. They simply aren't done, they're abandoned.

We have checked, and I think concluded, that aborted/flushed conversations are not caught so that any sort of listener could intercept them before they go away, they're just dumped silently by code we don't own.

It might be theoretically possible to add code to accumulate failed logins for password based systems and add/set it in an audit field that would be reported if the flow actually finishes one way or another. But it's my opinion that the majority of "failed logins" either don't matter because they're just mistakes, or they result in incomplete requests in which case it's not going to get audited.

Keep in mind, this whole idea of "failed logins" makes almost no sense for any other technology but passwords, or actually does get logged as a failed request since the user doesn't get to "keep trying" over and over.

-- Scott




More information about the users mailing list