PCI Logging HOWTO
Payment Card Industry Data Security Standard (PCI DSS) was created by the major card brands – Visa, MasterCard, American Express, JCB and Discover – 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 organization 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 logging particular and reviewing logs from system in scope for PCI compliance. One should always remember that log collection and review are also critical for good security operations and incident response. In this article, we will focus on operational aspects of logging and log management for PCI compliance.
Recent surveys indicate that logging and monitoring are the most challenging aspects of PCI DSS compliance. The reason for it is that unlike other prescribed controls and tasks, which are annual or quarterly, log review activities are explicitly prescribed to be done every single day. Another reason is that DSS guidance prescribes “log review,” but does not explain what specific logs need to be looked at and how exactly such review should be undertaken.
If that’s not sufficient reason to do it right, logging is a perfect compliance technology which is implied in all twelve PCI DSS requirements (as well as in most other regulations), and specifically mandated in Requirement 10. Under this requirement, logs for all in-scope systems and all system components must be collected and reviewed at least daily (An in-scope system is one that is used to process or store credit card information, the one that passes unencrypted card data or the one directly connected to them without a firewall in between). Furthermore, PCI DSS states that the organization must ensure log integrity by implementing file integrity monitoring to ensure that existing log data cannot be changed without notice. Time synchronization across log sources is mandated in Requirement 10.4 (“Synchronize all critical system clocks and times.”) It also prescribes that logs to be stored for one year.
To summarize, for PCI DSS you:
- Must have good logs
- Must collect logs
- Must store logs for at least 1 year
- Must protect logs
- Must synchronize time
- Must review logs daily (using an automated system)
Despite fairly prescriptive DSS logging guidance, people continue to ask for even more details; down to “what configuration settings we should change on XYZ system?”, “what events to log?”, “what details to log for each event?”, “what logs to retain?”, “what logs to review?”, “how exactly to review the logs?”, etc. Such guidance must cover both PCI logging requirements that are needed to achieve compliance, stay compliant with these requirements and those that are needed to get compliance validated by an on-site assessment or self-assessment.
Here is a recommended process to follow to get your logging and log management in shape for PCI compliance while getting other business benefits for security and operations.
Logging Process for PCIs
First, do determine the scope for PCI compliance, including systems, databases that store the data, application that process the data, network equipment that transmits unencrypted card data as well as any system which is not separated from the above by the firewall. In the case of so-called “flat network”, the entire IT environment is in scope and thus must be made compliant by implementing DSS controls.
Second, identify system components that touch the data: apart from the operating systems (Windows or Linux, for example) databases and web servers need to considered as well as payment application, middleware, Point-of-Sale (PoS) devices, etc.
Next, a logging policy must be created. PCI-derived logging policy should at least cover logged event types for each application and system deployed as well as details for all systems in scope for PCI DSS. For custom applications, this logging policy needs to be communicated to internal or outsourced developers.
After logs are created, they need to be centralized. It will make sure that logs are retained in a controlled environment and not simply “left to rot” wherever they are produced across the cardholder data environment.
Next comes log retention: PCI DSS has an easy answer for your log retention policy: logs must be stored for one year with three month supply available in an easily accessible storage (not tape!)
Log protection and security are prescribed in PCI DSS. It mandates limiting access to logs and employing the technology to detect any possible changes of stored logs. It comes with no surprise that access to logs must be logged! Many automated tools will create an audit trail of log review activities which can be used to satisfy PCI requirement and prove to QSA that requirement are indeed being followed.
Finally – the hard part! Daily log review procedures and tasks needs to be created, communicated to those who would be performing then and then operationalized. This requirement is by far the most onerous to most organizations, especially smaller ones. However, it does not mean that every single log must be read by a human being. Automated tools can and must be used for automating log review, given that log volume might well go into gigabytes a day.
Let’s now focus on log review in depth. PCI DSS states that one must “Review logs for all system components at least daily. Log reviews must also include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers” as well as VPN servers that grant access to in-scope environment. It then adds that “Log harvesting, parsing, and alerting tools may be used to meet compliance.”
Further, PCI DSS testing and validation procedures for log review order that a QSA should “obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.” QSA must also ”through observation and interviews, verify that regular log reviews are performed for all system components.”
To satisfy those requirements, it is recommended that an organization create “PCI System Log Review Procedures” and related workflows that cover:
- Log review practices, patterns and tasks
- Exception investigation and analysis
- Validation of these procedures and management reporting.
The procedures can be provided for using automated log management tools as well as manually when tools are not available or not compatible with log formats produced by the payment applications.
In other words, periodic log review practices are performed every day (or less frequently, if daily review is impossible) and any discovered exceptions or are escalated to exception Investigation and analysis. The basic principle of PCI DSS periodic log review (further referred to as “daily log review” even if it might not be performed daily for all the applications) is to accomplish the following:
- Assure that card holder data has not been compromised by the attackers
- Detect possible risks to cardholder data, as early as possible
- Satisfy the explicit PCI DSS requirement for log review.
Even given that fact that PCI DSS is the motivation for daily log review, other goals are accomplished by performing daily log review:
- Assure that systems that process cardholder data are operating securely and efficiently
- Reconcile all possible anomalies observed in logs with other systems activities (such as application code changes or patch deployments)
In addition, it makes sense to also perform a quick assessment of the log entry volume for the past day (past 24 hr period). Significant differences in log volume should also be investigated using the procedures. In particular, loss of logging (often recognized from a dramatic decrease in log entry volume) needs to be investigated and escalated as a security – and compliance!- incident.
What to Look For?
The following are some rough guidelines for marking some messages as being of interest for PCI log review. If found, these messages will be looked at first during the daily review process.
- Login and other “access granted” log messages occurring at unusual hour
- Credential and access modifications log messages occurring outside of a change window
- Any log messages produced by the expired user accounts
- Reboot/restart messages outside of maintenance window (if defined)
- Backup/export of data outside of backup windows (if defined)
- Log data deletion
- Logging termination on system or application
- Any change to logging configuration on the system or application
- Any log message that has triggered any action in the past: system configuration, investigation, etc
- Other logs clearly associated with security policy violations.
As we can see, this list is also very useful for creating “what to monitor in near-real-time?” policy and not just for logging. Over time, this list should be expanded based on the knowledge of local application logs and past investigations.
Frequency of periodic log review
PCI DSS requirement 10.6 explicitly states that “Review logs for all system components at least daily.” It is assumed that daily log review procedures will be followed every day. Only your QSA may approve less frequent log reviews, based on the same principle that QSAs use for compensating controls. What are some of the reasons when less frequent log reviews may be approved? The list below contains some of the reasons why log review may be performed less frequently than every day:
- Application or system does not produce logs every day. If log records are not added every day, then daily log review is unlikely to be needed
- Log review is performed using a log management system that collects log in batch mode, and batches of logs arrive less frequently than once a day
- Application does not handle or store credit card data; it is only in scope since it is directly connected to such systems.
Remember that only your QSA’s opinion on this is binding and nobody else is!
PCI Logging Mistakes
Finally, let’s review some common mistakes that were observed by the author in his recent consulting projects related to logging and PCI DSS.
- Despite clear evidence – in the DSS itself! – PCI compliance DOES NOT equal simply collecting logs. If you collect logs, you are making a good step towards compliance, but you are nowhere near done. Daily log review is explicitly mentioned!
- On the other hand, the belief that you need to read every log every day – manually – is just as misguided. Automated tools that parse and summarize the logs are perfectly adequate for compliance, security and operational log review.
- Logging and especially log review are hard to do – thus some people maybe hope that maybe they will get “a free pass” and will not have to do it. Such hopes typically result in lack of compliance, conflict with PCI assessors and their acquiring bank and ultimately data breaches that persist for months without detection…
Following the guidelines in this article will help you avoid these and other mistakes and develop a security and compliant environment.
- To conclude, PCI security guidance mandates not only the creation of logs and retention, but also their review. It is essential that your logging policy and procedures cover such daily review tasks, whether using log management tools or manually. This will allow you to get compliant, validate your compliance as well as stay compliant and secure on an ongoing basis. The major effect the age of compliance has had on log management is to turn it into a requirement rather than just a recommendation, and this change is certainly to the advantage of any enterprise subject to one of those regulations. With a bit of guidance such as this article, logging can be made understandable and reasonable, and not onerous.
Related Resource: This document identifies PCI-DSS requirements covering network security, data protection, vulnerability management, access control, monitoring and testing, and information security – and presents the log management solution for each.
New Trojan masquerades as Adobe update
This malware bears identical icons and version details to an Adobe update, which enables it to bypass antivirus software and system analysts, and to trick users into believing that it is legitimate. The Trojan drops other malware and contacts a remote server for orders. It can be controlled by cybercriminals remotely to steal data unknowingly from the victim.
Did you know? Malware installed unknowingly by employees can lead to theft of sensitive corporate data, and anti-virus and firewalls are generally insufficient for detection since malware signatures are changing constantly.
Data theft affected 24,000 HSBC accounts
HSBC, Europe’s biggest bank, said a theft of data by a former bank employee affected up to 24,000 client accounts, dealing a hefty blow to the reputation of its private bank. The bank had previously said “less than 10 clients” were affected – this number has now been revised to 24,000.
Did you know? Theft by malicious insiders is only growing in number, as seen by the wave of recent media coverage. Protecting data from theft by insiders is often as simple as monitoring access to critical resources by users and admins.
Prism Microsystems receives Network Products Guide 2010 Product Innovation Award
Network Products Guide, a leading information technology research guide, has named Prism’s EventTracker solution a winner of the 2010 Product Innovation Award in the SIEM category. This annual award recognizes and honors companies from all over the world with innovative and ground-breaking products.