NewslettersRelated Resources
EventSource April 2010– Logging for PCI HOWTO; New Trojan masquerades as Adobe update Featured Article PCI Logging HOWTO Introduction 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:
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. Log Review 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:
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:
Even given that fact that PCI DSS is the motivation for daily log review, other goals are accomplished by performing daily log review:
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.
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:
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.
Following the guidelines in this article will help you avoid these and other mistakes and develop a security and compliant environment. Conclusion
About author Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior" and "PCI Compliance" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry. In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups. Currently, Anton is developing his security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.
Industry News Violation of sensitive data storage policy led to exposure of information on 3.3 million student loan recipients
New Trojan masquerades as Adobe update
Data theft affected 24,000 HSBC accounts
Prism Microsystems receives Network Products Guide 2010 Product Innovation Award
Featured Webinar How to manage and monitor current security challenges When: LogTalk View our continuing video series on the 100 uses of Log Management. Recent videos include: * Log Management use #61 Static IP address conflicts * Log Management use #62 Tracking user activity
************************************************* Legal
|
© 2010 Prism Microsystems, Inc. • Privacy • Terms of Use