Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Verizon 2014 pci compliance report


Published on

Etat de l’art actuel en matière d’adoption des normes PCI DSS

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Verizon 2014 pci compliance report

  1. 1. Research Report Verizon 2014 PCI Compliance Report An inside look at the business need for protecting payment card information. In 2013, 64.4% of organizations failed to restrict each account with access to cardholder data to just one user — limiting traceability and increasing risk. (Requirement 8)
  2. 2. An executive summary of this report is available from pcireport/2014. This report offers a global perspective on the state of compliance with the Payment Card Industry (PCI) Security standards, highlighting the trends and noteworthy developments across industries and regions. We also look at how compliance can be a positive force for change, improving business processes and delivering a direct return on investment (ROI). UNIQUE INSIGHT AND ADVICE This report offers insight into the challenges and pitfalls that you may face when striving to comply with the PCI standards, a view into the progress and evolution of those standards, and advice on how to increase the impact of your compliance initiatives. Whether you’re a Chief Information Security Officer (CISO), a Compliance Officer, or a CEO, and whether you work in retail, hospitality, healthcare, financial services, or any other industry that processes card payments, this report offers you the opportunity to compare your own PCI experiences against those of other companies from around the globe. BUILT ON A STRONG DATA FOUNDATION This report is based on a unique dataset, including detailed quantitative results from hundreds of compliance assessments carried out by our PCI Security practice across hundreds of sites — stores, offices, data centers and even an airport. We also draw on data from our other highly authoritative security report, the Data Breach Investigations Report (DBIR). To learn more about our approach to producing this report, see the Methodology section on page 4. WHAT IS PCI DSS? PCI Security standards are a set of international standards created and maintained by the PCI Security Standards Council (SSC), which represents the major card brands, to verify that merchants and service providers are appropriately protecting cardholder data. They cover all forms of payment card — debit, credit, store and company purchasing cards — carrying the logo of a PCI brand member. This represents the vast majority of payment cards issued globally. PCI brand members: American Express, Discover Financial Services, JCB International, MasterCard, Visa Europe, and Visa Inc. The PCI Security standards are not law (except in a couple of US states) and so non-compliance is not punishable by imprisonment; instead, it’s enforced through terms of business as part of the contract between the merchant, acquirer, and other parties. Companies that choose not to comply are likely to get less beneficial commercial terms (and may even be refused service), and those that suffer a breach and are found to have fallen out of compliance are likely to face significant penalty fees. The PCI Data Security Standard (DSS) 2.0, on which this report focuses, is a set of six objectives — broken down into 12 requirements and 289 controls and subcontrols. These controls cover everything from encrypting stored data to conducting vulnerability assessments and configuring access controls. They offer merchants a baseline for effective protection of customer payment data. Over time the PCI Security standards have been augmented by a large number of additional templates, guidance notes, assessment criteria and other standards published by the PCI SSC. These documents are designed to be used both by organizations in their own compliance efforts, and by internal and independent assessors who evaluate each organization’s compliance state annually. 2 VERIZON ENTERPRISE SOLUTIONS
  3. 3. CONTENTS METHODOLOGY....................................................................................................................................................................... 4 INTRODUCTION........................................................................................................................................................................ 5 PCI HAS ITS CRITICS, ARE THEY RIGHT?...................................................................................................................... 8 THE STATE OF PCI-DSS COMPLIANCE........................................................................................................................ 14 REQUIREMENT 1........................................................................................................................................................... 17 REQUIREMENT 2........................................................................................................................................................... 19 REQUIREMENT 3........................................................................................................................................................... 21 REQUIREMENT 4........................................................................................................................................................... 23 REQUIREMENT 5........................................................................................................................................................... 25 REQUIREMENT 6........................................................................................................................................................... 27 REQUIREMENT 7........................................................................................................................................................... 30 REQUIREMENT 8........................................................................................................................................................... 32 REQUIREMENT 9........................................................................................................................................................... 34 REQUIREMENT 10........................................................................................................................................................ 36 REQUIREMENT 11........................................................................................................................................................ 39 REQUIREMENT 12........................................................................................................................................................ 42 PAYMENT APPLICATION DATA SECURITY STANDARD (PA-DSS).................................................................... 45 FIVE WAYS TO IMPROVE YOUR PCI PROGRAM...................................................................................................... 47 CONCLUSION......................................................................................................................................................................... 50 APPENDICES.......................................................................................................................................................................... 51 A: DEFINITION OF KEY TERMS................................................................................................................................ 51 B: POINT-TO-POINT ENCRYPTION (P2PE)......................................................................................................... 53 C: SCOPING...................................................................................................................................................................... 54 ABOUT VERIZON’S PCI SECURITY PRACTICE ......................................................................................................... 56 VERIZON 2014 PCI COMPLIANCE REPORT 3
  4. 4. METHODOLOGY Validation level lity ita sp 19.8% Le Ho Industry l tai Re l2 ve 8.9% e provider rvic Se Services ial nc na i 84.2% 25.7% Othe r er Oth 9.9% 32.7% 21.8% Company type .4 L.3 L L ev el 35.6% 55.4% Merchan t F Since 2009 we’ve performed nearly 4,000 assessments for more than 500 organizations, mainly large multinationals with complex, multisite environments. This scale of experience is unparalleled, making the insight provided by our PCI Security and RISK teams in this report invaluable. This research is based on quantitative data gathered by our qualified security assessors (QSAs) while performing baseline assessments on PCI DSS 2.0 compliance between 2011 and 2013. The companies that we assessed span many industries and countries. 1 Figure 1: Breakdown of our dataset In this report we look at: • Compliance by organization — the number of companies that passed all the validation testing requirements (controls and subcontrols) that it was assessed on, divided by the total number of companies assessed. We look at this by requirement and for all requirements. Where a control or subcontrol was failed, this failure is taken to cascade upwards (so failing 3.5.2.b would lead to failing subcontrol 3.5.2, control 3.5, Requirement 3 and the whole assessment). • Average compliance — the number of companies passing a specific set of controls and subcontrols (e.g., all those under Requirement 3), divided by the sum of the assessments made on that set of validation testing requirements. All data was anonymized prior to processing to protect the privacy of the organizations involved. About the authors Lead author: Ciske van Oosten, Director of Operations, Verizon PCI Security practice Ciske has been involved with PCI compliance since the very inception of the program in 2002. He established and directed the world’s first QSA company, and has since served as practice leader at several QSA organizations. In these roles he’s overseen more than 2,500 projects for processors, acquirers, issuers, merchants, and service providers. Throughout this research report we’ll make reference to specific requirements described in the PCI DSS 2.0 and 3.0, and related standards such as the Payment Application Data Security Standard (PA-DSS) and Point-to-Point Encryption (P2PE). These documents can be obtained from the PCI Security Standards Council (SSC) document library: security_standards/ documents.php 4 He is also the author of several publications on data protection and compliance, and a wellknown speaker on PCI compliance and compliance performance management — he’s addressed more than 130 conferences and events in over 25 countries. In addition to over 20 years of business experience, Ciske holds a Master’s in Information Security from the University of Liverpool, an Honors Degree in Computer Auditing, a Diploma in Business Computing, and various industry qualifications such as ISO/IEC 27001 Lead Auditor, CISSP, CISM, and QSA. Co-authors Allen Mahaffy, Amiel DeGuzman, Gabriel Leperlier, Ian White, Jaime Villegas, Kim Haverblad, Pierre-Emmanuel Leriche, Pieter Grobler, Raul Dolado, Rein van Koten, and Ron Tosto. Data analysis, contributors and reviewers Aaron Reynolds, Andi Baritchi, Antonin Garcia, Bruce Forestal, David Dos Santos, Doug Smith, Eric Jolent, Franklin Tallah, Gaurav Benjamin, John Marosi, John Williams, Jyri Ryhanen, Mark Stachowicz, Matthew Arntsen, Michel Banguerski, Priyanka Bhattacharya, Rob McIndoe, Rodolphe Simonetti, Sebastien Mazas, Staci Downey, and Vincent Lucas. This report would not have been possible without contributions of data and insight from across Verizon’s QSA community and RISK team. VERIZON ENTERPRISE SOLUTIONS
  5. 5. Verizon 2014 PCI Compliance Report INTRODUCTION 2014 will be a pivotal year for merchants and service providers looking to comply with PCI standards. A DECADE ON, AND MORE IMPORTANT THAN EVER Payment card data is becoming more important as cards supplant cash, and as our DBIR data shows, it’s a prime target for attackers. As we are putting the finishing touches to this report, the FBI has issued a warning to retailers to be wary of “card-targeting malware” thought to already be responsible for the breaching of over 100 million people’s card data.1 The PCI DSS is designed to standardize and assess how organizations are protecting the card data they hold from this and other threats. The PCI Security standards apply to all organizations that handle cardholder data. The core standard, the PCI DSS, has been around for nearly a decade; and service providers, merchants, and financial companies of all sizes and from around the world have adopted it. PCI DSS is the most widespread and established standard of its kind: it’s broadly accepted, widely discussed, and it’s not going away. 2014 MILESTONES • The PCI Data Security Standard (DSS) turns ten years old • DSS 3.0 becomes effective and validation assessments start (January 1) • DSS 2.0 expires and compliance validation against version 3.0 becomes mandatory (December 31) So it’s widespread. But is it effective in achieving security? Our evidence suggests that it is. ORGANIZATIONS THAT ARE BREACHED TEND TO BE LESS COMPLIANT WITH PCI DSS THAN THE AVERAGE OF ORGANIZATIONS IN OUR RESEARCH. As we enter the tenth year of PCI DSS, there has been important progress. With version 3.0, PCI DSS is more mature than ever, and covers a broad base of technologies and processes such as encryption, access control, and vulnerability scanning to offer a sound baseline of security. The range of supporting standards, roadmaps, guidance, and methodologies is expanding. And our research suggests that organizations are complying at a higher rate than in previous years. After an uncertain start, many organizations now feel comfortable with and better understand what the DSS is about, and accept that complying with it is not only a necessary part of accepting card payments, but also a solid baseline of controls for protecting cardholder data. Most analysts agree that, while the PCI standards are imperfect, they have evolved to clarify expectations and address feedback from the industry, and today they provide an increasingly mature framework for organizations to work toward. So why is PCI compliance still worth talking, and indeed writing a major piece of research, about? Global Card Fraud Losses ($Billions) $12B $10B $8B $6B $4B $2B $0 ‘00 ‘01 ‘02 ‘03 ‘04 ‘05 ‘06 ‘07 ‘08 ‘09 ‘10 ‘11 ‘12 Data from The Nilson Report, August 2013 Figure 2: The cost of card fraud; data from The Nilson Report, August 2013 VERIZON 2014 PCI COMPLIANCE REPORT 5
  6. 6. COMPLIANCE REMAINS A MAJOR ISSUE Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information. Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013 But our research also shows that the vast majority of organizations are still not sufficiently mature in their ability to implement and maintain a quality, sustainable PCI Security compliance program, and they continue to struggle to provide the required compliance evidence at the time of the annual compliance validation assessment. There’s significant variation across the individual requirements, controls, and subcontrols; as well as across industries and regions. Despite a decade of discussion, clarification, and education, there are fundamental disagreements and misunderstandings around critical areas of security and compliance, including how to define the scope of compliance itself, and how compliance is assessed. Some even regard the DSS, even in its latest 3.0 guise, as taking fundamentally the wrong approach to security. According to our research, only around one in ten organizations were fully compliant with PCI DSS 2.0 at the time of their baseline assessment. Despite the increasing maturity of the standard and organizations’ understanding of it, attaining compliance remains far from easy — and so it should. Protecting cardholder data is important and the threats to it are very real. And the drivers for investing in security and compliance are more pressing than ever. The very payment card data breaches that PCI DSS was designed to help avoid are growing in frequency and scale, with compromised records often numbering in the millions. As consumers and businesses continue to ditch cash and do more of their shopping online, the risk and impact of breaches is set to grow further. The related disciplines of security and compliance are, consequently, still a top business priority. Percentage of companies that passed 100% 100.0% 95.6% 95.6% 77.8% % companies 75% 71.1% Over half (51.1%) of companies passed 7 requirements. 60.0% 11.1% of companies passed all 12 requirements 51.1% 50% 44.2% 42.2% 31.1% 24.4% 25% 11.1% 0% 1 2 3 4 5 6 7 8 Number of requirements 9 10 11 12 Figure 3: Percentage of companies that passed; dataset 2013 6 VERIZON ENTERPRISE SOLUTIONS
  7. 7. PREPARING FOR CHANGE In many ways, PCI DSS 3.0, which became effective on January 1, 2014 and is mandatory from January 1, 2015, heralds an important shift in approach, with more new requirements and clarifications than we saw even in DSS 2.0. Our data shows that there’s an initial dip in compliance whenever a major update to the standard is released — so organizations will have to put in additional effort to prepare for achieving compliance with DSS 3.0. As a result, we think that 2014 will be a pivotal year for the PCI standards, for the organizations that strive to comply with them, and the companies that help them. While these questions are important, they’re overshadowed by one that’s even more crucial to organizations around the world: how can we comply more effectively? That’s the question we’ll come back to time and again in this report. Overall, we recommend five key approaches: 1 DON’T UNDERESTIMATE THE EFFORT INVOLVED 2 MAKE COMPLIANCE SUSTAINABLE 3 THINK OF COMPLIANCE IN A WIDER CONTEXT 4 LEVERAGE COMPLIANCE AS AN OPPORTUNITY 5 FOCUS ON SCOPING PCI compliance needs time, money, and executive sponsorship. It needs to be part of everybody’s job — application developers, system administrators, executives, and even staff in shops and call centers — not just left to the IT security team. There are thousands of tasks that an organization must complete throughout the year to stay compliant. To be sustainable, compliance needs to be embedded in “business as usual” as an ongoing process. The best thing you can do as an organization to simplify your PCI compliance workload and achieve real security is to put your compliance program within your wider governance, risk, and compliance strategy. Done right, PCI Security compliance can drive process improvements, identify opportunities to consolidate infrastructure, and generate additional equity. Think of it as an opportunity, not a burden. There is lots of misunderstanding around how to keep systems out of scope, but there are clear best practices to follow. The first is to store less data on fewer systems. This not only makes achieving compliance easier, it can also save you money on storage and backup. We discuss these recommendations in more detail on page 47. VERIZON 2014 PCI COMPLIANCE REPORT 7
  8. 8. PCI Has its Critics ARE THEY RIGHT? Achieving consensus between hundreds of companies across many industries and countries on anything is a daunting feat to attempt. And protecting data is a complex topic with wide-reaching implications. So, it’s little surprise that PCI DSS has its critics. In this section we look at the criticisms that we have encountered most often, and assess how we think the PCI SSC is doing. “Efforts to comply distract companies from what’s really important: security” THE CRITIQUE OUR RESPONSE The standard encourages organizations to focus on compliance as a goal in itself, rather than as a means for improving the security of the cardholder data environment (CDE) against the risks that it faces. The PCI DSS doesn’t drive an organization to build a comprehensive security program, it merely encourages it to achieve compliance for those systems in scope of the regulation. In fact, given the cost of complying with all the requirements specified in the standards, organizations may be discouraged from making other investments in security that could benefit their overall security posture. Our DBIR research found that organizations that suffered a data breach were less likely to be PCIDSS-compliant at the time of their breach — even if compliant at the time of their last assessment — than the average of companies assessed. While no set of security standards or technologies can eliminate the risk of a data breach entirely, we believe that organizations with security controls in place as part of complying with PCI Security standards improve their chances, both of avoiding a breach in the first place, and of minimizing the resulting damage if they are breached. In itself, this is an important achievement and a clear answer to the many criticisms leveled at the PCI Security standards. And compared to having no such standard, it’s clear that the PCI SSC has succeeded in raising the visibility of data protection issues across the industry. That said, there are several important criticisms of the PCI DSS in particular that remain open to discussion even after the enhancements, clarifications, and expansions in version 3.0. “The PCI program doesn’t address the dynamic threat environment” THE CRITIQUE OUR RESPONSE PCI-DSS compliance is based on an annual compliance validation assessment, either an assessment by a QSA or internal security assessor (ISA), or a self-assessment questionnaire (SAQ). In between these evaluations of an organization’s CDE, there’s plenty of time for the business, its processes, people, and technology to change, moving the organization out of compliance and away from security best practices. The risks and threats faced by the organization are also constantly changing. While PCI DSS does require routine monitoring of the CDE, and reassessment (or at least rescanning) of the CDE after “major changes,” the criteria for this trigger are ambiguous, and are fundamentally based on internal changes only. If the PCI SSC tried to mandate controls on systems outside the CDE it would face a barrage of criticism. The PCI DSS 3.0 makes a clear effort to position itself as a guide or vehicle rather than as a destination. The PCI Security standards set a solid baseline for data security; organizations are free to implement this throughout their entire business – and many would benefit from doing so. 8 Every change, from new server deployments to new malware outbreaks, multiplies the likelihood of a breach. Thinking about security solely in terms of achieving compliance with any standard is simply not enough — organizations must take responsibility for protecting both their reputation and their customers. Future releases of the DSS would probably benefit from having stronger integration of enterprise and operational risk management practices. That would help provide greater understanding of exposure to data breaches, increase confidence in control effectiveness, and facilitate levels of assurance. PCI compliance shouldn’t be seen as a burdensome annual ritual that the organization must endure. VERIZON ENTERPRISE SOLUTIONS
  9. 9. “The PCI program doesn’t keep up with change” THE CRITIQUE OUR RESPONSE Updates to the PCI DSS, PA-DSS and other standards occur on a threeyear cycle. This is not often enough to address the changing information security threat landscape, changing IT practices and changing consumers. Critics argue that it hasn’t kept up with: • Advances in payment technology — such as mobile payments and increasingly sophisticated store cards • The adoption of cloud and virtualization technologies by companies looking to increase agility and cut costs • The increasing sophistication of hackers and the brute power they have at their disposal We don’t believe that updating the standards more frequently is the answer. In fact, the release cycle shifted from the previous two-year cycle in response to feedback that organizations needed more time to learn about and comply with new versions of the standard, and to provide input and feedback to the PCI SSC. To enhance the maturity of the corporate information security management system, and the effectiveness of the control environment, organizations are encouraged to implement additional security controls beyond those prescribed in the PCI Security standards. Our DBIR research shows that while perpetrators are upping the ante — trying new techniques and leveraging far greater resources — less than 1% of the breaches use tactics rated as ‘high’ on the VERIS difficulty scale for initial compromise. In fact, 78% of the techniques we saw were in the ‘low’ or ‘very low’ categories. Difficulty of tactics used in initial compromise 0.2% High 22.7% Medium 67.3% Low 9.8% Very low 0% 25% 50% 75% 100% Figure 4: Sophistication of attack methods used; dataset DBIR 2013 The PCI SSC initiated several Special Interest Groups (SIGs) to provide guidance on technologies like cloud computing, virtualization, and tokenization, and other broadly applicable topics like risk assessment, maintaining PCI compliance, and third-party security assurance. It has also added multiple “best practices” to the DSS, which forward-thinking organizations can adopt before they officially come into force. WHICH IS WORSE: OUT-OF-DATE, OR HALF-BAKED? The PCI SSC has responded to demand for guidance on compliance in cloud environments by publishing a set of guidelines. But while in some respects well received, some analysts have called the recommendations unrealistic. For example, the guidelines demand that merchants provide logs from the cloud environment to their QSA. Critics have questioned whether cloud providers are in a position to share these logs, because they could reveal information about other users of the cloud environment. But all serious cloud providers have made great strides in addressing security concerns, and few would struggle to provide the assurances and information required by the guidelines. VERIZON 2014 PCI COMPLIANCE REPORT 9
  10. 10. “There’s little attention paid to residual risk” THE CRITIQUE OUR RESPONSE The PCI DSS fails to integrate a proper risk-based approach throughout the lifecycle of its security controls. All systems have a level of inherent risk; controls are implemented to reduce this risk, but they rarely eliminate it entirely. It’s vital that the residual risk, the level of risk remaining after the controls have been implemented, is assessed. This is the only effective way to measure the effectiveness of the controls and understand what risks remain and must be managed. Until this is included within the standard, it’s too easy for companies to either be unaware (in which case they will have a false sense of security) or unwilling to address these risks. The standard has included an annual risk assessment requirement (as part of Requirement 12) since its inception; QSAs must verify that this assessment has been performed and a written risk assessment report created. With subsequent updates to the standard, more risk assessment requirements were added, along with important clarifications and approaches that organizations can take to satisfy their obligations. Several DSS 3.0 controls require input from the organization’s risk assessment report and risk management strategy, as do decisions on the scope and implementation of a range of technical security controls. However, despite these improvements, it’s fair to say that the standard still doesn’t sufficiently focus on risk measurement and management to achieve maximum effectiveness: • While the standard suggests some industry-standard frameworks and methodologies to follow (OCTAVE, ISO 27005, and NIST SP 800-30), it does not stipulate that one must be used — without an improved definition of what a risk assessment should contain and how it should be carried out, what defines “passing” will remain highly subjective. • It sets no requirements for the qualifications of those conducting risk assessments, or for which individuals should have the authority to accept and approve risks. • The need for measuring and reporting on inherent risk, control risk and residual risk is not adequately described in the risk management guidance document and the standard. Calls for a risk-based approach should not be perceived as an attempt to allow organizations to avoid implementing controls they deem irrelevant to their specific risk profile. Stronger integration of risk measurement and management, and making it an integrated part of the evaluation of control effectiveness should not result in organizations skipping required controls or bypassing the compensating controls process, but in fact make PCI DSS more relevant and effective. It’s not enough to just implement controls and think that this makes you safe. Without a well-designed and maintained risk measurement program, there’s no way to reliably prove the effectiveness of your controls and the actual level of risk that remains in your business. There is a real danger in doing the minimum possible to comply. Looking back and knowing that you ‘ticked the boxes’ provides little comfort in the aftermath of a breach. 10 VERIZON ENTERPRISE SOLUTIONS
  11. 11. “The standards don’t include any performance management elements” THE CRITIQUE OUR RESPONSE PCI standards set goals and objectives for data protection controls — they give organizations a broad statement of intent and describe the specific required output that compliant organizations should achieve through their compliance program — but they fail to include guidance on performance measurement. The standards don’t specify any qualitative or quantitative performance metrics an organization can use to track its activities, performance and progress toward meeting its goals. Metrics are vital for managers to prove the effectiveness of their compliance initiatives, appropriately allocate resources to course-correct, and produce the data needed to demonstrate efficiency and ROI to stakeholders across the business. As well as the costs of remediation and lost business, any organization that suffers a data breach will face a more in-depth assessment when it’s time to re-validate. Most organizations are aware of this, but some still do the bare minimum needed to achieve validation. We feel that this is a shortsighted approach, and all organizations should take the security of their customers’ information more seriously than this — fortunately, most do. While the use of metrics is not a requirement for compliance, the PCI SSC encourages organizations to implement a program to measure their security and compliance capabilities and performance. The current lack of published performance management guidance from the PCI SSC means that organizations lack clear guidance on how metrics should be used to improve their data protection capabilities. A true lifecycle approach would involve ongoing measurement of the organization’s performance on: • Discovery of what data and assets the organization has, and when and how they move • Understanding of the risks the organization’s data and assets face • Selection, implementation, and maintenance of controls to form a sustainable control environment This would help organizations to identify, track and report on their progress, and go a long way in helping them to be more proactive and effective at compliance maintenance. The PCI DSS sets goals and objectives, but doesn’t specify qualitative or quantitative metrics that organizations can use to measure their performance. Without clear measurement, it’s harder for organizations to monitor progress and achieve continuous improvement. VERIZON 2014 PCI COMPLIANCE REPORT 11
  12. 12. “PCI-DSS assessments lack sufficient validation” THE CRITIQUE OUR RESPONSE Only the largest merchants, processing millions of transactions each year, are required to produce a final annual report on compliance (FRoC). Smaller merchants need only complete an annual self-assessment questionnaire and satisfy the regular vulnerability scans as part of DSS Requirement 11. While most merchants strive to comply in good faith (and protect their customers’ data), the lack of validation is a real problem. Internal assessors are likely to have less experience with PCI Security compliance validation than a QSA, and may come under pressure from the rest of the business to keep the burden and cost of compliance down by fudging assessments. While it’s potentially unfair and undesirable to burden smaller organizations with a full-blown assessment by a QSA, continued education is essential to ensure they understand their responsibility to protect cardholder data. The same PCI Security requirements apply to all merchants, large and small, and it is only the compliance validation requirements that are reduced for small merchants. While most merchants are striving to comply in good faith, the lack of validation can be a problem. Some merchants are not aware of this difference between the scope of compliance, and the scope of validation, particularly when newly exposed to the PCI Security regulation. This sometimes results in them focusing on controls that are tested during the validation assessment and giving less attention to the implementation of sustainable controls for the entire set of applicable requirements. QSAs can’t provide a 100% complete validation, because: • They’re assessing a selected sample, not the entire environment; they gather evidence that provides a reasonable basis for forming an opinion • The choice of samples, and the nature, timing and extent of evaluations, is a matter of judgment • The evidence gathered — which may include a huge volume of log files, reports, policy documents, standards, code, and assessments — must be interpreted against the individual QSA’s understanding of the standard, and the context of the merchant’s control environment Given all of these variables, what is realistically achievable is “reasonable assurance” that CHD is adequately protected. In any case, it should be clear that no standard provides absolute coverage or protection, and that no type of validation will be infallible. PCI compliance validation is intended to provide reasonable, independent, unbiased assurance that an organization is meeting the baseline standard established by the industry for the protection of payment card data. 12 VERIZON ENTERPRISE SOLUTIONS
  13. 13. So, will DSS 3.0 fix everything? The PCI SSC has stated that the changes in DSS 3.0 are designed to, “help organizations take a proactive approach to protect cardholder data that focuses on security, not compliance, and makes PCI DSS a business-as-usual practice.” The key themes are improving education and awareness, and increasing flexibility, and viewing security as a shared responsibility. But when the PCI SSC launched PCI DSS 3.0 in November 2013, some in the industry were disappointed that it didn’t go further to address the criticisms we’ve discussed — and others. One of the most important changes in DSS 3.0 is how it specifies that organizations must map out their CDE, following the flow of cardholder data (CHD). But while this is an important part of defining scope and identifying risk and vulnerability, the DSS does not mention any automated means of performing this data discovery — including data loss prevention (DLP) solutions. Perhaps most importantly — aside from improved physical security requirements, enhanced penetration testing, and vulnerability management — DSS 3.0 fails to embed its list of security controls within a full program of ongoing security governance, business continuity, and management. Organizations will benefit from making compliance activities part of business as usual, but are likely to require guidance about the assessment, management, change control, and incident response activities that help them run their security and compliance programs. Closer alignment with, or references to, information security governance and management quality standards — and in particular, the inclusion of a maturity model — would help to address this. It’s important to remember that while validation of compliance for attestation purposes (passing the annual assessment) is a “point in time” activity, PCI Security regulation requires full compliance to be actively maintained on a day-to-day basis. However, we feel that as organizations begin to prepare for validation, they will start to realize how significant a step forward DSS 3.0 is. For most organizations, achieving validation will involve significant new challenges. We look at the changes and their implications in detail in the coming pages. VERIZON 2014 PCI COMPLIANCE REPORT 13
  14. 14. The State of PCI-DSS Compliance IMPORTANT PROGRESS; ROOM FOR IMPROVEMENT In 2013 we saw a significant increase in compliance, but still only 11.1% of organizations complied fully. 85.2% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 85.2% OF CONTROLS. DSS 2.0 (All requirements): Compliance snapshot Compliance by organization 2013 Spread of compliance Average compliance Fully compliant, 100% 0-20% 11.1% Mostly compliant, 81-99% 85.2% 71.1% Compliance by organization Compliance OF COMPANIES MET ALL THE DEMANDS OF DSS 2.0 IN 2013, AN INCREASE OF 3.6 PERCENTAGE POINTS ON 2012. In 2013, 11.1% of organizations were fully compliant with the standard at the time of their annual baseline assessment, up from just 7.5% in 2012. 61-80% 2012 Spread of compliance 0-20% 7.5% 24.6% 41-60% Average compliance Fully compliant, 100% Mostly compliant, 81-99% 21-40% 81-100% 52.9% Compliance 11.1% MUCH HAS BEEN ACHIEVED… 21-40% 41-60% 61-80% 81-100% Figure 5: Snapshot for all requirements; dataset 2012 and 2013 This is still a very low figure, so we also looked at the percentage of organizations compliant with at least 80% of the controls and subcontrols. This showed a far greater increase: from just 32.1% (24.6% + 7.5%) in 2012, to 82.2% (71.1% + 11.1%) in 2013. It’s worth noting that four in five organizations were “nearly there” (see figure 5). Around one in five organizations came close to complying — they passed 95%+ of controls. Of these organizations, more than half failed Requirement 11 [Regularly test security systems and processes]. What caused this increase? We’ve identified three likely contributing factors: • Increased awareness about PCI: Efforts by the PCI SSC, the card brands, and security vendors have paid off. PCI compliance has become a regular topic of discussion in organizations, on the Internet, and in business and technology media. IT and business leaders understand the data protection and compliance landscapes better than ever. • Increased appreciation for the value of PCI compliance: The attention given in the mass media to data breaches has brought data protection to the forefront. The consequences of data breaches, and the value of implementing effective security controls, are better understood and appreciated across the business. • Increased maturity in the security standards: Each of the five updates to the DSS has addressed ambiguity and improved clarity around the interpretation and intent of the security controls. The security industry responded to improve existing security technology and develop new solutions where needed to address the changing risk and compliance landscape. 14 VERIZON ENTERPRISE SOLUTIONS
  15. 15. …BUT IT’S NOT ALL GOOD NEWS Compliance tails off quickly Average compliance 100% 75% 50% Average compliance across all requirements between 2011 and 2013 = 71.5% 25% 0% Controls in order of % compliance Figure 6: Controls in descending order of compliance; dataset 2011-2013 While the picture is very encouraging at a macro level, looking more closely at the data reveals significant variations: • Requirement to requirement: From 2011 to 2013, 58.4% of organizations complied with all the controls of Requirement 7 [Restrict access to cardholder data by business need to know], but just 23.8% with those of Requirement 11 [Regularly test security systems and processes]. Looking solely at 2013, 91.1% of organizations in our study complied with at least 80% of the controls of Requirement 5 [Use and regularly update anti-virus software or programs]; just 68.9% with those of Requirement 11. The number of organizations compliant with at least 80% of the controls in Requirement 11 increased by 50 percentage points (18.9% to 69.9%) between 2012 and 2013; the same figure for Requirement 4 was just 21 percentage points (54.7% to 75.6%). • Industry to industry: Twice as many retailers were compliant with at least 80% of all 289 controls as hospitality organizations, 69.7% versus 35.0%. • Region to region: In Europe, just 31.3% of organizations were compliant with at least 80% of controls, lagging the North America (56.2%) and Asia-Pacific regions (75.0%). 31.3% OF EUROPEAN ORGANIZATIONS COMPLIED WITH 80%+ OF DSS 2.0 CONTROLS, LAGGING THE NORTH AMERICA (56.2%) AND ASIA-PACIFIC (75.0%) REGIONS. Summary of compliance by requirement (l) = lowest (h) = highest Req Fully compliant 2012 2013 Mostly compliant 2012 2013 Average compliance 2012 2013 1 26.4% 64.4%▲ 17.0% 8.9% ▼ 55.0% 86.4% ▲ 2 22.6% 51.1% ▲ 18.9% 20.0% ▲ 53.9% 81.4% ▲ 3 17.0% 68.9% ▲ 13.2% 6.7% ▼ 45.5% 79.3% ▲ 4 34.0% 68.9% ▲ (h) 20.8% 6.7% ▼ 61.2% 87.8% ▲ 5 30.2% 80.0% ▲ 17.0% 11.1% ▼ 64.3% 95.9% ▲ 6 22.6% 68.9% ▲ 13.2% 13.3% ▲ 51.4% 87.4% ▲ 7 (h) 41.5% 73.3% ▲ 11.3% 4.4% ▼ (h) 66.6% 86.8% ▲ 8 22.6% 62.2% ▲ (h) 20.8% 15.6% ▼ 58.0% 84.1% ▲ 9 35.8% (h) 86.7% ▲ 15.1% (l) 4.4% ▼ 10 20.8% 60.0% ▲ 17.0% 17.8% ▲ 46.9% 82.2% ▲ 11 (l) 11.3% (l) 40.0% ▲ (l) 7.5% (h) 28.9% ▲ (l) 38.9% (l) 74.6% ▲ 12 30.2% 73.3% ▲ 13.2% 11.1% ▼ 54.8% 89.7% ▲ 7.5% 11.1% ▲ 24.6% 71.1% ▲ 52.9% 85.2% ▲ Overall 61.9% (h) 94.9% ▲ Too many numbers? Why not download our visualization of the entire dataset? Visit pcireport/2014 Figure 7: Summary by requirement; dataset 2012 and 2013 VERIZON 2014 PCI COMPLIANCE REPORT 15
  16. 16. The following pages give a detailed analysis of what we’ve learned about compliance with each of the 12 requirements of PCI DSS 2.0. Along with evaluating how well organizations are complying with each requirement and why, we explore why each requirement is important as part of a comprehensive security and compliance program. We also look at the major changes between DSS 2.0 and DSS 3.0. Average compliance by requirement 100% Despite the number of validation testing requirements per requirement varying from 6 (Requirement 5) to 40 (Requirement 12), we found no correlation between this and the level of compliance across our whole 2011-2013 dataset. 75% 50% 25% 0% 1 2 3 4 5 6 7 8 9 10 11 Figure 8: Average compliance by requirement; dataset 2012 (gray) and 2013 (red) 12 Throughout the coming sections we’ll refer to our “Top 20” and “Bottom 20” lists. Shown below, these consist of the 20 most- and least-often complied-with controls and subcontrols in our entire 20112013 dataset. Top 20 Rank Control Bottom 20 % complying Rank Control % complying 1 2.4 98.0% 270 8.5.1 57.4% 2 8.5.10.b 91.1% 271 11.5.a 56.4% 3 8.5.12.b 91.1% 272 10.4.1.a 55.4% 4 8.5.13.b 91.1% 273 10.4.2.a 55.4% 5 8.5.9.b 91.1% 274 11.3.c 55.4% 6 9.1.3 91.1% 275 12.9.4 55.4% 7 2.2.3.a 90.1% 276 2.2.2.a 55.4% 8 8.4.b 90.1% 277 11.2.1.c 53.5% 9 8.5.11.b 90.1% 278 12.1.2.b 53.5% 10 8.5.7 90.1% 279 1.1.6.b 52.5% 11 9.1.2 88.1% 280 2.2.2.b 51.5% 12 9.3.3 88.1% 281 11.3.2 50.5% 13 3.4.1.b 87.1% 282 11.3.1 49.5% 14 3.4.1.c 87.1% 283 6.1.a 49.5% 15 9.3.1 87.1% 284 11.2.1.a 45.5% 16 2.1.1.e 86.1% 285 11.2.1.b 45.5% 17 3.2.a 86.1% 286 11.2.3.a 45.5% 18 3.4.1.a 86.1% 287 11.2.3.b 45.5% 19 5.1.1 86.1% 288 11.3.b 43.6% 20 9.3.2.b 86.1% 289 11.3.a 39.6% Figure 9: “Top 20” and “Bottom 20” lists; dataset 2011-2013 16 VERIZON ENTERPRISE SOLUTIONS
  17. 17. REQUIREMENT 1 Install and maintain a firewall configuration to protect cardholder data WHY IS IT IMPORTANT? Requirement 1 helps ensure that firewalls and any other system components providing similar functionality are configured in line with documented standards. Organizations need to protect the perimeter of their networks if they’re to prevent unauthorized parties from illicitly obtaining information including CHD. A properly configured firewall is an essential part of the first line of defense. Firewall rules examine traffic and block transmissions that don’t meet specified security criteria, helping to prevent network intrusions. When ongoing management and maintenance of firewall and router configurations is neglected, it can significantly increase the organization’s exposure and reduce the security of the CDE. However, it’s important to note that organizations shouldn’t rely solely on firewalls, or any perimeter security technology, to protect their data. And they should recognize that if firewall configurations prove difficult to penetrate, attackers are likely to move on and target other vulnerabilities in the environment — for instance, applications. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? Data from Verizon’s RISK team showed that only 12.5% of organizations that suffered a data breach in 2013 were compliant with Requirement 1 at the time of their breach. By comparison, our QSAs found an average of 46.7% compliance with Requirement 1 in the same year. This shows a strong correlation between a badly configured firewall and the likelihood of a security breach. THE STATE OF COMPLIANCE Requirement 1: Compliance snapshot Compliance by organization 2013 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 86.4% (7th) 8.9% (8th) Compliance 64.4% (8th) 0-20% 21-40% 41-60% 61-80% 81-100% Compliance by organization 2012 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 17.0% (4th) 55.0% (5th) Compliance 26.4% (5th) 0-20% 21-40% 64.4% OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 1 IN 2013, AN INCREASE OF 38.0 PERCENTAGE POINTS ON 2012. 86.4% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 86.4% OF CONTROLS. 41-60% 61-80% 81-100% Figure 10: Snapshot for Requirement 1; dataset 2012 and 2013 For the individual subcontrols of Requirement 1, most organizations ranked high in addressing the simplest ones, like 1.1.3.a, 1.2.1.b, and 1.3.6. These subcontrols cover basic security practices that organizations usually have in place already — like including a firewall at each Internet connection, denying inbound and outbound traffic that is not necessary for the CDE, and ensuring the firewall performs deep-packet inspection. However, compliance for subcontrols 1.1.5 and 1.1.6.b was considerably lower. These cover the documentation and reviewing of firewalls and routers, rather than the technical aspect of configuration. Detailing a review of thousands of firewall rules is a resource-intensive task — and is therefore relatively difficult to do. In fact, compliance with 1.1.6.b was so low that it appears in our “Bottom 20” list with just 52.5% of companies complying. VERIZON 2014 PCI COMPLIANCE REPORT This requirement covers the correct usage of a firewall to filter traffic as it passes between internal and external networks, as well as traffic to and from more sensitive areas within the company’s internal networks. Attackers have moved from targeting servers to targeting the applications they run. Criminals are now launching attacks that exploit weaknesses in HTTP and XML implementations to circumvent increasingly robust perimeter defenses. In response, the security industry has developed next-generation or application-aware firewalls. The use of these improved devices is growing, but due to lack of understanding and poor implementation, few are exploiting the full potential of this new technology. 17
  18. 18. CHALLENGES AND PITFALLS The DSS still specifies stateful-inspection firewalls, first launched in 1994. As the threats to the CDE become more complex, these devices are less able to identify all unauthorized traffic and often get overloaded with thousands of out-of-date rules. To address this, vendors are now offering “next generation” firewalls that can validate the traffic at layers 2 to 7, potentially allowing far greater levels of granularity in the rules. Many of these devices integrate a number of network controls — for example firewall, intrusion prevention system (IPS), and malware detection — into a single platform, allowing any potential threats detected by one component to trigger changes in the behavior of the other components, and a more thorough analysis. A problem regularly encountered during PCI-DSS assessments is firewalls and routers being configured more “generally,” allowing a wide range of ports to ensure that applications function. Members of staff often do this because they lack a clear understanding of the CHD flow or the applications and services enabled on in-scope systems, and are therefore reluctant to risk blocking a legitimate business process. Organizations need a reliable inventory of in-scope systems to accurately configure the firewall to the cardholder environment. In order to do so, they need to bring business process design, application development, and infrastructure teams together to clearly document and understand the flow of information. Even organizations that do invest in mapping their systems and data flow often treat it as a one-off activity. Rule sets are defined at project stage and seldom updated once the project is moved to operations. Very few of these organizations have implemented the necessary review of firewall rules and after a couple of years it’s nearly impossible to find the business justification for them. An analysis of the initial architecture design and all the following changes is then required to justify the existing rules. Instead, organizations should review rulesets and configurations regularly, and document modifications with a change-management procedure. HOW IS THIS REQUIREMENT EVOLVING? Many of the changes to Requirement 1 in DSS 3.0 are intended to clarify the language so organizations can better understand what is needed for compliance. For example, in DSS 3.0, control 1.1 adds emphasis on implementing as well as documenting firewall and router standards. Several subcontrols have also been added to assist organizations in understanding the flow of data into and out of their environments. For example, 1.1.2 states that organizations must now produce a network map showing all the different hardware and software within the cardholder data environment. And subcontrol 1.1.3 states that organizations must produce a cardholder data flow map, which outlines where data originates in the network, how it is processed, and where it is sent out of the environment. These changes force organizations to better identify where cardholder data is stored, processed or transmitted. Using the information gathered from network assessments and from the maps themselves, organizations can create more precise firewall rules — better securing the perimeter. DSS 3.0 control 1.4 clarifies the firewall control requirements for mobile devices — including those owned by employees — that can connect to both the Internet and the cardholder environment. When connecting via the corporate environment, access to open public networks can be controlled — multiple layers of security can be applied that can block unauthorized traffic and identify malware and prevent it from reaching the device. However if a mobile device has unrestricted access to the Internet or other public network, then there is a significant risk it could become infected. The malware would have bypassed the corporate network controls, and the whole CDE could be at risk when that device is reconnected. 18 VERIZON ENTERPRISE SOLUTIONS
  19. 19. REQUIREMENT 2 Do not use vendors’ default passwords or security parameters WHY IS IT IMPORTANT? Vendor default settings, particularly passwords, are well-known by attackers; changing them at the time of installation is a simple and easy-to-implement process to harden production systems. Requirement 2 also aims to standardize configurations and configuration-management procedures. By completely defining and documenting the expected hardened configuration of each system, and adopting tools to automate that configuration, organizations can validate that settings have been consistently applied and avoid exceptions caused by manual configuration. This can help to reduce the workload involved in administering IT infrastructure, and can also reduce the cost of compliance assessments — the QSA can verify this automation and potentially reduce the size of the validation sampling. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? Our 2013 DBIR research found that attackers typically take the path of least resistance. Vendordefault passwords and user accounts provide the simplest possible way into a system — whether a laptop, server, or network appliance — enabling attackers to gather data directly, deploy malware, or attack other systems. When our RISK team investigated data breaches during 2011–2013, they found that only 38.8% of organizations suffering a breach had Requirement 2 in place. THE STATE OF COMPLIANCE Requirement 2: Compliance snapshot Compliance by organization 2013 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 81.4% (10th) 20.0% (2nd) Compliance by organization Compliance 51.1% (11th) 0-20% Spread of compliance Average compliance 18.9% (3rd) 0-20% 53.9% (8th) Compliance Mostly compliant, 81-99% 61-80% 2012 51.1% OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 2 IN 2013, AN INCREASE OF 28.5 PERCENTAGE POINTS ON 2012. 81.4% 41-60% 81-100% Fully compliant, 100% 22.6% (6th) 21-40% This requirement covers the controls that reduce the available attack surface on production systems by removing unneeded services, functionality, and user accounts, and by changing insecure vendor default settings. 21-40% 41-60% 61-80% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 81.4% OF CONTROLS. 81-100% Figure 11: Snapshot for Requirement 2; dataset 2012 and 2013 Of the individual subcontrols, 90.1% of assessed organizations managed to comply with 2.2.3.a, which involves verifying that system administrators and security managers have knowledge of common security parameter settings for system components. This was the seventh-most compliedwith control in the entire PCI DSS. This is an easy requirement to validate during the onsite visit, and most qualified IT staff should be able to answer the validation interview questions about the controls in place for the system in question. At the other end of the spectrum, organizations struggled with subcontrol 2.2.2, with just 50.5% of companies complying with both of its subcontrols — each of which is in our “Bottom 20” list. Only 55.4% of companies were in compliance with 2.2.2.a. This subcontrol requires that organizations document all services and protocols enabled on their system components, justify why they’re active, and verify that controls are implemented. Administrators didn’t always realize that insecure protocols were being used, as they weren’t the application owners. Other times, due to the usage of legacy systems, insecure protocols needed to be used and compensating controls needed to be documented — for instance, having additional strong access controls (Requirement 8) and properly configured firewalls (Requirement 1). VERIZON 2014 PCI COMPLIANCE REPORT 19
  20. 20. With the uptake of virtualization, data stored only “in memory” can now easily be retained on non-volatile storage when virtual systems are suspended or snapshots are taken. This poses new threats to the security of encryption keys kept in memory in virtualized environments. And just 51.5% of companies complied with 2.2.2b, indicating that organizations still find it challenging to provide valid business justifications for the use of insecure services, daemons, and protocols, and presenting the documentation for it. Subcontrols 2.2.a and 2.2.b require that organizations have system configuration standards and that they are applied when new systems are configured; only 50.5% of organizations assessed had both of these controls in place (59.4% and 59.5% respectively). In our experience, system administrators are usually so busy that proper and thorough documentation of configuration standards is not seen as a priority. CHALLENGES AND PITFALLS It’s common for organizations to struggle to meet subcontrol 2.2.4.b [Verify enabled functions are documented and support secure configuration]. Often the list of services running, which is obtained from the samples taken during an assessment, does not match what is documented. Requirement 2 covers the configuration of all systems within the CDE. This makes it one of the requirements most affected by the emergence of virtualization and cloud technologies. These technologies simplify the way in which organizations run their IT infrastructure. However, with new technology always come new challenges, like how to segment mixed environments (in-scope and outof-scope systems hosted in the same physical server) to prevent attacks based on shared resources or other out-of-band channels, among others. It’s worth noting that required controls cannot be used as compensating controls; an entirely new approach is required. Some retail organizations have started to pilot mobile payment applications in their environments. However, the PCI SSC stopped all PA-DSS certification reviews for mobile payment applications in 2011. The implications are that organizations using unvalidated mobile payment applications will have a very hard time passing PCI assessments, since compensating controls are much harder to implement in mobile devices due to their limited capabilities (the reason why the PCI SSC suspended all reviews for these devices). The way around this, according to the PCI SSC, is to use P2PE solutions where mobile devices can act purely as communications devices for the encrypted traffic. HOW IS THIS REQUIREMENT EVOLVING? DSS 3.0 provided some changes and clarifications to existing wording, and added control 2.4, which requires organizations to maintain an inventory of system components in scope. This mirrors similar guidance in other requirements. Another new control, 2.5, requires organizations to document and communicate the policies and daily operational procedures associated with vendor defaults to responsible personnel, helping to prevent insecure configurations. Some organizations skip requirements relating to wireless and virtualization technologies — for example, all five subcontrols of 2.1.1 were not applicable for 51.5% of companies because their CDE did not have any wireless access points. As wireless technologies and security standards continue to evolve, the DSS is changing to keep pace — we saw changes to 2.1.1 in both DSS 2.0 and 3.0. 20 VERIZON ENTERPRISE SOLUTIONS
  21. 21. REQUIREMENT 3 Protect stored cardholder data WHY IS IT IMPORTANT? Attacks on an organization’s systems are often perpetrated with the aim of extracting cardholder data: it’s a prime target. Stored cardholder data — whether archived long-term or cached temporarily while in use by an application — must be protected continuously, otherwise it’s vulnerable to attack. Requirement 3 stipulates that organizations must never store sensitive authentication data like the card verification values (CVV/CVV2) or PINs after authorization of the transaction, even if encrypted; and render PANs unreadable using encryption, truncation, tokenization, masking (when displayed), or hashing. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? According to the 2013 DBIR, of all the breaches studied by the Verizon Investigative Response team, not a single one involved cardholder data “in transit” between systems. However, two-thirds of data breaches involved data “at rest.” Simple rule: If you don’t need it, don’t keep it. When our RISK team investigated data breaches during 2011–2013, they found that 18.2% of organizations suffering a breach had Requirement 3 in place. Over the same period, our QSAs found that 32.7% of companies passed Requirement 3. This suggests some correlation between not having strong data protection methods in place and suffering a data breach. THE STATE OF COMPLIANCE Requirement 3: Compliance snapshot Compliance by organization 2013 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 79.3% (11th) 6.7% (9th) Compliance 68.9% (5th) 0-20% 21-40% 41-60% 61-80% 81-100% Compliance by organization 2012 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 13.2% (8th) 54.5% (11th) Compliance 17.0% (11th) 0-20% 21-40% This requirement specifically covers the storage of cardholder data on system components, such as servers and databases. It states that all stored data must be protected using appropriate methods, no matter what type of system it is stored in. 68.9% OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 3 IN 2013, AN INCREASE OF 51.9 PERCENTAGE POINTS ON 2012. 79.3% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 79.3% OF CONTROLS. 41-60% 61-80% 81-100% Figure 12: Snapshot for Requirement 3; dataset 2012 and 2013 Reasons for the massive increase in compliance with this requirement between 2012 and 2013 include: • Better tools: Improvements in the effectiveness of automated scanning tools — particularly cutting the number of false-positives — and the consequent increase in the use of these tools. • Consolidation: Better scope reduction — by cutting the number of systems that store CHD through consolidation of databases, backup systems and paper repositories. • Outsourcing: Increased use of third parties, reducing the amount of data processed and stored by the organization. Another contributing factor to the significant improvement in Requirement 3 is that nearly a third of its controls and subcontrols fall in milestone one of the PCI-DSS’s prioritized approach (it makes up 60% of the controls within milestone one). We have seen acquirers using this supporting document as a roadmap for merchants to achieve compliance, with dates set to achieve each milestone. VERIZON 2014 PCI COMPLIANCE REPORT 21
  22. 22. Data “at rest” is an easier target in several ways. It often has a larger window of exposure compared to data being transmitted, “data in motion”. Interestingly, retail organizations performed significantly better than hospitality companies. Many organizations failed to comply with 3.4, which demands that they confirm that the PAN is rendered unreadable via hashes, truncation, strong encryption or tokenization. Just 47.5% of companies were compliant with all four validation testing requirements: • 3.4.a: Obtain and examine documentation about the system used to protect the PAN, including the vendor, type of system/process, and the encryption algorithms (59.4%). • 3.4.b: Examine several tables or files from a sample of data repositories to verify the PAN is rendered unreadable — that is, not stored in plaintext (64.4%). • 3.4.c: Examine a sample of removable media (for example, backup tapes) to confirm that the PAN is rendered unreadable (74.3%). • 3.4.d: Examine a sample of audit logs to confirm that the PAN is rendered unreadable or removed from the logs (70.3%). CHALLENGES AND PITFALLS Data “at rest” is an easier target in several ways. It often has a larger window of exposure compared to data being transmitted, “data in motion”. This problem is exacerbated by a lack of understanding of all the places within the organization where CHD is stored, sometimes even in plain text. This has led many in the industry to call for a “Requirement 0,” mandating automated data discovery. This would alleviate the issue of organizations only looking at data in locations where it’s supposed to be — within the existing card data environment — and neglecting to confirm that card data is not present elsewhere. This isn’t a requirement yet, but we’d recommend that organizations adopt this approach to keep their customer’s data is safe and simplify their compliance maintenance efforts. As noted in our analysis of Requirement 1, one of the foundations for effective PCI compliance is to accurately know how and where card data flows through various systems — from its creation to its destruction. This is why it’s critical to identify and examine all desktops, laptops, and servers that handle cardholder information. This includes database files that contain card numbers, and any application system that accesses cardholder data. And it also means understanding not just databases and file stores where data is permanently stored, but also the caches and temporary files where data resides during processing. This is challenging enough in conventional IT environments. Mobile devices, particularly those brought into offices, retail sites, and other environments by employees as part of the “bring your own device” trend, make it even more difficult. Mobile devices running a range of operating systems, applications, and services require different tools to manage and may not support appropriate device management controls, including strong encryption and logging. New forms of attack are emerging that target data during processing and transmission — partly driven by increasing security measures put in place to protect data at rest. The PCI DSS does not currently require organizations to encrypt data being transmitted within the CDE. We believe that unless this is addressed, it could become a significant threat to CHD. HOW IS THIS REQUIREMENT EVOLVING? Many of the changes introduced to Requirement 3 in DSS 3.0 involve improving the management of encryption keys. Subcontrol 3.5.1 covers restricting access to keys to the minimum possible number of people, and 3.5.3 requires that keys are stored in as few places as possible. The subcontrols under 3.6 mandate that best practices are followed when replacing keys when they reach the end of their life or are compromised, and that those entrusted with managing keys understand and accept their responsibilities. DSS 3.0 also clarifies the principles of split knowledge and dual control. Split knowledge is a method in which two or more people separately have key components, and each person knows only their own key component. Dual control requires two or more people to perform a function, and no single person can access or use the authentication materials of another person. Control 3.2 has been updated to require that all data is rendered unrecoverable upon completion of the authorization process, clarifying the intent. 22 VERIZON ENTERPRISE SOLUTIONS
  23. 23. REQUIREMENT 4 Encrypt transmission of cardholder data across open, public networks WHY IS IT IMPORTANT? The encryption of data transmissions is a foundational information security practice, and most IT departments are familiar with how to protect common systems and applications. Requirement 4 covers communications over public/open networks, including email sent to and from the organization (e.g. in communications between customers and service staff) and transactions made over the Internet. It is essential to use suitable data protection technology (such as secure SSL or TLS) to encrypt communications containing cardholder data that take place over any untrusted network, including internal ones. The term “untrusted network” includes any network outside of the organization’s control, like the Internet, and local “over the air” networks, like Wi-Fi and Bluetooth — even if they belong to the organization. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? Attackers know that CHD sent over open/public networks is usually well protected, and therefore go after softer targets — of all the incidents our RISK team investigated and reported upon in the 2013 DBIR, not one breach involved data “in transit.” In two-thirds of breaches data was compromised at rest (see Requirement 3, page 21); the remaining cases occurred during processing. But this is no reason to be complacent, especially with more people using their own devices and working from home — potentially accessing all kinds of unsecured networks. THE STATE OF COMPLIANCE Requirement 4: Compliance snapshot Compliance by organization 2013 6.7% (9th) Compliance Mostly compliant, 81-99% 0-20% 87.8% (4th) 41-60% 61-80% 2012 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 20.8% (1st) 0-20% 61.2% (4th) Compliance 34.0% (3rd) OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 4 IN 2013, AN INCREASE OF 34.9 PERCENTAGE POINTS ON 2012. 87.8% 21-40% 81-100% Compliance by organization 68.9% Spread of compliance Average compliance Fully compliant, 100% 68.9% (5th) This requirement is designed to protect cardholder data and sensitive authentication data transmitted over unprotected networks, such as the Internet, where it could be intercepted by attackers. 21-40% 41-60% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 87.8% OF CONTROLS. 61-80% 81-100% Figure 13: Snapshot for Requirement 4; dataset 2012 and 2013 The most-often complied-with subcontrols included 4.1.b on the use of trusted keys and certificates (84.2%) and 4.1.e on using HTTPS in web sessions (83.2%). The least complied-with subcontrol within Requirement 4 was 4.1.a [Implement and maintain a system and supporting processes to ensure that cardholder data is always encrypted during transit over unsecure networks], with 24.8% of organizations failing to pass muster. The relatively high compliance with all these controls shows that these are common best practices. This has partly been driven by cardholders’ increasing security awareness — many consumers now avoid websites that don’t display the “green bar” or padlock indicating a secure connection. No controls within Requirement 4 ranked in our “Top 20” or “Bottom 20” — though 4.1.1 came close, landing in twenty-first position. Merchants performed slightly worse than service providers; our experience suggests that this is probably due to merchants continuing to use legacy systems that don’t support strong encryption to transmit cardholder data. VERIZON 2014 PCI COMPLIANCE REPORT Our 2013 DBIR dataset does not include a single security incident in which data was identified as being breached “in transit.” 23
  24. 24. CHALLENGES AND PITFALLS CLOUD COMPUTING Companies of all kinds are increasingly adopting cloud computing services, and the merchants and service providers covered by PCI DSS are no exception. Cloud computing services offer many benefits, including increased agility and scalability, but as with any managed IT services, they alter the compliance landscape. Providers can implement per-tenant, per-resource, and per-application security controls, keeping data secure despite the multi-tenant environment. Many on-premises environments rely on perimeter security as their only layer of defense and lack sufficient internal network access controls — so cloud environments can offer the same, or even better, security as their on-premises counterparts. Organizations can protect transmitted card data in cloud environments in various ways; for example, ensuring that the cloud providers segment the deployment into public-facing and private segments, and maintain encryption (or re-encrypt if necessary) until card data reaches an application server in a secure, private segment of the cloud environment. The biggest pitfall in complying with Requirement 4 is failing to understand the breadth of impact and the responsibilities it puts on the organization. For instance, should a customer email a merchant and include their card details in plain text, this could lead to unintended (and insecure) storage of cardholder data, and the merchant falling out of compliance with control 3.4. Unsolicited emails If a customer emails a merchant and includes their card details in plain text, the merchant must have a system in place to ensure that the PAN is either secured or securely deleted. Organizations receiving such messages should also respond to the sender advising them not to send card data by email. All organizations must regularly check for and securely remove any unsolicited card information that ends up in email servers and other databases. Many organizations go one step further and use their DLP system’s content filters to automatically block or quarantine any incoming or outgoing emails that contain cardholder data, helping ensure that the email system stays out of PCI-DSS scope. This may not be a practical solution for all organizations, and has potential downsides — like bringing the DLP systems and other components into scope. Strong encryption Requirement 4 covers any open, public networks or other messaging channels used to transmit unencrypted data — including email, efax, VoIP, instant messaging, customer support forums, and any other web session not protected by SSL/TLS. Unless organizations can find a way to adequately protect sensitive data passing through these channels, they may have to ban the use of these channels for sensitive data. The best practice is to extend the use of strong encryption widely across the organization, even beyond where cardholder data is usually transmitted. The most commonly used method for the secure transmission of cardholder data is SSL/TLS. Most people are familiar with these cryptographic protocols from e-commerce, but they are also increasingly being used as the method of choice for point-to-point encryption (P2PE) solutions (see Appendix B, page 53). SSL/TLS can be used to satisfy the DSS requirement for network segmentation by isolating the transmission of cardholder data from the rest of the company’s network traffic. Devices between the endpoints of an encrypted communication are out of scope as long as they do not have the ability to decrypt the data. If the organization being assessed has one of the endpoints in the SSL/TLS encryption, then the SSL/TLS process is in scope. To reduce the scope as much as possible, the organization can use terminals from the payment processor that encrypt data using keys created and held by the processor. HOW IS THIS REQUIREMENT EVOLVING? Efforts continue to address the security weaknesses currently inherent to wireless networking technologies on open public networks, such as weak legacy encryption and authentication protocols which allow attackers to exploit these vulnerabilities and gain privileged access to the CDE. The phrase “open, public network” caused much confusion in the early days of PCI DSS. Control 4.1 was updated in both versions 2.0 and 3.0 of the standard to improve clarity, aligning the language used in describing testing procedures to that used in the requirement itself, and expanding the examples given. Prior to 2013, lack of clarity caused uncertainty and concern around the requirements for protecting payment card data across cloud environments, in accordance with PCI DSS. In February 2013, the PCI SSC released the PCI DSS Cloud Computing Guidelines Information Supplement. This defines the security responsibilities of both the cloud provider and customer, and provides guidance for third-party cloud providers on how to secure payment data and maintain compliance with PCI-DSS controls in a cloud environment. 24 VERIZON ENTERPRISE SOLUTIONS
  25. 25. REQUIREMENT 5 Protect systems from malware and keep anti-virus software up to date WHY IS IT IMPORTANT? Attackers can use malware — malicious code — to gain a foothold in the environment, capture cardholder data, and damage systems; so it’s important for organizations to protect all systems processing or storing CHD with anti-virus software. Requirement 5 demands that anti-virus software is not only in place, but also that it is kept up to date; is capable of detecting, removing, and protecting against all known types of malware; generates audit logs; and that scans are performed regularly. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? According to the 2013 DBIR, 40% of breaches involved malware, placing it the second-most common threat action. 74% of malware breaches involved direct installation on systems by attacker themselves, and 47% involved email attachments opened by legitimate users, like employees. When our RISK team assessed organizations that suffered a security breach, they found just 34.9% compliance with Requirement 5. The average compliance across all organizations in our study was 56.4%. This suggests a correlation between having effective anti-virus software in place and reducing data breaches. THE STATE OF COMPLIANCE Requirement 5: Compliance snapshot Compliance by organization 2013 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 95.9% (1st) 11.1% (6th) Compliance 80.0% (2nd) 0-20% 21-40% 41-60% 61-80% 81-100% Compliance by organization 2012 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 17.0% (4th) 80.0% OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 5 IN 2013, AN INCREASE OF 49.8 PERCENTAGE POINTS ON 2012. 95.9% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 95.9% OF CONTROLS. 0-20% 64.3% (2nd) Compliance 30.2% (4th) This requirement concerns protecting all systems commonly affected by malicious software against viruses, worms, and trojans. 21-40% 41-60% 61-80% 81-100% Figure 14: Snapshot for Requirement 5; dataset 2012 and 2013 In 2013, compliance leapt to 84.4% indicating that understanding of the requirement had matured or that anti-virus software and maintenance of services had improved. In order for an application to be compliant with PA-DSS, it must support virus scanning — so efforts to certify with PA-DSS are driving broader implementation of anti-virus/anti-malware protections. Service providers proved significantly more compliant with this requirement than merchants. We found that 86.1% organizations assessed on 5.1.1 [Ensure that all anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software] passed, putting it in our “Top 20”. Of all Requirement 5’s controls and subcontrols, the one that organizations struggled the most with was 5.2.d [Ensure that anti-virus software log generation is enabled], with only 69.3% of assessments passed. A possible reason for this is that many large anti-virus suites provide their own logging capabilities, and these are often managed by a separate team. VERIZON 2014 PCI COMPLIANCE REPORT SHAPE-SHIFTING Modern malware is polymorphic, constantly changing to evade detection — like a spy slipping on a disguise. There have even been cases of malware being adapted to specifically target an individual organization. Signature-based technologies — like traditional anti-virus, anti-malware and intrusion detection systems — which work by matching characteristics of threats, do not provide adequate protection. Unfortunately, many companies — even large enterprises — still rely on these flawed technologies. 25
  26. 26. A study by Imperva in December 2012 found that “The initial detection rate of a newly created virus is less than 5%,” and that “For certain antivirus vendors, it may take up to four weeks to detect a new virus from the time of the initial scan.”2 Compliance with all other validation testing requirements exceeded 75%. This high level of compliance is probably because these controls cover some of the most basic security methods, and many organizations have a significant degree of process automation in place. CHALLENGES AND PITFALLS Historically, Requirement 5 has been associated with running local software that actively identified and blocked attacks. While there may have been some merit in creating and storing logs, organizations were often reluctant to place an additional performance overhead on systems. It’s no coincidence, then, that when DSS 2.0 clarified that logging was a requirement, the greatest challenges with Requirement 5 revolved around logging and retaining logs. Before DSS 3.0, any anti-virus software implemented in line with Requirement 5 did not explicitly address the newer threat of tailored malware, highlighted as a threat in the DBIR and similar studies. However, DSS 3.0 now redresses this balance by stating that organizations must be mindful of evolving malware: The threat from malicious software can change quickly, so it is important that organizations keep abreast of current trends and developments. This can be achieved by monitoring security notices and news groups to determine what new and evolving malware threatens their systems and data. HOW IS THIS REQUIREMENT EVOLVING? There are only a few changes for DSS 3.0, though some are quite significant. Much of the language has been clarified to ensure that organizations know what is required. For example, the title was updated to reflect the intent of using anti-virus software: to protect systems against malware. And control 5.2 now aligns the language between requirement and testing procedures for consistency. There is a new subcontrol and a new control within Requirement 5 in DSS 3.0: • 5.1.2 requires organizations to regularly evaluate systems not considered to be a common target for malicious software. In the future, organizations must regularly evaluate evolving malware threats in order to confirm that such systems remain exempt from the requirement to have active anti-virus software. Historically, Linux’s low share of the desktop market has meant that very little malware has been created for it (though that’s changing), and led many to consider anti-virus software unnecessary. While rare on the desktop, around half of the world’s webservers run on Linux and so this could have a significant impact. • 5.3 strives to ensure that antivirus mechanisms are kept actively running. It states that users should not be able to disable or alter anti-virus/anti-malware software unless specifically authorized by management on a case-by-case basis; and if protection needs to be disabled for a specific purpose, it must be formally authorized and extra security measures should be implemented while it’s inactive. Complying with this control will require strong policies, rigorous testing and monitoring, and fallback procedures to ensure continuity of protection. 26 VERIZON ENTERPRISE SOLUTIONS
  27. 27. REQUIREMENT 6 Develop and maintain secure systems and applications WHY IS IT IMPORTANT? Requirement 6 plays an important part in helping ensure that organizations maintain their security posture by: • Managing and documenting changes in the CDE. • Using secure development practices for applications in the CDE, whether developed internally or commissioned from third-party developers • Ensuring that security policies are operational and documented • Testing applications for the presence of known weaknesses and common design or coding flaws • Identifying emerging vulnerabilities and remediating against them by applying software patches Unless an organization knows what is in the environment at any point, it’s impossible to assess risk accurately. DSS 3.0 makes it clear that change management applies across the board. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? The 2013 DBIR showed that direct installation of malware on a compromised system was the most common attack vector. Stolen credentials and brute-force attacks were the most frequently observed ways of gaining access to systems. Requirement 6 specifies how organizations should harden their applications against attack; and compliance with this requirement therefore should help reduce vulnerability against this highly prevalent attack vector. Investigations by our RISK team found that only 16.4% of organizations that had suffered a data breach were compliant with Requirement 6, compared to an average of 53.3% of all organizations assessed by our QSAs in 2013. This suggests a strong correlation between the likelihood of suffering a data breach and non-compliance with the PCI DSS. THE STATE OF COMPLIANCE Requirement 6: Compliance snapshot Compliance by organization 2013 13.3% (5th) Compliance Mostly compliant, 81-99% 0-20% 87.4% (5th) 41-60% 61-80% 2012 Spread of compliance Average compliance Fully compliant, 100% Mostly compliant, 81-99% 13.2% (8th) 0-20% 51.4% (9th) Compliance 22.6% (7th) OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 6 IN 2013, AN INCREASE OF 46.3 PERCENTAGE POINTS ON 2012. 87.4% 21-40% 81-100% Compliance by organization 68.9% Spread of compliance Average compliance Fully compliant, 100% 68.9% (5th) This requirement covers how IT systems and applications, both in-house and third-party, are developed and maintained, whether by the organization or its suppliers. It recognizes that the threat landscape is always changing, and compliance measures need to change too. 21-40% 41-60% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 87.4% OF CONTROLS. 61-80% 81-100% Figure 15: Snapshot for Requirement 6; dataset 2012 and 2013 Patch management can be a major headache for a large organization, that’s why they often delay updates for as long as possible — many organizations skipped Windows Vista entirely, and 95% of the world’s ATMs still run Windows XP. After June 30, 2012 the guidance within DSS control 6.2 specifying a risk ranking based on the Common Vulnerability Scoring System (CVSS) from the Forum of Incident Response Security Teams (FIRST) came into effect. This provides a “universal, open and standardized method for rating IT vulnerabilities,” enabling companies to effectively prioritize the testing and deployment of patches. We believe that this contributed to the significant improvement in compliance with this requirement in 2013. The three most-often complied-with subcontrols were all met by at least three-quarters of the organizations we analyzed. 6.5.b [Interview a sample of developers and obtain evidence that they are knowledgeable in secure coding techniques] is relatively simple to comply with, given the wealth of VERIZON 2014 PCI COMPLIANCE REPORT 27
  28. 28. resources in secure coding available from major vendors such as Microsoft and Oracle. Subcontrols 6.4.4 and 6.3.1 govern the process of moving a system into production; specifying that test data, accounts and user IDs are removed before the system goes live — a one-off activity that’s relatively easy to incorporate into launch processes. The least-often complied-with subcontrols tended to be those related to the much more problematic areas of identifying and managing vulnerabilities and the associated changes on an ongoing basis. For example, 6.1.a (renumbered 6.2 in DSS 3.0) demands that systems and software are verified to have the latest vendor security patches installed. This subcontrol ranked among our “Bottom 20,” with only 49.5% compliance. CHALLENGES AND PITFALLS Patch management Patch management and associated vulnerability management processes represent the biggest problem areas, because they’re rarely well documented and automated. Many weaknesses are only picked up during vulnerability scanning as part of Requirement 11.2, which means organizations are always playing catch-up. The sheer scale of the task is also a problem. PCI DSS 3.0 states that all systems should have applicable vendor-supplied patches installed within an appropriate timescale according to prioritized risk, with critical patches installed within one month of release. Organizations must test patches for compatibility with systems and controls already in place before applying them to potentially thousands of devices, such as an estate of point-of-sale (POS) terminals across retail stores. As always, reducing the scope of the cardholder data environment should be the first step to reducing the patching workload. The irony is that, as onerous as this patching requirement is, the effectiveness of Requirement 6 in terms of actually closing vulnerabilities depends largely on the responsiveness of third-party software and hardware vendors in releasing patches in the first place. An organization may be both compliant and still at risk if a vendor does not release a patch for a known vulnerability. Organizations may find it challenging to maintain effective vulnerability management when an application or operating system reaches end-of-life and the vendor withdraws support. Relying on compensating controls to ensure effective data protection can only be a temporary solution, at best. Updating to a more recent release or alternative software offers a more robust and sustainable solution, and usually provides better ROI. Change management We also found significant problems with the change-management requirements covered under control 6.4, specifically relating to documentation and verification of changes. Change control is one of the key “gatekeeper” processes that maintain overall PCI-DSS compliance status. The cardholder environment is in constant flux, with new implementations and changes. The threat landscape also changes continually, with new attack vectors and vulnerabilities emerging. However, to maintain the compliance status of the cardholder environment, the organization must ensure that system or business process changes do not impact or disable the current PCI-DSS controls, and that any new systems implement all required controls and integrate current security controls before going into production. These controls may include incident response, log monitoring and reporting, access control, patch management, and malware management, to name but a few. Change-management features, such as functionality testing and change impact assessment documentation, were not in place in about half of the organizations we assessed during 2011–2013. This means that organizations may be making changes that remove key controls already in place and lead to insecure implementation of systems within the CDE (as mentioned before, this includes connected systems). 28 VERIZON ENTERPRISE SOLUTIONS
  29. 29. Secure code development Controls 6.3 and 6.5 govern secure code development, such as mandating code security reviews. Building security and compliance into the software development lifecycle requires a new set of skills; organizations need developers to: • Be aware of common and emerging coding vulnerabilities (such as found in the OWASP 2013 Top 10 and SANS Top 20) • Be able to identify and fix insecure code • Document coding standards and best practices • Follow testing procedures and checklists These can all be a burden for an already overworked development team tasked with getting new functionality into production environments as quickly as possible. The business must also change its behavior. When setting requirements for code development, business stakeholders should be aware that security testing must be passed before code enters a production environment. Even if the code passes functional tests, its implementation could still be delayed until security issues are addressed. Cloud and web application firewalls The emergence of the cloud has challenging implications for how organizations comply with control 6.6 in particular. This subcontrol is intended to ensure that externally facing web applications (including web services) stay protected against application-level attacks over time, either by reviewing or testing application code periodically or by deploying a web application firewall (WAF). When migrating applications to a cloud provider, it may no longer be possible for an organization to deploy a WAF in the provider’s hosted environment, requiring the organization to re-evaluate how it will remain compliant with 6.6. This should be considered as part of any cloud migration strategy. IN-MEMORY DATA With customers expecting ever richer and responsive websites and applications, and IT striving to deliver real-time insight to the business, use of in-memory technology — like SAP HANA — is growing quickly. As ever, hackers have been quick to see what opening this offers, and we’ve seen an increase of malware that can sit resident on a system component and scrape data from memory. Subcontrol 6.5.c is effective immediately. It requires that companies examine training records to verify that software developers received training on secure coding techniques. This means that application developers must demonstrate that they understand that the risks to sensitive authentication data (SAD) in memory and how it can be protected. HOW IS THIS REQUIREMENT EVOLVING? Requirement 6 was updated significantly in DSS 2.0 and again with the release of version 3.0. The overall wording of the requirement changed to specify that all applicable systems, not just critical ones, must have all appropriate patches applied, significantly increasing the scope of effort for organizations. The updates include six new “best practices” that will become requirements on July 1, 2015, and over a dozen clarifications on existing controls. The changes covered: • Securing authentication and session management in web applications. The new subcontrol 6.5.10 sets standards for web development practices, session control and timeouts, and testing of web applications that handle card data to reduce the probability of “man-in-the-middle” and client-side attacks. • Following the regularly updated lists of vulnerabilities provided by, NIST, OWASP, SANS, and CERT — vulnerability management must be made part of business as usual. • Clarifying that change management applies to all changes to all system components, not only during software development and maintenance. • The secure handling of cardholder data in memory, reflecting the increasing number of attacks targeting data at the time of processing. VERIZON 2014 PCI COMPLIANCE REPORT 29
  30. 30. This requirement specifies the processes and systems that restrict each user’s access rights to the minimum they need to perform their duties — in other words, “need to know.” 73.3% OF COMPANIES MET ALL THE DEMANDS OF REQUIREMENT 7 IN 2013, AN INCREASE OF 31.8 PERCENTAGE POINTS ON 2012. 86.8% IN 2013, COMPANIES WERE COMPLIANT WITH AN AVERAGE OF 86.8% OF CONTROLS. REQUIREMENT 7 Restrict access to cardholder data by business need to know WHY IS IT IMPORTANT? Every user account with access to cardholder data (and the systems that store it) is a potential security risk. The more people granted access to sensitive data, the bigger the target you offer to attackers, and the greater the risk of accidental or deliberate misuse by staff. Complying with this requirement is key to ensuring that critical data can only be accessed by personnel who need it to perform their roles. Requirement 7 covers policies and controls for both physical and IT security. An access-control system for each element of the cardholder data infrastructure must be in place, including using locks or restricted access to paper-based cardholder data records or system hardware; controlling access to the wireless network, PCs, and other devices; and controlling access to any digital files that contain cardholder data. Access controls should be limited on the basis of “need to know” or “least privilege,” giving each individual the minimum privileges and access to data required to perform their role. In order to ensure consistency and deal with changes caused by recruitment and employee termination, it is essential that access management is automated, based on well-defined roles, and enforced across all components of the CDE and connected systems. Roles themselves should be structured to ensure separation of duties. HOW DOES THIS REQUIREMENT RELATE TO SECURITY THREATS? The DBIR makes it clear that abuse of user privileges is a favored channel for attackers trying to capture data. Gaining access via a genuine, authorized account — by guesswork (brute force/ cracking) and/or phishing (increasingly including social engineering) — is often the most direct way to gain illegitimate access to a system, and one of the hardest to detect. The DBIR found that more than half of all breaches involved hacking, and that authentication-based attacks factored into about four of every five of these breaches. Furthermore, 66% of exfiltrated data was taken from databases and file servers, and commonly accessed through legitimate (but misused) credentials. There’s also a real risk from users themselves. 14% of attacks that we investigated in the 2013 DBIR involved “insiders” — legitimate users with access rights to company systems. Customer service personnel were responsible for 46%, end-users 33%, managers 7%, and executives 5%. These groups are not system administrators nor are they IT security experts, and they generally do not need extensive access privileges. Our DBIR-related investigations found that only 31% of organizations that suffered a breach were compliant with Requirement 7, compared to an average of 74% of all organizations assessed by our QSAs. This suggests a strong correlation between the likelihood of suffering a data breach and a lack of compliance with PCI DSS. The attackers may be external, or they may be insiders acting maliciously (or carelessly). In either case, restricting each user account’s privileges is an important part of preventing damage being caused. 30 VERIZON ENTERPRISE SOLUTIONS