Solaris audit settings for PCI DSS version 1.1
By martin on Sep 19, 2007
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
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
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
-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
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
10.2.7 Creation and deletion of system-level objects.
This requirement is met by the
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
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
and the only user who is a member of the
root group is
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
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
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.
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.
and set the file mode so that only the role may access the file
chown pci and
you don't have to audit
fr for everyone.
It will be enough to audit
fr for the
When the users who are authorized to access the data assume the
they get audited for
fr even though their normal account aren't.
root can read all files,
that account also needs to be audited for
This also takes care of the auditing of access to the audit file,
which are only accessible by
To catch someone changing the mode of cardholder data,
e.g. making it world readable,
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:
Note! I have yet to try this out on a live system, but as soon as I have, I'll post the results here.