Satisfying Clause 4: Context of the Organisation

This is the second time I am writing this because bad habits die hard, and Word didn’t save my first draft, because I never enabled that feature so who’s really at fault here? Obviously, the computer.

_So sei es._

Anyway, as you’ll recall in my previous blog post I listed a few key things I was going to focus on, I also started using an ISO27001 Implementation project plan, and I’m already behind. Luckily, the CEO and head of the implementation committee is willing to turn a blind eye in exchange for more cat snacks.

This weeks focus was on the following areas:

  • Determine the needs and expectations of interested parties (4.2).

  • Review the purpose, vision, and mission with reference to interested parties (4.1).

  • Conduct a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis (4.1).

  • Sketch out the ISMS and document as I go along (4.4).

  • Determine the scope of the ISMS (4.3).

I approached them in this order because I felt it made more sense to identify the needs and expectations of interested parties, rather than defining the purpose, vision and mission of the ISMS and then validate it with the interested parties.

As well, I see it as the approach that encourages cross-team discussion, and results in more open communication, because instead of asking people to validate what you see as the needs and expectations you get the answer straight from the people who will be working within the confines of the ISMS.

This is an important consideration to me because security and information technology teams are often very technology and control focused, not always, but often looking for ways to prevent their users doing a “Bad Thing™” – or they have a strong focus on technology/cyber based risk rather than widening that lens to include other internal and external factors.

If you disagree, that’s okay, it may be that you have a tech/security team that is well educated and informed about business needs. That could come from culture, past experience, there are a lot of reasons, unfortunately that’s not the case for everyone.

_(Ctrl + S)_

Another key point is, you (the ISMS implementer) cannot be expected to take every single consideration into account when speaking to the interested parties, and that’s something that should be made clear, i.e. “We are taking what you say on board but we are also trying to balance other obligations so not everything will be actually implemented.”.

The good thing is a proper ISMS should undergo continuous improvement, which means that while some of these pressure points may not be resolved in the first year, they can be reviewed yearly, and frankly where possible, I think the interested party should be updated on any changes, because the that time, their opinion may have changed and the ISMS may have solved the problem! I’m sure internally that got some “yeah right” and “wishful thinking” thoughts or mutters which again is fine.

You’re working within the confines of a company that probably has an established culture, and changes to culture can be some of the hardest. In these cases, the key isn’t to change the system over night, it’s to chip away at the problem. For example:

You’ve had an established ISMS and people continuously moan and groan about how it’s difficult and security theatre, why not book some time with some key end-users, have a virtual coffee and talk about it, have some open ended questions, make sure they know that none of what they say will be brought back to them.

Just an idea though, make it work for your style, and company culture.

But back to the more pressing matter, clause 4.2 – determining the needs and expectations of interested parties. I have four interested parties:

  • One internal user

  • One external user

  • The cat

  • Myself

Now because this is an informal “organisation”, or “business” if you can call it that, I started with a Teams message (yes, we run Teams, yes, we have a Governance channel, yes, I run this as close to a proper implementation as I can):

As most people know, I’m being a shithead and rolling out an ISMS at home, you’ve been invited here today because chances are you’ll be impacted by it. If you have any risks or opportunities you’d like to see addressed please let me know over the next couple of days in a thread.

I got Z E R O messages. N O N E. Sweet. So I went and annoyed my first internal user in person, the conversation went like this:

“What are your needs or concerns about implementing ISMS?” “What does that mean?” “Well, what are your hopes and dreams for being more secure, what are your biggest fears about having to work in an ISMS?”

Insert 20-minute conversation about controls here

And folks, this is the conversation that enforced to me, that people don’t always realise that an ISMS is broader than the controls they deal with on a day to day basis. Some of the key take aways from that conversation were also focused on the negative:

  • I don’t want changes to take forever, and be restricted to 12pm to 5am;

  • I want to be able to quickly spin up infrastructure/software for testing and not have to go through the ringer.

All fair points, the cat’s opinion was pretty standard:

  • You can do what you like as long as I get snacks and pats.

I’m yet to reach out to our one external user, but as the system is likely to cause too much of an impact to them at this point, I will probably defer their interview until after the initial implementation.

The thing that struck me as interesting, but not unexpected is the strong correlation between strong controls and poor performance – it suggests to me that previously organisations users worked for often found controls, processes and policies restrictive because the organisation was overzealous in implementing hard-controls (technical) or they just weren’t consulted or considered as part of the original interested parties.

While I had less than an A4 page in notes from my two users, I felt like I had a lot more information by also assessing what they didn’t say, which was anything astoundingly positive.

So now I can consider the purpose, vision, and mission with reference to interested parties, because I know what the expectation of these parties is!

The first time I did this I used a brand compass to help determine the purpose, vision and mission of my “organisation” but it wasn’t really helpful so instead I went with a why (purpose), what (vision), how (mission) to hopefully flesh this out a bit better.

So, what are we asking:

  • Why: To improve our security posture which will increase peace of mind.

  • What: By implementing what we understand to be best practise.

  • How: In a practical, measurable, repeatable way.

So our missions statement for the ISMS is basically:

To improve out security posture which will increase peace of mind by implementing what we understand to be best practise in a practical, measurable, repeatable way.

Some other questions I asked myself this time around:

  • Why am I going to an implement an ISMS?
    • Consider here internal and external obligations
      • Laws and Regulations – It helps meeting regulations easier.

      • Standards that might apply to your industry/sector

      • What the market expects of you (contractual obligations, this can also include what consumers (if you’re a services-based company) expect of you)

      • Internal policies (Code of Conduct, Occupational Health and Safety)

  • How will I get there?
    • Are there organisational cultural barriers?

    • Does the organisation have the capabilities to meet the requirements? Not just fiscally but also resource and skill wise.

  • What will it be like when I arrive?
    • How will we make security part of everyone’s job?

    • How will we support morale through this process?

    • What values do I want us to embody (transparency, blameless culture, learning)

  • Who will I see when I arrive? (An auditor lol)
    • Do we need more people? What sort of roles would need to be filled?

    • Are we going to get an external audit done?

I don’t think there are any questions that are set in stone, and you might have some better variations you like to ask, these are just some I thought of while going through this process.

So now I know why I am doing this, (besides just wanting to) I did a Strengths, Weaknesses, Opportunities, and Threats analysis – this isn’t mandatory, but I found it helped identify where there might be some problems in implementation:

Strengths

  • Skills in governance, risk, and information technology implementation/configuration;

  • Small “business” – we can make decisions quickly, rollout solutions quickly and roll them back quickly;

  • Strong networking capabilities;

  • Lack of compliance requirements.

Weaknesses

  • Lacking skills in configuring security information and event management (SIEM) solutions;

  • More infrastructure, means more maintenance;

  • Can’t do in-depth software risk assessments;

  • Small budget.

Opportunities

  • Become more familiar with implementing/managing/configuring open source solutions;

  • Can add more canary tokens to the environment (maybe even budget for a hardware based version);

  • Capabilities to build out a secure software development lifecycle;

  • Speed up the time, accuracy and security of deploying and edge services.

Threats

  • Unfamiliarity with solutions may result in misconfiguration and widened attack surface;

  • Identity thieves;

  • No cyber insurance.

Next up, clause 4.4 – work out what I want the ISMS to look like. In most cases people would probably take a business or process approach, I’m more interested in taking an iterative approach and using SCRUM.

I decided I wanted to do it this way before I even really started, because I value the core pillars of SCRUM, transparency, inspection and adaptation, and really they align quite well with ISO27001 if you think about it.

Transparency especially I think, makes for good security culture, and it ties into “it’s okay to make mistakes as long as you own up to them” which in turn helps encourage blameless culture which is important to help people grow and improve.

SCRUM also encourages cross-functional teams which help encourage personal relationships, promotes better communication, and in turn better co-operation. By removing silos, we basically have a better ability to see what others have to work with and hopefully develop some understanding and empathy.

I’ve read some literature online about how implementing SCRUM and ISO can go, and while I have seen some variations address some of the earlier clauses (particularly clause 5 leadership) this way, I don’t like it. Even in SCRUM you have a clear owner, and I personally think, that it is their role to interface with the business to satisfy this clause. Basically it is up to the product owner to understand the business and have a vision for the team.

But I digress, I’m here to tell you why I made my choice and not necessarily justify how it maps back. Basically it comes down to this, I see more value in implementing ISO using a cross functional team because the requirements, will ultimately be more precise, and aligned to the existing business processes and culture.

As we go through the clauses I may address this in more detail.

Finally, scope. Clause 4.3 determine the scope of the ISMS! I started listing out the areas that pose the most risk to us, and listing out the areas that we have little to no control over.

We’ve excluded a lot of the human resources parts, however, at least informally I might decide to take a look at awareness training and how we provision access across all our different solutions, primarily to make accessing different services easier.

Further to this physical and environmental security is out of scope. I’m not pricing and having HVAC installed to maintain a handful of on-prem servers. They have a UPS anything beyond that is in the hands of the gods.

Software development is out of scope, at least for now, I want to add it in later but right now it’s not a key part of the systems at home, and they are managed at least informally.

I ended up with this visual representation of the scope which focuses on “departments” rather than processes because right now we don’t really have many of those.

A visual ISMS scope that defines the different areas of the business in scope.

Which I translated into the following:

The scope of the ISMS includes the deployment, configuration and management of infrastructure and network-based software solutions at the head office, excluding physical, software development and research and development aspects. Risk and information security remain fully in scope, as documented in the statement of applicability version 1.0.

So right now, I’m pretty satisfied that I’ve closed off clause 4 for now, the next phase for me will be working on the risk and more generally planning – clause 6. From here I’ll probably jump around a little back to clause 5 – Leadership. My rational being, if I can demonstrate even some of the fundamental risks posed I’ll get better buy in (even though I have bought buy in already, it was on special at Aldi last Friday), and leadership will be committed and accountable for the success of the project.

Focus for the Coming Week

  • Define and document roles and responsibilities (5.3)

  • High-level risk assessment (6.1)

  • Determine and document the ISMS objectives (5.1)

  • Present the case for ISMS to Leadership (5.1)

  • Develop an Information Security Policy (5.2)

What I’m Reading

  • PRAGMATIC Security Metrics by W. Krag Brotby, Gary Hinson (ISBN: 9781439881538)

  • People-Centric Security: Transforming Your Enterprise Security Culture (ISBN: 9780071846790)