Designing a PCI-Compliant Log Monitoring System
by F. William Lynch - Manager CTG - Monday, 27 August 2007.
Moving along to requirement 10.5, we’ll note that 10.5.1 refers to securing logical access to the logs. Since we’ve centralized the log locations, we should be able to easily implement whatever need-to-know access is required by restricting access to the log server itself.

At this point, we need to consider a few methods for ensuring the integrity of the collected log files. We could do this using several different methods or combinations thereof such as employing a file integrity monitor (which we’ll need for 10.5.5), employing write-once memory such as writing directly to CD or DVD-ROM, or coming up with another kind of read-only data storage. Since file integrity monitoring is already required, let’s go ahead and choose it as our method of ensuring log file integrity. There are a few different file integrity monitoring products available today, with the most widely recognized being “Tripwire”, which is a cross-platform tool. Open source file integrity monitors are also available, with the most widely recognized being “Aide”, which is available for UNIX-like operating systems only. Also, keep in mind that you may still need to configure file integrity monitoring on your other PCI production servers in order to satisfy requirement 11.5.

Once the file integrity monitoring is in place, requirement 10.5.2 is also satisfied because the integrity monitoring functions in a way that protects the log files from unauthorized modification. In addition, the file integrity monitoring software might also identify the source of the unauthorized modification, depending on the features of the software package selected. Finally, we can leverage the log monitoring system to fulfill requirement 10.7 by specifying appropriate backup schedules for each logfile collected. We also need to make sure that the log monitoring system has enough disk space to maintain 3 months worth of online log files. Note that capturing the 12-month backups from the log monitoring system instead of the PCI production servers we can more cleanly schedule tape retention times for the PCI production servers, as its likely that some production data is not needed for a full 12 months.

This article has shown your organization might proceed to establish a log monitoring and management system compliant with the PCI DSS v1.1. We’ve examined the major sub-requirements with Requirement 10 that would be considered in-scope for such a system and one way in which we might architect such a system.

Requirement 10: Track and monitor all access to network resources and cardholder data

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.
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.
10.2.2 All actions taken by any individual with root or administrative privileges.
10.2.3 Access to all audit trails.
10.2.4 Invalid logical access attempts.
10.2 5 Use of identification and authentication mechanisms.
10.2.6 Initialization of the audit logs.
10.2.7 Creation and deletion of system-level objects.
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.
10.4 Synchronize all critical system clocks and times.
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.
10.5.2 Protect audit trail files from unauthorized modifications.
10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter.
10.5.4 Copy logs for wireless networks onto a log server on the internal LAN.


How to talk infosec with kids

Posted on 17 September 2014.  |  It's never too early to talk infosec with kids: you simply need the right story. In fact, as cyber professionals it’s our duty to teach ALL the kids in our life about technology. If we are to make an impact, we must remember that children needed to be taught about technology on their terms.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.


Thu, Sep 18th