Microsegmentation Needs to Isolate All Lateral Movement – Including Service Account Abuse

Originally published by TrueFort.

Written by Matt Hathaway.

The devastating part of a cyber attack is when it reaches application environments with sensitive data to steal or encrypt. While microsegmentation is recognized as the best way to minimize the spread of the initial compromise, it cannot truly isolate via network blocking alone. Controlling lateral movement requires that you also prevent service accounts from running commands on workloads where they aren’t required for application operations.

The most devastating attacks are those that spread undeterred

Ransomware is not a large concern when it encrypts a single server. A single administrator getting their credentials phished rarely puts customer data in a criminal’s hands. A software supply chain vulnerability isn’t severe at the moment of exploit – but as a stealthy jumping-off point. Regardless of the initial compromise, the devastation begins when it spreads to a production server or, worse, a critical database. And the primary reason is that security devices offer little visibility into lateral (AKA East/West) activity.

This lack of control over lateral movement is why so many organizations are now being required to implement the best way to combat it: microsegmentation. Cyber insurers, regulators, and Zero Trust architects all agree that legacy (macro)segmentation and application security measures are insufficient for combatting lateral movement. But not all microsegmentation is the same; a lot of vendors promise the ability to block traffic from the hypervisor or the network, but their guidance is limited because the solution doesn’t consider the attacker mindset for finding success.

Attackers know that the place to hide is within application environments

Thousands of workloads, often making dozens of network connections per minute, make it nearly impossible to know what normally happens. Most activity in production environments is executed by automation, meaning that not even the developers who wrote the code or the operations team monitoring production truly know why a given activity occurred or what needs to happen. And the average cyber attacker knows this, so once they’ve gained access to one of these environments, they study the tools in place, dump credentials from memory, and “live off the land” to move undetected.

The great thing for attackers about automated activity is that it is repetitive and, therefore, predictable. Existing segmentation, and even microsegmentation, solutions fail to explain what happens within applications on a regular basis – their analysis stops at what ports and protocols are typically used between IP addresses. However, lateral movement within and between applications is much more than network traffic. If you are only putting controls over network connections, you’re not segmenting in a way that stops attackers.

The spread of attacks is not merely done through new network connections

Setting restrictions on network traffic is effective at blocking known malicious activity, but it is not isolating behavior to the portion of the network where it belongs. Most actions taken after compromise are not obvious network connections on bizarre ports but rather abusing something else: identity. Not necessarily human identity, but the service accounts automated into daily operations, often by developers who don’t have any ability to monitor their use, maintenance, or retirement.

Services accounts are used in a highly predictable way and should always be limited to the applications where they are needed. To truly isolate the spread of attacks, you need technology that identifies unusual behavior in network connections, the commands executed to make those connections, AND the account used to execute the command. But you also need to go beyond the detection-only approach of so many behavior analytics tools – you need to prevent accounts from running unusual commands that instantiate network connections.