EP 1: The Three Big Questions your Security Strategy is based on

EP 1: The Three Big Questions your Security Strategy is based on
Photo by Kind and Curious / Unsplash

The answers to these three questions will never be completed but will underpin everything else within your Strategy

Relating to a previous rant about the myths of Information or Cyber Security
(you can find it here), Information Security isn't complex it's just never truly able to be "complete" the same way many other technology programs can be. This is by design and reflective of the reality we operate in. Your business never stays stagnant; even if it did, the technology underpinning it doesn't, and even if that did, the threats you face won't.

So to understand where you start, maintain and close the current cycle of your security strategy you will always need to keep these three questions and the answers to them in mind. This Episode goes into these three questions, with future Episodes exploring them in depth and how you would make getting those answers easier, faster, more accurate and more reliable.

The Three Questions

And the explanation of why these three in particular

The first questions I ask a business reflect the three questions I will now put forward you need to maintain an answer to:

  1. What are you protecting?
  2. Do you know who and why they can access that?
  3. OK, where have you documented that is true and acceptable?

The reason for these questions is that if you have no answer to these the rest of the questions you will need to explore in making your security strategy will be very difficult.

  • From an Audit perspective, you will not make it past the first 5 questions without a major failure.
  • From a business case perspective, how will you justify the cost without an accurate scope?
  • From a technology perspective, how do you know the technology underpinning your security architecture works in your environment?
  • Lastly, how will you remember why you chose that route in 3 years if it isn't documented?
I don't know how many times I have asked why do you use this technology, this supplier or why is it set up this way and the reply is a "I don't know"

When people talk about security they commonly use acronyms or frameworks to state how they will work out security such as the CIA triage, the NIST cybersecurity framework, or ISO 27001. None of the above makes any sense if you don't know what you are protecting, from whom and why you have chosen X, not Y.

So let's flip those three questions I ask each business into the three most important questions of your Security Strategy and explain why each one is important.

What are you protecting?

Question 1: Do you know your assets?

The land of continuous flux and misunderstanding of terminology

So What are you protecting? This is asset management plain and simple, but getting the answer isn't always simple and there are very obvious reasons why. However, there are solutions to these reasons.

We are a fast-moving agile company (usually a start-up/ early route to profit days)

A legit reason for not keeping the best documentation on what you are, however, no matter how new you are, or how fast (or... agile) you are. You will be building around a core collection of systems, interfaces and data stores. Start there when looking at where to map out your assets in your Customer Environment.

Customer vs Business Environment
There will be a separate episode on this, however, quick rule of thumb. Most businesses have 2 environments, we will treat these separately. One environment is where their business data stays (usually Office/o365 and in Azure) and One is where their Customer data stays (On-prem servers/ Aws/ etc)
We are a company of companies // we are 20+ years old and have lots of legacy // lost a lot of knowledge (Honestly, most big businesses)

A common problem is knowledge management and in most businesses a completely underinvested one when it comes to a solution. While the majority of your technical knowledge could be lost, what do you sell to your customers? And what systems drive those sales? Yes, you might have a lot of other systems. However, start with the 3 customer journeys that drive the majority of your income in the business and you will get the core collection of systems, interfaces and data stores of your Customer Environment.

We don't know where to start? What even is an Asset?

Now this is the real question you should be asking.

What even is an Asset?

So, good question. The easy answer is anything that has value, but that's also a bad answer because you might not know what does or doesn't have value due to you not knowing how to measure the value of an asset. This will be covered in a future Episode.

So let's start with a basic definition. Anything that can store, accept, move or transform data and without it the business would have a hard time providing the customer the value of using said business.

This can mean anything ranging from your website to a database to an email mailbox (remarkable how many businesses would fall over if they lost access to a shared mailbox)

Now your diagram how it fits together, how it communicates with one another and how it passes the data. Once you know this you can work out the architecture.
An example is below; (don't worry how we do this will be another episode)

Start with the following flows:

  1. How do they purchase something from you?
  2. How do they request support from you?
  3. How do you make sure the money comes in and is validated against an order?
  4. How do you make sure you pay your staff and your suppliers on time?
  5. How do you create a staff member and give them access to the right systems?

That last flow, it is critical for many reasons, and we will get into those in future episodes, but let's start with the fact without this how do you answer...

If you have the ability to create an architecture diagram that is required to make the flows technically work. Doing so even inaccurately will make the next question significantly easier.

Do you know who and why they access?

First Acronym you do actually need to know; JML
Joiners/ Movers/ Leavers

The easiest way to access something you should not have is to ask for it.

It is sometimes remarkable that work-life can be so similar to everyone's collective childhood.

Have you even been in a situation, when you were a child, that your mum didn't let you have something so you made sure to ask your dad before they could talk to each other?

Every business will do access control badly, now what you want to do is make sure your "badly" is done in such a way that it doesn't open you to unacceptable risks. Now unacceptable risk is not doing the bare minimum, so what is the bare minimum?

The Bare Minimum of Access Control

Accurately knowing who has access to the systems, infrastructure or applications. Over-simplified answer aside, you really should know where you are storing your critical data and who can get it.

Your critical data would be data that either;

  1. Drives income or drives sales
  2. Enables you to pay your customers and staff

Without doing these two things, you don't have a sustainable business. So;

  1. Who has access to the systems that allow the above?
  2. Who has access to allow people to have access to the system?
  3. Who can set up or change how those systems are setup?
  4. Who can pay for the system or change financial details in the system?

These are different profiles usually within the system, with these profiles made up of sets of permissions. The permission sets are important.

Most permission sets are split into two;
- User (Normal use of the application, required for your day job)
- Admin (Elevated and unusual permissions, allowing you to change how the system operates, is configured and who has access)

Granting Permission

So to make anything operate, you need permission to see/ use/ manipulate the data in question. This is commonly known as Read and Write.

Now Read or Read/Write of a system that is set up to do the job you need it to do is fine. However, when there is the ability to write permissions you need to pay attention to these accounts. These are important Admin accounts.

Check who has admin accounts as frequently as you remember, and try to remember often. The normal user accounts shouldn't have access beyond the norm and less hygiene around these will be less dangerous. Unless...

Joiner // Movers // Leavers

If your JML process is broken, you're in trouble. If your JML is unknown, accept it is broken and aim to fix it as a priority.

This is where the average technology person needs to really engage with a new Stakeholder; Human Resources. You need to understand who has joined your company, this is important so they can access what they need for their job, however, the other two need your attention more.

Leavers - This should be more obvious but if someone leaves your employment make sure their account doesn't have access to the system or the data.

(SSO) Even in the case where you do use single-sign-on remove the user from the group providing the permission to the data, while disabling an account should be step 1 leaving disabled accounts active just leave more accounts able to be activated when you forget

Movers - The problem child, many people know when new people join, or when people leave but what about when their jobs change? Does their permission stay the same? I know it seems less important, however, it is remarkable how many people will do favours with their old access and when they are not in the old role they might not know what damage they do as they don't have the context of the system anymore.

Help yourself out, while you might know Joe in Accounting used to be an admin in system X before he became a financial controller. When you scale or when shit hits the fan the person who is dealing with the incident might not and will be looking at the data showing Joes account being taken over and doing something malicious when he might just be doing a favour. Which went wrong.

Is reality Documented?

And is the documentation accurate and up to date?

So in the last situation if Joe in accounting still had access to a system due to his old job, this was documented and easily found in the case of a breach, you might be able to drastically reduce the time to identify and contain the problem.

Control of the timeline and the story where things go wrong (Malicious or accident doesn't matter) is the one thing you need to be confident you can do. It is the easiest way to lose control, open yourself up to further harm or repeat incidents and cost a whole lot more money to recover from

Dealing with an incident quickly is one of the easiest ways of reducing the cost of a breach. With the average incident costing 4.95 million if the event lifecycle is over 200 days (average is 277). If you get it under 200 the average cost drops 23% to £3.93 million

23% reduction is too large and easy to fic to ignore. This seems obvious but when was the last time you could easily access data or information that you do not need on a daily basis in say less than 5 minutes? Knowledge Management and Project Management are two skills that are never brought up in a Security Job Spec. However, without easy access to consumable knowledge you are in trouble fast. The knowledge you collect on the other two questions in the knowledge you will always need quickly.

Just remember when you are building your Security Strategy or ISMS you are building a system to allow you to control risk.

  • What is your level of risk?
  • What is the data you need to maintain yourself within your acceptable level of risk?
  • Who accepted that risk was out of appetite?
  • When would you have fixed that problem you knew existed?
  • How do you prove it really was an unknown?

Documentation... and control over your knowledge within a timely manner is the answer to all of the above. You can not do everything, fix everything and be everywhere at the same time. However, what you know needs to be shared, accessible and improved over time. Or i'll ask "Why are you even doing this?"

EP 2: Is an ISMS a Security Strategy?

Lets try and make these interlinked things separate but correlated

The Remote CISO

The Remote CISO

10 years on and with each job ending up doing the same job for 6 months, I wish to educate you and let you be able to save those 6 months of cost for the costs that truly matter.
United Kingdom