Over the past year or so we’ve heard lots about segmentation and micro-segmentation as new ways to build effective cyber defences in enterprise networks and data centres… but is it enough? Can we delve even deeper? I believe there may be a third leg to the segmentation stool: pico-segmentation.
Before I explain, I think it worth a moment or two to talk about the first two legs of the stool. Segmentation or network segmentation is really all about controlling the flow of traffic from one domain of control to another domain of control. These segments, or stovepipes are architected so that cross-domain communications can not be illicitly established. For example: traffic from the Internet flowing into your DMZ should only be able to communicate with the DMZ and vice versa. If security on the DMZ server were to be somehow compromised and a path from the DMZ to another system - in this case, let’s say your POS or financial transaction system - in a different domain was established, data from the POS domain should not be able to move onto the Internet because your perimeter segmentation rules wouldn’t allow it to pass.
Segmentation is almost always applied on the north-south traffic in a data center or in the cloud, especially when the traffic coming into the DC or cloud is from clients on the general Internet. A segment might also define a tenant’s specific group of assets, in a multi-tenant environment. Segmentation is usually found on perimeter security products like firewalls, but it’s not
cheap simple: it requires an advanced firewall with significant horsepower to manage inbound and outbound states for what may amount to millions of sessions. This level of processing and analysis is incredibly complex and very resource-intensive.
Micro-segmentation is all about managing traffic within a domain of control, such that only approved sources, destinations and services are able to communicate with each other inside that single domain of control - compared to segmentation where that traffic is unmanaged, once inside the domain.
With micro-segmentation, a domain of control may be a WAN, a LAN, a network subnet, a VLAN, or possibly even a mesh or ad hoc network among trusted devices. Micro-segmentation is typically discussed and architected with east-west traffic in mind in a DC or in the cloud. For example: a customer portal server is allowed to speak to the local LDAP server and the local DNS server, but the LDAP server and the DNS server have no need to communicate with each other. We’d place each server in a micro-segment within the domain of control, effectively creating a “segment inside a segment”. Micro-segmentation addresses the growing risk of a compromised server or device within a domain of control being able to communicate and perhaps subvert all the other devices within that domain - assuming conventional perimeter security is all that is available to the network. The ultimate risk is that somewhere in just about all domain of control will be servers that CROSS boundaries to other services. If they become compromised, they become potential attack-portal to other domains.
With that in mind, can we evolve this model further? Pico-segmentation may be the next evolution of security segmentation. Pico-segmentation takes the idea of micro-segmentation one step further: it’s not only about building micro-segments within a single domain, but further limits things such as ports used, protocols allowed, time of day, traffic volume, and packet sizes and other heuristics that distinguish legitimate traffic from unauthorized connections and attacks.
Let’s play out an example: you may have some east-west, micro-segmented traffic that is strictly limited to clients and servers that have a demonstrable need to communicate. But if we were to apply some additional rules to this - such as some measure of application control, upper and lower bounderies on traffic volume, what time of day this traffic should be allowed, etc… we may be able to further limit the ability of a compromised device to attack neighbors and improve our ability to spot abnormal communications. And what if we also require the applications themselves to obtain service-level authentication (logon) for any connection, even if we consider that device to be trusted inside that micro-segment?
We should keep in mind that the definitions of segmentation and micro-segmentation have not been formalized or agreed to by a standards body. Parts of what I call pico-segmentation are already be out there and useable, but not typically combined methodically with other forms of layered segmentation.
I believe the methodical consideration of segmentation + micro-segmentation +pico-segmentation is an opportunity for security architects and risk managers to model and apply a more fine-grained control into their infrastructures, or at the very least, be able to provide better guidance and more accurate assurance and risk calculations around specific information assets.
The IoT might drive pico-segmentation more formally
Looking at risk and liability, some systems and applications like games, social media and others may only require segmentation to show due-care and good faith in relation to service levels and availability… Meanwhile IoT systems and the devices that compose them that may be deployed to support safety-critical functions and infrastructure; they may require pico-segmentation to demonstrate the same levels of due-care and good faith and minimize risk and liability, as well as the potential for claims of negligence in the case of an incident?
It is widely understood that many IoT devices come from the vendor with limited security capabilities. This means that risk mitigations will need to be applied in places like gateways and networks, through methods such as pico-segmentation.
With that in mind, perhaps we should give deeper thought to the ideas around taking the idea of segmentation to another level. As the IoT explosion continues, I believe there is an immediate need to create more robust segmentation strategies to better secure these new environments and IoT systems and services.