TABLE OF CONTENTS. INTRODUCTION: - Section 1: PCI DSS Version 3.0 Changes - Section 2: Can IDS and WAF Techniques Replace Systems with PCI DSS 3.0?

Transcription

1

2 TABLE OF CONTENTS INTRODUCTION: - Section 1: PCI DSS Version 3.0 Changes - Section 2: Can IDS and WAF Techniques Replace Systems with PCI DSS 3.0? PREPARATION: - PCI DSS 3.0 Reporting and Auditing REQUIREMENTS: - Section 1: PCI DSS Requirements 10.6 Overview - Section 2: Doubling Down on Log Management PCI DSS 3.0 Q&A: - Fines, Tokens, and P2PE

3 INTRODUCTION SECTION 1: PCI DSS VERSION 3.0 CHANGES PCI DSS 3.0 went into effect on January 1, 2014, with a date of January 1, 2015 for complete transition to the new standards. With the deadline fast approaching, planning and execution of the requirements should be a top priority. And while many of the changes in the PCI DSS 3.0 requirements are clarifications, there are several new requirements that could take you some time to address. An overarching theme of 3.0 is the evolution of security compliance to a day-to-day practice, instead of a once-a-year event that happens just before an audit. It is clear that many of the new and expanded testing and auditing requirements directly support this goal. Drilling down to the details, the chart below highlights some of the significant new requirements, guidance on why they were added, and why they might be a challenge to meet. Requirement Why Added What s Challenging 2.4 Maintain an inventory of system components that are in scope for PCI DSS For systems not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats. 9.9* Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. 11.3* Implement an industry-accepted methodology for penetration testing. Enable an organization to define the scope of their environment for implementing PCI DSS controls. Identify emerging security vulnerabilities in systems that are not commonly targeted or affected by malware, such as mainframes and mid-range computers. Keep criminals from stealing cardholder data by stealing and/or manipulating card-reading devices and terminals. Enables organizations to gain a better understanding of their potential exposure and develop a strategy to defend against attacks. While configuration management database (CMDB) adoption and implementations are increasing in the large enterprise space, most mid-market and smaller companies don t have the resources to acquire, implement and maintain a complex solution. They may need to implement a CMDB or something similar to maintain an asset inventory. An organization will need to ensure they have agreement with their QSA on what are not commonly affected systems. After that, keeping track of emerging vulnerabilities will be challenging and costly for organizations that do not have extensive security expertise in-house or via partners. Many organizations want to give consumers more access to POS devices (e.g., self-checkout at the grocery store) to improve the customer experience (e.g., faster checkout) which in turn increases the need for security solutions (people, processes, technology) to support these improved customer experiences. The industry-accepted methodology requirement makes this a challenging requirement for organizations that don t have expertise in-house or currently work with a penetration-testing partner that doesn t take an industry-standard approach. In addition, organizations will need to treat penetration testing as a lifecycle management event vs. a one-and-done process. As the organization evolves (e.g., offers new services), the testing methodology and processes need to be updated and maintained and the security solutions extended to cover them. 12.9* Service providers acknowledge in writing that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer. Promotes a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. While many large and established service providers are already providing this information, organizations working with service providers that don t provide it might have a challenge convincing them to deliver it in writing. In the chapters below, we ll discuss these and other PCI DSS 3.0 changes in more detail and offer suggestions for overcoming potential challenges. *These requirements are best practices until June 30, 2015, after which they become requirements.

4 For complete documentation on all the requirements, visit the PCI Security Standards Council website. For information on how Alert Logic helps organizations comply with PCI DSS regulations, visit the PCI DSS Compliance section of our website. SECTION 2: CAN IDS AND WAF TECHNIQUES REPLACE SYSTEMS WITH PCI DSS 3.0? When reviewing changes to the PCI DSS requirements in the 3.0 version of the standard, we noticed some interesting changes to the language in a couple of requirements related to Intrusion Detection Systems (IDS) and Web Application Firewalls (WAF). The language change talks about using techniques instead of or in addition to systems. Below is the language from 11.4 as an example: 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. This might have some IDS and/or WAF users wondering if they still need to have a system in place. The test procedures language makes it clear that they do: 11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusiondetection systems and/or intrusion-prevention systems) are in place to monitor all traffic: At the perimeter of the cardholder data environment. At critical points in the cardholder data environment. From a QSA perspective, the language in the test procedure is more important than what s described in the requirement itself. The test procedures are detailed and prescriptive, making it easy for the assessor to determine if a merchant/service provider is meeting PCI DSS requirements or not. And the chance of swaying the assessor s option is improbable; assessors are themselves audited by the PCI Security Standards Council so they tend to be understandably conservative in their approach. All that said, some of the language in the PCI DSS standards is becoming more open, which is positive. This has been a trend as PCI has evolved from the very first version of the Visa CISP standard. Back in those days, there were even references to specific vendors like Tripwire for file integrity monitoring. While that language was great for that vendor s business (and they do offer a solid product), it s good to see the PCI DSS updating language to be a bit broader. Also, the techniques language should get merchants thinking of additional ways they can detect and/ or prevent intrusions. At AWS re:invent 2013, for example, there were some interesting sessions on using techniques that monitor billing and send alerts if there was an anomaly that might indicate someone was using your AWS account for their own purposes. SIEM technologies, which combine data from multiple sources such as log and more traditional intrusion detection systems, can be very effective intrusion detection techniques if properly implemented, maintained, and monitored. So, there s definitely room to complement your IDS with other intrusion detection techniques.

5 PREPARATION PCI DSS 3.0 REPORTING AND AUDITING The previous chapter outlined how the new and updated PCI DSS 3.0 requirements are making payment security part of the business-as-usual workflow, instead of a quarterly event. While that was always the case with PCI, the new requirements make it even more explicit. And although this is a great development from a security perspective, it likely means that businesses need to spend more time reporting and preparing for audits. The table below presents a few examples of what to watch out for when preparing for PCI DSS 3.0 compliance. Examples Need to collect and report on data that is not currently reported 2.4: Maintain an inventory of system components that are in scope for PCI DSS. Testing Procedures: Examine system inventory to verify that a list of hardware and software components is maintained and includes a description of function/use for each. Interview personnel to verify the documented inventory is kept current. Protection of additional systems required 5.1.2: For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. Testing Procedures Interview personnel to verify that evolving malware threats are monitored and evaluated for systems not currently considered to be commonly affected by malicious software, in order to confirm whether such systems continue to not require anti-virus software. Consider maintaining documentation that shows where management regularly reviews and approves of your organization s exception(s) to the malware and anti-virus requirements of the standard. That way there won t be any question as to the validity of the exception(s). Documenting new areas required : Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. Testing Procedures Verify the entity maintains information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. Depending on current practices, these requirements may necessitate little or no change, or they may require significant changes to an organization s PCI auditing and reporting procedures. If new actions are required, it is recommended that organizations determine the best course of action to address each change before implementing. There may be good options freely available as well. For example, for Requirement 2.4, if help is needed creating an inventory and there are cost-constraints, this recent Dark Reading article: Free or Low Cost Network Discovery Tools can provide useful information. For Requirement , organizations working with a service provider should have a conversation about what documentation is available on the services they re providing. Or, if working directly with a security provider, they should request documentation for products and services and ask for the Service Definition document for any product or service.

6 REQUIREMENTS SECTION 1: PCI DSS REQUIREMENT 10.6 OVERVIEW While many of the changes in the PCI DSS 3.0 requirements are clarifications, there are several new requirements that could take some time to address. An interesting clarification to a requirement that affects everyone collecting log data is Requirement 10.6: Review logs and security events for all system components to identify anomalies or suspicious activity. The requirement hasn t really changed as much as it s been clarified to be much more explicit about what log data needs to be collected and the actions that need to be taken on those log files. For example, below is the listing for Requirement 10.6 from the PCI DSS 2.0 requirements document: Examples 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). Note: Log harvesting, parsing and alerting tools may be used to meet compliance with Requirement Testing Procedures 10.6.a 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 b Through observation and interviews, verify that regular log reviews are performed for all system components. Now, here s a view of one of the sub-requirements of 10.6 from the PCI DSS 3.0 requirements document: Examples Testing Procedures Guidance 10.6 Review the following at least daily: All security events Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD Logs of all critical system components Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) a Examine security policies and procedure to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools: All security events Logs of all system components that store, process or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD Logs of all critical system components Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/ intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) 10.6.b Through observation and interviews, verify that regular log reviews are performed for all system components. Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach. Daily review of security events - for example, notifications or alerts that identify suspicious or anomalous activities - as well as logs from critical systems components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM) systems, etc. is necessary to identify potential issues. Note that the determination of security event will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of normal traffic to help identify anomalous behavior.

7 With PCI DSS 3.0, organizations are being asked to collect and monitor more information than previously stated in the PCI DSS requirements. Here are a few thoughts on what that really means to companies collecting log data: First, this change is a great motivator to review current log data collection and management processes. Organizations might identify critical data sources that are missing, or they might discover that everything is already covered. It s also a great opportunity to make sure all log data sources are properly configured. In other words, it s not sufficient just to collect the data; organizations must also make sure they are sending that information to a logging tool in the appropriate way. For a few hints and tips, download our Configuring Log Sources for Best Practice Reporting white paper. Finally, if it is determined that an organization doesn t have the time or resources to manage logs, this is an opportunity to consider outsourcing it. There are affordable log review options available for organizations that need to perform daily log reviews, but don t have the time or resources to do so. SECTION 2: DOUBLING DOWN ON LOG MANAGEMENT As mentioned above, log management has of course been part of the PCI specification for some time. Unfortunately for many merchants though, it meant only that they had to keep logs and rotate them (eventually). In some instances, there was not even anyone monitoring them. For many, logs have been viewed of as more of a forensics tool to be used after the fact in breach investigations than as a proactive security lever. With version 3.0, PCI DSS has put a bit of a bite into log management. Overall, PCI version 3.0 seeks to move PCI compliance away from a once a year audit to a business as usual posture. Changes in 3.0 fall into three categories clarifications, additional guidance, and evolving requirements. Most of what is new in version 3.0 falls into the clarification category. While the 12 areas of the PCI remain the same, the PCI Council has modified or added sub-categories to most of the 12 requirements. PCI regulations regarding log management are for the most part in section 10 of the regulations. In PCI version 3.0, major changes in section 10 include: Modification of to require logging of changes, additions or deletions to root access or administrative access besides identification and authentication mechanisms. The reason for this is that changes to root or administrative access can provide visibility of bypassing or impersonating valid accounts. Revision to extends the requirement to track the initialization of logging mechanisms to include the pausing or stopping of the logging mechanism as well. Malicious users often turn off logging. Pausing or stopping of logging can indicate malicious activity. As noted earlier in this chapter, the review of logs per 10.6 has been part of PCI DSS for some time. However in version 3.0, the PCI Council significantly strengthened the requirement to provide more clarity on what events need to be reviewed daily and which ones can be reviewed periodically based on risk assessments requires that exceptions and anomalies identified during review be noted.

8 The one year log retention period as defined in 10.7 has not yet changed. In the guidance column, the council states their explanation for the requirement. When dealing with breaches that sometimes takes months to discover, the requirement to keep logs for one year seems reasonable. Other areas of the PCI that deal with logs and have some changes in PCI 3.0 include: Section 3.4 regarding protection of cardholder data requires that Primary Account Numbers (PAN) which can be contained in logs, to be rendered unreadable; This could be accomplished with encryption, masking, etc. Section 5.2 requires that anti-virus software generate logs. Section 6.6 deals with WAF logs, which of course is very important, especially to Alert Logic WAF customers. More Information Alert Logic has a whole section detailing Alert Logic and PCI compliance on our website. December 31st will be here soon. Don t get caught behind the compliance 8 ball. Make sure your log management is up to specification with PCI 3.0. And again if you have questions or comments on log management or anything else PCI DSS 3.0 related, please contact Alert Logic at info@alertlogic.com. Note: You can download detailed PCI DSS requirements documents from

9 PCI DSS 3.0 Q&A FINES, TOKENS, AND P2PE During a recent Alert Logic webinar on PCI DSS 3.0 requirements and how to prepare your organization, Jeff Tutton from Intersec Worldwide joined Alert Logic s Chris Noell to answer questions about vulnerability scanning, penetration testing, how the requirements affect different levels of merchants, and more. Below are links to the webinars featuring the Overview of PCI DSS 3.0 and the follow-up Q&A: PCI DSS 3.0 Overview: PCI DSS 3.0 Q&A: What are the specific fines and penalties for non-compliance and is this aspect of PCI DSS changing with the new requirements? The actual fines and/or penalties associated with non-compliance with the PCI DSS and/or confirmed security breaches are defined by each of the payment card brands. So fines can vary by card and/or level of merchant. The card brand websites don t provide specific details (e.g., no one offers a table of these are our fines. ) but other sites give guidelines. E.g., the table below from the Focus on PCI website gives some ranges Noncompliance Fines- The consequences of not being PCI compliant range from $5,000 to $500,000, which is levied by banks and credit card institutions. Banks may fine based on forensic research they must perform to remediate noncompliance. Credit card institutions may levy fines as a punishment of noncompliance and purpose a timeline of increasing fines. The following table is an example of a time-cost schedule which Visa uses. Month Level 1 Level 2 1 to 3 $10,000 monthly $5,000 monthly 4 to 6 $50,000 monthly $25,000 monthly 7 and on $100,000 monthly $50,000 monthly It ll be up to the banks and payment card brands to decide on fine and penalty amount increases. In addition to the amounts shown above, in the event of a breach, the breached party will be responsible for reimbursing issuing banks for the costs of reissuance and fraud watch programs as well as fraudulent charges. Finally, it s important to consider brand impact of non-compliance, particularly in the event of a breach. For large merchants, lost sales and brand impairment are typically the most significant damage. How does using tokenization of card data impact our requirements? Protecting cardholder data by tokenization (substituting the card data that would be stored with randomly created data that can be only reversed back to card data using a unique identifier) is one way for merchants to reduce their PCI footprint. The tokens are stored in a central vault, typically offsite, meaning there are fewer systems storing card data which reduces the audit footprint. The storage of tokens and payment card data must comply with the PCI requirements but using tokens can simplify meeting the requirements by reducing the number of systems that are within the scope of PCI.

10 Some merchants view tokenization as a get out of PCI free card. This is not the case. While tokenization solves some problems related to secure data storage and scoping, it does not typically address one of the most common forms of breach malware installed on the point of sale itself that scrapes card numbers out of memory. Remember PCI requires protection of data while it is transmitted, processed, and stored. Protecting data while it is processed is no small challenge. How does PCI DSS 3.0 affect merchants utilizing P2PE technologies? Point-to-point encryption (P2PE) is extremely useful for keeping card data secure by immediately encrypting it at the point of sale device and keeping it encrypted all the way to its final destination. If your organization is taking advantage of P2PE technology, your responsibilities don t change with the PCI DSS 3.0 requirements. You still need to use a validated P2PE solutions and segment P2PE network channels. The PCI Security Standards Council P2PE documentation is your best source for details on P2PE. If you d like more detail or have other PCI DSS questions, Jeff and the team at Intersec Worldwide are great PCI DSS resources or feel free to get in touch with us at Alert Logic.

11 ABOUT US Alert Logic, the leader in security and compliance solutions for the cloud, provides Security-as-a-Service for on-premises, cloud, and hybrid infrastructures, delivering deep security insight and continuous protection for customers at a lower cost than traditional security solutions. Fully managed by a team of experts, the Alert Logic Security-as-a-Service solution provides network, system and web application protection immediately, wherever your IT infrastructure resides. Alert Logic partners with the leading cloud platforms and hosting providers to protect over 2,700 organizations worldwide. Built for cloud scale, our patented platform stores petabytes of data, analyzes over 400 million events and identifies over 50,000 security incidents each month, which are managed by our 24x7 Security Operations Center. Alert Logic, founded in 2002, is headquartered in Houston, Texas, with offices in Seattle, Cardiff, and London. For more information, please visit Security. Compliance. Cloud Alert Logic, Inc. All rights reserved. Alert Logic and the Alert Logic logo are trademarks, registered trademarks, or service marks of Alert Logic, Inc. All other trademarks listed in this document are the property of their respective owners.