Logged

Reports from system logs for compliance generally have the same basic requirements regardless of the standard being measured – whether PCI, SOX or FFIEC.  There are some foundational requirements for compliance reporting of logs to be considered effective:

• The data/time are synchronized throughout the environment.  This is vital to be able to correlate events between systems and to real-world events, such as security cameras, badge systems, etc.
• System, security and audit logs are sent to and stored on a system where users/administrators of monitored systems do not have access.   Logs will not be an effective identifier of fraud, theft or other nefarious acts if the perpetrator of those acts has the ability to remove log evidence of his activities.   Subscribing to a Log Management Service is a good way to address this concern.
• Individuals who access controlled systems should not have access to update or modify the scripts and/or software the produces the security reports.

The key elements for compliance log reports are:

Login Failure Report

I’ll be honest, I have never been a fan of reporting on things that didn’t happen, and this is no exception.  Depending on the type of asset that is in question (intranet or Internet facing, etc), such a report can be quite long.  An interesting use case would be to note that there is an attempt to brute force attack a privileged account from an internal source.  The preferable way to handle such problems is through account lockouts after a certain number of failed attempts.

In my view, the report should yield actionable data, so in this case, the purpose of the report would be to identify a potentially malicious insider that is attempting to log in with another employee’s credentials.  Another use would be to identify service accounts where the application is configured with an expired or out dated password.

A report of failed ssh login attempts for a server installed on the Internet would be an example of meaningless data.  The contents of the report would likely not lead to any kind of action.

Login/Log off report

The main focus of this report should be on privileged access – root, SU, administrator, SA, etc.  The key considerations for this report are:

Individuals accessing the system should be aware that access is monitored and reports are reviewed

Instances of login with a privileged account should be traceable back to a justifiable reason (a problem ticket or change ticket), such as troubleshooting a problem, installing a patch or software, etc.

In cases where shared accounts must be used (i.e., root), there should be a mechanism to identify the individual that made the access – such as through the use of normal accounts and SUDO or even SU’ing to root.

The frequency of review and integration with problem/change ticketing systems will depending on the environment and the criticality of the data and systems being protected.

Account and Group Management Report

Most compliance programs expect that permission changes are logged and reviewed for appropriateness.  Depending on the environment, that likely means validating that account creations and privilege modifications were authorized.  This is another area where linking to a helpdesk/change ticket system can identify exceptions without approval on this type of report.

Data Element Access Report

This type of report is generally used to monitor sensitive information, such as credit card numbers, health data, etc and is troublesome to establish, as it requires the identification of access attempts (succeed or failure), what was done (add, change, delete, view), and by who.   This type of reporting is not technologically possible with all types of software.  Reporting such information for a file in a directory on a Linux Server will be much more challenging than an Oracle database.  Provisions for such telemtry should be built into the systems that are used to manage sensitive data.