EP 3: Controls, how to baseline yourself?

What is a control? and how do i know where to start?

Security controls, a dreaded start of a conversation with all Security and non-security staff. These are your means of reducing the risks to the organisation through preventing, identifying and reacting to activities that would increase the risk. Or;

• Preventative - Forcing a way of working, removing a method that helps someone do their job, reducing the functionality of technology to a point where people will find workarounds.
• Identifying - Scanning and consuming all the technologies resources, collecting all the data and making a larger security/ privacy risk, falsely giving yourself the confidence you can see everything while not maintaining pace with the business.
• Reacting - Crying wolf, over-reacting, escalating to the wrong people losing control of the narrative and making preventative controls with all the complaints about automation of bad or uncontextualized data.

So this episode will look at the following;

1. What is a control? (a working definition)
2. What is a control family or statement (these terms and control are NOT interchangeable)
3. How do you know the applicability of a control
   

With the next episode looking at;

1. How to start measuring and when is it "Good"
2. Which one is the priority?

So let's start at the start, what even is a "control"?

When is a control a control, what is a control, and how is it a control?

There will be lots of discussion about definitions in this area around whose definition of security or technical control is most accurate. However, thinking of a control specific to security will limit your imagination of what a control can be, and understanding where a control is used to support a specific view of framework vs what you need the control to do for your organisation.

So we will NOT start with the definition of technical or security control, and use instead;

A control is a variable that can influence the behaviour of an action within the course of events.

The reason for having the less security-specific definition is that we wish to move away from immediately focusing on the capability of a tool or technical threat (such as Ransomware, DDOS, Injections... all the classics)

Focus on the behaviours you wish to encourage, (yes encourage do not start with the negative) and discourage from your users, systems, customers and threats. An example of this is that when you are responding to an event // incident // breach you want to know;

1. What has happened?
2. When did it happen?
3. Where did it happen and what do you know about it?

Coming up with technical controls, where all your logs are in one place, easy to get at and you have an SIEM that flashes when someone looks "Spooky" is all good and well. Are you sure it's working, you know how to use it and the experts in those tools are available?

However, if you encourage the behaviour that people feel comfortable telling you when;

1. They think something could go wrong (What has happened?)
2. Something feels off (When did it happen?)
3. They noticed it here (Where?)

When you get the pre-event story quickly, you can remove the false paths (there will be a series on Incident Management), remove assumptions, add context and you can do your one job when the lights are flashing that something is on fire.

When shit hits the fan you can only control one thing; You can control the timeline of the narrative.

Without encouraging this behaviour you are reacting when something has gone drastically wrong, not preventing when something is noticeably wrong and may have lost valuable time or data. Or worse, the narrative gets exposed without context and your minor event gets blown up externally as a major incident.

They can not do this when they trust you, they are using technology they are comfortable with (so they notice when something is "Off") and they aren't made blind to the consequences of their actions.

These variables that encourage or discourage behaviour tend to cluster into noticeable groups, there are a few frameworks that people will reference that look at controls within these groups.

So let's talk about Control Families and the most commonly referenced Control Frameworks (and why it has no controls)

There is rarely one control that can influence behaviour completely, we need groups of them.

Control families are where the variables start clustering into something that can be influenced and observed, meaning it can be measured and the behaviour manipulated.

Once we can measure it, we can work out if it working the way it is supposed to or how to add or remove controls. What you need to remember though is that there is no "perfect" solution, or control as we do not know all the variables so the job is to change the more problematic variables.

We then name these control families under an unifying term, such as asset management and start clustering controls into security or technical safeguards or countermeasures that can be commonly communicated to a wider audience.

Control Families making Frameworks

Most industry recognised and acknowledged frameworks are made up of very similar control families but they tend to have a different purpose and audience. Understanding the audience will help guide you on which one you should use, as remember the framework is a communication mechanism not technically a blueprint on how to build a control architecture.

Most control families will be quite reasonably named, without much jargon used. However, there will be jargon added to the specific controls stated. There will be a separate series of episodes on individual controls in each framework. For now, understand the families but the first two to focus on is Assets and Identity. As referenced previously in Episode 1: The three big questions these are you primary points of concern;

• What are you (Asset Management)
• Who has access to these (Asset Management and Identity)

Why not all Controls in Control Frameworks are Controls - Looking at you ISO 27001

The most recognised and known Information Security Control Framework, or as it will be correctly referenced ISMS is often the most misunderstood.

First off, there are no controls in ISO 27001, they are in the appendix and there also the ISO 27002 document to add a level or confusion. The more important fact to note on ISO 27001/2 is that they are control statements. Not Controls.

Control statements are a generalised end goal of the group of controls. An example of this is;

• Control Family 8 - Asset Management
• Control 8.1 - Responsibility for Assets
• Control 8.1.1 - Inventory of Assets

Implying that to have a suitable level of asset management, you must know who is responsible for the assets and this must be kept in an inventory. Not what is the;

• suitable level of information captures on the responsibility for the asset,
• is inventory of assets to be searchable?
• what level should you go into about the asset (metadata)
• how often you should refresh it?

Which would be the controls needed, it also does not tell you that within a solid implementation of 8.1.1 that 9.2.2 - user access provisioning, would be impossible.

So let us start with the what is a good control? It need to start with understanding your business.

The first rule of a control, when you are talking about variables that change behaviour you need to know what the behaviour of your business is with the control.

The reason for this is that each business works in different ways, and the last thing you wish to do is put in controls that cause dramatic changes to the ways of working. Unless you have a very good reason, and if you do educate them.

Security controls is read as written can cause known issues.

THERE ARE HUNDREDS OF CONTOL(S)

Yes there are, so the best way to ensure you do not get overwhelmed is accept at the start of reviewing then trying to answer the controls that the picture will not look pretty, but you might also be pleasantly surprised how much is common sense.

The reason for framing your strategy into the Key 3 questions from Episode 1;

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?

This is because the controls in these areas along with knowing, or working on your risk appetite will accelerate your progression with the rest, think of these being your key controls for certain risks and the pre-planning for the rest of the controls.

An example, is that there is usually questions around supply chain management or third party assurance, well this can get more tricky due to;

1. SAAS, also know as just programs // websites // services anyone can go online sign up and half the time they are free so you don't know its happening until they already have your data.
2. Legal requirements changing between geographical boundaries.
3. Regulation increase depending on type of business you are working with or integrating into (finance or healthcare for example being more stringent)

Now, dealing with any of the above will still start with;

1. SAAS, also know as just programs // websites // services anyone can go online sign up and half the time they are free so you don't know its happening until they already have your data.
   1. (asset management) What are we using?
   2. (asset management) What data is going there?
   3. (asset management) How is it integrated?
   4. (access management) Who can access it from an admin perspective?
   5. (access management) Who can access it from a user perspective and how is this managed?
2. Legal requirements changing between geographical boundaries.
   1. (asset management) Where is the data going to and from?
   2. (asset management) What is the data?
   3. (access control) How is the data accessed?
3. Regulation increase depending on type of business you are working with or integrating into (finance or healthcare for example being more stringent)
   1. (asset management) What is the data?
   2. (asset management) How is the data stored?
   3. (access control) How is the data accessed?

You will see clear themes, that with most controls knowing the data, how it all fits together (architecture) and how that is managed (technology management) coupled with who has access to it will be your starting point.

This is why making sure you document clearly, and have it easily accessible is really important. Or you will find yourself asking yourself the same questions over and over again.