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

A Control, all of the controls

The potentially most misunderstood and overused word in Security.

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)

Tool blindness;
When you focus on mechanisms or a security tool or technology or platform you can end up trying to force the "Industry" best into a situation or environment that doesn't reflect what that technology was baselined against. While security is simple and can be repetitive, it does need to be done within the context of your organisation or you will implement unnecessary expensive controls or worse think your controls are working as promised or designed when they are not or simply can not.

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.

I actively encourage you to focus on this behaviour model, as you might quickly realise that it is others who own the processes, relationships or technology that can reduce/ encourage the wanted behaviour. Security controls will never be fully owned by Security. Remember variables will have dependencies and variables of their own and fixing the problem may be better further up/ or down the chain.

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

Control Families and Frameworks

And why ISO 27001 is both useful and completely useless

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.

Communication is key, most security controls, control families or frameworks will use similar terminology when talk about types of controls. This standardisation removes a lot of details about the control, or due to it you can not rely on the broad wording working within your companies context.

Frameworks are not BLUEPRINTS to implement, that is a security strategy and programme, what they are is mechanisms to explain to people outside of our organisation, department or specialism what you are implementing security not how you are going it. If you can not explain you are doing something or have something, is there a point in having it? Do you understand it?

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.

The applicability of a Control?

How do you answer the control statement, or even start of what is a good or bad control for you?

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.

Local Admin on Endpoints (not servers)
One of the consistent controls that will be raised is that local admin should be removed from all machines. However, if you have local development team taking local admin away from them they will not be able to locally compile code and you will stop all the development.

The control is aimed at stopping malicious code from executing on the machines, however, if you have a mechanism that all data is stored in the cloud, the machine is basically a thin client and there is a mechanism for isolating those machines. You will have minimised the ability of that bad behaviour with other controls (variables) without needing to break a whole professions ways of working.


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.

Applicability of a control, start with the behaviours that you want to know what assets you have, how they fit together and know when they change. You do not need to sign off or approve all of this. Visibility is key! so work on controls and encouraging behaviour that allows that.

Then you can start on mapping who has access and how. Then simplify both of these down to be the easiest to manage and easiest to allow your customers to change. Once you have done that, look at other controls.

EP4: Measuring Controls

What is good and what is important?

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