Moscow deck final


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • As a result of discussions with everyone from all sectors involved in PCI, it was agreed that our standards would be updated every three years, on a continual improvement programThe wheel shows the various stages throughout the life cycleCritical for PCI when updating the standard is the feedback we receive. This is critically important in assessing what needs to change and whyIn addition we also work with Forensic Investigators who are working on breaches and seeing exactly how criminals gain access to data
  • Which leads us to version 3.0 of the PCI Data Security Standard, published last week. Lack of education and awareness around payment security and poor implementation and maintenance of the PCI Standards continues to be a problem. Version 3.0 is geared towards helping organizations better understand the intent of requirements and how to properly implement and maintain controls across their business. The changes introduced willhelp companies take a proactive approach to protect card data that focuses on security, not compliance, and makes PCI DSS a business as-usual-practice by introducing more flexibility, and an increased focus on education, awareness and security as a shared responsibility.  
  • These investigations also help identify which organisations and which sectors are being targeted the mostAs you can see, Retail and Food/Beverage are the top targets
  • What we have found from all of this is 4 key areasFirstly the biggest threat we face today is as a result of weak passwords and default passwords. These let criminals into your systems to steal the dataThis is closely linked with a lack of employee education. It is essential that all staff are given security training at least annually preferably monthlyMan organisations use the services of a third party provider, for either software, or actual payment processing. These organisations can and do have a significant impact on your security. It is essential that you understand who is responsible for security at all stagesFinally organisations are very slow at detecting when they are breached. It takes criminals minutes or hours to break into your systems, and then it takes you months to find they are there
  • Now let’s take a closer look at some of the key changes. First, with a focus on raising awareness, we’ve added a new section to the beginning of the PCI DSS, to provide guidance on how to implement PCI DSS into your business-as-usual, or BAU processes.The reason for this is – Organizations are always changing – and these changes can result in them not maintaining their security controls to the same level as when they were validated. It is essential that organisations have a proactive approach to security and assess the security impact on all changes. This requires a mindset change across the companyMaking security BAU can prevent;new vulnerabilities from being introduced, orpersonnel from bypassing securely defined processes in the futurea secure system from being modified in a way that reduces its security.The intent of this new section is to help organizations maintain their PCI DSS compliant environment in between PCI DSS assessments by implementing security and PCI DSS into their daily business activities.It’s important to note that this BAU guidance is just guidance – these are best practices and recommendations – Not new requirements, and they do not add to existing requirements - these do not need to be included in your PCI DSS assessment.
  • Probably the biggest change involves the PCI DSS Navigating Guide, or “Nav Guide” as it’s often referred to.HistoricallytheNavigating Guide has always been a companion document to the PCI DSS, and provides information about the intent of each of the requirements.Unfortunately, not everyone was aware that the Nav Guide existed, or that it contains this useful information.So for version 3, instead of updating the Nav Guide as a separate document we’ve incorporated much of this good information into the standard itself – this appears as a third column titled “guidance”.This column provides information about the intent of each requirement, right next to each requirement – so there’s no need to locate a separate document, or cross-reference between the two to find this information. We wanted to make sure that everyone had access to this information, and we hope this helps provide a more consistent understanding of the intent of the requirements.
  • So lets look at some of the changes to the requirements themselves – lets start with an example from Requirement 8As I mentioned earlier, weak passwords and authentcation are a significant issue So, rather than adding to the minimum requirements for password strength, we instead focused this update on educating users ... This change requires that, as well as communicating password policies to all users, organizations provide guidance for their users on how to choose strong passwords, how to protect their passwords, and how to change passwords if there’s a suspicion of compromise.
  • We received many comments that documentation and policies should be more important and included earlier in the requirementsWe listened to that and have taken the security policies and daily operational procedures (formerly requirements 12.1.1 and 12.2) – and instead of being a single requirement in 12, we’re incorporating them into each of requirements 1-11.This will help those organisations that break up PCI DSS controls by role or area of responsibility, so for example the firewall administrator might get handed requirement 1 but might not be involved with requirement 12 so not aware of the appropriate policy components.The goal with this update is to help organizations to ensure each department is involved and aware of the policies and procedures that apply to them.And by relocating these requirements to each specific control area – such as firewall/networking, vulnerability management, system configuration, etc., it will make it easier to track and validate that the applicable policies and procedures are in place and the right people are aware of them.
  • Another area we received a lot of feedback on relates to consistency of assessment procedures –that testing procedures need more consistent interpretations.To help address this, we’ve updated the testing procedures to really confirm what it means to “verify” that a requirement has been met. In this way, many v2.0 procedures which simply stated “verify that Control X is in place” have been updated to specify the particular testing activities that the assessor is expected to perform.We’ve also moved the reporting templates out of the standard and into standalone documents. We are combining it with the reporting instructions, so all information is now in one place, and assessors don’t need to cross reference between different documents. The new reporting templates are also being designed to streamline the level of detail to be reported, and reduce the need to repeat information throughout the report.
  • Increased flexibility is another big focus area in version 3.0. The goal here is identifying the right level of security that meets the risk that we’re trying to mitigate but allows the flexibility for merchants and others to leverage it in their unique environment.So we’ve added flexibility for other solutions that could meet the intent of a requirement. For example, feedback has indicated that change detection is an area that can often be challenging especially for smaller merchants– so we’ve added flexibility on alternative ways to do this besides file integrity monitoring, so that organizations can select the solution and approach that works best their business. Similarly,for requirement 6.6 – Web Application Firewall now says “automated technical solution that detects and prevents web-based attacks, and requirement 12.3 –now says to use a method to accurately and readily identify the pertinent information – with labeling being an example.
  • Logging is another area we receive a lot of feedback on: What to log, how to log it, and most importantly how the heck do we review it all?As a result we’ve added more flexibility around which logs need to be monitored and at what frequency, with the aim of helping organizations focus daily log reviews on security-relevant logs and critical systems. We understand that it’s challenging to review ALL logs dailyWe also got questions over value of reviewing non-security relevant logsSo for version3 – we’ve provided more FOCUS for log reviewsWe’ve identified which log events need to be reviewed daily and that logs of all other system components are reviewed periodically based on the organization’s policies and risk management strategy, andas determined by the organization’s annual risk assessment. We’d also like to clarify that log reviews do not need to be manual – there a lots of tools – many free – that can be used…These changes will help organizations focus on the logs and alerts that they need to be looking at on a daily basis in order to detect suspicious activity – and for example some of the major threats we’re seeing today such as malware.
  • At the Council we talk a lot about security as a shared responsibility and this is something we’re really emphasizing in version 3.0.Today’s payment environment is even more complex, creating multiple points of access to cardholder data, making it all that much more important that security is on everyone’s minds and that it’s clear who’s responsible for what when it comes to PCI DSS. In version 3.0 we’re actually taking recommendations from our Special Interest Groups and adding in more guidance on documenting PCI DSS responsibilities to help organizations understand their PCI DSS responsibilities when working with different business partners. We updated the Intro section of standard – to add guidance for outsourcing PCI DSS responsibilities.Additionally, we added 8.5.1 to require that service providers with access to customer environments must use a unique authentication credential (such as a password/ phrase) for each customer.This is to address scenarios where a vendor supports multiple merchants, and the compromise of their credential at one customer results in the compromise of all their customersAlso new is 12.9 which is an additional requirement for service providers to support 12.8. This means they must acknowledge that they will maintain applicable PCI DSS requirements to the extent the service provider handles or manages the customer's cardholder data.
  • Another weak link in the security chain we’re seeing is around point-of-sale terminal security.We continue to see skimming attacks on these terminals. To this point, we haven’t had anything specific in the DSS requiring merchants to inspect their terminals – this has been something we promoted through our guidance document on skimming best practices.But as skimming remains a threat, we’re incorporating elements of these skimming best practices into the standard – specifically onsite inspection to address these threats, ways to identify compromises and minimize risk, as well as helping build in education and awareness on this issue for employees. The key focus here is to get merchants to check their devices and educate theirusers.
  • Another key change made in response to feedback and challenges in the market, is regarding penetration testing and effective scoping. We’ve always said you need to have a methodology for pen testing. But we’ve received a lot of feedback asking for more information on this – so now we’re adding in more guidance on how to do it properly.As a result, we’ve expanded Req. 11.3 to address requests to provide more information about what a pen testing methodology should include – it incorporates what was in v2 with some additions. Penetration testing is also an important tool to confirm that any segmentation in place to isolate the cardholder data environment from other networks is effective. We’ve seen a lot of incidents where networks considered out of scope were compromised because they weren’t segmented properly so we’re updating the pen testing requirement to verify that the segmentation methods are operational and effective.So we added that Penetration testing should also be used to validate segmentation where it is used, to confirm that they are working as intended and actually providing the segmentation that you think they are.
  • Lets take a look at the important dates around the new and old standardPCI DSS 3.0 is effective on January 1, 2014.Version 2.0 is valid until Dec 31 2014, so in 2014 either v2 or v3 of the standard may be used Butafter 2014, only 3.0 assessments are acceptable.What this allows is for organisations to complete their current work before migrating across to the new standard.This was a key feedback from our community and is well appreciatedAlso it’s important to note that there are different supporting documents for the different versions –There will be the new v3.0 Attestations of Compliance, and the older ones for v2.0; reporting instructions for v2.0, and reporting templates for v3.0;and there will be SAQs applicable to v2.0 and those applicable to 3.0So it’s important that you don’t mix and match documents between v2 and v3:You can do either a v2.0 assessment or a v3.0 assessment during 2014 and use the coordinatingsupporting documentation.
  • Some of you may be asking, what about technology? Mobile, tokenization, cloud? How’s the standard addressing these areas?These advances in technology are exciting and offer a lot of opportunities.It’s important to remember that technology is just one piece of the puzzleAnd we still need to focus on the core security principles – people, process and technology.The security principles defined in PCI DSS and PA-DSS v3.0 are common sense best practices and aligned with other industry-recognized security practices that have applicability for emerging technology and alternative payment acceptance. And they remain relevant irrespective of underlying technologies.With new payment channels, such as mobile acceptance, and ever-increasing use of new technologies, such as the cloud, we’re aiming to provide flexibility in the requirements so that merchants can implement controls as appropriate for their particular technology in order to meet that requirement.The challenge comes in with how to implement and/or how to validate that the controls are properly implemented.
  • Also, be sure to check out our resources on mobile, also on the PCI SSC website. The Mobile environment is changing so fast that it’s premature for new PCI Standards on mobile specifically.These consumer type devices don’t yet provide a sufficient level of security.So in the interim, you need to understand the risks of using mobile and take advantage of the Council’s guidance on using mobile to accept payments.With the guidance we’ve put out, we’re beginning to see improvement in security of consumer devices and this will lead to better solutions for accepting Payments on those devices.And we’ll continue to work with the industry to develop guidance and security requirements as we move forward.
  • A big focus area for using is increasing education and awareness around payment security.And as I mentioned, this is a key driver for updates in version 3.0 of the PCI DSS.With this in mind, we’ve developed many training programs that will help you better secure Card Data.Please visit our website to learn more about these options.
  • We also have PCI awareness trainingWe can come to you, you can attend instructor led training or you can attend the training onlineAlso I hope to have information on exciting new training opportunities in Russia soon. Watch this space
  • Building internal expertise at your company to support your PCI security efforts is also importantOur New training and cert for individuals, the Payment Card Industry Professional or PCIP, is a way for businesses to equip their IT employees to support their PCI compliance efforts, while IT security and other industry professionals can take advantage of it to build their skills portfolio. With this initiative, we hope to build a baseline of PCI knowledge across the industry.
  • You can find all this information and more on our website.
  • Security is a shared responsibility and your participation here today demonstrates that you are committed to the challenge
  • Thanks for your time today!
  • Moscow deck final

    1. 1. PCI Security Standards Council Guiding open standards for global payment card security Jeremy King, European Director November 2013Guiding open standards for global payment card security
    2. 2. PCI Security Standards Suite Protection of Cardholder Payment Data Manufacturers PCI PTS Pin Entry Devices Software Developers Merchants & Service Providers PCI PA-DSS PCI DSS Payment Applications Secure Environments PCI Security & Compliance P2PE Ecosystem of payment devices, applications, infrastructure and users Guiding open standards for global payment card security
    3. 3. PCI DSS Feedback Changes made per our lifecycle • Open standards development process • Feedback from our global PCI community • Feedback period started in Fall of 2011 Guiding open standards for global payment card security
    4. 4. Why PCI DSS 3.0? Visit to view this infographic Guiding open standards for global payment card security
    5. 5. Who’s Getting Breached? Systems that store, process or transmit cardholder data remain primary targets for criminals Retail 45% Food & Beverage 24% Hospitality 9% Other 8% Financial Services 7% Nonprofit 3% Health & Beauty 2% High Technology 2% Source: Trustwave 2013 Global Security Report Guiding open standards for global payment card security
    6. 6. Market Trends & Drivers Weak or default passwords Lack of employee education Security deficiencies introduced by third parties Slow self-detection Source: 2013 Trustwave Global Security Report Guiding open standards for global payment card security
    7. 7. PCI DSS, PA-DSS 3.0 – Key Themes Education Awareness Flexibility Security as a Shared Responsibility Make PCI your compass, not your roadmap Guiding open standards for global payment card security
    8. 8. At a Glance… • 12 core security principles of PCI DSS remain the same • Several new sub-requirements that will impact PCI DSS security efforts • Future implementation dates provided for more significant changes • Clarified PCI DSS Applicability • Enhanced testing procedures to clarify level of validation expected for each requirement • Aligned language between requirements and testing procedures for consistency • Instructions for Report on Compliance (ROC) reporting now separate ROC reporting template Guiding open standards for global payment card security
    9. 9. Maintaining Compliance Best Practices for Implementing PCI DSS into Business-as-Usual (BAU) Processes • Focus on security not compliance • PCI DSS is not a once-a-year activity • Don’t forget about people Guiding open standards for global payment card security
    10. 10. Understanding Intent of Requirements Guiding open standards for global payment card security
    11. 11. Strong Authentication PCI DSS v3.0 PCI DSS v2.0 8.5.7 Provide authentication procedures and policies to all users 8.4 Include guidance for users: • Selecting strong authentication credentials • Protecting authentication credentials • Not reusing previous passwords • Changing passwords if suspicion of compromise Guiding open standards for global payment card security
    12. 12. Security Policies and Procedures PCI DSS v2.0 12.1.1 Maintain a security policy that addresses all PCI DSS requirements 12.2 Develop daily operational security procedures that are consistent with requirements in the PCI DSS PCI DSS v3.0 1.5 Security policies and operational procedures for managing firewalls are documented and in use 2.5 Security policies and operational procedures for managing vendor defaults and security parameters are documented and in use Guiding open standards for global payment card security
    13. 13. Consistent Assessment Procedures Promote consistent validation methods • Enhanced testing procedures • Clarify what it means to “verify” a requirement has been met Improve reporting • Combine template with reporting instructions • Clarify level of detail required • Reduce repetition Guiding open standards for global payment card security
    14. 14. Flexibility: PCI DSS Requirements Guiding open standards for global payment card security
    15. 15. Log Reviews PCI DSS v2.0 10.6. Review logs for all system components at least daily PCI DSS v3.0 10.6.1 Review at least daily: • All security events • Logs from systems that store, process, or transmit CHD/SAD • Logs of system components that perform security functions 10.6.2 Review other logs periodically as determined by the organization’s annual risk assessment Guiding open standards for global payment card security
    16. 16. Security as a Shared Responsibility Guidance Requirement 8 Requirement 12 • Outsourcing PCI DSS responsibilities . • Service providers use unique credential per customer • Service providers acknowledge responsibility Guiding open standards for global payment card security
    17. 17. Physical Security for POS Devices 9.9 Protect devices that capture payment card data from tampering and substitution • Maintain an up-to-date list of devices • Periodically inspect device surfaces to detect tampering or substitution • Provide training for personnel to be aware of attempted tampering or replacement of devices Guiding open standards for global payment card security
    18. 18. Penetration Testing and Effective Scoping 11.3 Implement a penetration testing methodology 11.3.4 If segmentation is used, perform penetration tests to verify that the segmentation methods are operational and effective. Guiding open standards for global payment card security
    19. 19. Effective Dates for v3.0 PCI DSS V3.0 is effective on January 1st 2014 Version 2.0 is valid until December 31st 2014 Different supporting documents Do not mix and match Guiding open standards for global payment card security Check our website for the latest documents
    20. 20. Building on a solid foundation • Following on from an excellent partnership • Supported by the Central Bank of the Russian Federation • PCI and ABISS will work together on providing a Russian Translated version of PCI DSS v3.0 and supporting documents Guiding open standards for global payment card security 20
    21. 21. And Emerging Technologies? People + Processes + Technology = Guiding open standards for global payment card security Security
    22. 22. Point-to-Point Encryption Guiding open standards for global payment card security
    23. 23. Mobile Guidelines published 2012-2013 • PCI Mobile Payment Acceptance Guidelines for Developers • PCI Mobile Payment Acceptance Guidelines for Merchants as End-Users • Accepting Mobile Payments with a Smartphone or Tablet Guiding open standards for global payment card security
    24. 24. Training Options  Online Internal Security Assessor (ISA) Training  Corporate PCI Awareness – Let Us Come To You!  Online Awareness Training in Four Hours  Qualified Integrators and Resellers (QIR)™ Program  PCI Professional Program (PCIP)™ To learn more, visit: Guiding open standards for global payment card security
    25. 25. Internal Security Assessor (ISA) Program A comprehensive PCI DSS training and qualification program for eligible internal audit security professionals that you asked for! • Improves your understanding of PCI DSS and compliance procedures • Helps your organization build internal expertise • Teaches processes that can reduce the cost of compliance Guiding open standards for global payment card security
    26. 26. PCI Awareness Training Team Building Convenience Cost We come to you! Guiding open standards for global payment card security
    27. 27. Payment Card Industry Professional (PCIP)™ Support your organization Professional credibility Competitive advantage Global directory Now Available Guiding open standards for global payment card security
    28. 28. PCI SSC Website • Documents library • Dedicated page for small merchants • Listings of approved companies and providers • Videos and webinars • Frequently asked questions microsite Guiding open standards for global payment card security
    29. 29. Security is a shared responsibility Guiding open standards for global payment card security
    30. 30. Questions? Please visit our website at Guiding open standards for global payment card security