I've reviewed the Payment Card Industry Data Security Standard version 1.1 for which audit settings are needed to be compliant, and thought I should share this. The reason for sharing it is twofold: I want to verify that I got it right as many of the requirements are vague or ambiguous, and think it is useful for those of you who also have to be compliant with the PCI DSS.

Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical. The presence of
logs in all environments allows thorough tracking and analysis if something does go wrong.
Determining the cause of a compromise is very difficult without system activity logs.

10.1 Establish a process for linking all access to system components (especially access done with 
administrative privileges such as root) to each individual user. 

This is handled by default through Solaris auditing, but you need to configure what to audit.

10.2 Implement automated audit trails for all system components to reconstruct the following events:

10.2.1 All individual user accesses to cardholder data 

This requirement is met by the fr and fw audit classes, but unfortunately you can not enable it for just the cardholder data, you will have to audit all files, which will generate a considerable amount of traffic.

10.2.2 All actions taken by any individual with root or administrative privileges 

This requirement is a bit vague. What is an action? Assuming that they mean executed commands, you can meet this requirement by using the ex audit class.

10.2.3 Access to all audit trails 

Access to the audit trails is audited using the fr and fw classes. As with 10.2.1 this will generate loads of unwanted audit records.

10.2.4 Invalid logical access attempts 

Again this requirement is vague. Access to what? Assuming that they refer to files, this requirement is met by the -fr and -fw audit classes.

10.2 5 Use of identification and authentication mechanisms 

This requirement depends on what authentication mechanisms you are using. Assuming that you just use plain Solaris it is covered by the lo class, and if you use Kerberos you need the ap class too.

10.2.6 Initialization of the audit logs 

This requirement is met by the +aa class.

10.2.7 Creation and deletion of system-level objects. 

This requirement is met by the fc and fd classes (file creation and file deletion). I assume that they only mean successful events, so we can use +fc,+fd to reduce the size of the audit trail.

10.3 Record at least the following audit trail entries for all system components for each event:
10.3.1 User identification
10.3.2 Type of event
10.3.3 Date and time
10.3.4 Success or failure indication
10.3.5 Origination of event
10.3.6 Identity or name of affected data, system component, or resource. 

All these requirements are met by the audit records generated by Solaris.

10.4 Synchronize all critical system clocks and times. 

This requirement is met by synchronizing time using NTP.

10.5 Secure audit trails so they cannot be altered. 

10.5.1 Limit viewing of audit trails to those with a job-related need 

This requirement is met by limiting who can become root, which is best handled by turning root into a role, as it require explicit authorization (knowing the password isn't enough).

10.5.2 Protect audit trail files from unauthorized modifications 

The default owner, group and mode of the audit trails are root, root and 640, and the only user who is a member of the root group is root, unless you have changed that this requirement is met by default.

10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter 

Upon audit file rotation (audit -n) it should immediately be sent through a drop box to a remote system.

10.5.4 Copy logs for wireless networks onto a log server on the internal LAN. 

This requirement has nothing to do with Solaris auditing, so I don't cover it here.

10.5.5 Use file integrity monitoring and change detection software on logs to ensure that existing
log data cannot be changed without generating alerts (although new data being added 
should not cause an alert). 

This requirement can be met by computing a MAC (mac -a sha256_hmac) of the audit file once it is terminated (audit -n) and recomputing it before you use it again.

10.6 Review logs for all system components at least daily. Log reviews must include those servers that 
perform security functions like intrusion detection system (IDS) and authentication, authorization, 
and accounting protocol (AAA) servers (for example, RADIUS). 
Note: Log harvesting, parsing, and alerting tools may be used to achieve compliance with Requirement 10.6. 

This is the hard part. The above settings will generate several gigabytes of data on one busy system.

10.7 Retain audit trail history for at least one year, with a minimum of three months online availability.

Two tips for storing audit trails: either compress it using gzip or save them on a zfs file system with compression enabled. See this post for more information.

A trick

Since we are required to audit all file access it will generate a gargantuan amount of data, probably several gigabytes per day per system. This got me thinking of how to minimize this without post-processing the audit trail, and I came up with a solution.

There are two sets of files for which we must audit access to: cardholder data and audit files.

If you make the cardholder data owned by a role (e.g. pci), and set the file mode so that only the role may access the file (chown pci and chmod 0600), you don't have to audit fr for everyone. It will be enough to audit fr for the pci role. When the users who are authorized to access the data assume the pcirole, they get audited for fr even though their normal account aren't.

However, since root can read all files, that account also needs to be audited for fr. This also takes care of the auditing of access to the audit file, which are only accessible by root.

To catch someone changing the mode of cardholder data, e.g. making it world readable, the pci role should be audited for +fm (successful file attribute modification).

Audit configuration files

Below are the audit configuration for the the PCI DSS version 1.1:

/etc/security/audit_control

flags:lo,-fr,+fc,+fd

/etc/security/audit_user

root:ex,fr,fw,+aa:no
pci:fr,fw,+fm:no

Note! I have yet to try this out on a live system, but as soon as I have, I'll post the results here.

[Technorati Tags: Solaris OpenSolaris Security ]