Simplified Segmentation with Intent
Introduction
This is going to be a little bit of a ramble but, hopefully, one that generates some interesting dialogue. I've messed about in networking and security for years. Sometimes we overcomplicate things, sometimes we overcook what should be relatively simple recipes. Network segmentation, particularly for mid-market/commercial customers, is one of the topics ;).
We all know why segmentation is a good thing, right ?. Just to simplify, we should contain devices, users, applications, services, etc in 'zones' and then restrict what can be communicated within and between those zones in order to minimise loss and disruption. Some industries are mature in this regard. For example, retail with Point of Sale systems - it should be pretty obvious that any device handing sensitive data such as card payments, should never be exposed to guest WiFi traffic (that might exist in said retail environment). Other industries are not - and sometimes because the process is a bit 'challenging'.
VLANs are good, better than nothing anyway, and have been around forever. However, they tend to be static in nature and aligned to IP addresses/subnets. We (us humans) and our devices don't tend to be that static any more, and if policy (how segments should or should not communicate with each other) is tied to subnets then things can get confusing pretty quickly - e.g. imagine a retail environment with 100 branches, each with a CCTV subnet, PoS subnet, HVAC subnet, Guest WiFi, Digital Media, etc, etc - let's just say 8 x subnets. They have to be unique and so that's 8 x 100 = 800 subnets now (there will be more ! ;)). Now imagine you have to build a policy that says, 'CCTV cameras can speak to a cloud DVR service only, and not even to each other, except for one admin machine in HQ'. That's 800 x subnets, so entries in a Policy tracked by subnet. Then do this for the PoS policy, etc. Starting to get complicated and that's where errors creep in...there's a better way !
Adaptive Policy
Imagine you could 'tag' traffic on the network, with those tags helping to (a) segment the traffic, (b) reflect intent for that grouped traffic and (c) be completely abstracted from fixed constructs, such as IP addresses/subnets. Well, guess what, you can ;). Cisco and our immensely clever engineers constructed this capability many moons ago and has been hugely popular in some of our larger, more sophisticated customers. However, it could be a little more involved and required a fair bit of planning and understanding to implement. How could smaller, mid-market/commercial customers make use of this fantastic capability but with the simplicity and efficiency typically demanded there ?. In steps Cisco Meraki - arguably our 'simplification' engine, and their ability to take these complex constructs and 'operationalise' them for the masses !
This software defined segmentation solution is called Adaptive Policy in the world of Meraki and, frankly, it's astonishingly simple to implement.
Some terminology first - and the main acronym that should be imprinted in core memory going forward, SGT - I'll write that again - SGT. The acronym can mean Scaleable or Security Group Tag depending on who you talk to (they are interchangeable). Security Group Tag makes more sense to me ;).
Intent based, or software defined, Segmentation can now be achieved using the SGTs that can be applied to the traffic on the network.
SGTs can be applied in several ways, with some examples shown below (statically or dynamically). In the case of dynamically, this could be based on authentication to the network and, depending on who or what or, indeed, many other attributes will be assigned a tag with which the network policy will then enforce.
Adaptive Policy is fairly well defined here https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Adaptive_Policy/Adaptive_Policy_Overview
You'll here more about how Adaptive Policy can then be aligned to Group Policies within Meraki as well as, and hugely importantly, how the abstracted SGTs can simplify Meraki MX based Firewall rules. As your local Meraki rep to tell you about these capabilities which round out the full Adaptive Policy requirement for a simplified full-stack Meraki deployment based on business intent.
Ramble
Now we go more in to the ramble section of my topic ;). I recently noticed what might be considered a bit of a 'gimmick' announcement from a network vendor using RGB based LEDs. This then having the ability to 'colourise' the port LEDs as needed. I do like purty colours........and what if you could reflect SGTs (and, therefore, groups - see the main topic picture) and associated allocation at a port level. SGT=Blue, so might as well make the port Blue. SGT=Yellow, might as well make the port Yellow. Of course, all that goes to pot when it's an AP attached, or a trunk port where - if we are being true to ourselves - will be White (ie all RGB) ;).
Of course, who's going to see this pretty stuff - we all know networking gear gets locked away in a rack somewhere and only the select few, the choses ones as it were, would be able to grace themselves in the presence of twinkling lights !.
And if there were a lot of them..........see below ;)
But it did make me think (always dangerous) and I wondered if colouring SGTs could provide a useful visual representation of the various groupings within a network and, perhaps, levels of traffic associated with devices within a group. Even, perhaps, a method to show traffic interaction between groups (assuming policy allows). My mock-up example below showing Blue, Purple, Green, Yellow, Orange, etc SGTs. Obviously not going to be much use to those that are colour blind, I have another idea for another article..... ;)
What is monitored ?
Software Defined Segmentation then made me think about best tooling to monitor network traffic for behaviour and intent (detection & response requirements). In true marketing style ('cos I can't remember where I read this), something like only 30-40% of what is attached to a network these days can be described as IT/Desktop managed (ie those Windows or Apple laptops the company gives us to do our jobs). About 60%-70% of devices are 'unmanaged' (in the sense that they are not typically managed like desktops, etc). Sticking to the mid-market/commercial theme these might be PoS, HVAC, Building Access Control, CCTV, Environmental Monitoring, Displays, etc 'things'. What we tend to call Internet of Things (IoT) devices. As our managed endpoints become more difficult to foil, then bad folks go after other targets of compromise and - guess what - the IoT devices are getting easier.
领英推荐
The 101 of what should be used to feed a simple eXtended Detection & Response (XDR) system, particularly where the network is involved is :
DNS
Always be looking at DNS (and might as well use that layer to control as well). Managed and unmanaged devices have to look up stuff, let's monitor what they are looking up ;). Can't do much better than Cisco Umbrella for this :
Netflow
A good old friend is Netflow - and it can provide tremendous insight and value from the network when determining traffic behaviour worth investigating. Keeping with the Meraki theme, ask your Meraki rep about the timelines for MX direct to cloud Netflow data........
Here, we can see immediate visual representation of traffic flows, as well as alerting data triggered either by Talos/Private intel or - indeed - trip wires created by the admin. For example, if I have SGT policies that say only RDP traffic allowed between IT Admins and these critical Windows servers, I'd like to know if I see RDP traffic trying to go to these resources from other sources.....
And if I'm going to monitor with Netflow, and I'm going to monitor (and protect) with Umbrella - I might as well have Cisco eXtended Detection & Response and wrap those two together (and also integrate other capabilities as needed !).
One of tiles below showing an MTTR (Mean Time To Resolution) KPI - is this a good measure of detection & response ?.
Summary
So, just to wrap up and summarise......
Software defined segmentation with business intent is made simple using Meraki Adaptive Policy. Simple is good - less prone to mistakes and, therefore, more secure.
Trust, but verify ;). Use DNS and Netflow to keep an eye on policy (and behaviour). This'll be Cisco Umbrella and, importantly, Cisco XDR (which incorporates a Netflow ingestion and analysis capability by default) to give you the feedback loop (and much, much more.....).
Go forth my friends, with intent.......