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

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 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?

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.

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.

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...

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.

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.

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.

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.

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

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?"