Forum OpenACS Development: Ideas about: SIEM / IDS (Security Information and Event Management / Intrusion Detection System) for OpenACS / ]po[?

Collapse
1: Ideas about: SIEM / IDS (Security Information and Event Management / Intrusion Detection System) for OpenACS / ]po[?
Posted by Frank Bergmann on 11/10/20 12:35 PM
Hi!

A customer recently asked us if we could keep track of failed login attempts. These events are kept in error.log, but this level of history is only available for a few days on a busy system.

In ]po[, we already employ a suit of im_alert_check_{integer|float|alphanum|...} procs for checking variables of insecure origin that we sometimes have to use. We currently send out individual emails, which is not great:
https://gitlab.project-open.net/project-open/intranet-core/blob/master/tcl/intranet-alert-procs.tcl

So what about a central in-memory store for security events with a bit of logic? I'd call this an "application-level SIEM". I'd also add the option to forward the security events to an enterprise level SIEM, to write a local security log, etc.

I've started to look at the acs-developer-support code for an example on how to use nsv_array, and I've got the first code working.

Before going for a full-blown implementation, I wanted to see if there are better ideas in the community already, or if somebody sees the need for such a package on the OpenACS level. We'd want to include such a package in our next ]po[ 5.2 release, which could be in 9-12 months.

Cheers
Frank

Collapse
2: Re: Ideas about: SIEM / IDS (Security Information and Event Management / Intrusion Detection System) for OpenACS / ]po[? (response to 1)
Posted by Gustaf Neumann on 12/14/20 07:27 PM
Hi Frank,

not sure, if you are aware of the login-attempts interface in OpenACS 5.10: 

auth::login_attempts::get_all (public)
auth::login_attempts::record (private)
auth::login_attempts::reset (public)
auth::login_attempts::reset_all (public)
This interface is based on a in-memory representation based on ns_cache, and is used primarily as a configurable measure against brute-force password attacks. One can specify a wrong password limit (when should blocking start) and a timeout (when should the blocking end). It offers as well a GUI for admins (e.g. in the organizations help desk) to reset the password attempts, when a user has really forgotten his password, or had caps-lock on, etc.

The approach is subsite aware (since subsites might use different authorities).