Screen Shot 2016-07-29 at 13.59.29

PCI DSS v3.2 vs CIS Critical Security Controls v6.0

A few months ago, while incredibly bored, I decided to perform my own mapping of the PCI DSS v3.2 to ISO 27001:2013.

I know what you’re going to say; “You can’t compare the two, one’s a management framework, the other’s a controls-based assessment standard!” I agree with you, however, it IS possible to map PCI’s Control Requirements to the ISO’s Control Objectives.

The DSS did not fare well; PCI DSS v3.2 vs ISO 27001-2013

This is not surprising really, the PCI DSS was never designed to be a security framework. It was designed to reduce the risk of card holder data loss to acceptable levels, and nothing more. Whether or not it has succeeded is a debate for the ages, and any frequent readers of my blog will know where I stand.

This week I found myself bored yet again, so I decided to give the DSS another shot at matching up to an ‘industry-accepted’ standard. This time I chose the CIS Critical Security Controls (CSC) v6.0 which, by definition, should have given the DSS a shot at redeeming itself.

It didn’t; PCI DSS_v3.2 vs CIS Critical Security Controls_v6.0

In the DSS’s defence, this is not a fair apples-to-apples comparison either, for 2 main reasons:

  1. The DSS is not a 100% controls-based standard, the CIS CSC is. The DSS, quite rightly, includes a significant chunk of policy and procedure, only a reverse mapping would give the full picture.
    o
  2. The CIS CSC includes a significant number of technologies ill-suited for all but the most advanced and mature environments. Not to mention those with unlimited budgets. The PCI DSS was written to be understood by as many people, and be as universally affordable, as possible.

That said, we can certainly make some observations that illuminate some of the PCI DSS’s more significant deficiencies:

  1.  Data Protection (CSC 13): 18% coverage – Rather ironic, but the entire raison d’être for the DSS; protection of card holder data, scores the lowest in terms of controls requirements. While CSC 13 does not include as much encryption as the DSS, the lack of Data Loss Prevention (DLP) techniques in the DSS is starkly transparent. The DSS has never even mentioned DLP in the main body, or even alluded to it in the “Scope of PCI DSS Requirements“. Only the Designated Entities Supplemental Validation (DESV) section mentions it, and that only in the Guidance as an option.

  2. Inventory of Authorized and Unauthorized Devices CSC 1 & Software (CSC 2)20% coverage – Asset Management is at the heart of every security program, nothing else can possibly function without it. The requirement for an asset register was not added to the DSS until v3.0. Along with Logging & Monitoring, the PCI minimums related to asset management are the most damaging to the overall program. Automation and alerting are both next to impossible without the baselines the asset register should provide.

  3. Malware Defences (CSC 8): 27% coverage – The DSS focuses almost entirely on anti-malware, and that almost exclusively on Windows. That’s what they mean by “…commonly affected by malicious software” in Requirement 5.1. Base-lining, white-listing, black-listing and so on aren’t featured in the DSS, because with asset management there is no way to track what should and should not be there.

  4. Security Skills Assessment and Appropriate Training to Fill Gaps (CSC 17): 28% coverage – This one is truly unconscionable given the enormous power of education and training. Security Awareness means nothing unless it’s in appropriate context to the individual taking it. One size does not fit all, and PCI would be wise to take note.

Clearly I have a significant bias against the PCI DSS in general, so I would welcome any counter-argument from others who are equally bored.

Now I have to go find something else to do..

Change Your QSA

Too Scared to Change Your QSA?

Or perhaps the question should be; “Can’t be bothered to change your QSA?

Or an even worse scenario; you know you can’t change your QSA because the new one might discover things you’ve been hiding from the last one!

I can almost empathise with the first two, but if it’s the third scenario you deserve the bad things that will happen when you get breached.

The fact is, if you have been working with a good QSA, not one of the challenges I list below will apply to you, Changing QSAs, or even QSA companies will not be an issue. You will have been doing security properly, and not just faking compliance.

Challenges:

A significant number of organisations are faced with at least 1 of these 5 main challenges;

  1. Lack of Continuity – Employee attrition is inevitable. QSAs have historically bounced from one QSA company to the next following the money. Which has been abundant for almost a decade now. This has left many clients in the unfortunate position of having to start all over again with another QSA. Often one who has received little to no hand-over.
    o
  2. Lack of Guidance – This is the QSA’s only real job. Other than writing the second half of the Report on Compliance, ALL of the remediation work belongs to the client. The role of the QSA is to ensure that the client NEVER hits a roadblock. QSAs are supposed to have ‘been-there-done-that’, so “What’s next?” should never be a question the client has to ask.
    o
  3. Inconsistent Opinions – Every security consultant has a different skill-set. Some are network wizards, others know encryption, most should be very familiar with policies and procedures. What happens when your last QSA agreed something that your current QSA won’t accept? Who is accountable for the loss of resource and/or capital cost?
    o
  4. Starting Over Again Every Year – Too many  QSAs are ‘just QSAs‘, with little experience or capability in fitting PCI into sustainable security processes. If your PCI compliance looks like an annual project, it is. Validation of compliance should be a simple process that should fit neatly into your BAU program. If it doesn’t, there’s a very good chance your QSA is at least partially to blame.
    o
  5. Black-Hole Communications – If you expect your QSA to be a project manager, you have completely misunderstood the dynamic. But if you expect them to respond to emails requesting guidance in a timely fashion, you should. A QSA is there to tell you everything you have to do to achieve compliance, that’s their job, they must be readily available.

Mitigation:

OK, so those are all the bad things, how do you fix them? Easy, choose the right QSA in the first place!

Facetious yes, and likely a moot point, but it’s never too late to change:

  1. For Lack of Continuity – All good QSAs have a methodology; Have you seen it? Does you QSA even have one? If the answer is no, you don’t have a good QSA. Continuity is simple, it just requires discipline, and a plan.
    o
  2. For Lack of Guidance – As stated above, this is the QSA’s only purpose, if they can’t provide it, find someone who can. Interview your QSA(s) before letting them onsite, but have your questions prepared. Insist on having access to QSAs suitably qualified in ALL 12 DSS Requirements. You’ll never find this in a single QSA, unless it’s one of the 3 that I know that come close (I’m not one of them).
    o
  3. For Inconsistent Opinions – Agree a process whereby the QSA company accepts mitigation plans or compensating controls, not individual QSAs. Agree, in writing, that ALL QSAs they send will accept a company approved option.
    o
  4. For Starting All Over Again – This is as much your fault as the theirs. If you had a security program in place that appropriately covered your business, PCI would fit into it, not the other way around.
    o
  5. Black-Hole Communications – Vendor Due Diligence + Service Level Agreements + Vendor Management. Period / Full Stop.

Changing QSAs every few years is a best practice, you should ALWAYS want fresh eyes on such a critical process. If changing your QSA is too difficult or inconvenient, it says a lot about both your current QSA, and your organisation’s attitude toward security;

They both leave a lot to be desired.

Here’s some old guidance I threw together a while back; Selecting the Right QSA for Your Business

Like this Article? Don’t forget to subscribe!

Screen Shot 2016-07-14 at 10.07.45

‘CEO Fraud’ Is The CEO’s Fault

Whichever way you look at it, the > $2Bn lost in ‘CEO Fraud’ is the CEO’s fault. Maybe not so much the first couple of cases (the ‘zero-day’ ones), but from that point forward, falling for such an obvious scam is indicative of broken processes that all point back to the CEO.

Even one of the most basic tenets of security; that of split-knowledge and dual-control, is all that was required to prevent these attacks! NO-ONE, including the CEO, should be able to authorise these transfers, and NO-ONE, not even the CFO, should be able to perform one.

Not for all transfers obviously, but when we’re talking hundreds of thousands to tens of millions, how was a single person able to proceed without sufficient checks and balances? For God’s sake, a simple CALL to the CEO’s mobile would have sufficed!

So, in the several thousand companies that have fallen for this scam, we can make several assumptions:

  1. The CEOs are above the processes of other employees – I have to believe that the transfer of [for the sake of argument] $100K requires the completion of a form of some kind. That form is then signed by the requestor, and forwarded on to finance for action. In every case where the fraud was successful, the process began with nothing more than an email.
    o
  2. The CEO is ‘God’ –  In this particular case, an accountant transferred $480K based on an email, then only became suspicious when asked for a subsequent $18 MILLION. Seriously? It didn’t occur to the accountant to call the CEO just to make sure? Is the CEO THAT unapproachable that s/he won’t take a 20 second phone call for $480K!?
    o
  3. There is zero oversight on the finance departments – As in the above case, there were clearly no checks and balances in place to confirm authorisation of a transfer, and no-one below the accountant thought to question their own actions based on largely undocumented request? Just following orders were they? What does THAT say about the company culture?
    o
  4. The Information / Cyber Security program is a shambles – Even the most basic Security Awareness & Training programs have sections on social engineering and fraud techniques, and no matter how well a thief did their homework, these emails should have been a huge red flag. How is it that people with such enormous impact on a business (i.e. finance) have no training in cyber security basics / essentials?
    o
  5. The organisations have zero ability to address the prevailing threat landscape – How easy would it be for the information / cyber security departments in these organisation to send out ‘mandatory-read’ emails to all-staff warning them of the ‘new’ threat? How do mitigation techniques not make their way into business process after a significant change in the threat landscape?

The saddest part of all this? This type of fraud is ON THE RISE!! Despite the significant press, despite > $2 BILLION in losses, organisations all over the world still haven’t taken appropriate action.

My most used phrase; “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 [enter any goal here], it’s the CEO’s fault, and no-one else’s.“.

In this case, replace “[enter any goal here]” with “immunity from email scams” and apply it the assumptions above. We can determine that;

  1. the CEO’s vision for the organisation does not include an appropriate security program – If they can’t even take care of their own MONEY, what is the chance they can take care of your sensitive data?
    o
  2. the CEOs put themselves above the company values – No company that I know of has ‘Do as I say not as I do.’ as a published value, but clearly the rules do not apply to these folks.
    o
  3. the direction of any organisation is towards its goals. Obviously. How does the loss of hundreds of thousands of €/£/$ and the sheer embarrassment of falling for this attack add to the company’s bottom line?
    o
  4. unfortunately security is up there with ethics when it comes to CEO priorities. They are a cost of doing business, not fundamental processes that add significant ROI when done properly.

The better CEOs who have been victims will look at the root cause of their incident, point their finger squarely in the mirror, and fix it. The rest will fire the finance person and leave themselves open for the next threat. The best CEOs led their company by example, and didn’t fall for the attack in the first place.

Which do you want to be?

Screen Shot 2016-07-15 at 13.31.46

National Retail Federation (NRF), Why They SHOULD Hate PCI

In a recent CSO Online article; “The National Retail Federation is dead wrong about PCI“, the author made, in my opinion, one the most reprehensible defences of PCI I’ve ever seen. Even the SSC have not been so bold as to make these kinds of off-the-mark and clearly self-serving assertions.

After an innocuous 2 paragraph preamble, the author(s) state;

Despite NRF assertions to the contrary, the payment card industry has asserted that their card security standards are voluntary. Merchants have a definite choice if they want to accept credit and debit cards or not. It’s quite safe to say if retail establishments couldn’t accept payment cards; most would see massive sales reductions, and a large number would simply go out of business.

How can he possibly say that merchants have a choice, when he says it himself that most would see “massive sales reductions”!? Call that a choice!? That’s right up there with ‘face or gut?’!

The fact remains that the card brands STILL have merchants by the short-and-curlies when it comes to non-cash payments. You only have to look at the anti-competition or unfair business practice suits that card brands have had to fight over the years to see how distastefully are their business practices perceived.

And quite frankly, this all shows a complete lack of understanding of the NRF’s main issue; They don’t CARE how they receive payment, payments are NOT core to their business. Being paid for their product / services is.

The author goes on to say;

Given the significance of payment cards, we would have expected the NRF to be at the forefront of PCI advocacy and compliance. Yet the reality is that they have an extremely disdainful view towards PCI.

Seriously? Ask me to pick up the cost of fixing your crappy service and I’ll be equally ‘disdainful’. Sod that, I’d be thoroughly pissed-off, but I still wouldn’t have a choice, not if I wanted to stay in business.

The NRF have every right to expect the card brands to do something more appropriate, THEY are the ones providing the service and THEY (and their associated middle-men) are the ones who’ve made billions through merchant transactions over the course of 50+ years.

But it’s the merchants who are the ones who are paying the interchange rates. And it’s the merchants who have to spend billions on infrastructures that do absolutely NOTHING to help them improve their customer’s shopping experience.

Guess who pays for this in the end? Yep, us, the consumers.

As I have written (or at least allude to) many times in the past, the very technology behind payment cards is past its usefulness. Anyone trying to prolong this ancient, inherently insecure, and zero-value-add technology clearly has a vested interest in doing so. Card Brands, Issuers, Acquirers, Payment Service Providers (PSPs), and Terminal Manufacturers are obvious stakeholders. However, QSA companies exist to a large degree on the budgets that PCI compliance extorts. Call them PCI War Profiteers if you wish, I’ve heard worse, and I have also benefited.

In the card brand’s defence, they have done a truly astonishing job over the course of 5 decades in bringing trust into non-cash payments. That’s what their logos are; a symbol of trust. The next generation of payment providers owe them an enormous debt of gratitude. That said, we didn’t keep horses around because we felt sorry for the ferriers, we jumped head first into the automobile.

Mobile phones are now more ubiquitous, and can be infinitely more secure and ‘value-add’ than branded plastic (even while tokenised in ‘[X] Pay’ services). All we need now are the banks to get their acts together and provide the trust and there will be little need for the innumerable middle-men.

Which brings me to my final point on the article; yes the NRF and all other retail associations have the right to be angry, but they have done next to nothing to help themselves. They played a game whose rules were set by the card brands and used none of their extraordinary power and influence to tip the balance in their favour.

For example, I have estimated that the Top 10 retailers in the US alone account for almost 1 TRILLION USD in branded transactions. If we assume an average of 1.75% interchange, that’s 1.75 BILLION in fees the retailers have paid to ‘middle-men’. How much influence would you exert over those middle-men if it was your business?

So in summary;

QSA Companies: Keep your opinions of retail to yourselves, your self-serving diatribes are inappropriate. Serve your clients, don’t brown-nose the brands.

Card Schemes/Issuers/Acquirers: Use your incredible knowledge and combined talent-pool to lead the way in the removal of plastic, and therefore the need for PCI. It’s time to move on.

Retailers: Put aside your differences, stop bitching to the wrong people in the wrong way, and do something useful with your power. Focus on what you WANT, not want you DON’T want.

All of this boils down to one thing; what do consumers want? Most have no idea, but I do, as do thousands of others like me. Ask us.

…and it had better not involve yet another piece of plastic.

Security Program

What is a Security Program?

It occurred to me that after 15 years of consulting, 10 years of public speaking, 3 years of blogging, and saying things like; “All regulatory compliance falls out the back-end of a security program done well.” and; “If you fail to develop an appropriate security program, it’s the CEO’s fault and no-one else’s.” that I have never actually defined what I consider to be a good security program.

In my defence, a good (i.e. appropriate) security program is as unique as the organisation trying to implement one. However, like any other discipline, there are basics that ALL security programs must have to be successful.

All of the best security experts on the planet pretty much agree on these basics. But just try looking for something you can apply to your business and you’ll soon be as confused as I am when trying to read anything written by a lawyer. Regulatory compliance, greedy product vendors, incompetent consultants and a whole host of other factors conspire to take security out of the hands of those who need it most.

Nothing I am about to write has not be said by me many times over, or by a thousand others much smarter than me, but for some reason it never seems to stick. As much as I hate the concept of rebrand-it-to-sell (e.g. a ‘service on the Internet’ is now called The Cloud), I can see the attraction. If we could make security ‘sexy and new’, perhaps we’d have an easier time bringing back the basics. 99% of security lives and breathes in the basics.

For example, everyone knows that there is no security program without senior leadership (i.e. CEO) support. This is free, takes a fraction of a percent of the CEO’s time per calendar year, and has benefits well beyond anything you can imagine. But try getting it.

Anyway, on with the program detail, but first; If you don’t believe that a security program is a balance of People, Process, and Technology, stop reading, this will all be lost on you:

  1. Senior Management Support – Been over this a million times. If you don’t have it, stop here, you’re wasting your time. Can you have some security without it? Yes, but guess who will be blamed when things go wrong.
    o
  2. Governance Committee – Senior stakeholders who will run the program with the full and visible support from senior leadership. Governance runs everything from risk assessments to change control, and without this centralised function your security program will collapse like a flan in a cupboard.
    o
  3. Policies & Procedures – Again, if you don’t know by now how important this one is, don’t bother reading the rest, you’ll never understand.
    o
  4. Appropriate Security Controls – No, I do NOT mean technology! Technology supports security, it does not define it. Your controls will be a direct result of the risks determined by Governance, and the requirements as defined in your policies (requirement for hardening guides for example). Technology purchases are the last resort.
    o
  5. Vulnerability Management / Change Control – I don’t lump these together very often, but from a program perspective, they have similar results. i.e Don’t make things easy for the attacker by a) ignoring the evolving threat landscape, and b) introducing potential vulnerabilities without due diligence respectively.
    o
  6. Testing Program – Test everything, then when you’re done, go back and test it again. Repeat. You simply have no idea whether or not your security program is working until you test it. Test results feed back into everything done before it in order to make the necessary adjustments.
    o
  7. Security Awareness & Training – Again, if this makes no sense, you’re reading the wrong blog. None of the above works unless EVERYONE knows what part they play.

That’s it. Finished. there is nothing more to do for any organisation to develop an appropriate security program. Nothing here is complicated, perhaps that’s why people ignore it, it’s just not dramatic enough.

However, making this process simple can be extremely difficult, as is getting the program in place, and these difficulties should not be underestimated. It’s the difficulty, not the complexity that ruins most security programs, especially when you don’t have the support you need.

FWIW, done well, a security program based on the above will not only make you more secure than most of your competition, but give you demonstrable compliance with every regulation out there. How’s that for an ROI?