GettyImages-835976500 Article VFINAL-01

The 5 phases to build a network micro-segmentation plan – Cybersecurity Series Part 1

A couple of weeks ago, I wrote an article about macro- and micro-segmentation and the need to integrate NAC with […]

Post on 20.04.2021 by pmart
LAN Network management Security WLAN

A couple of weeks ago, I wrote an article about macro- and micro-segmentation and the need to integrate NAC with firewalls. Since then, several people have approached me saying something along these lines “This makes a lot of sense, however, how do I go about segmenting the network without wreaking havoc in the process?

Recently, we have learnt about multiple high-profile cases of ransomware attacks bringing entire hospitals and other institutions back to the dark ages of manual, paper-based processes. IT departments are in the hot seat and security has become even more top, front and centre than ever before. The mandate from upper management can be summarized as:

  1. Get it done by yesterday, and,
  2. No, no downtime

Spoiler alert: if you come here looking for the “network security on/off” button, there is no such thing. If it was that easy, you would have already pushed that button.  If you want to learn the methodology that will help you get there, read on.

(Micro) segmentation is not new, it has been supported on LAN & WLAN for many years. However, its rollout has been held back by a lack of understanding about 1) the very devices and applications that it is meant to protect, 2) the features, and 3) the architectures that combine them effectively. For this reason, micro-segmentation initiatives have been put in the “too hard” basket.

Until now.

In this article, I will present the overall methodology. In the following articles in the series, I will explain the steps in detail. Let’s begin.

This methodology has 5 distinct phases:

 

 

 

  1. Monitor: Before you do anything, and while you develop an appropriate micro-segmentation strategy, start collecting the data that will assist in its development. Turn on IoT profiling to have an IoT device inventory report – this will be key in phase 2. If your devices support it, turn on DPI and start collecting data about the applications used by each device type and their traffic flows – you will need this for phase 3. If your devices do not support DPI, you can still turn on sFlow collection on LAN and user behaviour tracking on the WLAN. You should also enable monitoring/logging on firewalls, proxies and other monitoring tools that you may have.
  2. Validate: Having an IoT device inventory, you now need to 1) identify the stakeholders, 2) research the security capabilities 3) identify the required traffic flows 4) asses the security policy compliance and 5) create a remediation plan if necessary. We need to answer the following questions: 1) Is there a legitimate business need for this device? If not, let’s get rid of it, it unnecessarily increases the attack surface. 2) what security capabilities does it have, does it support certificate-based authentication, encryption, etc? 3) what other devices and applications does it need to communicate with 4) does it comply with password, firmware updates and other security policies and, if not 5) develop a remediation plan for it.
  3. Plan: With information collected in the previous phases, we can now begin to devise a segmentation strategy. The exact strategy may be different for different device and user types. What is the right macro-segmentation strategy? Is it VLAN, VPN, tunnelling? What are the required device and/or user roles or profiles? What are the required micro-segmentation policies for each device type? How will the device be authenticated to the network? 802.1x certificates? MAC authentication? Or will it use IoT fingerprint classification instead? Will firewall integration be required?
  4. Simulate: In this phase, authentication and security policies are rolled out in “fail open”, logging-only mode. This means that devices that fail to authenticate will still be allowed to connect and unexpected traffic flows will still be allowed through. Authentication and policy hit and miss occurrences will be logged for a period of time and adjustments will be made until no critical misses are recorded. With these policies in place, even in logging-only mode, traffic monitoring reports (phase 1) become more meaningful because now we can filter statistics by specific role or profile.
  5. Enforce: Once we are satisfied that we have nailed the authentication and security policies, we can finally convert them to “fail closed” – any unauthenticated devices or unexpected traffic flows will be blocked (or quarantined) and logged.

In the next article, I will explain how to set up IoT profiling and DPI/flow monitoring to produce the most useful reports that will help configure policies later on. Until then…

Please wait...

Comment below to share your thoughts on this blog post

This site uses Akismet to reduce spam. Learn how your comment data is processed.