PCI to GDPR

Going From PCI to GDPR? You Are Starting from Square One

To be very clear from the outset, if you think the PCI DSS is a good ‘stepping stone’ to GDPR, you need to do a lot more homework. Data security represents less than 5% of the entire GDPR, and the PCI DSS is – in my admittedly biased estimation – no more than 33% of a true security program.

I have, for years, railed against the PCI DSS as an inadequate baseline for security, and even the card brands and the SSC have never claimed it be more than what it is; a set of MINIMUM security control related to the protection of cardholder data. Well, except for this ill-advised and rather naive quote perhaps;

People come to me and say, ‘How do I achieve GDPR compliance?’… Start with PCI DSS.

The PCI DSS was written for ONE very specific purpose, and it’s only ego, desperation, or vested interest that would lead people to think it’s anything more.

The reason for this particular blog is reading articles like the two samples below. It’s articles like these that lead organisations who don’t know better [yet] into making bad decisions. They also give cybersecurity professionals a bad name. Well, worse name, unscrupulous QSA companies and greedy product vendors have already caused significant damage.

Article 1, and by far the most egregiously overstated quote [so far] is from an article in SecurityWeek (PCI 3.2 Compliant Organizations Are Likely GDPR Compliant); “Any company that fully and successfully implements PCI DSS 3.2 is likely to be fully GDPR compliant — it’s a case of buy one and get one free.” Given the author’s apparent credentials, he should know better. Since when does the PCI DSS deal with explicit consent, or children’s data, or the right to erasure/correction/objection/portability and so on.

Then, in the very recent article 2; How the PCI DSS can help you meet the requirements of the GDPR – the author states that; “Failure to report breaches attracts fines of up to €10 million or 2% of annual turnover, whichever is higher. Breaches or failure to uphold the sixth data protection principle (maintaining confidentiality and integrity of personal data) can attract fines of up to €20 million or 4% of annual turnover (whichever is higher).

No part of the above statement is factually correct:

  1. Just because Article 33 – Notification of a personal data breach to the supervisory authority is included in Article 83(4)(a) – General conditions for imposing administrative fines, it does NOT mean that failure to respond in 72 hours will attract a fine. There are many caveats; e.g. Recital 85 states ; “the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it (Recital 85)”‘
  2. sixth data protection principle“? – Nothing to do with confidentiality and integrity, assume author meant the seventh principle (security).
  3. Maximum fines for data breaches are 2% (for an undertaking, a.k.a. a group of companies), not 4%.

The author then goes on to say; “The ICO is also likely to treat inadequate or non-implementation of the PCI DSS as a failure to implement appropriate “technical and organisational measures” to protect personal data…” which is clearly not the case. The ICO has always left loss of cardholder data / PCI up to the card schemes, and have already mentioned ISO 27001 in their “The Guide to Data Protection“.

Every article I have read on how PCI helps with GDPR, is at best, hugely overstated, and at worst, full of self-serving lies. I can fully appreciate the desire for cybersecurity companies (especially QSAs) to branch out from the massively price compressed and ultimately doomed PCI space, but to do so in this manner is unconscionable.

Unfortunately if you are falling for this advice, I can safely assume that you:

  1. have little idea of how limited the PCI DSS is, even as protection for the only form of data to which it’s relevant;
  2. have little idea what the GDPR is trying to achieve if you think a bunch of security controls are that significant a component; and
  3. don’t actually know what an ‘appropriate’ security program should look like.

This is actually not meant as a criticism, these things may not be your job, but if you have any responsibility for GDPR, you absolutely must learn to ask the right questions.  I will finish with some reasoning below, but leave to up to you work out whose guidance to take.

PCI and GDPR are very far removed from each other.

  1. Data protection Articles are only 3.34% of the Regulation – yes, I actually worked this out on a spreadsheet. That means the GDPR is 96.66% NOT security control relevant. Of course IT and IT security are important and intrinsic to GDPR, but PCI does not cover anything else other than than those things.;
    o
  2. PCI DSS makes no mention of the need for Governance – PCI compliance is almost invariably an IT project, and while this is obviously wrong, does not prevent organisations from achieving compliance. In GDPR, the IT folks have absolutely no idea where to start. Nor should they, IT/IS people aren’t lawyers and they do not control the organisation’s direction, they are business enablers who do as bid by senior management. GDPR requires a team effort from every department, which is exactly what Governance is.;
    o
  3. PCI DSS is about compliance to an already defined standard of security controls, the GDPR requires a demonstration of ‘appropriate security’ measures – For example, what if your annual risk assessment showed that the PCI controls were actually excessive? Could you scale some of them back? No, you can’t. Alternatively, what if your risk assessment showed that they weren’t enough, could your QSA insist that you went above and beyond? Again, no, so what the hell is the point of the risk assessment in PCI?
    o
  4. Only QSAs that started out as security consultants [not the other way around] have the skill-set to provide any help at all. If they were experts in ISO 27001, CoBIT, NIST etc., then yes, they can help you both define and implement ‘appropriate security’. If all they did was pass the QSA exam, the only guarantee you have is that they can read.
    o
  5. The PCI DSS can never keep pace with the threat landscape – It’s already way behind, and with its complete inability to change significantly, the DSS can never represent appropriate security. If the DSS did change significantly, both the card brands and the SSC would be lynched. Millions of organisations have spent BILLIONS on PCI, they will simply refuse to start all over again. GDPR on the other hand has no defined controls, it’s up to YOU to show that your controls meet the measured risk.

In the end, the only way PCI can help with GDPR is to use the assigned budget to do security properly. You will never reach GDPR ‘compliance‘ using PCI, but you will achieve both PCI and GDPR compliance on the way to real security.

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

GDPR

GDPR: Focus on the WHY First, Not the HOW

By far the most common answers to the questions; “Are you worried about GDPR?” and “If yes, why?”, are, in this order:

  1. The fines;
  2. Possible loss of reputation;
  3. What’s GDPR again? (no, unfortunately I’m not joking)
  4. The cost / complexity; and
  5. Board-level accountability (a.k.a. it’s a law now).

While from a business perspective I can empathise with most of these, I have zero empathy for 3. That’s not really the point though, which is that not one person I have ever spoken to about GDPR got anywhere near touching on the actual reason GDPR is here in the first place;

It protects a human right.o.

If you haven’t read the Universal Declaration of Human Rights, and surprisingly few seem to have done so, it forms what I will call a code of conduct for what the United Nations calls the ‘human family’. So while it’s not a global law (per se), and somewhat impractical taken in its entirety, you have to be something of a sociopath not to recognise its basic goodness. It just fits. For example, and most relevant to this blog:

UDHR Article 12

“No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.”

Fair enough, right?

Therefore, the GDPR starts out of the gate with:

GDPR Recital 1

The protection of natural persons in relation to the processing of personal data is a fundamental right. Article 8(1) of the Charter of Fundamental Rights of the European Union (the ‘Charter’) and Article 16(1) of the Treaty on the Functioning of the European Union (TFEU) provide that everyone has the right to the protection of personal data concerning him or her.

And while the GDPR does go on to say things like; “The right to the protection of personal data is not an absolute right because it must be considered in relation to its function in society and be balanced against other fundamental rights... (Recital 4)”, it’s meaning and intent remain both clear and unwavering.

So if you want to know why fines are in place, why loss of reputation is such a big deal, and why infringements will be breaking the law, look no further. Compliance should go way beyond being just another consideration in your effort to demonstrate corporate social responsibility. This is not just some PR exercise you can fake your way through.

On the other hand, why is this so one sided against businesses? Why do they have to do all the work? I have made no secret of my disdain for people who don’t take responsibility for their own lives and actions. People who blame retailers for using personal data in ways they resent when they were the ones who gave it away without question. Even people who blame criminals for stealing their identity when it’s the victim themselves who made it possible by posting their entire life on social media.

When was the last time you read Google’s T&Cs? Or iTunes? Or anyones? No, I haven’t either.

I have long contended that your privacy is a currency that you spend for the conveniences you crave. GDPR is there to make the risks of spending it far more transparent. Or as Angela Boswell (a privacy lawyer, DPO, and GDPR implementation lead for her organisation) puts it; “What GDPR intends is to put the choice of ‘if’ and ‘to what extent’ back in the hands of the data subject.

So while organisations will have a lot more responsibility moving forward, you should still do your homework before sharing personal data.

But in the end, the main reasons it’s the businesses who are now [mostly] responsible for protecting people from themselves are clear. For years, many businesses who should have been guarding your privacy, weren’t. And those businesses who were supposed to protect the data they had, weren’t. Not even close. This will all change under GDPR.

In theory however, the businesses who were already doing the right thing are [for all intents and purposes] GDPR compliant, it’s only those described in the paragraph above who now have a really tough time ahead. GDPR is and extension of, and replaces the Data Protection Directive (Directive 95/46/EC) which has been out for 22 years! You really should not be starting from scratch here.

Depending on your business, GDPR might get tricky as you progress through it, but every organisation starts out the exact same way: By mapping your business processes (at both the individual asset and ‘asset interdependency’ level). This does not require a lawyer, and isn’t something you should not already be doing. If you don’t even have this in place, you will likely never be able to demonstrate the appropriateness of the ‘extent and proportionality’ of your data processing should things go wrong.

If I was a supervisory authority (e.g. the ICO here in the UK) I would reserve my biggest penalties not for those who aren’t compliant, or even necessarily those guilty of a minor infringement, it would be for those who have done nothing.

If that’s you, you’ve already wasted ~13 months of the 2 year run-up to GDPR’s application. There will be no ‘grace period’ after May 25th 2018, you’re IN the final stage. So you only have ~11 months left before the penalties can be applied. You must start asking the right questions of the right people now, and if you don’t know what and who they are, I suggest that’s where you start.

This is very basic, but it’s a beginning; Preparing for the General Data Protection Regulation (GDPR) 12 Steps to Take Now

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

 

GDPR: Get Your Priorities Straight

GDPR: Forget the Damned Fines, Worry About Staying in Business!

How many ‘news’ articles / blogs / ads have you seen with titles like; “You could be fined up to 4% of your global revenue under GDPR!”  a.k.a “Be afraid and give us lots of money you clueless sap.

I’m seeing it from every online cybersecurity publication, lawyers, cybersecurity vendors / consultants, and increasingly from cyber insurance vendors. I’m even getting spammed from people I KNOW!

It’s more than a little irritating …frankly, it borders on unprofessional.

I can understand lawyers jumping on the bandwagon. The GDPR was written by lawyers, and if you don’t get a lawyer’s input to how GDPR will affect your business, you deserve a 4% fine. Yes, privacy lawyers are expensive, and yes, it’s bloody annoying to spend this money on something that adds absolutely nothing to the bottom line, but do it anyway. At the very least, piggy-back of a business partner that has spoken to a lawyer!

And no, asking your contacts on LinkedIn is not the same thing.

For cyber insurance vendors, I can fully appreciated how tough it’s been to find something to pin a marketing budgets on. Ambivalence towards cybersecurity is legendary. But what I cannot condone is using GDPR’s fine structure to scare organisations into buying a policy that will likely be completely inappropriate. Even choosing the right cyber insurance requires significant due diligence.

As for cybersecurity vendors, I’ve already addressed/redressed them in GDPR and Cybersecurity, a Very Limited Partnership. They simply have no right to bring up a 4% fine in a sales pitch when the maximum fine for data breach is 2%, not 4.

There is a lot more than fines in the GDPR of which you should be aware, but first…

About the Fines…

…borrowing heavily from my previous blog;

It can be assumed that if the maximum fine for ANY infringement, no matter how egregious, is 4% of the annual revenue from the previous year (in the case of an undertaking). That 4% is what the EU considers the maximum for a fine to qualify as “effective, proportionate and dissuasive” (per Article 83(1)). Therefore, a fine of €20,000,000 (for example) would be reserved for any organisation with revenue over €1,000,000,000 annually. Yes, that’s 1 BILLION.

It must follow that if 4% is the maximum, then fines will go down the less egregious the offence. Everything you need to determine the level of ‘egregiousness’ is contained in the 11 lines of Article 83(2)(a) – (k). Words like ‘intentional’, ‘negligent’, ‘degree’, and ‘manner’ are bandied around, all of which can be answered by you.

In this spreadsheet, I have taken a stab at adding specific questions to each of the (a) – (k) line items. Answer them all truthfully and you’ll get an indication of what I consider to be an appropriate fine based on your annual revenue: GDPR Fine Worksheet. Note: This is based on data breaches only (2% fine structure), and is not based on anything resembling known fact or precedent.

Frankly, it’s not the fines you should be worrying about, as I get the feeling you have to REALLY screw up before they’ll even be considered in the first place.

Worry about the ‘Corrective Powers’

What no-one seems to be writing about are the other so-called ‘corrective powers’ as detailed in Article 58(2) that each member state’s supervisory body will wield. Some of these are far worse than fines, and from what I know of GDPR, far more likely to be put into effect first.

Article 58(2) starts out very reasonably; 58(2)(a), (b) and (c) are:

(a) to issue warnings to a controller or processor that intended processing operations are likely to infringe provisions of this Regulation; [i.e. be careful]

(b) to issue reprimands to a controller or a processor where processing operations have infringed provisions of this Regulation; [i.e. smack on the wrist]

(c) to order the controller or the processor to comply with the data subject’s requests to exercise his or her rights pursuant to this Regulation; [i.e. now do it properly, we’re watching]

..then it gets a little more punitive in (d) and (e):

(d) to order the controller or processor to bring processing operations into compliance with the provisions of this Regulation, where appropriate, in a specified manner and within a specified period; [i.e. now do it properly, or else]

(e) to order the controller to communicate a personal data breach to the data subject; [i.e. tell everyone with whom you do business that you f*&%ed up]

…then there’s the stuff that could put you out of business (assuming personal data is central to it) from (f)  through (h):

(f) to impose a temporary or definitive limitation including a ban on processing[i.e. stop everything you’re doing with personal data, now]

(g) to order the rectification or erasure of personal data or restriction of processing pursuant to Articles 16, 17 and 18 and the notification of such actions to recipients to whom the personal data have been disclosed pursuant to Article 17(2) and Article 19; [i.e. you can’t do what you do with personal data the way you were doing it]

(h) to withdraw a certification or to order the certification body to withdraw a certification issued pursuant to Articles 42 and 43, or to order the certification body not to issue certification if the requirements for the certification are not or are no longer met; [i.e. good luck getting anyone in the EU to do business with you]

…and NOW the fines:

(i) to impose an administrative fine pursuant to Article 83, in addition to, or instead of measures referred to in this paragraph, depending on the circumstances of each individual case; [i.e. not only can we stop you doing business, but we can also fine you]

…and finally, back to the potentially out of business:

(j) to order the suspension of data flows to a recipient in a third country or to an international organisation. [i.e. specific to cross-border, but you’re screwed if this is relevant]

Now ask yourself; can a cybersecurity vendor help you in a scenario where the data is safe but you’re just not allowed to use it? Could cyber insurance replace your ENTIRE business and customer base?

Clearly not, so the only people you SHOULD be talking to right now are privacy experts. Not ones who passed a 75 question multiple choice exam to achieve a Certified Information Privacy Professional (CIPP) acronym, and/or the Certified GDPR Practitioner course, a lawyer. And not just any lawyer, a lawyer who specialises in privacy.

I’m not disparaging the CIPP/E or EU GDPR P certifications, they are actually very good foundations for anyone wanting to ask a true expert the right questions. And if, as per Recital 13; “…this Regulation includes a derogation for organisations with fewer than 250 employees with regard to record-keeping.”, you are small enough not to have to worry about validation of your practices, maybe someone with these certs is good enough.

It’s up to you, you’re the ones betting your businesses on it.

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

PCI, You Have Chosen Poorly

PCI DSS, You Brought It On Yourselves

I have never hidden my disdain for the PCI DSS, and have written numerous blogs as to why. Not just whinging mind you, I have always included a stab at providing solutions or alternatives. But every now and again, I have to remind myself why the DSS even exists in the first place. And who needs to accept a sizeable chunk of the responsibility for it.

It’s you Mr. Retail, and you Mr. E-Commerce, and especially you Mr. Service Provider. You are every bit as culpable as the Card Brands.

Yes, the payment card technology is 50+ years old, and hopelessly outdated. Yes it’s a ridiculous way of paying now that there are so many better ways. And yes, it’s very difficult to protect cardholder data, but it’s really not complicated. All it took was effort.

But organisations didn’t make any effort. For decades on end. From stand-alone terminals, to integrated points of sale, to e-commerce, and now to mobile, the threat landscape has changed beyond measure. The corresponding risk management programs have done next to nothing.

Let’s take a quick look at the causes of 3 of the worst card data breaches to date:

  1. T.J. Maxx (2007 – 45.7M Primary Account Numbers (PANs) compromised) – I know this one’s going back a bit, but it’s one of those rare examples of where the PCI DSS was [mostly] up to speed with the prevailing threat landscape. The breach was caused by weak encryption on their wireless access points. Although Wired Equivalent Privacy (WEP) was:
    o
    i)   known to be vulnerable way back in 2001;
    ii)  replaced by WPA in 2003;
    iii) deprecated by the IEEE in 2004, and;
    iv) addressed specifically in the DSS from as early as v1.0 – “4.1.1 For wireless networks transmitting cardholder data, encrypt the transmissions by using Wi-Fi Protected Access (WPA) technology if WPA capable, or VPN or SSL at 128-bit. Never rely exclusively on WEP to protect confidentiality and access to a wireless LAN.
    o
    …T.J.Maxx still had WEP as its standard. This vulnerability (plus horrifically poor network segmentation) lead to the compromise. It also took T.J.Maxx 18 MONTHS to find out.
    o
  2. Target (2013 – 40M PANs compromised) – Network access credentials stolen from a 3rd party and used to remotely log in to systems in-scope for PCI. An HVAC provider at that! Where to even begin on where Target went wrong?! But we can assume:
    o
    i)   vendor due diligence and management was sub-standard (addressed in Requirements 12.8.x);
    ii)  vendor access standards and monitoring were not in place (addressed in Requirements 8.1.5.a, 8.1.5.b, and 8.3.2.a);
    iii) change detection mechanisms were either not in place, or ineffective (addressed in Requirements 6.4.x);
    iv)  logging and monitoring mechanisms were either not in place, or ineffective (addressed in Requirements 10.x), and;
    v)   network segmentation was inadequate.
    o
  3. Home Depot (2014 – 56M PANs compromised) – Similar to Target, which makes this one even more embarrassing and unforgivable.

If we were to look at the thousands of other breaches that have occurred we would find little difference. It’s not so much concerted attacks from dedicated and skilled hackers that’s the problem, it’s the complete disregard for basic security practices by the vast majority of organisations. Organisations who KNOW better, but have chosen instead to just roll the dice.

I’m not saying that these three examples were not perpetrated by skilled hackers, but the level of skill required was significantly less than it should have been. In fact, if these organisations only had DSS levels of security controls in place, the attacks would have significantly more difficult. REAL security would have made these targets of last resort.

What Are You Going to Do About It?

As the South Africans say; If you want security, build your fence higher than your neighbour’s.” The reason the PCI DSS exists is because no one was building any fences!

The right things to do for security have, quite literally, been written down for generations. Ignore these basics and the upcoming regulations related to privacy will make PCI look like a walk in the park by comparison.

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

Who is making cybersecurity so complicated?

Who’s Making Cybersecurity So Complicated?!

One of the goals of this blog, as well as the ultimate goal of my career, is to simplify all aspects of cybersecurity. Well, maybe not all. I have no idea how to simplify a penetration test (or even perform one), or encryption mechanisms, but I’ve got the high-level stuff covered! 🙂

From my perspective, cybersecurity is already simple. You would hope so, it’s what I do, but that’s not actually what I meant. Which is that every aspect of cybersecurity must be simple for it to even be effective security in the first place. There is no room for complicated. It must also be accessible to everyone who needs it, regardless of their current role or previous experience.

It is therefore the job of every cybersecurity professional to make this stuff easy, but clearly we are not doing a very good job. In fact, I would go as far as to say that there are certain elements that seem to go out of their way to make things difficult!

What / who are these elements, and why are they doing it?

o

  1. No offence, but Element 1 is You; While you may not be a security expert, you are every bit as responsible for security as those who are the experts. Ignorance of your responsibilities is no excuse, and if your organisation does not provide you the necessary training, demand that they do so. Unless you’ve lived in a hole for the last 10 years, you have seen the headlines related to data breaches. You really don’t want to be the cause of one.
    o
  2. Which is the ideal segue into the Element 2, which is; Senior Management. If they don’t care about security, there’s a very chance you don’t care (see element 1.). If cybersecurity is not in the Top 5 priorities of your BoD / CEO, then you likely have an entirely ineffectual security program. If you even have one at all. There is nothing more difficult and seemingly complicated than starting something from the very beginning, but start you must.
    o
  3. Element 3 is of course, Lawyers / Regulators. Not that they do this on purpose, it’s that they just can’t help themselves. The language of the law is practically incomprehensible to the rest of us, yet it has to be lawyers that write every contract, regulation, and [of course] law out there. Combine their legal-ese with something you already don’t understand [cybersecurity], and you’re left scratching your head in frustration. Or worse, avoiding it altogether.
    o
  4.  And the worst of the bunch, Element 4; Security Vendors. This is the one that is truly reprehensible. How many of you, for example, know what Cloud Access Security Brokers (CASBs) are? Or User and Entity Behavioral Analytics (UEBA)? What about Intelligence-Driven Security Operations Center Orchestration Solutions? No, me either. What I DO know is that you don’t need ANY of these things until such times as your risk assessment TELLS you need them! You have that process well oiled, right?

Of all the horrendous clichés out there, my favourite is ‘Back to Basics’. Cybersecurity is simple, bloody difficult, but simple. Anything that complicates it can be effectively ignored until such times as you’re ready for it. You will never get there by buying technology, and you will never get there until you get the basics right.

Luckily the basics are the cheapest things to fix. All you have to do is get your CEO to care, formalise your Governance, and get all of your policies and procedures in place.

Simple, right?

OK, that was facetious, but if you think any of these things is complicated you’re just not asking the right people the right questions.

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