This is the fourth post in the long, long series (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.
And so we continue with our Complete PCI DSS Log Review Procedures (for now, we are still in the introductory section, BTW!):
Other Requirements Related to Logging.
Many claims that are made about PCI DSS controls, such as data encryption or anti-virus updates, can make effective use of log files to actually substantiate the claims.For example, Requirement 1 ,“Install and maintain a firewall configuration to protect cardholder data” mentions that organizations must have “a formal process for approving and testing all external network connections and changes to the firewall configuration.” However, after such process is established, one needs to validate that firewall configuration changes do happen with authorization and in accordance with documented change management procedures. That is where logging becomes extremely handy, since it shows you what actually happened and not just what was supposed to happen.
The entire Requirement 1.3 contains guidance to firewall configuration, with specific statements about inbound and outbound connectivity. One must use firewall logs to verify this; even a review of configuration would not be sufficient, since only logs show “how it really happened” and not just “how it was configured.”
Similarly, Requirement 2 talks about password management “best practices” as well as general security hardening, such as not running unneeded services. Logs can show when such previously disabled services are being started, either by misinformed system administrators or by attackers.
Further, Requirement 3, which deals with data encryption, has direct and unambiguous links to logging. For example, the entire subsection 3.6, shown below in an abbreviated form, implies having logs to verify that such activity actually take place. Specifically, key generation, distribution, and revocation are logged by most encryption systems and such logs are critical for satisfying this requirement.
Requirement 4, which also deals with encryption, has logging implications for similar reasons.
Requirement 5 refers to anti-virus defenses. Of course, in order to satisfy Section 5.2, which requires that you “Ensure that all anti-virus mechanisms are current, actively running, and capable of generating audit logs,” one needs to see such mentioned logs.
So, even the requirement to “use and regularly update anti-virus software” will likely generate requests for log data during the assessment, since the information is present in anti-virus audit logs. It is also well-known that failed anti-virus updates, also reflected in logs, expose the company to malware risks, since anti-virus without the latest signature updates only creates a false sense of security and undermines the compliance effort.
Requirement 6 is in the same league: it calls for the organizations to “Develop and maintain secure systems and applications,” which is unthinkable without a strong audit logging functions and application security monitoring.
Requirement 7, which states that one needs to “Restrict access to cardholder data by business need-to-know,” requires logs to validate who actually had access to said data. If the users that should be prevented from seeing the data appear in the log files as accessing the data usefully, remediation is needed.
Assigning a unique ID to each user accessing the system fits with other security “best practices.” In PCI it is not just a “best practice”; it is a requirement (Requirement 8 “Assign a unique ID to each person with computer access”). Obviously, one needs to “Control addition, deletion, and modification of user IDs, credentials, and other identifier Objects” (Section 8.5.1 of PCI DSS). Most systems log such activities.
In addition, Section 8.5.9, “Change user passwords at least every 90 days,” can also be verified by reviewing the logs files from the server in order to assure that all the accounts have their password changed at least every 90 days.
Requirement 9 presents a new realm of security—physical access control. Even Section 9.4 that covers maintaining a visitor logs (likely in the form of a physical logbook) is connected to log management if such a visitor log is electronic. There are separate data retention requirements for such logs: “Use a visitor log to maintain a physical audit trail of visitor activity. Retain this log for a minimum of three months, unless otherwise restricted by law.”
Requirement 11 addresses the need to scan (or “test”) the in-scope systems for vulnerabilities. However, it also calls for the use of IDS or IPS in Section 11.4:“Use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. Keep all intrusion detection and prevention engines up-to-date.” Intrusion detection is only useful if logs and alerts are reviewed.
Requirement 12 covers the issues on a higher level—security policy as well as security standards and daily operational procedures (e.g., a procedure for daily log review mandates by Requirement 10 should be reflected here). However, it also has logging implications, since audit logging should be a part of every security policy. In addition, incident response requirements are also tied to logging: “Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations” is unthinkable to satisfy without effective collection and timely review of log data. Next section deals with PCI-derived logging policy.
Thus, event logging and security monitoring in PCI DSS program go much beyond Requirement 10. Only through careful data collection and analysis can companies meet broad requirements of PCI DSS.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:
- Incident Log Review Checklist
- All posts tagged PCI_Log_Review
