Please check out Part one of this series of articles
Metric One: Do you have more than one segment?
This question is, of course, more of a rhetorical question, but there is a point about this one. Of course almost all companies have more than one segment. Most companies use VLANs extensively. We break out DMZs and internal data center LANs of course. Sometimes we use firewall interfaces between those VLANs or segments and treat them as zones.
But are we really segmenting for the sake of security with those segments? Do we have fine grained policy in between them or even make them private VLANs?
One way to put up a metric for this would be to actually measure how many of your segments have rules that permit or prohibit access to other segments.
Metric Two: How exposed is something?
When you think about segmentation and what it does in the first place, it is trying to limit access to things. Our ultimate goal is to reduce access to the least amount possible, similar to the least privilege principle we use for running programs or servers.
But how can we potentially measure this?
To find a way to measure this, it makes sense to look at a application before and after segmenting it.
- number of possible connections into something
- number of possible and required connections into something after segmenting
- what about the quotient of the two, that would be a nice number on a reduced attack surface
Metric Three: How big is the blast radius if something goes wrong?
The idea of a blast radius is often mentioned when we assume breach and try to limit adversaries from spreading in our networks. As with exposure, we want to limit this to the least amount possible.
If you think more about this, the blast radius seems to be the opposite of the exposure, it defines how many connections something can make and have direct access to.
I’m in the process of preparing a third article on this and might expand on one or the other metric in the future.
comments powered by Disqus