Building Resiliency in Critical Infrastructure Networks Using Microsegmentation: Lessons Learned in the Real World – Source: securityboulevard.com

“There is more than one way to skin a cat,” my grandmother used to tell me. It turns out this idea applies to operational technology (OT) security as well. If we take a look at the market (and my own experience in this industry), some common fundamental principles of OT security emerge. These are: 

• Asset inventory
• Vulnerability management
• Intrusion detection
• Data flow detection
• Configuration change detection
• Risk scoring 

In this blog, we’ll examine the investment in time (and therefore money) for the various methods. First, let’s take a brief look at each security approach.

Asset Inventory – A foundational feature, universally agreed to be needed for everything that follows. Valuable to engineering in and of itself. Any debate on this is about the level and value of the detail.

Vulnerability Management – Just like in IT asset inventory, for each operational technology device we need the exact make, model, serial number, firmware version, and known vulnerabilities. Then we have to go out and patch, baby, patch. That’s when we discover that a lot of company politics and real-world risk is introduced by patching and firmware upgrades. You probably just generated years of work for someone. It’s OK, though, because most organizations probably have 10 or so people sitting around waiting to do this. (Or, much more realistically, not.)

All kidding aside, if you have:

• A mature vulnerability management program
• The willingness to add your Industrial Control System (ICS) environment to that program
• The ability to score risk based on the importance of the asset
• Agreement on which asset types (Windows, Linux, controller, VFD, etc.) get patched at what time, and what to back out if problems occur
• The staff to take on the additional workload 

Then, by all means, go ahead.

That isn’t a snarky attitude. It’s an open-eyed look at what happens after you deploy; an attitude earned by my painful experiences in the real world. We often forget what the care and feeding of these systems look like, which is sort of the point of this article.

Intrusion Detection Systems (IDS) – Just like IT, or even easier, because you have a much smaller set of targets, and the protocols are better defined per device and device family. Most importantly, you should be able to define which assets can talk to each other.

When you first connect, you will probably see a horrifying set of misconfigurations and other network issues, but the IDS tool can help you clean them up. A well-tuned system (which is where the heavy lift is) generates minimal false positives. But you need an OT networking and security person to work with your engineering group to get that done. Then, you need a well-paid SOC analyst who knows OT to watch the screen(s). The implementation can be a bear—you have to ID (or install switching) where you can TAP/SPAN, and it’s hard to come to consensus on what devices can speak to each other.

Data Flow Detection – A close cousin of IDS, the philosophy is that since we are listening to network traffic anyway, let’s give the user some attractive graphical screens that show the conversations. The dirty little secret is that all these capabilities are based on sensors spread throughout the network. And yes, I know there are some that have ACTIVE abilities. But to see conversations, you have to have a bunch of sensors. They come in different flavors, but realistically it’s a chunk of hardware deployed widely to get this ability. The cost is not only in the sensor, but in the planning, disruption, and labor of deployment.

Risk Scoring – This is all about prioritizing responses in vulnerability management or intrusion response. We know we don’t have time to cover everything, so what do we respond to first?

I told you all that so I could tell you this: it doesn’t always work smoothly in actual practice. Whether you are chasing vulnerabilities or chasing intrusions, you must dedicate staff to the task. If you have the people, or have the budget to hire them, that’s great. However, I’ve seen too many customers walk down that path without understanding what it takes. (Spoiler alert: I am going to suggest a different approach.) 

In the next section, I will assume a base knowledge of the NIST Cybersecurity Framework (CSF) 2.0. I will not cover governance or identity (in this article, anyway). For the purposes of this discussion, these functions are not affected by my approach. 

NIST CSF FUNCTIONS

PROTECT

The first big function is PROTECT, and the existing OT market covers this through remediation. In other words: find the vulnerabilities and patch them. A daunting task. Mitigation through compensating controls is left to the firewall vendors. Yes, some well-established firewall vendors have OT protocol support. They are used widely, but scale and expense are an issue. Much like the sensors mentioned above, deployment costs can be prohibitive. A firewall can be plugged in easily, but getting good results means writing very granular rules and deploying them widely. This is tough to do in any environment, and it’s exponentially difficult in the bowels of an ICS network.

There is a solid alternative here: software-defined microsegmentation. ColorTokens Xshield uses a combination of agent and agentless technology to protect ICS environments.

Here is a high-level view of how it works: an agent is installed on Windows or Linux computers. A lightweight hardware gatekeeper is deployed for controllers, HMIs, and older or highly sensitive systems.

In the initial phase, they listen to the traffic in the environment. A detailed visual representation of the endpoints and the traffic between them is displayed on the Xshield console user interface (as shown in the figure below).

By deploying lightweight, inexpensive, and minimally intrusive systems, we get a more detailed view of the environment within and between zones.

Typically, two things occur at this point. First, the zones and conduits needed for secure but ongoing operations are easily seen and defined. Required traffic can be modeled, tested, and verified—then ultimately whitelisted or blacklisted. Whether you are using IEC 62443 or other security models, Xshield makes it easier to start with large perimeters and then slowly and safely reduce the security perimeters in your environment.

Secondly, services that should not be present—or should only be present—within the ICS environment are identified. These can be addressed through configuration of the various endpoints and systems. For example, remote terminals are in use when prohibited, enterprise services are called upon, and DNS out on the internet is used.

DETECT – The classic definition of detect in NIST-speak centers around IDS functionality. The three ways Xshield helps in this regard are: a much better view into the protocols and traffic patterns of your ICS system; much less traffic in and out at chokepoints; and, should any adversary get a toehold, Xshield will report on blocked traffic when lateral movement is attempted. Any security analyst tasked with watching the system will thank you.

RESPOND – Think about the various ransomware and other types of attacks, where, out of an abundance of caution, operations were halted. Then, picture a drawbridge in a medieval castle.

During normal operations, the drawbridge serves as a chokepoint. Guards can inspect the comings and goings, looking for problems. During an attack, the drawbridge is raised. Xshield can be used as a drawbridge. During normal operations, traffic needed for data analysis or reporting can flow. During an attack, you can enforce predefined policies to protect and continue operations.

RECOVER – Pure-play OT solutions are not enough. Providing asset identification and intrusion detection capabilities is important. Going beyond that, having the ability to see and control traffic at the asset level is a game changer. No one can—or will—guarantee absolute security. That’s why we say we help you “Be Breach Ready.” Using the Xshield system, recovery times are reduced significantly.

I told you earlier there’s more than one way to skin a cat. And now you’ve seen my way. Microsegmentation isn’t magic, but it’s close enough. Just remember: nothing beats doing your homework first. Trust me; your grandmother (and mine) would approve.

Ready to talk OT security? Drop us a note, and we’ll figure out how to get you “Breach Ready.”

The post Building Resiliency in Critical Infrastructure Networks Using Microsegmentation: Lessons Learned in the Real World appeared first on ColorTokens.

*** This is a Security Bloggers Network syndicated blog from ColorTokens authored by Dwayne Edwards. Read the original post at: https://colortokens.com/blogs/cyber-physical-systems-security-microsegmentation/