What you measure is what you get

If you are like me and live and breath IT or IT security, the above statement probably does not ring a bell and you don’t realize the source of this. It is from a person called Robert. S. Kaplan who developed something you may have heard of, the balanced scorecard.

I will not dig into economics, because we are not in business school, but the essence of the scorecard is that you need metrics on which you can measure success or failure to be successful or be able to reach your objectives.

As network and IT security professionals we love data, we like to measure things. We even run giant systems collecting all sorts of data just to never look at it again until something happens and we realize some of the data we need is missing.

• Latency
• RTT
• number of hops to a destination
• CVSS scores for vulnerabilities
• code and test coverage
• percentage of disk space free/allocated
• availability

There are a ton of metrics around to measure what is going on in IT and the above is only a minimal subset of what we use day in day out.

When i thought of how do we actually measure segmentation, strangely there is not a lot of metrics around for this subtopic of IT security at all. No numbers, no percentages, no scores. Not even a traffic light that would show us what is segmented and what is not or what your coverage is.

Thinking about metrics

To get to the essence of this, i think we first have to think about what is important about security segmentation and when could i personally or as a team or company say, that we are segmented or not?

Here are a couple of thoughts i have about metrics and please, as always, feel free to comment or add your thoughts on this in the comment section below.

Goals of security segmentation

First of all let’s be clear on why we segment or try to in the first place. It normally is to protect data. That can be data in transit or data at rest, or data that is processed by applications.

Then it is people that care about that data, that is for example regulators, your internal revision, your CISO,

Protecting data

The primary goal of segmentation is to protect data and this really falls into the CIA (Confidentiality, Integrity, Availability) bucket.

We have to protect data and be sure to prevent information from leaking. Access needs to be restricted on a least privilege base. Data can also be classified into different risk categories that define the criticality of the loss of confidentiality for this dataset.

The same can be said for integrity of data, limiting access to the data is one of the first measures you should take to protect integrity (not the last).

Availability normally is affected if things go wrong and have not been breached, hit by ransomware or a outage because you had to rebuild parts of the application.

Limiting access to things

When you think about segmenting for security reasons (not just to get tinier broadcast domains), there are a couple of things that people typically look for:

• limiting access to things, typically data
• limiting the ability to move inside the data center
• limiting the blast radius of things that are in your network already

We will look into the more interesting stuff in the next article. As always, i am thankful for your input and thoughts in the comment section below.

• ← Previous Post
• Next Post →