| CSC 12-11 | Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted. |
Why should you do this?
This is a detective control. You can't control what you're not tracking. Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.
What is the typical approach?
On Windows: Harvest and mine of the Windows event logs. Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX: Harvest and mine the UNIX syslogs.
What is the real challenge for organizations?
Data vs. Noise. How can organizations reconcile all the sources of data into meaningful information? This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.
Centrify's enhancers:
- Use what's native: Uses syslog and event logs. Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
- Enhance to differentiate the data from the noise: Centrify can be configured to require reference information upon elevation, for example, change control number.
- Contextualize with DirectAudit to "clear the noise": Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
- Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"
Have a look:
How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:
How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation
How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:
No comments:
Post a Comment