Category: Policies & Procedures

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

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

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

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.

Internal Audit.

It’s right up there with Traffic Wardens, Used Car Salesman, and Lawyers, isn’t it? You get a phone call from Internal Audit (IA) and it feels like you’ve just been sent to the Head Master’s office!

But why? If you have been doing everything right, following appropriate policies and procedures, have ACTUALLY read the Acceptable Use / Code of Conduct, why would this be any different? I mean, even SECURITY winces at IA, and we’re total pariahs ourselves!

This is unfortunate, because like it or not, every department needs someone to provide checks and balances. Someone who can look at everything with a fresh and objective pair of eyes, someone not answerable to YOUR boss so can tell them how it is without repercussions, someone who can suggest changes that you know should happen, but fear / politics prevents you from saying anything.

Take your pick, regardless of how you view IA, they, like InfoSec, are an necessary evil in a world where both the threat and regulatory landscapes are spinning out of control.

Best practice frameworks like ISO 27001 call for Internal Audit by name, and an ever increasing number of regulators are requiring  evidence FROM IA processes so that organizations demonstrate that they are actually complying with their own policies. This should not be a hardship, if your corporate security culture was adequate, this would not be an issue. Look to the senior leadership, it they don’t care, no-one else will.

I have stated over and over again that if you were doing security properly, EVERY compliance regulation on the planet would fall out the back-end (plus or minus some customised reporting). Not one has ever, and likely WILL never go above industry accepted best practices, as no-one is looking for perfection, just risk-reduction enough.

It makes perfect sense to me therefore that you would put a watcher on the watchers. Security have their fingers in almost every business pie, just to make sure that proper security controls are built in from the beginning. Like Legal, security is there to save the business from itself, and done properly, it should NEVER get in the way.

This can lead to a certain complaisance, or blinkered view of the world, IA can provide the necessary perspective to continually test processes that that could potentially stagnate if not seen through an objective lens. And who knows, because IA generally have direct (if dotted line) access senior leadership, there is a very good chance your requests for budget/resources will be looked on favorably if supported by an entity mostly immune from repercussions.

In this context therefore, Internal Audit is the conscience of Security; Are the controls enough?; Are they too much?; Are they easily measured?; are they flexible enough to adapt to business goals?; etc…

From the very first policy draft, to the almost ubiquitous Plan, Do, Check, Act of ISO 2700X, security professionals need to look to IA for support and guidance, but the opposite is equally true. IA can tend to rely on their unassailable positions to hide behind lack of expertise in security subject matter, they need to work just as closely with security to make sure they are up to the task.