Boy! When topics come up, they come up often and consistently. Over the past couple of weeks the topic has been disaster recovery (DR) and its effect on PCI compliance.
The first thing that always seems to come up is in regards to where does the PCI DSS specify requirements for disaster recovery? Most people are confused because they cannot find those requirements. The reason people cannot find PCI requirements regarding disaster recovery is because there are none. The PCI DSS does not concern itself with disaster recovery. PCI does not concern itself with whether or not processes can be recovered, the PCI DSS only cares if sensitive authentication data (SAD) and cardholder data (CHD) are secured.
Which leads to the next question, “I have a hot/warm/cold DR site. Is it in-scope?” Well, as in the immortal words of the Council, “that all depends.”
In all but the most very rare of cases, if your production data center is in-scope, your hot site is also in-scope for PCI compliance. The reason is that there is already CHD stored in the hot site because it needs to take over immediately if the primary data center becomes inoperative.
Cold sites are never in-scope for PCI compliance. By their very definition, a cold site has no equipment other than electrical power, telecommunications terminations, empty racks, HVAC and physical security. As a result, there is no CHD or any other data storage/processing/transmission at a cold site.
Warm sites are always problematic. In almost all of these cases, it falls to the QSA/ISA to determine if SAD is processed or transmitted or CHD is stored, processed or transmitted using the warm site. And do not expect those data flow diagrams to necessarily point out that the warm site is in-scope. In most cases, the people working on PCI compliance have forgotten how DR processes work or even exist.
This can be trickier than you might think. The most common situation I encounter is where the people that set up the DR site/processes are no longer with the organization and the people left have no idea of what is stored/processed/transmitted at the warm site. DR is one of those areas where IT people on their way out of the organization seem to end up. And as soon as the DR plan is complete, out the door they go.
The next most common situation is data is being replicated SAN-to-SAN between data centers and there may even be servers there, but no production applications/processes are running. That SAN-to-SAN data replication was likely overlooked because it is done by the SANs and therefore the application and network people likely will not know/remember it is even happening. And it is always possible that SAD/CHD may or may not be at the warm site until it is used for production. I have encountered that situation in a few rare cases.
I have also encountered situations were organizations load balanced their networks using their warm site and had SAD and CHD flowing through the warm site to transaction gateways/processors unbeknownst to others in the organization.
As a result, it can take a significant amount of effort to determine if a warm site is in-scope for PCI compliance.
But there is an even more disconcerting issue regarding DR that people do not think about until it is too late. While the PCI DSS does not concern itself with DR, if production is moved to the DR site for any reason, that DR site immediately comes into PCI scope. There is no grace period. When you put production in the DR site, it immediately is in-scope. So if there are PCI compliance issues at the DR site, they must be remediated as soon as possible because the organization is no longer PCI compliant until they are fixed.
And that is the rub. DR sites typically are not assessed for PCI compliance because they are out of scope because there is no SAD/CHD there. And people are vehement in their arguing about scope because assessing a DR site obviously adds to costs and time. Yet if the DR site is ever invoked, the DR site is immediately in-scope. This is why I tell my clients to assess their DR site(s) periodically for PCI compliance so they have as few surprises as possible should the DR site get used. Particularly if there are changes to their DR site or they move to a new DR site.
So there you have it. DR and PCI in a nutshell.
PCI Guru 
This is similar to something I was considering recently.
Why aren’t development resources more in scope? We saw with OpenSSL and a Linux distro (it was Debian/Ubuntu I think?) that this is definitely a way in and is perhaps the most catastrophic. Obviously you have to draw the line somewhere but with so many companies relying on constantly attacked services like GitHub it seems like an oversight. Add in the increasing prevalence of immutable servers and often the dev machines are the only reliable way in.
Side note: why did the council take so long to recognise virtualised machines and why don’t they encourage stuff like immutable servers? Things like virtualisation and A-EP (the only benefit of which over A is anti-XSS – a problem that was already mostly solved) really make me think that the council is 5-10 years behind the times.
Old fashioned note: recently I couldn’t even find what P level is required for paper shredders?
I have a real problem with “why did the Council take so long to recognize virtualised machines”. Virtualization has always been considered under the PCI DSS, but explicitly since v2. That said, the only thing different that virtualization brings to the table is the hypervisor. The rest is covered by the secure OS configurations in the VMs being run.
Have you read A-EP because your comment makes no sense (“the only benefit of which over A is anti-XSS”)? A-EP requires vulnerability scanning, penetration testing and a whole host of other requirements well beyond XSS which you point out. SAQ A is the bare minimum and requires little more that policies, standards and procedures, physical security and end user management.
Paper shredders are required to meet DoD standard 5220.22-M.
The services you quote should be covered under the third party coverage of requirement 12.8. The problem with Github and the like is that they are not independently PCI validated which means that the merchant or service provider are responsible for assessing them or developing the requisite compensating controls.
Remember the fuss over whether virtualisation counted as separation of duties or not? Some basic fundamentals can be very different with virtualisation and need to be explicit, e.g. ever tried to license something per CPU for use in the cloud?
Sorry, I meant D. I was thinking of the businesses that got kicked off A who would have gone to D but ended up on A-EP. I know you already agree that iframes aren’t as secure as some make them to be so I don’t think we actually have any disagreement here. One thing A-EP does have over D is that it does help to protect users of older browsers such as IE8 but since they don’t support TLS1.1+ they don’t matter anymore anyway.
5220.22-M says that all new shredders must be from NSA’s EPL. The shredders on the EPL all seem to be US only models. What would you need outside of the US?
12.8 will apply in some areas but I’m thinking more about the whole pipeline rather than specific services. I’m thinking the ecosystem of continuous building, continuous testing, and sometimes even continuous deployment, often spread out over a combination of self hosted and third party services. The reason I bring this up as a comment on disaster recovery is that in a cloud setup firing this pipeline is your disaster recovery. 6.6 should cover these problems except the solutions involved in 6.6 are part of the pipeline.
The specification for NSA compliance is a shredder that produces a 1/32″ x 1/2″ (0.79mm x 12.7mm) piece of paper.
Sorry, but I do not recall any discussion of separation of duties and virtualization because virtualization has nothing to do with separation of duties. Separation of duties is all about people not being able to totally complete a task such as creating checks and also signing them. In the IT world, improper separation of duties would be configuring an operating system and then reviewing the configuration against the configuration standard and signing off that the configuration complies with the standard.
I think what you are talking about is the argument regarding whether or not in-scope VMs could coexist in the same hypervisor farm as not in scope VMs, i.e., does such a configuration meet segmentation and the “one server/one service” rules.
I can’t read my previous comment at this time but I’m pretty sure I got that turned around too. Basically in the original comment it should say the only benefit of A over A-EP is anti-XSS.
Turn things around – the “benefit” is not added security procedures but reduced attack surface.
What makes a solution go from D to A-EP? Using direct post i.e. not touching card data.
What makes a solution go from A-EP to A? Using an iframe i.e. not being vulnerable to (invisible) XSS.
XSS is still a problem but the XSS auditors in modern browsers are decent and it’s not the wild west days of 5+ years ago. If XSS is such a big concern to the council that it essentially requires its own level then why was A-EP so late?
(Yeah I know the draft A-EP originally included iframes.)
If cross site scripting (XSS) was no longer an issue, I would agree with you. But you read the Verizon, Symantec, etc. breach reports, and at the top of all of their lists is (wait for it) – XSS.
What allows a merchant to use SAQ A-EP is that they are eCommerce only with no other payment channels but are not using a redirect or iFrame to conduct those online payments. Visa produced a great table that explained this. See my post on SAQ A versus SAQ A-EP for that table.
To be clear. I am not a fan of allowing merchants to use SAQ A when their Web site is using a redirect or iFrame. In my very humble opinion, they need some additional security such as quarterly vulnerability scanning, annual penetration testing, log monitoring and critical file monitoring, at a minimum, to protect their Web site.
This mix of trust is an issue but it was the sharing of duties that I remember being the main concern. It is addressed in the supplement from the time: https://www.pcisecuritystandards.org/documents/Virtualization_InfoSupp_v2.pdf
The shredding sizes you mentioned are only for existing shredders. Here’s the quote from the NISP:
> Crosscut shredders currently in use capable of
> maintaining a shred size not exceeding 1/32 inch in
> width (with a 1/64 inch tolerance by 1/2 inch in length)
> may continue to be used. However, any crosscut
> shredders requiring replacement of the unit and/or
> rebuilding of the shredder blades assembly must be
> replaced by a crosscut shredder on the latest NSA
> Evaluated Products List of High Security Crosscut
> Shredders.
1/32 inch x 1/2 inch = 0.8mm x 12.7mm = 10.16mm² = equivalent to the European DIN level P-5. If you look at the specs of machines on the current NSA EPL they all seem to be P-7 equivalent which is <=5mm² (don't be confused if the spec sheets say level 6 as level 6 was renamed to 7 a while back, instead merely look at the size of the particles).
Without disclosure of how a breach was achieved, breach reports are not much more than marketing material.
Listing XSS as high occurrence doesn't really mean much in terms of how payment solutions should be rated. I could use an XSS attack to spear phish a staff member's cookies or submit CSRF requests which could then give me access to modify the checkout templates. This would be reported as an XSS attack but an iframe on the payment page would do nothing to defend against it as the breach was elsewhere.
All an iframe does is prevent XSS attacks directly on the payment page but even your typical reflected / non-persistent XSS attack isn't much of a problem on a payment page. On an ecommerce site customers don't usually land on the payment page and buy right there, they browse around, fill up their basket, and go through a multi step checkout process. Non-persistent XSS attacks can't survive this. Non-persistent XSS would be a problem on a single page donation site type thing but they nearly always use PayPal.
What could be used against an iframe is a persistent XSS attack. Persistent XSS usually gets in through user generated content like blog comments and I don't see a reason why checkout pages would contain user generated content unless the designers are insane. To pull off a persistent XSS attack what you'd probably do is put the XSS in a product review, wait for staff to view that review, hijack their sessions, and modify the payment page.
An added bonus to this situation would be “significant change”: If the DR site was not included during the annual PCI assessment and then gets activated and CHD starts flowing through it, that would be considered a “significant change” to the card data environment and trigger all the requirements that have “significant change” in the wording?
So on top of dealing with the original disaster and in the middle of trying to ensure the company can continue to survive you now are supposed to find the time and resources to VA scan, pentest and run a risk assessment of the your “new” environment.
Exactly. You get a “Fire Drill” in addition to the “Fire Drill” you are running to recover.
Good information and points I’ve been making for years. Yet I see people argue that DR is out of scope (for 1 or multiple reasons) only to discover they transfer operations to the DR site annually to verify it’s operational.
SIGH, you just can’t have it both ways.
No you cannot have it both ways. But people still want their cake and to eat it too.
In my particular case I can’t seem to get a straight answer from anyone about what is/isn’t stored or transmitted to the DR site.
Common problem and why whether a DR site is in scope can be so difficult to determine.
The closest they get to DR stuff is with PCI DSS Requirement 12.10.1…”Business recovery and continuity procedures” and “Data backup processes.”