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!]

Screen Shot 2016-08-13 at 12.58.57

Can Governance Replace the CISO?

Perform research on IT Governance models and you’ll eventually come across the concept of People, Process, & Technology (The Golden Triangle). Yet another concept whose origination has been lost in time (it was not Bruce Schneirer), but one whose evolution has polarised the security industry.

On the one side you have the technology-first advocates. Even a security icon like Bruce Schneier says; “We rely far too much on policy and people, neither of which are reliable, especially when dealing with fast-changing, large scale infrastructures.“. Oddly enough you’ll find most of the security product vendors in this camp too. I know, weird huh?

Then you have the side that I’m on, that says all the technology in the world can’t fix stupid. The enormous benefits that can be derived from technology are only achievable if the people put the processes in place to make the technologies effective.

In cybersecurity, technology can only enhance, it cannot fix.

Yes, of course technology is critical, why do you think I rage against PCI’s ‘daily review’ of logfiles so much? No, I do not believe that an organisation can ever achieve good security without the automation that only technology can bring, but putting technology first is the definitive cart before the horse.

In cybersecurity, technology can only enhance something that already works, it cannot replace it entirely.

So, to me, the job of the CISO is to get the three aspect of the golden triangle into line with the only things that matters; the business goals. In the digital age, technology is the ultimate enabler, and the CSO/CISOs the ultimate facilitators of that technology. The IT security function gets involved in everything from M&A to compliance, from incident response to internal audit, it’s the CISO’s role to bring it all together into a sustainable program. One that that is only ever appropriate to the business’s needs and no more.

But none of this is possible without Governance. The CISO, as a facilitator, is only a bridge between the business goals and the means to get there. It’s the Governance function that gets the job done.

Also, not every organisation can afford a CISO, and frankly nor should they even contemplate one if there is no discernible return on investment. This is where the Virtual CISO can come into play, and from my perspective, the only reason to consider one. It’s the v-CISO’s job to train the governance committee (or whatever it’s called) to do what CISOs do.

Too many organisations are instantly turned off by the word ‘Governance’. At best it’s seen as unnecessary bureaucracy, at worst it’s perceived as some kind of dystopian ‘Big Brother’. Nothing could be further from the truth; it’s not a department, it’s not an institution, it’s a function, one designed to help keep a business IN business.

EVERY organisation needs governance, regardless of size, region, or industry sector. The governance charter, membership, responsibilities, and operation will vary considerably, but all need to be appropriate, and of measurable benefit.

Only someone with the skill-set of a true CISO can put this in place in such a way as to be sustainable without them. But only a Governance function can keep it going.

[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!]

Screen Shot 2016-08-10 at 10.28.02

The Evolution of the PCI DSS, From v1.1 to v3.2

In honour of the SSC’s 10th year in power [oops!] business, I thought it would be interesting to run a little retrospective.

On December 15th, 2004, a day that will live in infamy, Visa released the Payment Card Industry Data Security Standard (PCI DSS) v1.0.

~2 years later, the PCI Security Standards Council (SSC) was formed, closely followed by the release of DSS v1.1.

Six iterations later, here we are at v3.2.

To emphasise yet again just how sad I am, I chose to map v1.1 against not just the v3.2 standard itself, but its corresponding Report on Compliance (RoC) Reporting Template . While this seems like an extreme comparison (download it here), I wanted to get the full flavour of just how PCI compliance assessments have evolved in the 10 years since v1.1’s debut.

At first blush, they would appear to be radically different. For a start, v1.1 was just 17 pages long, v3.2 is 139 pages, and the RoC Reporting Template is a whopping 198 pages! But what becomes clear very quickly is that most of the changes are related to assessment guidance, validation guidance, and wave after wave of clarifications.

I mean, seriously, excluding the Bill of Rights the US Constitution has only been amended 17 times in 227 years!

Take Requirement 1.1.1 for example, this is what v3.2 looks like in the v3.2 RoC Reporting Template:

Screen Shot 2016-08-10 at 10.46.04

This is from v1.1:

Screen Shot 2016-08-10 at 10.39.46

Radically different, right?

Not really, everything in 1.1.1.a – 1.1.1.c is validation guidance, nothing more. In other words, if the original v1.1 assessors were doing a good job, this is how they would have assessed their clients back in 2006.

But they weren’t doing a good job. Not even close. Even into v1.2 QSAs were still filling out ‘Yes’ for in-place and ‘No’ for not-in place.

What we have seen from v1.2 onwards is the gradual increase in detail related to the validation that has to be performed. From v2.0, a separate document was provided to QSAs, the ‘ROC Reporting Instructions for PCI DSS v2.0‘ that broke down what was expected during compliance validation.

This was also implemented poorly by a lot of QSA companies, while others were clearly unaware of its very existence.

Roll on DSS v3.0, the version that caused by far the biggest stir in the PCI community since the DSS’s initial release. There were shouts from the merchants that the SSC had just raised the bar to unacceptable heights. There were even complaints from QSAs that the ‘new’ instructions would increase the workload to the point assessments would be unprofitable. And worst of all, the more unscrupulous QSA companies actually raised their prices! Here are my thoughts on those companies; PCI DSS v3.0 – Do NOT Pay More For Your QSA Services!

The fact is that v3.0 was a consolidation of the DSS Requirements and the Reporting Instructions, and little more (detailed mapping here). If the QSAs and the organisations they were assessing had been performing assessments properly, the effects would have been minimal.

How Similar is v1.1 to v3.2?

About 82% according to my calculation. Obviously this is at the overarching control level, not the validation detail. v1.1 had exactly zero guidance in that regard.

Other than some wording and requirement numbering changes the controls have remained remarkably consistent.

…and the ‘major’ changes aren’t really that major. Certainly nothing outside of basic common sense:

  1. Req. 1.1.3  – Cardholder Data Flow Diagrams – [How would you determine scope in the first place?]
  2. Req. 2.4    – Asset Inventory – [Seriously, how could you possibly achieve PCI compliance without one?]
  3. Req. 5.x    – Make sure anti-virus are actively running etc. – [Really!?]
  4. Req. 7.x     – Additional requirements around job classification etc. – [RBAC is RBAC, this should never have needed changing.]
  5. Req. 8.6    – ‘Other’ Authentication Mechanisms – [About time non-password stuff was introduced.]
  6. Req. 9.3    – Physical access based on job function – [As opposed to?]
  7. Req. 9.9     – Protection of Terminals (only affects retail) – [Sigh…]
  8. …etc…

So What Are You Saying?

There are two ways to look at these results:

  1. The main controls of the DSS were correct from the very beginning and there has been no change in either the threat landscape, or security technology; and
    o
  2.  The card schemes do not WANT to make significant changes, because they already consider the controls to be risk reduction enough. Not to mention the poo-storm that would descend on them if they did.

I think we all know that the first option isn’t true, so that leaves the second. And can you really blame them? Besides, what does it really matter, the DSS will never have the opportunity to improve much beyond minor clarifications. Payment cards just don’t have enough life-span to warrant anything else.

Nothing more to add really, now I need to go get a life.

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

Don't Hate the Salesperson

Don’t Hate Salespeople, Hate the Person

[OK, so you shouldn’t hate anyone, but; “Don’t Have Significant Issues With…” is nowhere near as catchy.]

In an otherwise spot-on article by Peter Smith; “Why do we hate (our own) sales people?“, he made what I believe is a fundamental error. Especially given his premise.

He says of salespeople that they are the “…life blood of the company…”, that; “If they don’t sell, the rest of the company doesn’t work.“, and finally that “These are your top performers.“. It’s that many salespeople actually see themselves this way that causes a lot of the resentment or even hatred.

There is absolutely no questions that sales is a critical function in any organisation, but it’s not the most important. There is no such thing as a most important department. It’s like saying the heart is the most important organ in body, just try living without your liver.

Who makes the products or services they sell? Who delivers them? Who arranges all the financing etc? Who ensures the contracts are in order? Without any one of these things no company can survive. A real salesperson is only ever as good as the things they sell, and the teams around them.

I say a ‘real’ salesperson because they are the ones with both the integrity to only sell what the client needs (not asks for), and to use his/her entire support team in the process to ensure mutual benefit.

From my experience, the majority of my issues with salespeople fall into three main categories:

  1. Lack of Product/Service Knowledge: We’ve all met salespeople like this, all smiles and no substance. This is not a salesperson, this is a clown, a real salesperson is extremely well versed in his/her wares. They may not be an expert in the overarching subject (cybersecurity for example), but they know who is, and whom to bring to the table when required to answer the prospect’s questions. The best salespeople I’ve worked with are facilitator who piece together solutions by putting the right people in front of each other.
    o
  2. Selling to Their Quota: I use the word hate way too often, but I REALLY hate the American way of selling. The quota system is ridiculous, and forces salespeople into a never ending spiral of price compression and end-of-quarter discounts. You sell my time as a consultant for half what it’s worth just to reach your target and we’ll having a very short conversation. Words like ‘fired’ and ‘incompetent’ will be used liberally.
    o
  3. Selling Outside of Their Skill-Set: To me there are two types of salesperson:
    o
    Hunters
     – Very aggressive, easily bored, hates detail, DESPISES paperwork. Basically, these folks want to get in, get the deal signed, and move on to the next ‘battle’.
    o
    Growers – Less aggressive, and tend to prefer to relate to the client on a more personal level. These are the folks who will take the initial sale and turn it into years of up-sells / cross-sells though their deepening understanding of a) the client’s business b) the client’s people, and c) the state of their security program.
    o
    Selling outside of your skill-set is a sure way to mess the whole thing up for everyone.

A real  salesperson does none of these things, and I have met some truly exceptional salespeople whom I am also honoured to call friends.

So if you hate salespeople, you either have a company full of bad ones, or you have no idea what they do. Selling is difficult, VERY difficult, and a good salesperson has a skill-set most of us cannot even hope to duplicate. As an introvert, the very thought of doing what they do every day gives me the willies. And that is just the tip of the iceberg. From research on prospective customers, to getting the first meeting lined up, to pitching an appropriate statement of work, the amount of work that goes into a sale is enormous.

From the other side, and as Peter Smith said very eloquently; “If a person is worried about having sales in their job title, then they probably do not have the right DNA.“.

Salespeople are necessary, they are NOT a necessary evil. But if you think you have what it takes to be one, try it for 6 months, 99% of you will beg for your old job back.

I know I would.