Author: David Froud

In a rather ludicrously titled article (yes, even for me!) ‘Too big to fail’ cloud giants like AWS threaten civilization as we know it” the author nevertheless addresses an interesting point. And while I almost entirely disagree with the final conclusions, they represent a valid, if extreme viewpoint. If those conclusions are a little self-serving, this can be forgiven in light of my own issues with some Cloud Providers.

The basic premise is that traditional hardware (servers etc.) sales are dropping, while cloud-based and managed services are on the rise. With the corresponding drop in hardware related skills (no demand), eventually we’ll be dependent on one of the big providers (Amazon, Google & Microsoft).

This is apparently very bad, as: “If one of these goes down hundreds of thousands of other companies go down too.” This is the “interesting point” I referred to earlier, unfortunately the reasoning presented simply makes no sense. Two examples provided are:

  1. power grid failures or natural disasters – with the fallout propagated worldwide; and
  2. AWS’ hiking of its UK prices post-Brexit as an example of how quickly customers could be affected.

First, suggesting the Google, Amazon or Microsoft have a single point of failure that could take them down globally is ridiculous. Second, with regard price fluctuations, this is likely the result of organisations choosing a provider based on price alone, and not performing adequate due diligence. In trying to save money by using US based provider, and not writing mitigating language into contract, you are the ones leaving yourselves exposed.

I’m really not picking on either the subject of the article, or the author, I’m just using this to demonstrate my point. Cloud services, done PROPERLY, are the future. Or without the stupid buzz-phrase; outsourced services over the Internet are the future of infrastructure management. The issue is that a lot of Cloud services are abysmal, and the due diligence performed by many organisations nothing short of a disgrace.

But outsource they will, and they should. For example, how many organisation really want to hire dedicated teams to perform all of the following;

  1. Design Operating System Hardening Guides;
  2. Build and maintain servers;
  3. Install and configure all relevant security software/application;
  4. Patching and Vulnerability Management;
  5. Data Encryption;
  6. Access Control;
  7. Logging & Monitoring
  8. …and the list goes on.

Whilst finding a single cloud provider to take care of this is almost impossible at this stage, that’s where it’s going. Only the economy of scale available to large providers can make these offerings cost effective enough to be an option for non-enterprise businesses. And frankly, the only businesses who actually care about how data is made available, are the ones being paid to make it happen for someone else.

The motivations behind the referenced article are rather simple to deduce; 1) they have a vested interest in selling hardware, and b) they can make more money through channel than Cloud.

Fair enough, but channel’s loss of market share, and their inability to pivot is entirely their fault. They are now suffering because they have never tried to put their products into perspective. The rush to maximise profit margins was at the expense of making themselves a truly valuable partner.

If channel had only put a consulting wrapper around their offerings, they could still be selling solutions, not stuck trying to flog pieces of metal and plastic.

Perhaps this article will make more sense now they they are feeling the pain; Attention Channels/Resellers, Don’t Forget Consulting Services!

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

There’s an old phrase that’s depressingly appropriate when it comes to the completion of Self Assessment Questionnaires (SAQ); “Not worth the paper it’s printed on.” At least that’s how it is for the majority of the ones I’ve seen, SAQ validation is universally performed badly.

The reasons for this are many. From acquirers leaving the choice of SAQ up to the merchant, to merchant indifference, to flat out incompetence, many SAQs are works of fiction. While the PCI DSS itself has undergone significant modification to ensure more appropriate validation, the SAQs have not followed suit.

For example, for a relatively simple requirement like ‘1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.’, the DSS requires all of this;

screen-shot-2016-10-15-at-10-51-49

The corresponding SAQs (A-EP, and D-M and D-SP) require just this;

screen-shot-2016-10-15-at-10-54-41

While the DSS requires full descriptions of HOW the requirements we validated, the SAQ requires just one of 5 tick-boxes; “Yes”, “Yes, with CCW”, “No”, “N/A” and”Not Tested”.

I fully understand that the SAQ requirements are completely tied to risk, however, EVERYONE is liable for full compliance against the entire DSS. The SAQ is just a reporting mechanism, nothing more. In other words, if you don’t validate properly, you’ll still be held fully accountable in a worst case scenario.

It follows therefore, that when validating your applicable SAQ requirements, you follow the Testing Procedures of the DSS. That way, should the worst happen, you can actually demonstrate appropriate due diligence. If you can “Describe how…” you sampled, examined, and tested firewall and router configuration changes, you cannot claim to have properly “Examine[d] network configurations”.

So, to help resolve this, and to once again demonstrate how sad I am, I have performed yet another mapping. This time I have mapped the applicable requirements as defined in all 9 SAQs to the validation requirements of the full PCI DSS v3.2. I did though go one stage further, and added a “Questions” sheet to help determine requirement applicability up front.

For example, if you do not retain full cardholder data post-auth, the majority of the encryption requirements become ‘Not Applicable’. Same for absence of wireless, no in-house application development, and so on.

Start with the ‘Questions’ tab of the spreadsheet (available here in Downloads) and answer “Yes” or “No” to each question. Now when you go to the ‘v3.2’ tab you will see which requirements are applicable to which SAQ (marked with a ✓). Now just choose your column and feel free to filter.

If I’m completely honest with myself – which I usually am – I know that there is little benefit to this document, but it may be of interest in these scenarios:

  1. Any merchant changing SAQs, going up a level, or adding a service – For example, if you’re a Level 2 Merchant and you’re going to kick up to Level 1, you’ll see just how much work you have to do. Or if you are adopting P2PE, you see just how much your SAQ validation is reduced.
    o
  2. Anyone who wants to see just how irrelevant the SAQs are in relation to real security – If all you do is complete an SAQ, you’ll be able to compare a minimum set of security controls (the full PCI DSS) to what you’re doing. Well, what you should be doing at an absolute minimum if you cared at all about your customers data.
    o
  3. Any entity wanting to validate their SAQ properly.

In 10+ years of providing PCI guidance, I have never seen an acquirer ask for validation evidence outside of an ASV scan. I doubt I ever will, so if you want to do security properly, great, but don’t use the SAQ as your guide. In fact, don’t even use the DSS for anything more than a rough guide, you’re better off with a real consultant.

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

One of Sun Tzu most quoted phrases in The Art of War states; “All warfare is based on deception.“

Sun Tzu was not in cybersecurity.

99% of the defence against hackers has nothing to do with deception. It’s about making things too difficult to be worth attacking in the first place. Very few of you reading this are ever going to be the specific target of a state-sponsored agent, or an organised crime ring. Threats to you will therefore be mostly opportunistic in nature. Bad guys are lazy, make things difficult and they will usually move on pretty quickly.

On the other hand, expose something to an opportunistic hacker that looks easy to break, and you will have his/her attention. You would not have had their attention otherwise. To make it worse, when they find out that they have been deceived, you have done the worst thing imaginable. You’ve pissed them off.

Now it’s personal, and for a hacker, this means they will be patient. Very patient.

This is bad.

So What is Deception Technology?o

According to TechTarget a deception technology is a; “category of security tools and techniques that is designed to prevent an attacker who has already entered the network from doing damage. The technology uses decoys to misdirect the attacker and delay or prevent him from going deeper into the network and reaching his intended target.”

You’ve already failed to detect the intruder through your other security controls / technology, so you should buy another tool to slow them down?

Even the very far from perfect PCI DSS has enough security controls defined to make breaches difficult enough. From hardening standards, to encryption, to access control, to FIM, to penetration testing, very few organisations need more. The issue is not the number or even type of controls in place, it’s the complete inadequacy of their implementations.

Why Deception Technology is a Horrible Idea

As far as I’m concerned, it should be possible to assume any organisation that implements deception technologies has or is:

  1. …completely optimised their security program – because why would you try to deceive before you’ve done your best to prevent, or detect with existing controls?;
  2. …the in-house expertise to perform the function – because who in their right mind would buy Deception-as-a-Service?;
  3. …ridiculous amounts of money to spend on cybersecurity toys – because even open source tools have a corresponding resource cost;
  4. …happy to draw the attention of the bad guys – because hackers hate a challenge, right?; and
  5. …a security chief who wants to be fired – because why else would they waste their time and the company’s money on something so pointless?

If you accept that you shouldn’t buy technology until your risk assessment process highlights a relevant functional gap, then consider this; In 15 years of performing security assessments at organisations both large and small, I have NEVER seen the need for deception technology. Never. Governance, yes. Policies and Procedures, absolutely. Incident Response, without doubt. Deception Technology, not even on the radar.

You Won’t Get Fired for Doing the Basics

Finally, every blog I have ever written harps on about the exact same thing; back to basics. If you were doing the established cybersecurity processes correctly, deception technologies would not be necessary. Every aspect of your security program must focus on baselining your environment to a known-good, and reporting exceptions. Nothing more.

But risk assessments, vulnerability management, change control, asset management etc are just not sexy enough to sell. If it’s not shiny and has a fancy new name, vendors can’t get a foot in the door. Demand generation is ruling the day, and only the vendors are seeing the benefit.

It’s not their fault though, you’re the ones buying their snake oil.

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

In “What’s the CEO Equivalent of The Peter Principle?” I posited that there are 3 kinds of CEO:

  1. Those good at starting a company;
  2. Those good at building start-ups to the point they can go public, or be acquired; and
  3. Those good at leading a company for the long-haul.

…with the theory being that unless the CEO knows which s/he is, s/he’ll eventually run a company into the ground. No CEO is really good at more than one, and I’ve met too many who aren’t good at any of them.

The CISO role is no different, and if you’re looking for one, you had better ask the right questions of your candidates. However, if you are a CISO or want to be one, then you must know which kind you are or you’re setting yourself up for failure.

What Are The 3 Types of CISO?

o

  1. The Planner: – The p-CISO comes in at the beginning of an engagement, before an organisation even knows what it actually needs. Their job is to design a security program that does the only thing it’s supposed to; support / enable the company’s business goals. The p-CISO must also write the Governance Charter, get the CEO to sign it, then implement the Governance Committee. 99% of all security programs fail at this stage, so this is perhaps the most difficult task of all.
    o
    Of the 3 types, this is the most creative, but also the least detailed oriented, which is why they probably should not try to run the program long-term.
    o
  2. The Executor: e-CISOs get things done. They take the hand-off from the p-CISO and put the agreed plan into action. While this may seem more like project management, there is a lot more to it than that. Putting a security program in place takes a shift in an organisation’s entire culture. Installing a firewall is easy, getting the CEO to accept full accountability for the ISMS is a Herculean task.
    o
    This type has the rare ability to focus on enormous amounts of detail, but is political enough to bring the people components together.
    o
  3. The Optimiser: o-CISOs are in it for the long-haul. These are the folks that take the still raw security program, and make sure it get fully instilled in the company culture and business as usual processes. They will also likely Chair or Co-Chair the Governance committee.
    o
    The most political of the 3 types, and it is the o-CISO’s incredibly difficult task to ensure that IT, IT Security, AND the business side all do their part. The depth and breadth of the position makes it one of the most difficult jobs imaginable.

Ignorance of these 3 types certainly goes a long way to explain why CISOs last less than 2 years on average. Organisations ask the wrong questions, and prospective CISOs have little concept of their own limitations.

I’m not saying that there is no overlap in these roles, there is. I’m also not saying that a single individual can’t be fairly good at more than one, they can. What I am saying is that, in practice, the skill-set required to be REALLY good at these roles is mutually exclusive. e.g. I have never met someone who thrives on creating something from scratch (p-CISO), have any interest whatsoever in baby-sitting something for the long-haul (o-CISO).

And that’s OK, you don’t just have one kind of doctor, or lawyer, why should a CISO be any different?

Unfortunately, too often the CISO role is seen as the ultimate goal in the career of a cybersecurity expert. But the fact remains that this role suits very few people long-term. Both p- and e–CISOs are senior level consultants, only the o-CISO is a long-term employee.

And let’s not forget; Make the CSO Role a Board Appointment, or Don’t Bother Having One, the CISO is no different.

I’d be very interested to hear what actual CISOs think of this theory?

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

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