Tag: PCI

There are 2 types of Qualified Security Assessor (QSA):  The ‘also-QSA’, who was a security consultant long before PCI, and had performed much of the work as detailed in the Security Core Concept blogs.

Then there are the ‘just-QSAs’ who managed to read a book, pass the CISA/CISM/CISSP exam, and qualify for the ever-so-difficult QSA training. They have delivered nothing but PCI ever since.

In case it’s unclear; first one good, second one bad.

Well, bad for you if you’re one of the ‘justs’, and bad for your clients if you’re all they have to rely on.  You won’t learn how to do security properly, or be able to provide consulting services regardless of the data type, compliance regime, or industry sector. Your clients will never get anything other than tick-in-the-box compliance.

PCI has a shelf life, and I imagine that at the current rate of payments innovation, you have only a few years to diversify. After that there is no way you will be able to maintain your current compensation package. Without some significant experience in non-PCI security areas, your usefulness is limited.

Progress will be difficult if you work for a ‘just-QSA-Company’, because you HAVE nothing else to do. You may want to seriously consider working for a security company that’s in the ‘also’ category.  There are many.

You probably have a training budget too, so spend it.  ISO Lead Auditor, CIPP/X, CLAS (UK), ITIL, Prince II, while not all security specific, are most certainly relevant. Relevant to providing the kind of  guidance that is in depressingly short supply.  If you can use this training to your current company’s benefit, great. If you can help them design non-PCI services, you are way ahead of the game.

However, there is a better than average chance that your career preferences will fall more on one side or the other of ‘business-focused’, or ‘technical-focused’. It’s important therefore that you NOT try to embrace all 6 core concepts at once.  Even security experts need to specialise.

What we are all working towards is an understanding that IT and IT security are business enablers, not a roadblock. PCI is ‘just an expense, with limited to no return on investment’, or at least thats how it is mostly seen.  Our job is to put security into a business context so that the benefits are clear to every level of the organisation.

The CEO cares about the bottom line, s/he does not care about the detail until that detail gets in the WAY of business.  This is why there is so little management buy-in when it comes to security and compliance.  If we can show that a well run IT infrastructure enables business transformation, innovation, enhanced efficiency and so on, we’ll have demonstrated our worth.

THAT’S our job, not just protecting credit card data with a minimal set of security controls to which you had no input.

The fundamentals of security have never changed, and won’t any time soon. So if you take the time to get back to basics, you’ll future-proof your career.

Security is simple, it’s not easy, but it is simple.

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…