PCI HOWTO Part 2; Revised NIST guidelines

PCI Logging HOWTO, Part 2

Payment Card Industry Data Security Standard (PCI DSS) was created by the major card brands and is now managed by the PCI Security Standards Council. Since its creation in 2006, PCI DSS continues to affect how thousands of organization approach security. PCI applies to all organizations that handle credit card transactions or that store or process payment card data – and such organizations number in the millions worldwide. Despite its focus on reducing payment card transaction risk, PCI DSS also makes an impact on broader data security as well as network and application security. Therefore, it can be considered to be the most influential security standard today.

Among other things, PCI DSS mandates producing and reviewing logs from systems within PCI compliance scope – those are the systems that process card data, are directly connected to them and the ones facing the hostile Internet. One should always remember that log collection and review are also critical for good security operations and incident response. In this article, we will continue to focus on operational aspects of logging and log management for PCI compliance.  In part 1, we have looked at the central logging requirements from PCI DSS Requirement 10. However, logging as a means of IT accountability is a perfect compliance technology; that is why it is implied in all twelve PCI DSS requirements! Let’s review where else logging is mandated or prescribed and what you should do about it.

On a high-level, logging and log management are used for two purposes in PCI DSS:

  • To directly satisfy a requirement – namely requirement for logging (Requirement 10.2 Implement automated audit trails for all system components and others) and log management (for example, Requirement 10.6 Review logs for all system components at least daily). These logging requirement usually get all of the attention of implementers and pundits as well.
  • To substantiate and enable other PCI DSS requirements such as user credential management (Requirement 8 Assign a unique ID to each person with computer access) or firewall rules (Requirement 1 Install and maintain a firewall configuration to protect cardholder data). These indirect requirements are no less important and no less mandatory as the other DSS guidelines.

Now, let’s dive deeper into the role of logs in order to further explain that logs are not only about the Requirement 10, which we covered in the previous paper. Just about every control that is deployed to satisfy the PCI DSS requirements, such as data encryption or anti-virus updates, can use log files to substantiate its validity.

Starting from Requirement 1 “Install and maintain a firewall configuration to protect cardholder data” we see that it 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 in accordance with documented change management procedures and do not put the firewall configuration out of sync with DSS guidance. That is where logging becomes extremely handy, since it shows you what actually happened and not just what was supposed to happen according to a policy or process.

Other log-related areas within Requirement 1 include section 1.1.6 “Justification and documentation for any available protocols besides Hypertext Transfer Protocol (HTTP), SSL, Secure Shell (SSH), and VPN” where logs should be used to watch for all events triggered due to such communication. Seeing that “connection allowed” to port 21 (telnet) log should call for some attention!

Also, section 1.1.7 “Justification and documentation for any risky protocols allowed” (such as for example TFTP or even FTP that exposes plain text passwords as well as transferred data to sniffers), which includes the reason for use of protocol and security features implemented, where logs help to review and monitor the use of “risky” protocols. This especially applies to cases where the use of risky protocols is not “official.” What is worse is when payment data is actually exchanged using such protocols. While logs will not show you what data was transferred, the use of the protocols themselves will be apparent in the logs.

Further, the Requirement 1.3 contains guidance to firewall configuration, with specific statements about inbound and outbound connectivity. One must use firewall logs to verify this; a mere infrequent review of firewall configuration would not be sufficient, since only logs show “how it really happened” and not just “how it was configured.” In order to substantiate this requirement one can use firewall system logging such as records of configuration pushes and updates as well as the summaries of allowed connection to and from the “in-scope” environment.

In order to address these section of Requirement 1, make sure that firewalls that protect a cardholder environment  log their configuration changes and user modifications as well as inbound and outbound connections to and from the environment.

Similarly, Requirement 2 “Do not use vendor-supplied defaults for system passwords and other security parameters” 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 after they compromise a system. For example, if Apache web server is disabled on an a mail server system (due to PCI DSS Requirement 2.1.1 “One primary function per server”), a message such indicating its startup since the service should not be starting or restarting.

In order to address these section of Requirement 2, make sure that system status and authentication  events are logged and can be used to reviews such activities.

Further, Requirement 3 “Protect stored cardholder data”, which deals with data encryption, has direct and unambiguous links to logging. For example, the entire subsection 3.6 that deals with generation of key storage, periodic encryption key changes, etc implies having logs to verify that such activities 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 “Encrypt transmission of cardholder data across open, public networks”, which also deals with encryption, has logging implications for similar reasons.

In order to address these section of Requirement 3 and 4, make sure that key management and other encryption system operations are recorded in logs and later reviewed.

Requirement 5 “Use and regularly update anti-virus software or programs” refers to defenses against malicious software. 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 logs. This requirement is directly satisfied by producing and collecting anti-virus logs based on PCI DSS log management guidelines. By the way, PCI DSS assessment guidelines for QSA state the following in regards to this requirement: “For a sample of system components, verify that antivirus software log generation is enabled and that such logs are retained in accordance with PCI DSS Requirement 10.7.”

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 assessment 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.

In order to address these section of Requirement 5, make sure that anti-malware software produces logs and such logs are managed and reviewed in accordance with Requirement 10.

Also, PCI DSS Requirement 6 “Develop and maintain secure systems and applications” is in the same league: secure systems and application are unthinkable without a strong application logging functions and application security monitoring. This is the area where a security team must work with internal or outsource development team in order to assure that the applications they develop can be used in PCI DSS compliance environments. Specifically, if your organization makes an unfortunate choice of using homegrown payment applications, logging the operations with PANs and other cardholder data becomes an absolute imperative. A useful discussion of how to create security application logs can be found here.

In order to address these section of Requirement 6, make sure that newly created and deployed applications – especially applications directly handling card data – have extensive and useful security logs that at least satisfy the DSS Requirement 10.2.

Further, Requirement 7, “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 such  data, remediation is needed.

In order to address these section of Requirement 7, one needs to make sure that access to such data, whether in databases or files, is logged and such logs are managed and reviewed as prescribed in Requirement 10.

In general,  assigning a unique ID to each user accessing the system fits with other basic security “best practices.” In PCI DSS, it is not just a “best practice”; it is a specific 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) and most systems log such activities in order to assure that they are indeed taking place. 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. Sadly, a few of the systems do not log password changes – in this case, other means of verifying such actions need to be used.

In order to address these section of Requirement 8, one needs to record key systems actions with user names. Using automated tools to detect when accounts are shares is a useful trick as well.

Requirement 9 “Restrict physical access to cardholder data” presents a new realm of security—physical access control.  At first glance, it might seem that the area of locks, video cameras and armed guards has nothing to do with syslog and computer audit traces. In reality, logs to make their appearance here as well: section 9.4 that covers maintaining a visitor log is connected to log management if such a visitor log is electronic (managing physical written logs falls outside of the scope of this article). Also, there are separate data retention requirements for such logs: “Use a visitor log to maintain a physical assessment trail of visitor activity. Retain this log for a minimum of three months, unless otherwise restricted by law.”

In order to address these section of Requirement 9, physical access should be  logged and the resulting logs managed in accordance with Requirement 9. It is curious that physical access logs don’t carry an explicit daily review requirement.

Requirement 11 “Regularly test security systems and processes” addresses the need to scan ( automatically test) the in-scope systems for vulnerabilities. However, it also calls for the use of intrusion detection or prevention systems (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 monitored and IDS alerts and logs are the way such monitoring is performed. Here is an example IDS log that should be reviewed with other logs, as prescribed in Requirement 10, discussed in our previous article:

Jan 23 16:38:16 bastion snort[1131]: [1:3813:2] WEB-CGI configdir command execution attempt [Classification: Attempted User Privilege Gain] [Priority: 1]: {TCP} ->

In order to address these section of Requirement 11, IDS and IPS logs needs to be reviewed for threats and incident response should be followed when called for.

Requirement 12 “Maintain a policy that addresses information security for employees and contractors” covers security issues on a higher level— that of security policy as well as security standards and daily operational procedures (e.g., previously discussed procedure for daily log review mandated by Requirement 10 should be reflected here). However, it also has logging implications, since application 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.

In order to address this section of Requirement 12, explicit logging policies and operational procedures needs to be created. A guidance from part 1 of this article can be used to jumpstart these efforts.

Thus, event logging and security monitoring in PCI DSS program go much beyond Requirement 10. Only through careful log data collection and review can help companies meet the broad requirements of PCI DSS.


To conclude, PCI security guidance mandates not only the creation of logs, retention and their review. Logs are features in PCI DSS at a higher level: as a means to substantiate other PCI DSS requirements. Thus your logging policy needs to focus higher and broader than a mere Requirement 10. Similarly, deploying a log management system allows you to not just “make Requirement 10 go away” but also create proof of following many of the other twelve requirement.  Following the principles and examples in this article, an organization can utilize logging to the fullest extent for PCI DSS compliance, security and operational efficiency.

Industry News

NIST guide: The imperative of real-time risk management
Revised guidelines for assessing security controls for government IT systems reflect a shifting emphasis toward continuously monitoring systems and making real-time risk assessments.

Did you know? Risk assessment begins with deep real-time visibility into log data produced by perimeter defense systems and IT assets inside the perimeter. Then, the application of powerful correlation and analytics point you to the things that matter for defense in depth.

Cyber security bill would penalize agencies for non-compliance
A House bill would give the government more authority to enforce cyber security measures in federal agencies… The bill directs civilian agencies to show they have complied with FISMA when submitting annual budgets. Under the bill, the cyberspace director can recommend the president withhold awards and bonuses for agencies that fail to prove they have secured networks.

Related resource Whitepaper: Meeting FISMA compliance with EventTracker

Virtualization security falls short among enterprises
Enterprise adoption of virtualization is still going strong, but security for those environments is not. A survey by Prism Microsystems shows many organizations are failing to enforce a separation of duties and deploy technologies to protect the hypervisor.

Related Resource: The complete results of the 2010 survey on virtualization security are now available. Download the PDF here