...
Per-credential store instructions are needed for exporting failed authentication records via syslog.
Some credential store-specific plugins may need to be developed.
Syslog Accumulator
Syslog is a (near) real time protocol, potentially generating a significant amount of traffic. An existing product such as rsyslog (GPL v3) could be used as the accumulator, as it is high performance, can be made highly available, can write to a database, and is modular.
Optimized modules for failed authentication counting could be developed.
Reference instructions for installation and configuration could be developed.
Database
A relatively simple schema can track failed authentication events as reported to the Accumulator. A basic table would track
Column | Description |
|---|---|
| ID of this row |
| ID of the credential |
| ID of the service generating the failure event |
| Originating IP address of the failure event |
| Time of the failure event |
An additional table is required to track when a count should be reset (perhaps due to a password change). A simple method would be to have a separate table to track the current count. Such a table should probably be managed by the Accumulator, as relying on stored procedures can have concurrency implications.
Column | Description |
|---|---|
| ID of this row |
| ID of the credential |
| Current count |
A table that tracks reset events (relying on database or application logic to calculate the current count) would also be viable. This table would be managed by the Monitor.
Column | Description |
|---|---|
| ID of this row |
| ID of the credential |
| Timestamp of count reset event |
Monitor
The final component is the Monitor, responsible for determining when thresholds are reached and taking appropriate action, as well as managing reset events. The most portable approach may be for the Monitor to periodically poll the database for counts, and then fire off events as appropriate. (It may be possible to leverage database trigger mechanisms to push events to the Monitor, but this is unlikely to be achievable in a cross-platform way.)
The Monitor would likely provide
- A polling mechanism to retrieve current counts
- Support for different thresholds to trigger different actions
- Notifications
- Credential expiration
- IAQ revocation (potentially without a credential being expired)
- API services
- Pull current state for a subject (useful, say, for integration with SSO or self-service tools)
- Reset counter (eg: on password change)
- User Interface
- Administer/configure Monitor
- Reporting on current counts and events
The Monitor would likely need to be developed (presumably as an Open Source project).