> To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance.
It's possible that some compliance regimes exist that mandate keeping logs of all unsuccessfully authentication attempts. There's surely a compliance regime out there that mandates every possible permutation of thing.
But the far more common permutation, like we see with NIST, is that the organization has to articulate which logs it keeps, why those logs are sufficient for conducting investigations into system activity, and how it supports those investigations.
> The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period.
A centralized IDP that touches every service is not mandated by NIST though. So while you are right that an IDP can handle that, the organization may not have the IDP integrated with a given system and you will still need compensating controls or mitigations. Outright incredulity over logging failed access attempts is surprising.
Did I express outright incredulity about logging failed attempts?
If you’re a company trying to meet a compliance regime and you don’t already have a central IDP, that’s step zero. None of the NIST requirements say “you must have an IDP”, but a massive portion of them are trivial with an IDP and a massive pain in the ass (both to implement and evidence to auditors) without one.
