Internal network security monitoring for visibility
By Patrick Miller
Internal network security monitoring (INSM) - visibility into what’s happening on your internal OT/ICS networks - is showing up in important places like the National Security Memorandum, CISA guidance and FERC rulemaking notices.
Keysight Sr. Industrial Solutions Manager Gail Ow interviews Ampere CEO Patrick Miller about internal network security monitoring. Interview edited for length and clarity.
GAIL:
Okay, so I'm back. Gail Ow, talking about industrial cybersecurity and with me again is Patrick Miller, CEO of Ampere. So this next question is about network monitoring and threat detection. Patrick, what are we monitoring in the ICS World in terms of devices and traffic.
PATRICK:
So from a devices perspective, we're monitoring all of the industrial things out there that are keeping our lights on our water flowing, our gas flowing, our transportation moving, they're not like a Windows or a Mac, or even a Unix device. In most cases, these are purpose built. They do one thing. They open a valve. They sense the quality of water or they open a breaker to stop power, for example. What we're listening to from a traffic perspective is they all talk to each other all these devices have to talk and communicate as part of a system. So we're trying to make sure that these devices are doing all the things they should be doing and not doing things they shouldn't be doing. We're monitoring as they're talking to each other and what they're doing at the same time.
GAIL:
So we're doing that how?
PATRICK:
In most cases, these devices can't take a software agent. They are purpose built. You can't install an antivirus agent on them, for example. So, we have to listen to the network to see how they're talking. And from there, we can get a sense of what's normal. We can say, well, this always happens, or that never happens. Why was that happening? So we can just look at the network traffic and see how the devices all talk to each other and look for anomalous things. This is really what we're looking for.
GAIL:
So it makes sense, we should be doing this, right. But do we have to?
PATRICK:
Well, in some cases, yes. If you are a part of the electric sector, then yes, there are some some elements there that you'd have to do. It's also finding its way into the gas space with the TSA Pipeline Safety Guidelines and Security Directives. It's making its way through the chemical and water sectors, likely, and some others as well. For now, electric as the only one that must do it. There are some components that are mandated in the gas space, but other than that, you should be doing this because it's very good for your operations, not the least of which is you'll know security issues. But you also know if some humans did something wrong, right accidents happen too.
GAIL:
So we should be doing this, it makes sense. But what would happen if we don't
PATRICK:
Right well, if you don't, then things can happen in your environment that you don't know about. And that can cause everything from outages to disruption of operations - electricity, water, gas, whatever. Or it could affect a product that's coming out of the process. You're really just trying to make sure that things are operating the way you're expecting them to. And if they're not, you need to know why. It could be malicious, it could be accidental, it could be just the machines are have had a problem.
GAIL:
You've mentioned in the past the concept of a black box for critical infrastructure. How do we get started and how do we get ready to do such a thing as a black box?
PATRICK:
So the concept of the black box is like a flight recorder. In the executive order 14028, there was the discussion of something called a cyber NTSB. When there's a plane crash or similar, the NTSB shows up. They're an independent body that does an investigation and the first thing they go for, at least in plane crashes, is that black box because it contains all of that important data for those important critical components on the plane. Or in other situations, if there's like a train crash or something, they get as much data as they can. So having something like that for a cyber incident would be tremendously useful, especially in critical infrastructure. As it stands now, whenever there's an incident, some organizations have some data but many don't have enough data, or any data at all. So this this concept of actually monitoring enough of the right things in the right ways, so that you or a cyber NTSB could actually effectively respond. That's the goal. That's what we're trying to do.
GAIL:
Makes sense. That's a great analogy. I appreciate that very much. The black box isn't something I can just go out and buy one, right?
PATRICK:
Yeah, this isn't something you just drop in and turn on. A lot of these networks need to be designed with this in mind - and many of them were not designed with this in mind. Originally, they were designed for ease of operation. Typically with critical infrastructure, they're really concerned with uptime and availability to make sure that machines are always running. It's how all of our original things were built but we're changing that mindset to segment them off, separate them, isolate them, and then put some listening devices in to somehow get that traffic and security data out of that network into another area where it can get analyzed. There’s also the issue of getting the humans to realize, process, and then take action when they find something. So it's not just something you just drop in and turn on. There's a lot of process and a lot of design and a lot of human components that come with it as well.
GAIL:
Can you give us an example of a situation that's happened where they weren't prepared - and they maybe didn't have a black box - and what could have been how this could have been better?
PATRICK:
I think probably the most famous one would be the Triton/Trisis/Hatman event. This was an attack that happened on a safety instrumentation system. These are the systems that keep big things from going ‘boom.’ The hackers got into this system, and they manipulated it in a way that could have caused real big problems. They made mistakes and shut off the plant - which is the only way they found out. They should have found out earlier using network monitoring tools to notice this long before it got to that stage. Here is a case where using this kind of anomaly detection would have given them notice well in advance of the successful attack. You shouldn’t be relying on hope that the attacker makes a mistake and somehow gives you notice.
GAIL:
So in more recent years, we've heard of these hackers getting in and actually sending different signals off to the HMI so people aren't aware of what's really happening. But how does that change things today?
PATRICK:
These tools can tell you when something like that happens. They're looking for anything out of the ordinary. If that happens, they're gonna let you know, using a variety of different types of detection. But if HMIs were getting different commands, or sending different commands, or getting different results back from some of the equipment - for example, fake results back from equipment to make an HMI think it's seeing what it's not seeing - these tools will definitely notice that and show you.
GAIL:
Well, Patrick, thank you so much for joining me once again. I sure appreciate it and I sure hope our audience does too. Take care. Thanks.
Also see Keysight Technologies’ companion blog - Why Internal Network Security Monitoring (‘INSM’) Begins with Visibility.
