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

Security Core Concept 1: Risk Assessment / Business Impact Analysis

This begins a series of posts related to my theory of The 6 Security Core Concepts. I am assuming that The 4 Foundations of Security are either already in place, or at least being addressed in parallel.

So, in terms of cybersecurity, what is a risk assessment? According to Wikipedia it’s; “…the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat.”

NIST SP800-30 Revision 1 states; “Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems.”

Great David, now what? I know what a risk assessment is, I just don’t know how to do one!

There are 5 golden rules of conducting a risk assessment;

  1. Get Management Buy-In – I know, surprising huh?;
    o
  2. Agree on the Scope – region, department, business line, compliance regulation etc. Keep it simple or you’ll never finish;
    o
  3. Agree the Methodology & Deliverables – whether you use something based on methodologies such as NIST or OCTAVE, or a combination of many, agree the method up front and stick to it for ALL of your risk assessments;
    o
  4. Agree the Timeframe – from the beginning to the delivery of the results stick to the agreed timeframe, even if you’re not finished.
    o
  5. Get Started! – don’t get caught in ‘analysis paralysis

Once these are agreed, start your interview process, and again, don’t over-complicate this. Each department is going to have a different take on what’s important, and it’s not your job – yet – to argue priorities. You simply ask them what they consider to be the major threats to the business (from their perspective), and what is the likelihood of that threat being realised.

Bear in mind, this will not just be IT threats – IT does not corner the market – but it IS a big chunk of them; malware, data theft or other loss, network outage, Internet outage, server crash and so. That said, even such concepts as operational resilience have a majority foundation in IT systems, so that’s why the IT department have traditionally – and incorrectly – owned this process (if it exists at all).

Done correctly, the risk assessment will be driven by the Governance Committee (Core Concept 4), and have equal input from both the IT and the business sides. If not, it won’t have the management buy-in I go on so much about.

Once the data is collected, it must be put into some kind of perspective. This is where the words quantitative and qualitative come into play. Only very mature risk management processes should attempt quantitative, it’s simply too difficult for most organisations. Qualitative allows for better adoption by non-technical personnel, and will most likely speak better to the immediate needs of the business; i.e. reducing risk.

Assuming you’ve chosen qualitative, you must still put some value on the identified risks; 1 -5, 1 – 100, high-medium-low etc., as well as some indication of its likelihood of occurrence. For example; a planetary implosion would be catastrophic, but VERY unlikely. The payroll server going down has much less impact, but will occur more often, so should be the priority in this ridiculous example.

Now that you have your risks ranked in terms of impact and likelihood, you need to put some kind of monetary value on each in order to put the final prioritisation against it. It is VERY difficult to put $/£/¢ values against these risk rankings, but unless you do, you can’t prioritise, nor can you set the baselines required in your operational resilience (OR) / incident response (IR) / disaster recovery (DR) plans.

For example, if your e-commerce sites makes 100% of your revenue downtime is not an option. Therefore you not only need full redundancy in your systems and apps etc, and real-time monitoring of system health, you also need extremely robust SLAs against your 3 party vendors (hosting facilities etc.). Only this will ensure that both IR and DR processes are in line with your Business Continuity Management (Core Concept 6) plans.

You have those, right?

If it is determined that the risk is just too great for the organisation to stomach, you will move on to the next step in the process; Security Control Selection & Implementation (Core Concept 2). You will start by performing a gap analysis of your infrastructure to see where the gaps are between your current capability, and the agreed standards accepted by management in the risk assessment phase.

The purchase of technology is always the LAST resort! Business process review is the first, enhancing the capability of existing infrastructure is the second. Rushing to throw technology at gaps can lead to bigger problems as I have suggested in Insecurity Through Technology.

One of the themes I have running through my posts – other than the terrible grammar – is the concept of how not knowing where to start often leads to organisations doing nothing at all. As in every other instance, the way to avoid this issue is to ask the people who DO know. A good consultant will not only be able to help you design a risk assessment methodology for your organisation, they will be able to teach you to run it yourself. Remember, the role of your consultant is to teach, not just do.

Finally, like every other business process, the risk assessment methodology should be standardised across the enterprise so that the results are compatible with the business culture and comparable against each other. However, they should also be reviewed at least annually, or after significant organisational, change for continued suitability. As your organisation changes and adapts to the future business environment, so must your risk assessment keep up in order to stay relevant, and useable.

This post is not meant to tell you how it’s done (there is an infinite variety of risk assessment methodologies), but to ease the confusion that is still prevalent. Hopefully I have done that enough that you at least begin to ask the right questions.

Like all security, the risk assessment is simple, not easy, but simple.

To summarise;

  1. Don’t do ANYTHING until you’ve conducted a risk assessment, and this includes starting your PCI compliance project (if applicable). This is beginning of all security, and the initiation of all future business plans;
  2. Don’t over-complicate it, just choose your target, set a time goal and stick to it. Whether you are finished or not isn’t important, you can always get back to it later and reducing your risk as soon as possible is more important;
  3. Get an expert in the first time, learn from them;
  4. Don’t BUY anything until you know where it fits in, and how you’re going to manage it; and
  5. Unless the solutions you choose costs well under the estimated value of the data, don’t buy them, it’s career limiting.

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