Policies & Procedures

Information Security Policy Set: It All Starts Here

Information Security Policies, or more accurately; Policies, Standards, & Procedures (a Policy Set) are the cornerstone of every security program. It is therefore rather odd, that not one client I have ever helped started with any of them in place. While not everyone is a security expert, everyone can be security savvy enough if, and ONLY if, what they are supposed to do is written down!

That’s what a good Policy Set is; an instruction manual on what to do, what not to do, why, and how.

I have written too many many times on why a good Policy Set is important, and have used the term ‘baseline’ more times than I’ve had hot dinners. I have described what a Policy Set consists of, and even how to manage one, but what I have not do up till now was to describe how to find a Policy Set that’s right for your business.

First, you may be wondering what’s so hard about finding policies. And I agree; type “information security policy example” into Google and you’ll get tens of millions of hits. Universities readily publish theirs for the world to see (e.g University of Bristol), and a whole host of organisations even make editable versions freely available. On top of that, online services with ridiculous promises like “THE ONLY WAY TO GET AN INFORMATION SECURITY POLICY CUSTOMIZED FOR YOU IN AN HOUR, GUARANTEED.” are depressingly common.

The challenge is that if you’re looking for information security policies in this fashion you clearly have no experience implementing them, let alone actually writing one yourself. An overly-dramatic analogy; I found thousands of instructions on emergency appendectomies, would you now trust me to perform one on you? A good Policy Set is one that is appropriate to your business. Not your industry sector, not the prevailing regulatory requirement, your business!

Therefore, if you don’t have security expertise in-house, it is very unlikely that you know the right questions to asks providers of Policy Sets. The vast majority of vendors will sell you what you ask for (can’t really blame them for this), so ensuring you get what you actually need is entirely based on the homework you performed beforehand.

To that end I have written something vaguely resembling a white paper to help you. In the imaginatively named ‘Choosing the Right Policy Set‘ I have broken the choosing of a policy set vendor into 15 Questions. These could easily form the core of an RFI or RFP if you were taking this seriously enough.

Simple questions like; “Can you provide a Document Management Standard and Procedure?” or “Does your service include a mapping of policy statements to the PCI DSS?” are sometimes not even considered. But when you consider that the choosing of a policy set can be the difference between compliance and non-compliance, it makes sense to ask them. Up front!

90% of organisation will end up either throwing something together themselves, or buying the cheapest option available. That’s fine, when regulatory fines start getting handed out they will realise just how expensive their choice was.

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

Reasonable Security Measures

GDPR: How Do You Define ‘Appropriate’ Security Measures?

Ask a lawyer what ‘appropriate’ or ‘reasonable’ means and they’ll come back with something like; “What would be considered fair by a disinterested third party with sufficient knowledge of the facts.”, or “Fair, proper, or moderate under the circumstances.”

Now translate that into what kind of security measures are considered appropriate? How would you justify that what you are doing is reasonable, fair, or proper under the circumstances?

Because that’s what you’ll have to do if things go wrong under GDPR. You’ll have to justify that the measures you took to protect personal data were underpinned by an appropriate program for measuring and treating risk. If your breach was shown to be anything other than a determined attacker, all you’ll have in your defence will be poor excuses. This is no better than negligence.

When you consider that the General Data Protection Regulation (GDPR) – and every other regulatory compliance for the matter – was written by lawyers, should we not be able to work out what ‘appropriate’ means for a security program? After all, lawyers have no problem defining the word ‘reasonable’, they even apply it to their fees!

The good news is that the process is not only well known, it’s simple; it’s called Risk Management, and it’s been around for decades.

Step 1: Complete your Asset Register;

Step 2: Map your assets to your business processes (which should already be mapped to revenue);

Step 3: Map your business processes to your business goals;

Step 4: Run a Risk Assessment against all business processes and / or key IT systems;

Step 5: Document the business impact of each risk (mapped against both revenue and business goals);

Step 6: Document Senior Leadership’s risk appetite against each business goal;

Step 7: Perform full analysis of security controls, determine if there are any gaps between the current state and the risk appetite;

Step 8: Fill the gaps;

Step 9: Document everything; and

Step 10: Repeat annually, or prior to any major changes.

Now put yourself in the shoes of an auditor after you have been breached. What are they going to task you for? What could anyone reasonably expect of you to have in place if you were taking your duties seriously?

If I was an auditor I’d ask for 5 things up front, as without them I know there is no way you have an appropriate security program in place:

  1. A mapping of your policies, standard and procedures to whatever security framework you based your on;
  2. Your risk assessment procedure, and the results of the last one conducted;
  3. Your risk register;
  4. Your change control procedure; and
  5. Your incident response procedure.

At this stage I would care nothing for your technology, or how much you spent on it. A technology purchase outside of a properly defined business need is nothing more than smoke and mirrors. Besides, no regulator has ever tried to qualify how much you spent. It’s up to you to show why you spent what you did, and why you didn’t spend more.

Thing thing to bear in mind here is that the validation of ‘appropriateness’ is not a conversation, it’s documentation. It’s not even evidence of the technologies you have running, it’s showing that the technologies you do have meet the risk you have defined. While from a lawyer’s perspective, appropriate is demonstrated by precedent, in cybersecurity, appropriate is demonstrated by the extent and capability of your security program.

Complying with the cybersecurity of the GDPR is simple, every step is written down for you somewhere. There are a few things to bear in mind though:

  1. GDPR is 90% about how you get the data, and what you then do with it when you have it. Anything you spend on security should be justified against the business goals, not a compliance requirement;
  2. There is no cyber insurance against loss of reputation, this should not be about the money;
  3. Any security vendor offering “GDPR Compliance” is at best telling you 10% of the story, at worst, is lying to you.

While I agree it may be difficult to sort through the good advice and the crap when it come to this stuff, there is no excuse for  doing nothing. GDPR and every regulation to come will not change the basics, security will be same regardless.

The issue is not regulation, it’s that organisations still aren’t asking the right questions.

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

Don't say no

In Cybersecurity? Remove “No” From Your Vocabulary!

In the vast majority of organisations for whom I’ve provided guidance, the security departments are seen as something to work around, not alongside. In not one of those organisations was security actually seen the critical and intrinsic-to-the-business asset is can, and should be.

While I have written incessantly about this all being the CEO’s fault for not creating the necessary culture, the fact remains that most security professionals do themselves no favours. However good intentioned our actions may be, most of us completely miss the point. Like it or not, our entire existence is predicated on achieving the following:

“To provide the business with all the information, and as much context, as we can to enable them to make the best decision they can.”

Yes, that may include decisions that we in security would consider completely unacceptable, and would likely never make ourselves. It also may even include decisions that turn out to be really bad ones, but that’s just as much our failure as theirs.

The bottom line is that if we cannot speak the business’s language, if we are unable to convince them of the risks, we have failed them. There is no room for towering egos or hubris in security, it does not matter what we want, it only what the business needs. This will never be our decision, and we should never expect the business to speak our language.

I’m not saying that if you’re a cybersecurity professional that you have to say yes all the time, but you should avoid saying no whenever possible. Frankly, it’s not your job to do so. And as much as we would love to believe that as security experts we’re here to help, and that we have the best interests of our clients at heart, we will never be anything more than enablers. What’s more, if we’re anything less than that, there’s little point in having us around.

In the movie Office Space, one of the most cringe-worthy moments was when Bill Lumber reveals the “Is this good for the Company” banner. I remember laughing at the ridiculousness of the message, and laughing again when our hero tears it down. Almost 18 years later, here I am expounding the exact same message as that banner.

Why?

Because in security, we rarely have enough knowledge of the company’s big picture to put our guidance and recommendations into the right context. Even if we know that the company’s long-term goals are, unless we sit on the board we are in no position to appropriately address the risk appetite. A Sword of Damocles scenario to us, may well be a necessary gamble to keep the business competitive.

That leaves us only 2 things to do:

o

  1. Explain risk in the format they respond to best; detail the impact of not doing what we suggest; provide suitable alternatives; and
    o
  2. Cover your arse by having THEM sign-off on the residual risk.

The business does not need our approval to proceed with even the most egregious risks, but that does not mean we have to like it. Legal have far more power than we’ll ever have, but even they have to compromise. That said, we are fully entitled to document our objections as part of the final sign-off, but we should never take this personally.

As a corollary to the last paragraph, never, EVER say “I told you so”! Given that it’s likely partially your fault that senior leadership didn’t make the right decision, your only focus should be to help mitigate the negative impact. Take the high road, you’ll be employed longer.

In the simplest terms, map everything on your Risk Register to the business’s goals, and only worry about the things that impact them. Doing the right thing in security is rarely, if ever, measured by security metrics, it’s measured by the company’s success.

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

CISO Lifespan

Why CSOs / CISOs Only Have a 2 Year Lifespan

In previous blogs I expanded upon two main reasons why CISOs seem to have such a limited lifespan, and why the role is currently one of the most difficult senior leadership roles to both fulfil, and stay in long-term.

In Make the CSO Role a Board Appointment, or Don’t Bother Having One I touched upon the fact that so few CSOs; 1) are hired by the right people or for the right reasons, 2) report to the correct hierarchy, and 3) have the necessary support from the people from whom they need it most.

In The 3 Types of CISO: Know Which You Need I tried to explain why there is effectively no such thing as an ‘all-rounder’ CISO, so expectations are already completely out of line with reality.

I’ve now come up with a 3rd; Expecting the CISO alone to fix everything.

While this may be a byproduct of the first two, it is nevertheless important enough to be addressed by itself. And for once, I can’t actually blame the CEO entirely for this issue, the CISO is every bit as culpable.

Consider this scenario; An organisation, for whatever reason, decides it needs a security expert in senior management. Even if the BoD does get involved from the beginning, the organisation will end up writing a job description of some sort. This is no different from going to the Doctor’s, diagnosing yourself, and writing your own prescription.

This description will then be advertised in some fashion, guaranteeing that the only people who respond are the ones wholly unqualified to fill it. In the same way that anyone who wants to be in politics should be stopped from doing so, anyone who responds to a CISO role that they didn’t draft themselves has no idea what they are doing.

There is only one exception to this, and that’s if the organisation has already put the basics of a security program in place and need someone to optimise it. Everything before this is a series of consulting gigs, the aim of which is to prepare the organisation’s security program to the point a CISO can come in and run with it.

So, whether you’re an organisation looking for a long-term CISO, or a CISO looking for a long-term gig, what do you do?

A Security Program in 10 Difficult-as-Hell Steps

o

Clearly there are many steps in between these, as none of this appropriately addresses two of the most important aspects of any security program; 1) Senior Leadership’s role in changing the corporate culture, and 2) a Knowledge Management program personified by documented processes and procedures.

But in no way do I wish to downplay the CISO role to one of a babysitter, it is still one of the most difficult roles imaginable. However, I have never met a CISO who joined an organisation at Step 1, and was still the CISO a year or so later. Because the CISO role is perceived by many security professionals as the pinnacle of their career, too few ask the hard questions before committing;

  1. Has the organisation followed the 10 steps? – If no, where are they in the process?. If yes;
  2. Am I right for the job? – If no, can I help them find someone who is. If yes;
  3. Do I really want the job? – Go in with your eyes wide open, or again, walk away.

As long as both the organisation and the prospective CISO are fully aware of these issues, there is no reason a CISO can’t go the distance. That said, there is no reason a security program can’t be put on track without one…

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

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