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

ISO 27001 Certification

How to Begin Your ISO 27001 Certification Project

There are many consultants with significantly more ISO 27001 experience than I have. And type “how to begin ISO 27001” into Google and you’ll get ~8.2 million hits. So what makes me think I can do any better?

Actually, I not saying I can, but I am saying that my style of consulting seems to be conducive to getting such difficult projects off the ground quickly. Or at all for that matter. No security project is more difficult that implementing an ISMS.

In last week’s blog; ISO 27001 Certification, Is It Really Worth It? I stated that the top 5 reasons that ISO certification projects fail are:

  1. Grossly underestimating the level of effort;
  2. Doing it just to land a big contract (or for marketing purposes);
  3. Tying the certification to an overly aggressive deadline;
  4. Ignoring the expert help; and
  5. Having no business goals in mind.

It follows therefore that to make certification a success, you must overcome these challenges at a minimum. Sadly, nothing I say from this point point forward will be in any way new. Some of what I have to say has been said dozens of times by me, and thousands of times by my peers and betters.

The Challenges

  1. Grossly underestimating the level of effort – Symptomatic of one thing; asking the wrong questions. If you had asked the right people the right questions you would KNOW just how difficult an ISO certification project is. No certification should be undertaken lightly, but there are more than enough ISO experts out there to make the level of effort abundantly clear.
    o
  2. Doing it just to land a big contract (or for marketing purposes) – While I can empathise with this one, allowing what amounts to greed to provide the entire impetus for something that requires a fundamental shift in culture is naive at best. The promise of a big contract can, and often does, provide the initial business case for ISO certification. But to then focus entirely on doing just enough to land that project is a total waste of time and effort. Many good consultants will rightly walk away from such projects. It’s our reputation too.
    o
  3. Tying the certification to an overly aggressive deadline – Usually an extension of 2 above, and will invariable derail the project before it begins. If all you’re focused on is a looming deadline, nothing will be done properly, nor will it be sustainable. Remember, ISO certification requires 6 month health checks, an unsustained ISMS will result in the removal of your certification. Quite right too.
    o
  4. Ignoring the expert help – You don’t go to the doctor and tell them you have a brain tumour. You tell them you have a headache and let them do the rest. So why would you hire an ISO expert them argue with every step of the way just because you don’t like what you hear? A good consultant will not ask you for anything they already have, or they do not need, so either do the work or stop the project if it’s too much.
    o
  5. Having no business goals in mind – Contracts, even very large ones, are not business goals, they are a means to achieving a business goal. Done correctly, an ISMS can enable almost every goal you’d care to mention. Done correctly. Before you begin your project, find out what your CEO’s goals are and map the ISMS efforts to them. Miss this step and you will fail every time.

I use the word ‘recommend’ very carefully, but I HIGHLY recommend that you put all the relevant stakeholders through a 1 day ISMS training session to set the scene. Without this context, you will have no support.

If the CEO can’t even make an appearance at this session, that will tell you all you need to know about how your project is going to go.

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

ISO 27001 Certification

ISO 27001 Certification, Is It Really Worth It?

For the last decade, ISO 27001 certification has been the de facto standard for security programs across the globe. The only problem is, few organisations can be bothered with it. In the years of its existence, I have been asked about implementing a total of twice.

Why?

The reasons are numerous, and vary from organisation to organisation. However, they most often fall within these categories. The client has:

  1. never actually heard of it;
  2. doesn’t care about cybersecurity;
  3. thinks it’s too difficult;
  4. thinks it’s too expensive; and
  5. cannot see a return on investment (ROI).

But the biggest reason I have not been involved in ISO that much?… The Payment Card Industry Data Security Standard (PCI DSS). Which coincidentally, began at almost the same time.

All by itself, PCI has sucked the security budgets out of enough organisations that there was little left for anything else. And if I’m honest, because of PCI, I haven’t had to go looking for any other work.

Think about that for just a minute…

A very basic, controls-only standard, related to a single form of data, that’s not even a law has driven enough business my way that I have not had to worry about diversifying.

And frankly, I still don’t, but with what’s going on here in the EU, we are all going to need something better. From the General Data Protection Regulation (GDPR) to the Payment Services Directive (PSD2), the regulatory landscape is finally making real security a necessity.

It follows therefore that organisations will begin looking to ISO for options.

And that’s really the point, can the ISO standards actually help, or is the 2700X series just a bunch of meaningless paperwork? At first glance, it certainly looks that way, and few organisations choose to go any further. And the ones that do, get so lost in the paperwork that they forget why they are doing it. It’s only when the framework is fully customised and implemented, that you see its true and significant benefits.

However, before you look to ISO, you absolutely MUST do your homework! You have to know exactly what an Information Security Management System (ISMS) is, why you’re doing it, and how you’re going to keep it going. If you can’t answer those questions, don’t start, because you will never cross the finish line.

The biggest killers of ISO certification projects, are, in this order:

  1. Grossly underestimating the level of effort;
  2. Doing it just to land a big contract (or for marketing purposes);
  3. Tying the certification to an overly aggressive deadline;
  4. Ignoring the expert help; and
  5. Having no business goals in mind.

These are usually exacerbated by not getting senior leadership support, and then failing to tailor ISO to your needs. So what organisations end up with 99 times out of 100 is a stalled project and an external consultant taking all the blame.

ISO 27001 certification is bloody difficult…

…just accept that from the beginning. It requires commitment from every aspect of your organisation, and will only be effective if you enable the culture shift necessary to embrace it properly.

Strangely enough though, it actually looks fairly simple, as the ISO 27001 standard itself is only 30-odd pages long and only 114 controls. However, for every 1 of those controls, there are an average of 4 additional aspect to consider from the NINETY-odd page ISO 27002. Then, if that’s not enough, you must show some kind of evidence that you actually doing what you say you are!

For example, the very first ISO 27001 control is “A.5.1.1 – Policies for information security – A set of policies for information security shall be defined and approved“. Sounds simple enough until you realise that there are a minimum of 19 suggested ‘Implementation Guidance’ factors behind it.

From requiring that Information Security Policies address; “business strategy” and “regulation, legislation and contract“, to the suggested ‘examples’ of “policy topics”, A.5.1.1 becomes a project all by itself. Then, assuming you get all this paperwork together, you have to ensure that the policies are; “communicated to employees and relevant external parties in a form that is relevant, accessible and understandable to the intended reader, e.g. in the context of an “information security awareness, education and training programme” (see 7.2.2).” Finally, you then need to provide some ‘record’ that this is all implemented , or that you have a risk treatment plan in place that shows you’re going to get it implemented …how …and when.

There are 114 of these, and even if you decide a few of them are not relevant to you, you must fully justify their EXclusion.

Not trying to put you off, the implementation of an appropriate ISMS is one of the best things you can do for your business as a whole. Just make sure you start out the project for the right reasons, with the right support, and the right goals in mind. And for GOD’S sake, get an expert in for a day FIRST to show all major stakeholders what to expect BEFORE you commit to the full project!

I see ISO 27001 certification becoming a must-have for almost any business, but only if it’s done properly.

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

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 support (i.e. CEO). 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.

8 Steps to an Appropriate Security Program

o

  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. Risk Management – The primary function of the risk management is to ensure that all security controls meet the organisation’s risk appetite. Risk Assessment, Business Impact Analysis, Risk Treatment, and the Risk Register all sit here.
    o
  5. 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
  6. 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
  7. 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
  8. 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?

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

An Agile Security Program? I Don’t Think So.

In my vast experience of the Agile Methodology (just over a month now), I have managed to go from a proponent (as in Running PCI as an Agile Project?) to someone who is rather more circumspect when the objective in question falls outside the realm of a short-term project. An easily defined short-term project at that.

In other words, NOT a soup-to-nuts security program.

The overused adage; “If all you have is a hammer, everything looks like a nail.” is particularly relevant here, as Agile proponents have actually gone looking for nails to the point where some security ‘professionals’ are designing their entire program around this single tool! Being generous, this shows a spectacular naiveté,  at worst, it shows a complete ignorance of what constitutes a sustainable and effective security program.

And to be clear; Agile is a tool, nothing more. It is not a philosophy, it’s not even a framework, it is used for very specific requirements at very specific times for an easily quantifiable result; like a new user interface, a segmentation project, or even the installation of a centralised logging technology. Where it make absolutely NO sense is the exact place a good security program starts; with the culture.

The implementation of a good security program has always been, and will always be, more art than science, and completely dependent on the prevailing culture, a culture defined by the CEO’s attitude towards it. In other words, trying to implement a security program AND instill a culture at the same time with nothing more than a single tool, is no different from trying to build an entire house with just a hammer. It simply does not work that way.

Also, those focusing on Agile tend to come from a highly technical background and therefore focus on technology over process, which just compounds the problem to the point where any short-term gains will be built on nothing but air (like my sandcastle ‘metaphor’). Technology is critical for the automation of KNOWN-good processes, it can never be the solution in and of itself.

In one of my first blogs I posited that there are only Four Foundation of Security:

  1. Management Buy-In / Culture
  2. Policies & Procedures
  3. Governance
  4. Education & Training

…I would now actually add a fifth; Vision (or perhaps just include it in the first one), as it’s the CEO’s vision for the organisation that will drive the development of an appropriate security program.

Assuming you agree with the Foundations, perhaps you can now see how using Agile for any one of them is utterly meaningless. Implementing two week sprints and daily stand-ups to ask whether or not the CEO has signed-off on the security policy framework, or if all relevant staff have taken their annual awareness training, makes no sense whatsoever.

In the development of a security program, a competent security practitioner at the CSO / CISO level would usually follow these steps (gross oversimplification):

  1. Get the CEO to agree to take an active role in the program’s implementation / socialisation. Get this in writing.
  2. Define the governance framework to get all relevant senior stakeholders to the table. Have the CEO ratify it.
  3. Draft Information Security Policy Framework for the policy committee’s review and approval. Have the CEO sign it.
  4. Distribute the relevant policies to the right people as part of the socialisation and initial training exercise. Have the CEO visibly endorse it.
  5. Implement an ongoing awareness program to solidify the culture changes. Have the CEO evangelise it.

If you can’t even get the first step in place, you needn’t bother with the rest, as no matter what you do your security program will collapse under the weight of indifference.

No tool is going to fix this, certainly not Agile.