In my previous article about micro-segmentation, I explained the 5 different phases in a micro-segmentation strategy. In this article, I will focus on the first phase: Monitor.
The monitor phase is a fundamental first step. The goals of this phase are:
- To create a device inventory.
- To discover traffic flows associated to those devices.
The device inventory must include all devices, regardless of whether they are owned or sanctioned by IT or not. This includes unknown “shadow IT” or “shadow IoT” devices. An incomplete inventory will most often lead to failure due to denied authorization or traffic flow: a business process will be broken. Device information cannot be simply pulled from a CMDB (Configuration Management Database) because a CMDB will not contain information about unknown devices: you don’t know what you don’t know. This information must be extracted from the network itself. It can then be correlated and enriched with information contained in the CMDB.
The OmniVista NMS can generate such IoT inventory report using information passively collected by OmniSwitch and OmniAccess Stellar devices. Devices are categorized and classified by type, vendor and model. More than 30,000 different types of devices are identified by their “fingerprint”, which is the combination of:
- The MAC OUI: the first 3 bytes of a device’s MAC address identify the manufacturer
- The DHCP fingerprint: the combination of DHCP options requested by the device
- The HTTP user agent used in HTTP get requests issued by the device
- The DNS fingerprint: the combination of DNS name resolutions requested by the device
This feature can be enabled in two modes: monitor mode and enforcement mode.
As a first step, this feature should be enabled in monitor mode only. This is straightforward and enough to generate the device inventory report in PDF or CSV format which can then be correlated and augmented with information from the CMDB.
Note that the detected device category may not be very specific at first. This is because certain fingerprints can only be taken at specific times. For instance, a DHCP fingerprint will not be taken until the device’s current DHCP lease expires and is renewed, or a HTTP user agent fingerprint may not be generated until the device contacts its server to check for a firmware update, etc. Therefore, IoT monitoring must be allowed to run long enough (e.g. at least a week) before proceeding to the next step.
The next step is configuring enforcement ARPs (Access Role Profiles) for the various identified device categories. At first, these profiles will be “dummy” profiles in the sense that their enforcement will have no effect over the device’s network connection and flows: when mapped to access switches and AP groups, they will map the device to the same VLAN that it was previously on and they will contain no ACL policies. The benefit of this seemingly unnecessary step will become clear when generating application flow reports, so bear with me.
Once these profiles are created and mapped to access switches and AP groups, we will proceed to enable IoT profiling in enforcement mode, but with no effect over the device’s connection or traffic.
For generating traffic flow reports, we can use one of the tools below:
- DPI (Deep Packet Inspection) – supported on Advanced OmniSwitch and OmniAccess Stellar devices, or
- sFlow – supported on all AOS 8 and AOS 6 OmniSwitches, or
- CBT (Client Behaviour Tracking) – supported on all OmniAccess Stellar devices
Out of these three, DPI reports are the most useful because they can be broken down by UNP (User Network Profile), which is a synonym for ARP. And this is the reason for enabling IoT profiling in enforcement mode even when the use of “dummy” profiles has no effect on connectivity or traffic flows.
But that is not enough to generate per-device-type reports.
When enabling DPI (Application Visibility) we must also:
- Enable all applications in the application monitoring profile
- Enable application “enforcement” and not just “visibility”.
The difference between “visibility” and “enforcement” is not immediately obvious so I will explain it here. Visibility simply collects “flow” statistics whereas Enforcement also collects byte and packet counts for those flows and, allows for policies (e.g. block or rate limit) to be enforced on those flows too. But crucially, Visibility reports cannot be broken down by UNP role, only Enforcement reports can. This is the reason for enabling DPI in Enforcement mode even if no policies will be enforced at first. However, DPI enforcement policies will be enabled during the “simulate” and “enforce” phases, so this is the right mode to use for that reason as well.
sFlow reports can still provide useful information but identifying the traffic flows associated to the device type of interest will require more work. First, because these reports are “top N” type of reports which feature devices that generate the most traffic even though those are not necessarily the devices that we may be interested in. Second, because these reports show device IP addresses instead of roles (device type) and deriving the device type from its IP address is not straightforward. That being said, one way of generating per-device-type traffic flow reports is to enable sFlow only for the ports that the devices of interest are connected to.
CBT can also be used to provide flow information. However, these are logs instead of reports. Deriving per-device-type flow data from these reports will require scripting or processing with a third-party tool.
Whatever feature you choose, make sure to monitor traffic for a long enough period such that flows associated to upgrades, backups and other events that do not happen so often can be captured.
That covers the different tools that will be most useful during the “Monitor” phase and how to use them effectively to produce the information that you will need in the subsequent phases of your micro-segmentation journey.
In my next article, I will focus on the “Plan” phase. I will compare the different segmentation features and explain when to use them – or not. Until then…