This week on the PrOTect OT podcast, we speak with one of our own: Greg Valentine, SVP of Solutions Engineering at Industrial Defender. He has over 30 years of experience in the software industry. The past 15 of which have been focused on cyber security. Greg currently holds two certifications including an ISC2 – CISSP, and GIAC – GRID. In this episode, we discuss the difficulties in demonstrating compliance, strategies for obtaining high-quality data without relying on manual inspections, and ways to make the data useful, reportable, and suitable for audits.
Here is a quick excerpt of our discussion. If you're interested in these topics, be sure to listen to the full episode and subscribe to the PrOTect OT Cybersecurity Podcast.
Aaron: I know one of the biggest pieces of compliance is… how do I show compliance? If there's a requirement for antivirus or allow listing or logins or changing passwords -- I can do the thing, but how do I prove it.
Greg: A hundred percent a struggle. Yes. And this all depends on the compliance that you happen to be having to comply with. Because some are better than others at being more descriptive, more specific, more definitive on what they're actually asking for.
Compliance in general, it's a good first step. You're kind of being forced, and that's not nice, but it's a minimal level of cybersecurity posture to be in, right? Hopefully you take that and you run with it; you extend from there. But this is kind of your foundation level of a cybersecurity. So it doesn't matter if we're talking about NIST CSF or NERC CIP or IEC 62443, whatever it happens to be, that’s your base standing.
But proving it is challenging. A lot of this is in the eye of the auditor. And there's going to be some variance between auditors even. But you could write scripts, you could manually walk down the plant and write down the information that you need and log that, keep that in a safe place and bring it out when the auditor comes on board. But that is a lot of work. That is a lot of manual work.
And NERC specifically has requirements to show what has changed between two points in time. So that means you have to regularly go out and manually do this walk-down data collection process. So, it does depend on the rules that we're talking about, but you want something that's safe, first and foremost, and secure in the sense that it is not changeable. You want something that cannot be altered once the data is collected.
Aaron: You talked about NERC CIP. There are regulatory required compliance standards, but there's also internal ones, right? How do you see entities handling this? How many are overwhelmed with just doing that with that baseline standard, much less going above and beyond?
Greg: Compliance is kind of a strong word in my mind. You have regulating bodies and “thou shall do X, thou shall do Y.” If you want to play in that playground, then you have to comply with their guidelines. But organizations also have their own security policies that they have put in place to protect the organization – to protect their OT assets, to protect the enterprise. So in that case, compliance is a difficult word, but it's more of a minimum security posture. So, yeah, there's IEC, NERC, TSA, NIST, CIS, etc., but your organization probably has some cybersecurity guidelines as well that you also need to make sure you are complying with. The fines aren't the same, but job security might be at stake instead.
Aaron: Smaller OT environments, they just don't have the bandwidth and the personnel to really focus on cyber. How do organizations deal with compliance in an environment where they normally just leave it – set it and forget it?
Greg: So this kind of bleeds into what's the cost benefit analysis. Some of this you can solve manually. Or you can purchase a tool or a solution of some kind that automatically, on a regular cadence, collects this information and gives you reporting capability and the ability to compare two points in time. All of that automated stuff is really great for auditing because it's unalterable and your auditor can even use that product for the specific report they need. It's also a big time saver as far as manual time goes. You don't have to walk the plant once a week or whatever the cadence happens to be because, yes, you may not be changing the configuration on your systems, but you have to validate that it hasn’t changed. You have to go collect the information and then compare it. And that is a giant problem, honestly, in the OT space. On top of people's regular OT engineering jobs, now they're being tasked with collecting all this configuration data and comparing it with other points in time. It's a real challenge.
Aaron: If you got a job tomorrow and they didn't have any compliance program and they said, “Hey, I need you to build a compliance program. We've got sites all over the country, all over the world. We don't have any other OT staff, you're it.” What do you prioritize and how do you go about standing one up?
Greg: I would probably start by one of the big compliance frameworks like NIST. And then I would probably go through the process of bringing on board an automated solution to collect this information on a regular basis. It's boring to say, “you can't protect what you don't see” or “you can't protect what you don't know about.” But it's absolutely true. You can't build a program around things that you just don't have eyes on. And you need more than just the IP address of that box, the name of that box, and the MAC address… you need more than that. You need to know configuration information, then you can really get a sense of “where am I exposed? Where am I pretty well buttoned up so I can worry about other areas?” That's where I would go and I would look for a solution that's been around for a while. I would look for a solution that could run NIST CSF. And again, ensure data that is regularly being updated.
One thing that I'm most concerned about in the OT space is just the culture of “this is just the way that it always has been and the way that it probably always will be.” And from a safety perspective, this is probably a good thing. But it’s the pace of change, the pace of accepting new ideas that’s different. So I think that cybersecurity is a different way of looking at things than your process automation/engineering way of looking at things. It's the merging of the two and finding that happy middle area. So that's taking longer than I had thought it would, but it's much better today than it was 10 years ago by far.
This has been an excerpt of a PrOTect OT Cybersecurity Podcast episode (edited for clarity). For the full conversation, listen and subscribe here: https://podcasts.apple.com/us/podcast/the-protect-ot-cybersecurity-podcast/id1662081824
