Log monitoring activities are an integral part of Requirement 10 of the PCI Data Security Standard and it can be difficult to understand how the different logging portions of Requirement 10 interrelate. Despite this fact, some organizations are seeking to redesign their PCI logging environment in order to best accommodate the PCI requirements. In this article we will examine a few key design points for architecting a log monitoring and management system that would be compliant with PCI Requirement 10.
The first step in designing the log monitoring system is to evaluate the PCI requirements and determine which ones would be in scope. The detailed requirements list from the PCI DSS 1.1 is given in the sidebar. The requirements that might be satisfied with a log monitoring system include:
10.1 – Logging is enabled and active – We need to incorporate these sub-requirements into our log monitoring system design.
10.4 – Time Synchronization – We would need to configure the log monitoring servers to use the same NTP source as the log clients.
10.5 – Audit trail security – We need to incorporate these sub-requirements into our log monitoring system design.
10.6 – Log Review – We can incorporate these sub-requirements into our log monitoring system design.
10.7 – Log Retention – We can incorporate these sub-requirements into our log monitoring system design.
Note that 10.2 and 10.3 would be out of scope for the log monitoring system as these specify the types of events and the metadata that would be recorded. Obviously log content and generation would need to be configured appropriately at each monitored device.
Now that we know what we’re trying to achieve, let’s examine the possible design concepts and ways in which we can meet the requirements. Perhaps the best way to start is by including a centralized log server in the design. Although only sub-requirements 10.5.3 and 10.5.4 specifically calls for a log server, we’ll see that using the centralized design will allow us to be more flexible in meeting the other requirements and will also only require minimal changes to the production servers in the PCI network.
If you have a geographically distributed network, then you should take the quantity of log traffic into account. Assuming the default syslog protocol is used (as opposed to newer, more enhanced protocols such as syslog-ng) the log messages will be UDP based and could be discarded when WAN traffic is heavy. Therefore, you will probably want to distribute your log monitoring system with at least one log server per datacenter. This will reduce the amount of WAN traffic to a minimum. Don’t forget to configure your wireless APs to communicate with the centralized log server in order to satisfy requirement 10.5.4!
Once we have the logs collected in a centralized location, we can start applying additional controls around the logs that satisfy the other PCI sub-requirements. Let’s start with 10.6, which requires us to ensure that periodic log reviews are performed. The revised version 1.1 DSS explicitly allows for the use log monitoring/alerting tools to achieve compliance. There are many commercial and some open source tools available that we can implement to handle this monitoring and alerting. Since we’ll be running this process only on the centralized log server itself we also won’t have any performance hits to the rest of the production servers on the PCI network.
Once our log alerting is in place, meeting requirement 10.1 will be quite simple. We can state that any server from which we have received log data in the past arbitrary time period is considered to have its logged capabilities enabled and active. Should a particular server not check in within the arbitrary time period, then we would want to generate an alert for that server.
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.
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).
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.
10.7 Retain audit trail history for at least one year, with a minimum of three months online availability.