Information Security Policies

Why Information Security Policies are Pointless

The title should be; Why YOUR Information Security Policies (ISP) are Pointless, but I figured this title was far more contentious/click-worthy.

If you’ve come this far, you’re in one of two groups:

  1. You’re horrified at my ignorance and want to rip me a new one (good for you by the way); or
  2. You’re thinking the equivalent of “I knew it!”, in which case you need this more than anyone.

When I say that your ISPs are pointless, it’s because in all likelihood they are. Assuming you even have a policy set (policies, standards and procedures), ~20 years of consulting experience has shown that they invariably:

  1. are not sponsored/supported/signed-off by the highest levels within and organisation – does anyone really care about something their bosses don’t visibly to care about?;
  2. are not managed by a governance function to ensure adherence to business goals / regulatory compliance / corporate responsibility etc – who else is going to do this? The CEO? A CXO by him/herself?;
  3. include no overarching framework policy that 1) spells out a commitment to security, 2) breaks down the responsibilities for everyone from the CEO to the interns, or 3) details the consequences for non-conformance – how well do buildings stand up without foundations?;
  4. are generic templates with zero attempt to fit them to the prevailing culture – sometimes the phrase “That’s not how we do things here!” is perfectly acceptable;
  5. are non-aspirational – it’s actually a good practice to set your policies above your current security capability, IF you have a comprehensive exception/variance process linked to a risk register / risk treatment plan as part of the framework;
  6. are not DIRECTLY linked to robust risk management processes to ensure full policy coverage and continuing suitability to the business – how do you know they’re right?, now and in the event of significant change?;
  7. are not part of an [annual] internal audit process to measure adherence – few companies even have an internal audit function, let alone one capable of assessing IT/IS policies;
  8. are not part of employee on-boarding and ongoing security awareness training programs – every role should have relevant policies assigned to it, and appropriate training should be continuous;
  9. are not maintained appropriately/consistently – you don’t need a librarian to do document management well, you just have to be organised; and
  10. are not distributed or made available to everyone whom they impact – “Policies, what policies?”

Bottom line is that I have never seen a policy set done well, and it’s not a coincidence that I’ve never seen security done well either. These two things go hand-in-hand and you absolutely cannot have one without the other.

Yes a decent policy set is ‘paperwork’, yes it’s bloody difficult and time consuming, and no, it’s not even remotely sexy, but don’t bother trying to get a security program in place without them. Seriously, don’t even bother, because it will fail.

Lego don’t send out a 4,000+ piece Death Star set without detailed build instructions, and that’s exactly what your policies, standards and procedures are; instructions on how to do security appropriately within your organisation.

So why don’t all security folks take this more seriously? Two main reasons; 1) they are so focused on technology that the processes fall to the wayside, and 2) they have tried over and over and finally gave up, electing to do what they can, knowing full well it will never be enough.

Sad, huh?

Security is about People, Process and Technology, in that order, because without a policy set you will have:

  • no understanding of the technology[ies] you will need – risk assessment;
  • no processes to run the technology properly – procedures;
  • no way to sustain the technologies moving forward – vulnerability management;
  • no understanding of what to do with technology output – incident response;
  • no-one who could perform the incident response even if you did – security awareness training.

A decent set of information security policies ties all of this together into a sustainable program, and if you still don’t think they are that important, you are simply not paying attention.

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

Security Good Practices

When Security Good Practices Aren’t Good Enough


For the better part of 20 years I have fought with – and sometime against – my clients to help them achieve a particular standards of security. Whether it was PCI, ISO 27001 or any other standard, all I have ever done my whole career is beg my clients to take security a little more seriously. I’d say that I have failed more than I have succeeded, security is just not a priority to most organisations. Kinda like insurance.

Recently however, I have had the distinct pleasure to be told that neither the ISO 2700X standards or NIST Cybersecurity Frameworks are enough, they wanted more. A lot more. In fact, they wanted security so good that they could actually use it as a selling point for their services. For security itself to be a distinct and measurable competitive advantage.

Once the shock wore off, we had to work out how we would actually deliver this. Not only have I never been asked for more than ‘good enough’, I’ve never actually thought about what truly great security looked like. For individual components, yes, but not for a soup-to-nuts security program. And I have certainly not given much thought as to how I would begin the implementation of one. What was the point?

So where did we start? First, we had to address:

  1. What standard(s) to use for alignment – like it or not, unless you align yourself to industry accepted good practices, it is far more difficult to demonstrate the ‘appropriateness’ of your security program. Any client with regulatory compliance obligations must bear this in mind;
    o
  2. How to determine what ‘great’ looks like – regardless of the request to go above and beyond, the final result has to be achievable. In an industry plagued with pointless technology and buzz-words, the final result has to be both achievable, and justifiable. If you cannot demonstrate a meaningful ROI you have wasted their money;
    o
  3. What’s is foundational, and what is a separate project – In security, there are a number of basics you cannot do without. What I call core concepts. Management buy-in, governance, policy set etc. Then there are things that can begin as a project before consolidating the output with the whole (logging and monitoring, access control etc.);
    o
  4. What are the client’s business goals / principles – as I’ve said too many times; security is only here to enable the business. If a security solution does not map to a goal it’s wrong; and
    o
  5. How long do we have? – The implementation of any security program takes time, and the more you want the longer it takes. The desire for great security has enormous ramifications on resources and capital expenditure, and absolutely cannot be rushed. The resulting program must not only be sustainable, but it has to be embedded in the culture. We’re talking years, not months, and this must be understood at all levels.

You will notice however that at no point were we concerned with technology. Yes, technology will be enormously important – there can be no great without automation – but technology choices are driven by the processes they are meant to enhance, not a solution by themselves. Besides, it’s always the functional requirements you define first as you have no idea who’s going to be managing it yet.

So we ended up going with a combination of ISO 27001 and the NIST Cybersecurity Framework (v1.1), but we mapped these to what we considered to be the most logical groupings encompassing a full security program. Governance, Policy Set, Risk Management, Asset Management and so on. There are 18 of them.

But even this combination could only ever represent average, as ‘compliance’ with either standard is achievable long before you could be considered secure. So then we had to define a scale where average was where it should be, in the middle, and ‘great’ went up from there. We went with the ages old Capability Maturity Model (CMM), then mapped all of things we believe represent each level. ‘Defined’ = average.

For example, this is what Governance looked like:

The are simply no standards or documents for what happens next. The client has to understand what each of the groupings means, then they have to choose how far up the scale they wish to go. This is a long conversation, and if the results of this conversation aren’t understood at the Board level, we’re already derailed.

There are also many dependencies to consider. You can’t have great vulnerability management without very mature asset management, or business continuity without top notch incident response for example.

And above all, if the implementation of the program is not simple, with clear direction and guidance, the people who have to do the work will never get on board. Nor will they ever be able to manage it after we’re gone.

Honestly, I have no idea how this is going to end up, I’m in new territory for the first time in many years. This is also the first blog I think I’ve written where I’m not either trying to help, or bitching about someone/something.

I just thought I’d share something positive for a change, and I look forward to sharing my numerous mistakes and lessons learned! 🙂

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

Ransomware

Ransomware, Stop Focusing on the Symptoms!


Once again, a ransomware outbreak (WannaCry) has dominated the media headlines, and cybersecurity vendors are scrambling to capitalise. At the time of this writing, the top 3 (non-paid advertising) spots on Google to the search phrase ‘ransomware’ are 2 vendor ads, and one ad for cyber insurance. All but one thereafter on page 1 results are doom and gloom / blamestorming ‘news’ stories. The one exception? Good old Wikipedia.

This is the exact same thing that happened the last time there was a ransomware attack, and the time before, and is the exact same thing that will happen the next time. Because there will be a next time.

From the Press’s perspective, this is just what they do, and you’re never going to see headlines like; “NHS Goes 6 Months Without a Breach!”, or “Acme Co. Blocks Their 1,000,000th Attempted Hack!”. Only bad stuff sells, and frankly no-one gives a damn about cybersecurity unless they’re a victim, or they can make money off it.

I have dedicated many blogs to the criticism of cybersecurity vendors for being little better than ambulance chasers. This blog is no different. So let’s be very clear;

Ransomware is NOT a TECHNOLOGY problem!!

If your organisation is the victim of an attack, 99 times out of 100 it’s entirely your fault. Either your people, your process, or a combination of both were inadequate. And I’m not talking about your security program not being cutting-edge/best of breed, I’m talking about it being wholly inappropriate for YOUR business. It does not matter what business you’re in, you have a duty of care to know enough about security to address the issues.

Yes, the bad guys are a$$holes, but we’ve had bad guys for millennia and they will always be part of the equation. Security is, and has always been, a cost of doing business, so suck-up and take responsibility. And if you aren’t even doing the security basics, not only will technology be unable to help, but you deserve what you get.

Harsh? Yes, absolutely, because the basics don’t bloody well cost anything! Not in capital terms anyway. It takes what I, and every other like-minded consultant out there have been preaching for decades;

Common sense!

  1. Don’t keep your important files on your computer –  Keep your data on external encrypted hard drives and/or cloud drives. If it’s not ON your system, you can’t lose it. In a perfect world you can Forget the Systems, Only the Data Matters;
    o
  2. Patching – Your systems would have been immune from WannaCry if you had installed a patch made available by Microsoft in MARCH! I could rant for hours about this one, but there’s no point. You know you should be patching your systems, and if you don’t know that, you are clearly not from this planet. Your laptop or your PC is just a means to manipulate the data. Ideally you should completely reinstall your PC/laptop every 6 months to ensure that you have only 1) the latest and greatest versions of everything, 2) no extraneous crap you no longer use/need, and 2) no hidden malware;
    o
  3. Back-Ups – I don’t care how little you know about computers, if you have one and are online, you damned well know you should be backing up your data. And not just to one location, several locations. Everyone from your operating system, to your bank, to your grandkids have told you about back-ups, so there’s no excuse.  External hard drives are cheap, and the online Cloud drives are numerous. Use them all. Yes, I know this is different for a business, but not much;
    o
  4. Don’t open every attachment you get – I feel stupid even writing this one, and it’s not just me talking from a position as a security professional. This is me talking from the position of someone who can read.

So from an organisation’s security program perspective, if you’d had 4 basics in place, WannaCry would not have been an issue:

  1. Policies, Standards and Procedures – The dos, don’ts, how-tos, and what-withs of an organisation;
  2. Vulnerability Management – where patching sits;
  3. Incident response – where back-ups sit; and
  4. Security Awareness Training – self-explanatory

SOME technologies can make this stuff easier / more efficient, but fix the underlying processes and people issues first. That or get yourself a huge chunk of cyber insurance.

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

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 by 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 ask you for? What could anyone reasonably expect 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 security program 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.

The 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 elements 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 95% 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; and
  3. Any security vendor offering “GDPR Compliance” is at best telling you 5% 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 the 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!]