Category: PCI

To this day, people are surprised when an organisation is breached after having achieved PCI compliance.

Why?

The SSC has never claimed that PCI compliance ensured the protection of cardholder data, especially when you consider most organisations don’t DO PCI compliance for security, they do it to get their acquiring banks off their backs. All the SSC have ever claimed is that it helps, and it does.

Security is not about being impenetrable, that’s impossible, it’s about knowing your two main enemies; thieves and ignorance.

Thieves are lazy. In fact, I’d go as far as to say that laziness, more than a desire to be bad, is the leading driver behind computer crime. This drives them to steal first what is most easily available; the so called low hanging fruit. So to avoid thieves, just have YOUR fruit higher up the tree. That’s what PCI compliance does, and that’s all.

Continue reading “Stop Confusing PCI Compliance With Actual Security” →

Truth be told, this post could be titled; ‘The Top Roadblock to Compliance, and The Other 9 That Result From It”, but per the excellent advice from a blogger far better than I “You can’t [stop readers cold] if you use cute, clever or confusing headlines.” I’m keeping it simple.

So what is this offending roadblock?

1. Lack of Management Buy-In

Sounds simple, in fact, it sounds like a cliche, and above all, it does not sound anywhere near as important as I’m making it out to be. But let me ask you this; If your manager doesn’t care about something, how much do YOU care about it?

Now extrapolate that from the CEO all the way down and you get something like this;

Management

If the CEO makes it clear that they don’t care about PCI, how much traction do you think achieving compliance is going to get? The project gets handed to the IT Manager (because it’s clearly an IT problem not a business one, right?), and PCI will receive no attention, very limited budget, and no respect.

That is, until they get breached and fined for the equivalent of gross negligence, and then the IT Manager gets blamed for slacking. Sounds familiar?

The CEO, as well as senior management, control the culture, and that culture had better include the importance of cybersecurity.

Let’s be very clear; The CEO sets the tone for the entire company; its vision, its values, its direction, and its priorities. If the organisation fails to achieve PCI compliance, it’s the CEOs fault, and no-one else’s.

And now for the other 9…

2. No Perceived Return on Investment (ROI)

While very closely tied to the 1st reason, this is distinct because it’s clear that few have accepted that there are actually benefits of PCI compliance (see Why PCI Isn’t ALL Bad). So even if the CEO does pretend to care, few will get behind the process in any meaningful way. Nor will they bother trying to fit PCI into their existing security program, which is the only way it makes sense.

3. No Dedicated PCI Project Manager

PCI compliance, like all security, is eventually a process, but achieving it for the first time should be a project with a dedicated internal resource. Ideally, that resource has nothing else to do except PCI, but that’s rarely practical. So until compliance is achieved, they will need considerable support from management, and some of their more mundane duties re-distributed.

4. Choosing the Wrong QSA 

Per my white paper on Selecting the Right QSA for Your Business, the choice of an assessor is extremely important. The right one can help you deal with almost all of these roadblocks, the wrong QSA may be the roadblock. It’s probably in your best interests to bring a security expert in first to prepare your security program and infrastructure for the QSAs visit. At the same time helping you to make not only PCI, but your entire security programme sustainable – and just as importantly – cost effective. And above all, appropriate to the value of the data to your business.

5. Thinking Policies & Procedures are Just Paperwork

Odd as it sounds, without solid documented and enforced policies, standards and procedures (Policy Set), there is no real way you can have the culture of security necessary to achieve the company wide backing necessary to run an effective PCI project. The Policy Set is a corner-stone of your security program and should received its due.

6. No Standardisation

This is a very broad subject, and includes configuration standards, change control, monitoring, patch management, the SDLC, vulnerability management etc. The PCI DSS allows sampling of systems during validation, but this must be earned. Without standardisation, there can be no sampling as there are no systems created and maintained identically.

7. No Centralisation

How organisations manage often hundreds of devices without some form of centralised management is beyond me. I have to assume it’s not done well. The QSA also has a very hard time granting the privilege of sampling if you cannot show centrally HOW you keep the systems the same. There are plenty of tools out there, and the benefits of them go way beyond PCI compliance.

8. Not Knowing Where to Start

At first this may seem obvious, and perhaps a little redundant, but bear with me. I have had a lot of experience with this little roadblock, so I know just how difficult it can be to overcome. The answer – as it was for me – is simple; Ask someone. Your QSA should be able to take you all the way through this process relatively seamlessly, but if you don’t have one yet, ask someone who has already achieved compliance for their organisation. I personally know dozens of people who are more than happy to spend time with PCI novices and share their experience and guidance. This is one of the easiest roadblocks to overcome if you keep your ego or shyness out of play.

9. “But we’ve always done it this way!”

Perhaps the most irritating phrase in the English language – with the possible exception of “What are you thinking?”, especially for a consultant. The business wants things to stay the same, they want the same access they’ve always had, and they want the same data. The fact remains that the vast majority of business processes have very short shelf-lives, so they should be reviewed regularly, and access to in-scope systems or data justified. I’ve found that adding PCI compliance expenses to their cost centres tends to get their attention.

10. No Budget

Not much you can do about this one, but it’s certainly worth trying to re-iterate that the security controls should be in place anyway, and that they fall firmly in the good practices introduced in my The 6 Security Core Concepts.

I didn’t know how to blog until I asked my wife, and I have no idea how to read legal-ese so I ask my Sister. If you want to be PCI complaint, or even better, be secure AND PCI compliant, ask someone who’s done it.

[If you liked this article, please share! Want more like it, subscribe!]

As you probably know, the PCI DSS is a minimum set of security controls that must be in place around anything that transmits, stores, or processes cardholder data. That’s probably why the card brands and the SSC get so irritated that even this basic set of good practices is so hard to achieve.

That said, unless you have a way of monitoring and maintaining your compliance within these baselines, it’s not only VERY difficult to stay compliant (let alone secure), it makes validation of your compliance an annual nightmare of gathering screenshots, log samples, and so on. I estimated that validation of controls can take up to 50% of the entire annual assessment cycle.

This is a tremendous loss of resource time, and does nothing for your ROI. So why DOES the PCI DSS only require an annual point-in-time validation and not validation of continuous compliance? Yes, you are accountable to stay compliant at all times, but you only have to validate it once a year, and – if you’ve earned it – on only a sample of your systems.

The answer is, they simply cannot go that far. Continuous compliance validation is far more difficult than achieving PCI compliance, and is firmly in the realms of good security practices. They can enforce minimums, they cannot enforce more than that and get the necessary acceptance.

So what IS Continuous Compliance Validation? “It is the near real-time notification of a variation from your baseline norms.” Or to put it another way; once you know what something should look like all day every day, you want to know if it changes from that.

For example, the PCI DSS specifies over 20 validation points for an operating system; e.g. business justification for all listening ports; access control; logging; FIM and so on. Once a year, you have to show your assessor that these validation points meet the DSS requirements, and that’s it for the YEAR! All too often, systems fall out of compliance within a matter of days.

Instead, what I propose, is that you should automate (as much as possible) the collection of that validation data, and compare it to not only the PCI DSS requirement minimums, but to ALL of your compliance / regulation / internal policies / standards. And not yearly, but hourly, daily, weekly, whatever makes sense. Wouldn’t you rather show your assessor a green checkmark for ALL of your systems than a dozen screenshots for a mere sample?

If this can be configured for just 50% of your in-scope devices, your entire annual validation burden will be enormously reduced. Plus, you also have a very convincing addition to your compensating controls for lack of FIM or AV (if applicable).

Best of all, you are now doing security as it was meant to be done; Enterprise wide, and Business As Usual.

Any operating system experts out there want to help me put this together?

[If you liked this article, please share! Want more like it, subscribe!]

If you came this far you did one of the following when you read the title:

1. Scoffed;

2. Screwed up your forehead in confusion, or;

3. Laughed.

Good, these all mean you’re cynical and therefore a perfect audience, so let me put you out of your misery; this is a story of unintentional cause and effect, and has started a trend that will not stop until credit cards as we know them are dead and buried.

About time too. 60+ year old technology in payments is akin to leaches in medicine (no offence card brands, but this analogy is particularly relevant).

When PCI was first drafted, it was very clear for whom it was geared; e-commerce organisations running Windows. How do you translate the configuration standard requirements (for example) to someone working on a mainframe. For Windows, you take out what you don’t need (hardening), for zOS, you build in only what you need. What about logging? Can syslog record everything you need in 10.2.X?

This is one of the most minor issues that drove organisations to seek alternatives to compliance, cost / effort / ROI, you name it, PCI is a burden any way you look at it. Yes, cardholder data should be protected, but enforcement of a single standard across all industry sectors and business types was never going to work.

At first, organisations became VERY creative in making their PCI burden go away. From outsourcing, to revamping all business processes in favour of truncated card numbers (except authorisation of course), to going back to cash only (not kidding). While almost EVERY merchant organisation should consider the first 2 anyway, it really didn’t help either retail, or e-commerce.

So the first foray into a technical ‘innovation’ was to make PCI go away for areas where they could not fix their systems to a degree that supported PCI compliance. Organisations started looking for alternatives to processing the full cardholder data; tokenisation was born (poetic licence, we’ve had forms of tokenisation for centuries). But this does nothing for authentication traffic which requires the fill account number.

Then came my personal favourite; Point to Point Encryption (P2PE), a.k.a. – and before the SSC decided to kibosh it – End to End Encryption (E2EE). The theory is very sound; encrypt the data for the point of interaction (usually a Pin Entry Device, or PED) all the way to the point of decryption, but the eventual PCI-approved solution is as complex as the DSS, limited (currently) to approved hardware devices, and requires a degree of certification few have even looked at.

A lot of organisations put their entire PCI programme on hold until such times as the P2PE standards were defined, and now that the first one (hardware/hardware) cannot apply to them, they continue to do nothing until such times as a hybrid standard is released.

So what you have here is; PCI forced the innovation, which in turn caused a justifiable delay in doing anything at all, which means that cardholder data is no better protected. Brilliant.

So P2PE, which had so much promise, is now stagnant. Organisations SHOULD have developed software solutions for legacy PEDs 3 years ago, which would have almost forced acceptance. But no-one did, and now it’s too late. How do you standardise a P2PE solution for an infinite number of scenarios? You don’t obviously, but with the advent of the next innovation, even PEDs themselves are becoming redundant…

We have the ultimate PCI and card brand killer; Mobile Applications / Mobile Payments. Still fairly new, growing exponentially – and to add the ultimate piece of irony – but cannot be PCI complaint unless the device was built for purpose. In other words, smart phones and tablets, by themselves, can never be PCI compliant. Not that this will stop their use.

Mobile payments, in all its forms, is already forcing the CARD BRANDS to innovate, or in the case of Visa, buy interest in vendors like The Square. But the SSC, as a standards only body, can never keep up. Eventually, as credit card numbers decline, so will the SSC and ALL it’s standards, and a replacement will be formed when people realise this massive drive for innovation has set us BACK in security…again.

That’s my final point of this blog; unless security is built in from the ground floor of this wave of innovation, the innovators will be directly responsible for the impossible-to-follow standards of the future.

As long as there are profit drivers, and Windows OS, I will always have a job…

 

Anyone who’s worked in PCI for more than 5 minutes knows it has serious limitations with regard security. Even security of cardholder data, which is the only type of date to which it relates!

That’s because PCI DSS was not written with comprehensive security in mind, or would not start and end where it does.  It was designed to be security-enough to keep the US Federal Government off Visa/MC/Amex/et al backs.  You would not be surprised to hear that things like this generally happen when someone important is inconvenienced.  In this case, a couple of senators were the victims of credit card breach.

Good security never ends, but it almost always starts with a business need, followed by a Risk Assessment.  The end of a security life cycle instance is when the business continuity plan has been updated, and security processes become business as usual.  PCI builds in the Risk Assessment (that’s what the 260-odd controls are), does not allow for residual risk, and stops at Incident Response.

In other words, and if you take the PCI DSS to the negative extreme, neither the card brands nor the SSC care if compliance fits your business needs, nor does it care if you even stay in business (as long as the cardholder data is safe).

Clearly this is not the case, they do care (to a point), but the issue is that the majority of organisations working towards compliance either do not care about security themselves (it’s just another cost of doing business), or they do care and just don’t know how to go about it.

So where is the good in PCI?  It’s twofold (for the purposes of this post);

1. It has significantly raised the profile of security in general as a business necessity, and;

2. It has driven innovation to an amazing degree into a SIXTY+ year old payment technology …the credit card number (blog pending on this).

OK, so the PCI DSS is limited, but at least they did what NO-ONE has done before, or since; actually defined what they consider to be a minimum standard of data protection.  Every other standard says things like ‘appropriate’, or ‘reasonable’.  Appropriate and reasonable to whom?  The PCI DSS says you must have a firewall capable of stateful packet inspection, you must have up to date configuration standards, encryption, logging, POLICIES and so on.  The way to compliance is WRITTEN DOWN FOR YOU!

Of course, it’s not that easy, and the confusion is where to start, and how to implement compliance in a way that suits the business, not the other way around.  A good QSA can help (White Paper:  Selecting the Right QSA), but the assessment process starts with the CEO and a culture of security.

The PCI DSS has, and continues to change the security climate for the better, all you need is the right perspective, and the right guidance.