Please check out Part one and part two of this series

Continuing our series about metrics for segmentation, there are a couple more angles how you can measure the effectiveness of your segmentation.

Metrics from previous parts

In the two previous parts, i introduced a couple of examples on how to measure your security segmentation.

• How many segments do you have?
• How exposed is something?
• How big is the blast radius if things go wrong?

Those were all quantitative metrics and even those are very hard to get in your current network. Not even mentioning how hard it is to keep up with the status quo in your current pressure that the business puts on you.

Another metric that we need to look at is how to prioritize your segmentation strategy and what problems to tackle first. This can be especially hard because your estate is too big or you don’t know the infrastructure good enough. If you are lucky you already established a risk management process, that also has a list of the most critical systems and application your organization uses.

Sometimes those systems are obvious, sometimes it is the systems, that nobody wants to touch or make any changes to, because they are afraid of the implications that a change to those systems might have.

So let’s come up with some indicators and metrics.

What do i need to protect first?

There is no segmentation approach that just works out of the box and with a big bang suddenly your data center is segmented. The biggest chance to do that is to move everything into a new data center and by doing this, you will have peace for a while, but as soon as the new data center or infrastructure changes things will start to become worse again.

So for most environments it will make sense to concentrate on the things that are most important to protect. How do you determine those systems?

The basics

If your infrastructure is big enough you will have no chance to identify the applications that you need to protect first. There is a good chance you can come up with a handful or two though.

What you will need is a list of all the applications that your company runs. That list may exist in your CMDB or other systems like a ITSM system.

Core services

If you think about the huge amount of core services traffic that make up the traffic in your infrastructure it makes sense for you to segment some or all of that away first and identify the core services applications.

The benefit will be a much clearer picture when you start segmenting your business applications later and it will help you focus on application traffic.

The obvious candidates

When you think about your IT infrastructure, it probably will not take a long time for you to come up with a good list of systems that are essential for your business.

Here are some typical candidates, that i have seen:

• your Active Directory - this serves as a way to authenticate machines, users, often serves DNS records and does a lot of other things - people are very fast discovering this
• your identity providers and authentication systems - this can be your AD, but often this is done by something like One Identity or other identity managing systems
• privileged access management systems - privileged access is the way to get to the core of your business and often this is handled via bastions, jumphosts or applications like CyberARK or BeyondTrust
• your ERP system - we often see that things like SAP or Navision run most of the business
• your main database infrastructure - this can be something like Oracle Exadata
• everything you communicate with - this can be your email systems if you still run them, but can also include other systems that are used to run your business communications

Applications that define your business

This is one that is very hard to answer, because every organization is different and there’s different applications that run their business.

For banking, this can be the core banking applications and payment systems. For manufacturing, this is often the system called SAP although it usually is a ton of systems that run SAP and different SAP applications.

Additional sources

• your business continuity and disaster recovery plans
• risk management

A excursion into risk management

I am by no means a risk management expert, so please excuse my ignorance and correct me if i am wrong.

The two streams of how to measure risk are:

• qualitative risk management - measures impact and probability and defines the resulting risk based on those scores - high impact, high probability - high risk
• quantitative risk management - uses measurable data, usually understood better by anyone in the business

Qualitative risk assessment

One of several qualitative risk assessment techniques is to assess impact and probability of a event to happen. That event may be the breach and therefore reduced availability of a application. Often we use just a low/medium/high or green/amber/red scale for both of the measures and get a pretty good understanding how much risk is imposed on a single application.

Another great example how to model risk is DREAD, originally developed by Microsoft. DREAD stands for:

• Damage
• Reproducibility
• Exploitability
• Affected Users
• Discoverability

Quantitative risk assessment

When talking about quantitative metrics, cost usually is one of the metrics how people measure things and how the business understands the cost of a breach much better.

It’s not easy to measure risk in money, because we do not have uniform data across all of the organization, we deal with different applications, some of them have customer data, some don’t, some of them process most of the money your business is making, others are just utilities.

One thing you can measure easily is the impact a failure or breach of one application would cost.

Indicators and metrics for this are:

• customer acquisition cost
• communication costs for each customer
• cost to reestablish your system
• number of customers affected in the breach
• SLE (Single Loss Expectancy) - this can be a result of the above numbers and is the cost for the breach more or less
• ARO (Annual Rate of Occurence) - how many times did this event occur
• ALE (Annual Loss Expectancy) - the product of the two above metrics above

Using risk scores to prioritize segmentation

Once you have risk scores calculated or categorized deciding on what to segment first will be a lot easier and you have a metric to use during your deployment and continuous operation.

Segmenting applications with the most risk first will make sure that you minimize global risk in your organization.

Should i start with the most critical application?

If you ask me if you should start segmenting with your most critical applications i would vote not to start with them.

Will there be a part four of this series?

When i hear of new metrics, i will add them to this article series for sure.