GDPR Certification

What Will GDPR ‘Certification’ Look Like?

From my current perspective, these are the 3 most significant unknowns in the implementation of GDPR:

  1. The appropriateness of Privacy Shield (i.e. it’s not);
  2. What will ‘Representation’ look like (per Article 27); and
  3. What will ‘Certification’ look like (under Articles 42 & 43)

There will certainly be more as my knowledge grows, and you will have your own Top 3 depending on whether you know either more or less than me on the subject. Though it’s hard to imagine anyone who’s actually reading this crap knowing less.

I took on Privacy Shield last week, and I’ll take a stab at Representation at some point, but I just got through reading the European Union Agency for Network and Information Security (ENISA)’s ‘Recommendations on European Data Protection Certification‘ so naturally I consider myself an expert in the field. Maybe I should create ‘Certified EU General Data Protection Regulation (GDPR) Certification Theory Foundation and Practitioner’ courses?

Basically the subject of ‘certification’ is far from straightforward. Not complicated per se, just very difficult.

For a start, what certification do you mean? Do you mean an organisation getting certified against the GDPR itself? Or do you mean someone who is certified to perform the certification?

First, it’s clear that there cannot be certification TO the GDPR, and that there will be no PCI DSS-esque tick-box exercise to perform. Instead, and only if applicable to your organisation, you will be certified AGAINST the GDPR in terms of adherence to its principles and intent. Or as ENISA puts it; “[…] compliance with the GDPR is not possible to be certified. What can be certified, is compliance with (or else: conformity to) certification criteria that are derived from the GDPR.

‘Criteria’ in this example could be as broad as; “Provide a summary of the appropriate technical and organisational measures in place.” (for Article 32). Or it could go as deep as; “For data protection, describe your encryption/anonymisation/pseudonymisation mechanism(s), including [where relevant] the cipher type and bit strength.”. Either way, it’s not telling you what to do, it’s making you demonstrate the appropriateness of what you have (i.e. compliance ‘against’, not ‘to’).

ENISA also makes it very clear that we must be specific and accurate in our terminology. ‘Certification requires the “provision of assessment and impartial third-party attestation that fulfilment of specified requirements has been demonstrated.“, whereas a ‘self-assessment‘ (first or second-party) can only lead to a self-declaration of conformity, never certification.

By far the lion’s share of organisations will be self-assessing, as hiring a third party to perform an onsite assessment would be overkill for a voluntary process (surmised from Art. 42(1) final sentence and Art. 42(3)). Yes, this could make a farce of the whole thing (like PCI SAQs), but should you BS your way through your self-assessment what do you think the supervisory authority is going to do should you appear on their radar? (Articles 58 and 83 for your reference.)

What I think this means in practice is that ‘compliance‘ will consist of demonstrating that your controls, processes, and documentation related to the processing of personal data are appropriate to meet the intent of the Regulation. And while that sentence seems to be just as wooly as the Articles 42 and 43 themselves, it should actually be very good news for you.

Why? Because it means that while no certification or even self-assessment mechanisms are available (and won’t be for some time) that compliance with the GDPR is determined by you!

Yes, you should be able to demonstrate that you are meeting the intent, and yes, you will actually have to fix what you know you’re doing wrong, but it means that May 25th is no longer a deadline, it’s an indication of your risk appetite. In other words, do you [stupidly] do nothing and wait for more definitive guidance, or do you do the best you can now until such times as a bar can be set by the supervisory authorities?

So, as I stressed way back in There is No Such Thing as GDPR Certification …Yet!, there still isn’t, and ANYONE with the word ‘certified’ anywhere the word ‘GDPR’ is no more qualified to help you than someone who has done a few weeks of reading on their own (like me).

To reiterate one more time (for the UK):

  1. There is no certification mechanism for organisations wanting to validate GDPR/DPA compliance through a third-party;
  2. There is no official self-assessment mechanism for organisations wanting to self-assess their conformity to GDPR/DPA;
  3. There are no organisations able to provide ANY form of OFFICIAL certification program for businesses or individuals; and
  4. There a no individuals certified to a program sponsored by ANY body associated with the administration of GDPR/DPA

For certification to work in a harmonised fashion across all member states there is still a lot of work to be done. I cannot see a mechanism for certification, self-assessing etc. in place for some time. So UNTIL they officially announce one, focus on something else.

However, waiting for this mechanism before you do anything towards compliance is no different from letting yourself drown until someone throws you a life preserver. The first steps in ANY GDPR project are as simple as they are common sense:

  1. Find your personal data;
  2. Map the data to your business processes;
  3. Get rid of everything you don’t need;
  4. Protect the rest with appropriate security controls; and
  5. Determine your lawful basis(es) for processing.

ALL of these things can be done now by anyone, and once they are done, the remaining aspects of GDPR implementation will be reasonably self-evident. Yes, 5. may be difficult for non-legals, but you’d be amazed at the number of qualified people out there willing to help for next to nothing in return.

Basically stay away from anyone promising you certification of any sort for now, and just keep swimming.

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

Privacy Shield

Privacy Shield Does NOT Equal GDPR Compliance

Once again, I will begin this blog with the caveat that I am NOT a privacy expert. However, even a single reading, some brief research, and little common sense makes it clear that Privacy Shield is more about keeping US-EU business moving than it is protecting the rights of data subjects. At least from the US side.

And I’m perfectly fine with that, because to a significant degree the GDPR is predicated on enabling business across the globe. However, the challenge is that this simply cannot be at the continued expense of a fundamental human right.

For example, what if I placed the following statement in my website terms and conditions; “To complete this sale I hereby agree to forgo my right to a fair and public hearing by an independent and impartial tribunal.” – Universal Declaration of Human Rights Article 10

Or; “Please check this box to accept that you are no longer permitted to marry or found a family.” – Universal Declaration of Human Rights Article 16

So why is this OK?; [paraphrasing] “You hereby agree that your personal data can be used for any purpose we see fit.”? – Universal Declaration of Human Rights Article 12

How would you like it if a merchant sold your personal details to an insurance company, and based on their profiling algorithm your rates went up? Or less extreme, how irritated are you when you contribute to a charity then get inundated with other charities begging for money because you’re a proven ‘soft-touch’?

The GDPR is designed to put the control of personal data back into the hands of its rightful owner; the data subject. But how can a US-based organisation, not established in the Union, possibly comply with a Union law? And even if they DID want to, how could it possibly be enforced to the same extent?

The mechanism is called ‘adequacy’ (GDPR Recital 103 and Article 45); “A transfer of personal data to a third country or an international organisation may take place where the Commission has decided that the third country, a territory or one or more specified sectors within that third country, or the international organisation in question ensures an adequate level of protection. Such a transfer shall not require any specific authorisation.” In this case the ‘third country is the US, and the ‘adequacy decision’ was rendered by the European Commission in their Commission Implementing Decision (EU) 2016/1250 on 12 July 2016.

Unfortunately that decision was made “pursuant to Directive 95/46/EC” which is the soon-to-be-defunct Data Protection Directive (DPD), not the General Data Protection Regulation. What happens to the adequacy decision when the DPD is no longer in effect? Well, even if Privacy Shield didn’t continue on (which it will …for now), GDPR Article 46(2) would still have the answer. i.e. the same things required for any non-Union establishment will take effect; contracts, BCRs, standard clauses, certification, codes of conduct and so on. In other words, things that cover the entirety of GDPR. Not adequately cover, completely cover.

At this point I think Article 46(2) would be the EU’s preference.

As for the chances of the current adequacy decision making its way seamlessly into the new regulation, the Article 29 Working Party were far from impressed in their First Annual Joint Review (28-Nov-17) to the point that; “In case no remedy is brought to the concerns of the WP29 in the given time frames, the members of WP29 will take appropriate action, including bringing the Privacy Shield Adequacy decision to national courts for them to make a reference to the CJEU for a preliminary ruling.” In other words, fix the major issues or we’ll recommend the adequacy decision be revoked.

But where does all of this leave US companies wanting to do business with the Union? Do they still self-certify to Privacy Shield and hope it remains mostly intact, or do they ensure the same controls that could claim ‘GDPR compliance’ are in place? What about EU-based organisations wanting to send data to the US for processing? Do they rely entirely on a demonstration of Privacy Shield certification even though Article 28(1) specifically states; “Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.” and they know full-well that Privacy Shield has gaps?

With only a week’s immersion in Privacy Shield, I am certainly not in a position to give advice, but I WILL throw out a couple of obvious warnings:

  1.  If you’re an EU-based organisation hoping to avoid some of the GDPR heavy-lifting by dumping all of your data to an US-based processor, I wouldn’t, you are still 100% liable;
    o
  2. If you’re a US-based organisation hoping to hide behind the Privacy Shield’s less strenuous requirements, you will be left behind when it either changes or gets entirely revoked

EU law will not go backwards to accommodate the relatively immature privacy laws in the US. Instead, the US privacy laws will need to evolve into something more acceptable to global expectations. While the GDPR is EU-specific, most of the rest of the world is going in fundamentally the same direction, and like it or not, business does not come first.

As consumers become more privacy-savvy, often despite themselves, it will only get tougher for organisations to not take privacy seriously. Like good customer service, it will be one of the few differentiators between you and your GLOBAL competitors.

My advice is to start doing things properly now while you still have room to make mistakes.

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

EU Citizen

GDPR: It’s Not Just About EU Citizens, or Residents

It is with some chagrin that I write this post. I fell for the very thing that I have warned my clients about for decades; “Read [regulation name] carefully and NEVER make assumptions, and if you don’t know something, ask someone who does!” Here I am now having to admit that I thought the GDPR was only about EU citizens.

It’s not.

The WORD ‘citizen’ never even appears in the Regulation. Not once. In fact, I’ll go so far as to say that it’s not even about EU residents, because that word never appears in the Regulation either. Neither of these words is what GDPR means by “in the Union“.

I take some very limited solace from the fact that I have never claimed to be a privacy expert, but my ongoing mission of pushing everyone to actually read the GDPR carefully makes me something of a hypocrite. So apologies for that, I should have known better.

But even now that I have read the relevant Recitals and Articles, and asked real experts for guidance, I am still only able to make assumptions. I know that somewhere, someone(s) knows exactly what all of this means in practice (and precedent) as there is very little ‘arbitrary’ about the law. Hopefully these someone(s) jump in at the supervisory authority level.

So the real point of this blog is NOT to impart knowledge, or instruct, I am unqualified to do so. It is to gather feedback, or even opinion on the below interpretation(s). And yes, I have reached out to both the ICO and Art. 29 WP for clarity, but I doubt I’ll get much back anytime soon.

[Note: I won’t name the people who have provided the following guidance (unless they want me to), but I thank them for it. That said, if I’m still way off the mark the blame is entirely my own.]

First, the KNOWN Facts:

  1. Nowhere in the GDPR, or any referenced document [of which I am aware], are the phrases ‘data subject’ and ‘natural person’ tied to ‘EU citizenship’ or even ‘EU residency’;
    o
  2. Recital 2 states – “The principles of, and rules on the protection of natural persons with regard to the processing of their personal data should, whatever their nationality or residence, respect their fundamental rights and freedoms, in particular their right to the protection of personal data. […]” – [this is, after all, a human right];
    o
  3. Recital 14 states – “The protection afforded by this Regulation should apply to natural persons, whatever their nationality or place of residence, in relation to the processing of their personal data. […]” – [it does not matter who or where they are];
    o
  4. Recital 22 states; – “Any processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union should be carried out in accordance with this Regulation, regardless of whether the processing itself takes place within the Union.” – [a business established in the Union can [with caveats] process the data anywhere in the world, GDPR still applies];
    o
  5. The phrase – “[…] in the Union […]” appears frequently in relation to scope and/or applicability – [i.e. regardless of nationality and location];
    o
  6. Article 3(1) states – “This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.” – [regardless of 4. above, GDPR still applies]; and
    o
  7. Article 3(2) states – “This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to […]” – [applies to non-EU establishments if they ‘target’ people in the Union]

Now, the Assumed ‘Facts’:

  1. If your personal data is collected and processed while you are physically IN the Union, and Article 3(1) or 3(2) apply, it does not matter what your nationality is, nor does it matter where you live normally. GDPR applies.;
    o
    Scenario: A US citizen is on holiday in the UK and orders something from an e-commerce merchant ‘established’ in the Union. The site collects personal information. GDPR applies.
    o
  2. For processing of personal data outside of Article 3(1) and 3(2), it doesn’t matter whether you’re an EU citizen or not, GDPR does NOT [necessarily] apply;
    o
    Scenario: Someone ‘in the Union’ orders online from a merchant based in the US, who has made no effort whatsoever to market/aim their services to anyone outside of the US. All payments must be in USD. Just because they agree to ship the merchandise to the EU does not, by itself, put the merchant ‘in-scope’ for GDPR, even if they do collect personal data.
    o
  3. Even if you are not ‘in the Union’, the processing of your personal data by an establishment whose activities provide the context for the processing are in the Union, is in scope for the GDPR;
    o
    Scenario: A citizen, including non-EU, is on holiday in the US and orders online from an e-commerce merchant ‘established’ in the Union. GDPR applies.

In the end it’s becoming clear that being an EU citizen does not give you rights anywhere outside of the boundaries of Union law. It is also clear that regardless of your nationality, or where you live, doing business with Union-based organisations may give you rights that it’s quite possible you are not receiving in your own country (especially in the US).

And not that I’m particularly bright, but for me to make such a fundamental mistake in interpretation further supports my contention that you should only ever take guidance from proven privacy experts. This is just too important to rely on people who have only recently jumped on the bandwagon.

Again, I am not saying that any of my assumptions/interpretations are facts. I actually expect to be corrected. About the only benefit you can get from this is you should now have your own questions to ask.

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

PIN on Mobile

PCI: Software-Based PIN Entry on COTS (a.k.a. PIN-on-Mobile)

Almost four YEARS ago I wrote Software PIN, the Rosetta Stone of Future Payments, then just over a year later I wrote; Mobile Authentication: Exceeding Card Present Security?

Just this month the SSC finally came out with their Software-Based PIN Entry on COTS Security Requirements v1.0.

[Ed. While I don’t have to wonder why PIN was my primary focus, I can see how pointless it was …almost. It just makes the delay on this standard that much more inexcusable.]

On with the story… Software PIN is more commonly referred to as PIN-on-Mobile (or the catchier PIN-on-Glass), and is the ‘game-changing’ technology that will; “enable merchants to accept PIN-based payments with the PIN entered on a commercial off-the-shelf device, such as a consumer-grade mobile phone or tablet.”

What has taken them so long to make what – from my jaded perspective – is the only move that will delay their inevitable demise? It’s not like there was some miraculous innovation in mobile or encryption technology in the last couple of years! Every requirement in the standard was available/achievable long before I even wrote my blogs. As were viable solutions for that matter.

I suspect there’s lots of reasons of why they were so slow, but chief amongst these has to be their complete inability to adapt to the fast-paced innovation rampant in the FinTech industry. Especially given their hopelessly antiquated technology. It’s only their global adoption and sheer ubiquity that keeps them where they are. I blame the banks too, change for them means acceptance of liability.

Come to think of it, what an amazing coincidence that PSD2 – the biggest nail in the payment card’s coffin since …well ever, came out this month as well. Weird huh?

As far as I am concerned, PIN-on-Mobile was the card brand’s last hold-out, now they’re done. Hopefully between the XYZ-Pays (ApplePay, SamsungPay etc.) and now the entry of cardholder PIN on [almost] any CoTS device, big merchants / retail associations will finally have the balls to stand up for themselves.

How many millions have they spent in the US on EMV terminals just to find out a few years later that it was not only entirely unnecessary, but they’re now tied into an investment that will leave them lagging behind their competition who were slower of the EMV block?

I know that’s harsh, and we really have no right to judge. Have any of the following questions ever occurred to you?:

  1. If I can use my phone to pay for something, why do I have to tie that payment to a branded card?;
  2. With all of the security requirements required for the entry of a software PIN, why the Hell do I still have to use one? In other words, if it’s that bloody difficult to secure it, why not use something else?; and
  3. Isn’t there a better way!?

If you’re like the majority of the population, these questions are more like:

  1. Why doesn’t MY bank support this?! (looking at YOU Barclay Business!), or more commonly; why would I use this service when I have a piece of plastic?;
  2. What’s wrong with PIN?; and
  3. [nothing]

The fact is that the lion’s share of the cashless transactions globally are performed by those who have never known a time before payment cards. We simply can’t imagine anything else and we don’t even notice their inconvenience. We also don’t see the costs imposed by the middlemen.

But let me ask you this; Would you ever go back to using a feature phone? I’ll [almost] guarantee that you had no idea what features you wanted in a phone until you used a smartphone for the first time. And now you can’t live without it. Hell, most of us can’t even put the damned things down!

The same thing WILL happen to payments, but not until consumer indifference is overcome by something shiny and new.

Frankly this blog is boring even to me, and I really have nothing more to say about payment innovation that I have not already said a hundred times. But I simply can’t let anything so patently meaningless as PIN on Mobile to go unanswered.

Innovation my arse.

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

AI

If AI is the Answer, You’ve Asked ALL the Wrong Questions

For those reading this who are cybersecurity professionals (and who else would read this crap?); In your entire career, have you ever come out of the back-end of a risk assessment and said; “We need Artificial Intelligence.”

Anyone?

I seriously doubt it, unless you happen to sell artificial intelligence, or more likely, you’re trying to pass off your product as artificial intelligence.

But let me just clarify before I continue whining; AI is exciting as Hell, and I cannot WAIT to see what comes next. I am not in the ‘Skynet’ camp, and I even disagree with people a thousand times smarter than me. No, not my wife (this time), but the likes of Stephen Hawking, Bill Gates and Elon Musk, all of whom have issued their own warnings/predictions on the subject. I think AI is going to make our lives better in almost every way. Almost.

But not in cybersecurity at the organisation level. Not yet. Most businesses simply don’t have anywhere near the foundations in place to implement it appropriately, let alone effectively. Implementing any technology on top of broken processes and/or an indifferent security culture may only serve to make things worse.

I can see it in working the threat intelligence arena, where a behemoth like Alphabet – and their mind-boggling access to almost everything -, can fund something like Chronicle. But this is just one small part of a security program, feeding into the ages-old clichés of ‘defence in depth’ or ‘layered security’. AI is certainly not the panacea those with a vested interest would have you believe. Basically, if you don’t have the same access and deep pockets as Alphabet, you should be probably be focusing on the hundreds of other things you should have done long before now.

And even if there was an AI ‘appliance’ that you could just plug-and-play on your network, do you honestly think the bad guys won’t work out how to circumvent it with some AI tricks of their own? Regardless of the technology, the good guys always have to play by the rules and the bad guys will always do whatever it takes. This is not a fight we are EVER going to win, so stop trying. The only thing we can do, and the sole premise of my career, is to minimise the damage. Security folks are the definitive guys bringing a knife to a gunfight. But we will fight.

This is neither cynical, nor a cop-out, it’s reality, and spending money on a technology you’ll never understand, or maintain yourself, is not going to change that.

But none of this will stop organisations spending money on nonsense. On the one side you have product vendors, technology-centric consultants, hype in the press, and indifferent CEOs. On the other side, you have the ages-old security basics and a very limited number of stubborn practitioners. It’s not really that surprising that acronyms and the latest shiny-things get all the attention, just unfortunate.

In fact, it’s no different from ‘get rich quick schemes’ or ‘diet pills’, there are very few shortcuts to wealth and none to losing weight. Both involve getting off your lazy arse and doing something. So does security.

But most of all I simply can’t abide vendors who try to fit every single problem into the one thing they can do. From operationalising the whole of GDPR with ISO 27001, to solving every limitation of digital payments with biometrics, the attraction of the silver-bullet is just too much for some to resist. AI and machine learning are the latest purveyors in a long line of empty promises.

Perhaps I’m no better, all I can do is help you implement the basics. But I’ll guarantee what I’m selling is a damned sight cheaper and significantly more permanent! 🙂

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