What's in the Draft PCI DSS v4.0?

In late 2020, the PCI DSS v4.0 will be released. And in what promises to be an even more significant change than that from 2.0 to 3.0 (released in Nov. ’13), there is, rather unsurprisingly, a great deal of interest in its contents.

So what’s in it?

I’ll be honest, I can’t tell you, or more to the point, I’m not ALLOWED to tell you as the draft version is currently in ‘Request for Comment’ (RFC) status. Yes I have read it, not only that, I have mapped it line-by-line to v3.2.1 and analysed the differences in detail. I have even written a brief on what I consider the impact of those changes will be, but it will have to remain unread until the moratorium is lifted.

Now that you’re pissed off and disappointed, some good news; It is actually quite easy to extrapolate the evolution of both the threats to the payment card industry and the PCI DSS itself into a common sense approach to get out ahead next year’s release.

But first, you have bear a few things in mind:

  1. The PCI DSS has always been, and will always be a “minimum set of requirements for protecting account data“, therefore if all you have ever done is meet those minimums, any change is going to create work for you;
  2. As a corollary to 1., there is nothing in the PCI DSS that you should not already be doing, not just for PCI compliance, but for all data assets critical to the business. So, if you treated PCI compliance as a tick-box exercise, you are completely unprepared for what’s to come;
  3. If you were doing security properly there’s nothing the SSC could add to the DSS that would not already be covered, even if it was just a line item in your risk register;
  4. Just like security in general, the PCI DSS will never keep up with the threat landscape (good guys have limitations, bad guys do not), so you only have to look at the highest risks to cardholder data to understand where the next DSS is going to focus;
  5. The DSS has had 15 years to stop the bleeding as much as possible, now it’s time to fit the maintenance of it into a more ‘flexible’ risk framework, which it is, per the SSC’s stated goals;
    • Ensure the standard continues to meet the security needs of the payments industry;
    • Add flexibility and support of additional methodologies to achieve security;
    • Promote security as a continuous process;
    • Enhance validation methods and procedures

Given the above, as well as the example control topics the SSC provided…:

  • Authentication, specifically consideration for the NIST MFA/password guidance;
  • Broader applicability for encrypting cardholder data on trusted networks;
  • Monitoring requirements to consider technology advancement;
  • Greater frequency of testing of critical controls

…what is likely to change most in my opinion:

Prediction 1: There is no way you can support the goal of ‘promot[ing] security as a continuous process‘ unless you have the following in place:

  • Some form of governance, or at least a growing culture of individual accountability;
  • Robust Policies (cultural definition), Standards (systems baselines), and Procedures (corporate knowledge);
  • Comprehensive risk management processes – or you’ll never be able to define ‘appropriate’.

Guidance: You should therefore expect enhancements to the DSS requirements that contain; “Examine documentation…“, “Interview responsible…“, or impact risk management.

Prediction 2: There is no way you can support the goal of ‘Ensur[ing] the standard continues to meet the security needs of the payments industry‘ unless you up the ante on the more egregious gaps in security capability.
I have previously defined these as some of those gaps:

  • The PCI DSS only covers POST-auth data, not PRE-auth data;
  • Weak change control;
  • Ineffective logging and monitoring; which leads to
  • Weak incident response;
  • Entirely manual process for data asset management;
  • and so on…

Guidance: Unless you can demonstrate that the PCI minimums are appropriate security for your organisation’s unique risk profile, you should consider bringing some of the more egregious control gaps up to some of the established industry good practices.

Prediction 3: The SSC’s stated control topic of “Monitoring requirements to consider technology advancement” can only suggest that technology now needs to play a greater part in PCI compliance. The DSS requirements that include an aspect of ‘monitoring’ include:

  • Anti-virus;
  • Third party access;
  • Physical access;
  • Logging;
  • Failure of security controls (service providers only);
  • ‘Rogue’ wireless access points;
  • and so on…

Guidance: It stands to reason that while compliance with some of the DSS requirements could previously be more of a manual process, the increased availability and the decreased cost and complexity of ‘monitoring technologies’ may render their continued lack of use inappropriate.
Not that the SSC will ever make a specific technology mandatory, you have to work out how best to meet the DSS’s intent.

Prediction 4: The control topic; “Broader applicability for encrypting cardholder data on trusted networks” can only mean one thing; encryption of cardholder data ‘on the wire’ is going to be required across trusted networks as well as untrusted.

Guidance: If this does make it to the final version, you will [I suspect] have 2 years to implement it. Start now, and not because the DSS might say so, but because encryption of important data assets across ANY network is the right thing to do.

Prediction 5: The control topic; “Authentication, specifically consideration for the NIST MFA/password guidance” does not mean you don’t have to change passwords anymore, it means you will have to revamp your entire authentication infrastructure in line with current best practices. Passwords of 7 characters, upper/lower case, history of 4 etc. are not adequate in NIST’s eyes, not that they ever were.

Guidance: Going above the DSS minimums with regard authentication is easy. From simple things like upping the password length/history/lockout, to enforcing MFA across the enterprise, to use of more appropriate authentication factors, this is yet again something that is right for the business.

I have to stop here as I must be careful not to give away any detail, but I can state categorically, that if you were doing security properly there is NOTHING in v4.0 that would be an issue for you.

Further, if you were to integrate your ‘GDPR compliance’ efforts with your ‘PCI project’ you would have everything you need from both a governance AND a technology perspective.

And the best thing about this is that you don’t have to wait to find out what’s in v4.0, a good security consultant could tell now what your gaps are.

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

If You Need to be ‘Disruptive’ to Sell your Security Product, Make a Better Product

You’ve all seen the ads; “Service X is disrupting the Y industry!“, or worse; “We’re using Artificial Intelligence to disrupt…”.

At this point I will look no further at what you have to offer, because if your product/service could stand on its merits, why would you to resort to using tired and almost entirely inaccurate marketing drivel? And are you really to solve my problems or just make money?

Yes, that was a rhetorical question.

Continue reading

On the Convergence of Data Privacy and Data Security – Part 2

In Part 1 of this two-part blog ‘series’, I played the part of a security expert (which I do most days), and examined how privacy is changing the face of the security industry.

In Part 2, I have enlisted the help of a lawyer, data protection and contracts expert, who is basically to blame for me getting into this ‘privacy stuff’ in the first place. She also happens to be my sister; Angela Boswell.

In her learned (and earned!) opinion……………………

Continue reading

On the Convergence of Data Privacy and Data Security – Part 1

If you’re fairly new to this ‘privacy stuff’, you might be wondering why I used the phrase ‘data privacy’, not ‘data protection’. Well, unlike the security industry where we can’t even agree on when to use ‘cybersecurity’, ‘data security’, or ‘information security’, the privacy world has its act together. Hell, security folk can’t even agree on the spelling OF cybersecurity/cyber security!

But for the purposes of this blog, and the Part 2 guest blog to follow, it’s important that you accept my definitions at least, whether you agree with the names or not. It’s the points I’m trying to make that matter, not the nomenclature.

‘Security’ Definitions:

I am assuming it’s universally accepted that ‘information’ is simply ‘data in context’. So ‘data security’ and ‘information security’ are pretty much the same thing, they’re just at different stages of a data life cycle. e.g. If I steal a whole bunch of individual files with no indication of their content I have stolen data, but if I steal the plans for a revolutionary widget, I am stealing information. ‘Data’ and ‘information’ are used pretty much interchangeably from a security persons perspective – as will I for the reminder of the blog – because it’s not security folks who make the decisions on the data/information’s use, the business does.

I will therefore settle on the following names/definitions:

  • Security – Every aspect of security, from physical (e.g. buildings, laptops, personal safety, etc.) to logical (e.g. cybersecurity);
  • Data Security – Is the protection of data or information assets in any format; i.e. physical (e.g. paper) and electronic (e.g. on a computer);
  • Cybersecurity – Is the protection of any electronic form of data or information, regardless of data life cycle context;

In this respect, I have always seen cybersecurity (joined up because Gibson coined it ‘cyberspace’, not ‘cyber space’) as a subset of data security, but apparently ‘cyber’ is just way cooler to say despite it’s more limited applicability. The security industry, it seems, is obsessed with the need to introduce new buzz-phrases to replace things that weren’t actually broken.

None of this means anything to a privacy person who only cares about ‘data privacy’ and ‘data protection’, which are not the same thing. The privacy person cares about how the data/information is used (privacy), how personal data is protected is a subset of that goal.

‘Privacy’ Definitions:

Privacy is a state, not a function; i.e. you either have it or you don’t. Loss of personal data does not, in and of itself, equate to a loss of privacy, just as you can lose privacy where no data is involved (e.g. peeping toms). In data terms, privacy is lost if, and only if, the data is used in a manner that actually violates the data subject’s fundamental human right to privacy (first enshrined in UDHR Art. 12). The protection of this right in the EU is now significantly matured in the GDPR, and that’s really the whole point of this two-part blog series; how is the use/misuse/loss/theft of personal data driving two disciplines, previously perceived as quite separate, together?

But back to the definitions:

  • Privacy – “a state in which one is not observed or disturbed by other people.” the ‘state’ of privacy cares nothing for how you have it, just that you do have it in-line with the right to it;
  • Data Privacy – not surprisingly this is also known as ‘information privacy’, and is concerned with the proper handling of data (e.g. collection, consent, use, transfer to third parties etc.), particularly under regulatory obligation (like the GDPR);
  • Data Protection – is concerned with the unauthorised use, corruption, loss, availability of the personal data.

All of the above definitions, security and privacy, can be summarised thus:

If Privacy is a state, then so is being ‘Secure’, and the overlap between the two is likely far more significant than the above diagram might suggest. Especially in the 21st century where privacy has become little more than a currency, and security no more than an afterthought to convenience or for a few ‘likes’ on social media.

I have spent 20 years in the IT / IT Security industry, and it was not until I read the draft GDPR back in early 2016 did I see it as something that impacted me. I had my own ideas of privacy, none of which appropriately factored in privacy’s growing interdependencies with my chosen career path. It took another year or so for me to realise that unless I knew more about how privacy would impact security that I would be severely limited in the help I could provide my clients. Most of whom, quite frankly, knew little about either. Why would they, that’s why they hired me in the first place?

The overlap between security and privacy has been increasing rapidly in the 3 years that I’ve been paying attention, and we’re getting to the point that privacy is no longer a ‘siloed’ aspect of security professional’s body of knowledge, it’s intrinsic to the industry itself. As a security professional you no longer have a choice, you either learn enough about privacy to talk somewhat intelligently, or your security-relevant guidance cannot be seen in an ‘appropriate business context’.

Having seen the writing on the wall, I did what most people do when they start to feel left behind; I jumped on the study / specialist certification bandwagon. I read as much as I could from the better law firms, absorbed most of what the ICO posted, subscribed to the more objective newsletters, and wrote blog after blog hoping the real experts would pay attention and set me straight.

I then got myself ‘acronymed up’ by taking IAPP’s CIPT, CIPM, and CIPP/E, all to do just one thing; to gain enough knowledge that I can translate what the real privacy experts say into language the IT/IS experts can understand. And vice versa. I will never truly understand privacy, not from a purely legal perspective, I have always been, and will always be a security person. But someone has to take what the privacy folks say in legal-ese and translate that into geek-speak, or every decision stays on the paper on which it was written.

So here we, 1,000 words into my blog and I’m finally getting to the point; security people are perfectly placed to be the translators if, and only if, they make the necessary effort to do so.

If you assume that a GDPR compliance project looks something like this (much simplified):

  • Step 1: IT folks discover all data assets;
  • Step 2: IT / IS folks help the business-side map the data into process flows, including 3rd party dependencies;
  • Step 3: Privacy experts make determination of lawful basis for processing for all process flows, and dictate the changes that have to be made to that processing;
  • Step 4: IT / IS folks have to implement the “technical and organisational measures” that fulfil those required changes;
  • Step 5: IT / IS folks have to detail the final work product back to the privacy expert for signoff and onward reporting.

But who sits in the middle? Who can:

  • tell the IT folks what to look for in the first place, and how to report the findings?;
  • guide the business side into the right way to report the resulting processes?;
  • present the business process mappings to the privacy experts in their language?;
  • translate the privacy expert’s guidance into action items an IT person can follow?;
  • report back to the privacy experts in a language that can be readily incorporated into contracts, records of processing, policies, notices, and so on?

The problem with the security person trying to do all of this themselves, and the reason why it’s a 2-part blog, is that VERY few security folks are able to go the whole way by themselves. The ‘legal’ side absolutely must make an equivalent push in the other direction, as without a similar level of effort from both sides the two simply will not meet in the middle.

But what options are there other than to study as I did? A few universities are offering courses that attempt to tie these disciplines together, but we are wayyyyy behind the curve on this one. It is up to each security professional to decide what’s best for them and get themselves back to ‘school’. That or be left behind.

In Part 2, I will present a guest blog from the ‘other side’; from a lawyer, contracts guru, DPO, and all-round expert in the field. Not in theory, in practice.

Cybersecurity Vendors: Masters of Distracting Innovation

I’ve heard that the best writers draw inspiration from the people around them. Clearly this works for crap writers too, because I totally stole the phrase ‘distracting innovation’ from a friend of mine. So thank you for that Gareth.

I have dedicated the last half of my career to providing my clients the only thing that makes sense to me; an appropriate security program that supports and enables the needs of the business. I have also chosen to predicate the implementation of that program on the following well established cornerstones. In order of importance:

Continue reading