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.
By subscribing to our early morning news update, you will receive a daily digest of the latest security news published on Help Net Security.
With over 500 issues so far, reading our newsletter every Monday morning will keep you up-to-date with security risks out there.