PCI DSS 3.0: Don’t Shortchange Your PCI Readiness
•Als PPTX, PDF herunterladen•
3 gefällt mir•2,641 views
In this archived webcast, the first of three in our compliance series on PCI DSS 3.0, we provide some insights on the notable requirements and clarifications that have been introduced in PCI DSS 3.0, and provide some practical suggestions of what you may want to start considering now to successfully navigate your audit preparations for v3.0. Jeff Hall, CISSP, CISM, CGEIT, PCI-QSA, PCIP and Senior Security Consultant at FishNet Security and Cindy Valladares, Senior Manager Corporate Communications at Tripwire, discuss PCI DSS 3.0 will impact your organization and what you need to do: - Understanding key themes for PCI DSS 3.0 - Making sense of clarifications, additional guidance, and new requirements - What’s changed, what hasn’t, and what will affect merchants most - How Tripwire’s continuous compliance solutions for PCI DSS are helping thousands of businesses worldwide The full recorded webcast is available here.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (6)
Ähnlich wie PCI DSS 3.0: Don’t Shortchange Your PCI Readiness
Ähnlich wie PCI DSS 3.0: Don’t Shortchange Your PCI Readiness (20)
Mehr von Tripwire
Mehr von Tripwire (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
PCI DSS 3.0: Don’t Shortchange Your PCI Readiness
- 1. PCI DSS 3.0: Don’t shortchange your PCI readiness PCI COMPLIANCE WEBINAR SERIES PART 1 OF 3
- 6. PCI DSS 3.0 was officially released November 7th, 2013 Goes into effect January 1st, 2014 ROC Templates anticipated in March 2014 Existing PCI DSS 2.0 compliant vendors will have until 12/31/2014 to move to the new standard
- 8. The mission of the PCI DSS has not changed since its introduction in 2004 -- to help merchants protect payment card data wherever and however it's stored, processed or transmitted -- but the theme of PCI DSS 3.0 is to make PCI compliance "business as usual," or, more specifically, increase the importance for merchants to integrate PCI compliance with other important day-to-day business activities.
- 9. Recommendation: Begin internal meetings now with Application Developers, Networking and Security teams to begin to understand current state and communicate expectations
- 10. Only 34% of the retail sector measure the reduction in access and authentication violations to assess risk management efforts Recommendation: Work across development and IT operations to clearly define access rights based on business purpose
- 11. Recommendation: Start to centrally manage (discover, monitor, report) on your wireless infrastructure periodically to get visibility
- 12. Recommendation: Accept that this is really difficult to do and begin to hone and develop ways to create and manage these inventories
- 13. Memory Scraping Malware Attackers used memory-scraping malware to probe system memory and steal sensitive data in about 50% of investigations where malware had data collection functionality. Attackers used malicious PDF files, targeting Adobe Reader vulnerabilities in 61% of all client-side attacks. Recommendation: Get this essential book Hacking Point of Sales: Payment Application Secrets, Threats, and Solutions to help you address this serious problem
- 14. There are more than a billion active credit and debit cards in the U.S., and nearly 48% of those are breached annually at the point of sale! Recommendation: Focus on security awareness training at the endpoint to train non-technical resources of what to look for and be clear as to what your expectations are
- 15. Recommendation: Kick start conversations with your MSSP, vendors and service providers to ask them to document scoping and enter into a formal, written agreement about it
- 16. Only 41 percent of the retail sector uses penetration testing to identify security risks Recommendation: Immediately begin to document and keep track of all threats and vulnerabilities to your environment for the last 12 months
- 18. Infographic PCI DSS 3.0 Webcast Series https://www.pcisecuritystandards.org/s ecurity_standards/documents.php Market Research Solution Information http://www.tripwire.com/register/howpci-dss-30-impacts-your-organization/ PCI Scoping Toolkit http://www.tripwire.com/ponemon/2 013/ http://www.tripwire.com/regulatorycompliance/pci-dss-compliance/ http://www.tripwire.com/state-ofsecurity/regulatory-compliance/pcidss-3-0-whats-new-infographic/ http://www.fishnetsecurity.com/sites/d efault/files/service-attach/PRCSL0015_PCI-Solutions_WEB.pdf http://itrevolution.com/pci-scoping-toolkit/
Hinweis der Redaktion
- Polling QuestionDo you believe your organization’s culture lends itself to implementing BAU?-Definitely-Maybe-Probably NotWhile a lot of the requirements have remained at their same numbers, the PCI SSC has reordered a number of requirements (most notably 6.1 and 6.2) and added a few new requirements. So those of us that have requirements memorized are going to have a learning curve with the new version.It is interesting that the PCI SSC touts the new version as giving more clarity than version 2. I was recently listening to a Southern Fried Security Podcast that had Brandon Williams as their guest and he pointed me to investigate the new version as he said the use of the words “periodic”, “periodically” and “should” had all increased in the new version. My results indicate that there 17 occurrences of “periodic” or “periodically” in the requirements or tests in version 3. That is a 113% increase over version 2. There are a total of 103 references of the word “should” in the PCI DSS v3. Eighty-two of those occurrences are in the requirements/tests. That is an increase of 382% over version 2. As a result, I have serious reservations as to how such increases in these nebulous terms will enhance clarity and improve consistency.Everyone attending this year’s Community Meeting was expecting a huge discussion of how “business as usual” or BAU was going to be integrated into PCI assessments. After all there is a page and a half dedicated to a discussion of the topic. There were a lot of disappointment when Bob Russo stated that BAU is just a recommendation or suggestion, not a requirement. But if you think about it, to test for BAU would drive up the assessment costs because testing would have to be performed over the assessment period such as sampling change requests, wireless testing, monitoring, logging, etc. That additional amount of testing would just not be acceptable to most organizations. However, it is mystifying as to why the PCI SSC then chose to bring the subject up if it’s not a requirement.
- Polling QuestionHave you started your PCI 3.0 planning efforts already?-Absolutely-Not Yet-2015 is a long ways away
- [CV]This will probably be the biggest challenge that organizations will face in getting to version 3. That is because it needs to be addressed immediately as there is no grace period until 2015.[JH] The biggest driver for this change is the fact that organizations are still struggling with defining the scope of their PCI assessment. With the publication of the Open PCI Scoping Toolkit, a lot of us thought this issue was finally behind us. However, this issue continues because most organizations have no idea how data, least of all SAD, traverses their networks. You ask the network engineers and they will tell you they are just a utility providing connectivity. You talk to the security folks and they respond that they just open and close ports based on change requests. You talk to the developers and they look like deer caught in headlights when you ask about what ports their application requires to work. As a result, there is no one that knows the answer to this key question which therefore makes defining what is in scope and not in scope a huge problem.To address this situation, version 3 is now going to require a data flow diagram that overlays on the network diagram. Given some of the network diagrams I have encountered over the years along with their corresponding data flow diagrams, I know that for some organizations, this will be a monumental task. One reason is that, for a lot of you, this will be the first time that you have gotten all of these parties together to create such a document. Another reason this will be a huge task is that the complexity of your network and application environments will not lend themselves to easily develop such a document.As a result, I expect to see sales in automated tools that map networks and simulate network traffic paths to become hot items as did security incident and event management systems did for complying with requirement 10.
- [CV] This requirement got a lot of discussion at the Community Meeting and for good reason. [JH] QSAs are now going to be required to obtain each user access role and make sure that a sample of users assigned that role do, in fact, deserve to have that role. The problem? User Access Roles have typically never been formally defined, in detail, in most organizations, so actual documentation is not readily available. This gets all the more complicated by the fact that this is not just end users, but also system administrators, network administrators and anyone else that has access to the cardholder data environment or CDE. To add insult to injury, this requirement has no grace period so you will need to get this documentation created as soon as possible to move to version 3.[CV] Discuss the retail findings of the Ponemon survey
- [CV] Here is another new requirement that needs to be implemented as soon as possible in order to move to version 3.[JH] The rationale behind this requirement is that a lot of organizations are still doing a poor job of managing their wireless networks and assets. Unlike wired networks, wireless networks are visible outside of an organization’s facilities and can be observed by anyone with a smartphone, tablet, PC and the right tools which are readily available. In addition, organizations are routinely providing their customers and visitors with access to wireless that is supposedly separate from the organization's internal wireless. The bottom line is that the risks related to wireless are too high and uncontrolled in too many instances.Where most of the discussion occurred on this requirement was around scope. “If wireless is out of scope, why is this not marked Not Applicable,” was the refrain most repeated. As with requirements 1.2.3 and 11.1, the PCI SSC has determined that this will be another requirement that cannot be marked Not Applicable. Your QSA will be required to document that an inventory of wireless access points is maintained and those access points have a business justification regardless of whether the wireless network is in or out of scope.For organizations that have invested in tools such as AirMagnet, AirDefense, AirWave and similar wireless network management tools, meeting this requirement will be straight forward. It’s just a report that needs to be run.However, for organizations that have not invested in such tools, this requirement has the potential of being a nightmare.
- [CV] Going right along with the theme started with wireless access points, here is another inventory item that will need to be immediately addressed as there is no grace period.[JH]Once the data flow diagram project is completed, you will need to follow that data flow and make sure that all of your category 1 and 2 devices are inventoried. For those of you that have not read the Open PCI Scoping Toolkit yet, category 1 devices are those that directly process, store or transmit SAD – essentially all devices that are in an organization's cardholder data environment. Category 2 devices are those devices that do not process, store or transmit SAD but have controlled access to and/or from the organization’s cardholder data environment. It is with category 2 devices where organizations struggle and why the data flow over the network is important as that should positively define those category 2 systems. My guess is that the data flow diagram process will generate a significant increase in category 2 devices. This is because a lot of devices that were believed to be out of scope will be shown to be in scope. This will result in projects to remove them from scope but those efforts will likely take time to complete let alone even if some of these new in scope devices can be removed from scope.This problem gets exacerbated due to virtualization. Organizations typically have a great handle on physical assets, but most IT organizations have poor control over virtual assets. As a result, generating an inventory of virtual devices will likely be daunting.
- [CV] Sensitive authentication data or SAD is replacing cardholder data as the “term du jour” in the DSS. SAD has always been in the PCI Glossary, but has never been widely used until now.The driver for the change is the change in tactics by attackers to going after SAD in the memory of terminals and computers. Threats such as BlackPOS and vSkimmer are fairly sophisticated tools. They have white lists of applications that they look for so that they do not have to scan all of memory for SAD. Once the SAD is found, the malware collects it for later retrieval either through file transfer via network or Bluetooth or transfer to USB stick.While the DSS adds 6.5.6 as a new requirement to address this threat, the tests seem to be rather lame. The PCI SSC stated at the Community Meeting that QSAs will be required to interview developers and ask them about what they do to protect SAD while in memory and then the QSA is to observe that this in fact is done. If you think about it, most merchants are running off the shelf software, so having a QSA assess this so far down the road is a little late in the game in my opinion.
- [CV] Here is a requirement that will probably takeorganizations a while to roll out which is why it does not go into effect until July 1, 2015.[JH] The driver behind this requirement is the tampering of card terminals be they separate or embedded such as at gas pumps. The threat is that an attacker swaps a good terminal with a doctored terminal. Terminals can be doctored crudely such as having a USB drive soldered into the terminal to sophisticated as with software modifications or even simply such as with an electronic logger plugged between the terminal and the network. Regardless of method, to anyone casually looking at the terminal, it will look normal. This swapping of terminals typically occurs during the retailer’s overnight shift when the store is being restocked and cleaned. The doctored terminals are brought into the facility surreptitiously and the good terminals and bad terminals are then similarly taken out. The information collected by the bad terminals is then removed and the process continues until discovered.In a widely reported breach from last year the terminals were replaced by unwitting employees. The attackers shipped the terminals to the retail outlets with a letter explaining that an existing terminal was generating errors and required replacement. The box, terminal and letter all appeared to be from the retailer’s legitimate terminal supplier and employees replaced a good terminal with a doctored terminal without questioning the replacement. Had any of the employees contacted their corporate help desk to confirm the terminal replacement, the scheme would have been uncovered.I am sure that there will be a lot of complaints from some merchants about this requirement. However, I can tell you from personal experience, that there are extremely large retailers with large installed bases of terminals that have implemented these controls to minimize the tampering to their terminals. And I can further confirm that compliance with these sorts of controls can be easily done daily, if not more often.I had a client with more than 400 locations and an average of 30 terminals per location is easily able to comply with this requirement today. Their terminals are all in locked cradles that swivel. All of the seams on the terminals are covered with a serialized security tape. On their gas pumps, they put serialized security tape over the connectors to the card reader on those pumps where there is access to the reader. All of the terminals are inventoried and the serialized tape numbers checked at every manager shift change which occurs three times per day. If any terminal is noted to be not in compliance such as tape is missing or loose, the terminal is taken out of service until it can be replaced with a known, good terminal.
- [CV]For organizations that are providing services to organizations that need to be PCI compliant, this is your trouble maker. The good news is that you have until July 1, 2015 to be compliant. The bad news is that you probably need to get started on this effort right now.[JH] The impetuous behind this requirement is there have been a number of breaches that were the result of service providers using the same credentials to gain remote access to the organization’s cardholder data environment. Once those common credentials became known out in public, it was a simple matter of identifying the organizations using the service provider and it was game over.This requirement is going to drive the sale of enterprise credential management solutions. I have a number of service provider clients that have implemented such solutions over the years and I can tell you that those implementations do not occur seamlessly. As a service provider, you need to anticipate service level agreement incidents as you implement your credential solutions. You will encounter lockouts from customer equipment and other issues that could put your SLA to the test.In addition to this, a new requirement has been added in 12.8.2 that requires service providers to acknowledge their responsibility to protect SAD for all of the organizations they provide services.
- [CV]This is possibly one of the most controversial changes that has been made. Never mind the fact that organizations have until July 1, 2015 to comply. However, for some, it may take that long to get things in place.[JH] Penetration testing is possibly one of the most contentious subjects in network security. The reasons are that there are a variety of ways to conduct a penetration test and there are so many security professionals that cannot distinguish a penetration test from a vulnerability scan. As a result, the PCI SSC decided with version 3 to assist everyone and dictate a series of requirements surround penetration testing and what they wanted to get out of the process. But while these requirements are fairly open ended and not restrictive, these new requirements have been seen by some as having gone too far and are too prescriptive.The key point of the change to 11.3 is the requirement to have a documented penetration testing methodology. This was probably one of the larger complaints because the Council used the NIST SP800-115 standard as their example. Repeatedly the members of the Council stated that NIST was not the only standard that could be used, but you could see that this was seen as the OWASP Top 10 argument with version 2 all over again. There are a number of open source and proprietary penetration testing methodologies available. All the Council is asking is that you pick one and implement it.Another key provision of 11.3 is that the penetration testing confirm that network segmentation is in fact in place and functioning as documented. No longer will organizations be allowed to tell their QSA that they have network segmentation and here are the configuration files to prove that fact. Now the penetration testing process will also be required to provide that proof.The final twist in the new requirement is that the penetration test must cover threats that the organization encountered during the last 12 months. Not only will the organization now have to track viruses, malware and other attacks that they encountered, they will have to test for them to show that these threats have been addressed. A lot of this information will be available in log data, but it will mean that someone will have to pull it together in a report.The bottom line in all of these changes to 11.3 is that organizations are finally going to have to have a true vulnerability management program in place.
- Polling QuestionWhich of the top 3 things do you feel are most important to being ready for PCI DSS 3.0?-Protect My Point-of-Sales Terminals (req 9.9)-Work Through Service Provider Credentials (req 8.5.1)-Implement a Pen Testing Methodology (req 11.3)-None of the Above