Episode Three: Bridging Patch Management and Vulnerability Strategies for NERC CIP
Hosted by Jay Gignac, this episode of the Foxguard OT cybersecurity podcast brings together Scott Crow and Kathyrn Wagner from AssurX to discuss why patching and vulnerability programs are mission critical in OT environments.
The conversation focuses on translating NERC CIP requirements into actionable workflows, balancing compliance with real world security risk, and prioritizing vulnerabilities using CVE and CISA KEV data. Jay, Scott, and Kathy also explore the challenges of OT patching, managing low impact assets, and building defensible documentation for audits. This episode also highlights the collaborative approach between Foxguard and AssurX in helping utilities reduce operational burden through integrated patch intelligence and compliance workflows. Designed for utility, compliance, and OT security professionals, the discussion offers practical guidance grounded in real industry experience.
Listen now or read the full NERC CIP OT patch management podcast transcript below.
Looking for more context on the topics covered in this episode? Explore related posts from our Decoding NERC CIP & OT Security series:
The Critical Role of Vendor-Approved Patching | Decoding NERC CIP & OT Security Podcast: Episode Two
Decoding NERC CIP & OT Cyber Security Podcast: Episode 3 Transcript
Jay Gignac: All right, so let’s get started. My name is Jay Gignac, and I’m glad that you can join me for episode three of our podcast series today. I’m very lucky to be joined by Scott Crow from AssurX, as well as Kathy Wagner. I will give them a chance to introduce themselves in just a moment. Scott is the Senior Business Systems Strategist—that’s a very fancy title, Scott—and he’s focused on energy and utilities, and Kathy is VP, Industry Solutions, for Energy and Utilities. It’s a pleasure to have you both with me. We use this podcast to generate conversation and encourage some back-and-forth discussion. I’m looking forward to having this conversation with both of you today.
Can I please ask you guys to introduce yourselves?
Kathyrn Wagner: Yeah, hi, as Jay said, I’m the VP of Industry Solutions for Energy and Utilities here at AssurX. I’ve been with AssurX for over 13 years, working with utilities, mostly to help them implement their compliance management solutions.
Scott Crow: I’m Scott Crow, Senior Business System Strategist, which basically means that I geek out on compliance. The last 11 years I’ve spent helping Energy and Utilities in North America with the intersection of Cybersecurity and NERC compliance. So, nice to see everybody.
Jay Gignac: Thank you both. Great to have you here once again.
So, I want to maybe talk a little bit about what to expect from this episode and these podcasts in general. We tend to focus very much on OT Cyber Security. We will touch on other topics that revolve around this. There’s, of course, compliance, which is a big factor in what we talk about. And although you could see that as being adjacent to cyber security, I think it’s really part of what cyber obligations are from an enterprise standpoint.
We do talk about patch management because that’s the background and history that Foxguard has around outsourced compliance patch management programs, and so on. We’ll touch on vulnerability management and all the implications around that, as well as how to implement best practices in OT. So, I’m looking forward to having my esteemed guests be able to talk on these topics and contribute. We’ll talk about potential future topics for the podcast, and we always welcome feedback. Please reach out to us on LinkedIn, either on the company’s LinkedIn site or to us as individuals, and we’re happy to receive feedback as well as suggestions on future topics.
All right, so here are the topics we have for the conversation today: Why Patch and Vulnerability Programs are Mission-Critical to Operations, Translating CIP-007 and CIP-010 into Actionable Workflows, Risk-Based Prioritization With CVE and CISA KEV, Low-Impact Systems–Simple But Effective Management, and Decoding a Collaborative Solution Between Foxguard and AssurX.
And without further ado, I’ll give a very short overview of what Foxguard does today.
Foxguard has been around since 1981. We came into the market very much on the Compute side of things, doing Compute Custom Systems for many of our industrial customers, from utilities to OEMs to a very diverse group of customers across the board. So, we’ve been in this space for a very long time, and roughly about 15 years ago, we had emergent solutions on the cyber security side, and our portfolio today really has been an evolution of the initial program that we stood up for patching within the NERC-CIP industry. Essentially, we’ve evolved that portfolio to meet the current needs of our customer base, as well as being members of the OT industry and collaborating across the board with many partners, including AssurX.
So, from discovery, Foxguard Discover starts our portfolio off around asset detection, discovery, and threat mitigation. This is centered around CIP-15, for example, to provide the means to not only comply, but also have available solutions that really combine with the rest of the components in the customer portfolio, to understand the journey and relationship between asset vulnerability and patching. The synergy and relationship between those three components are very important for us. We launched Discover, really to address the fact that many customers had ineffective patching programs, based partially on the fact that they had a hard time really understanding what assets they had within their environment.
But of course, there’s a close relationship to our Cyberwatch product, which is around compliance management, vulnerability management, and asset management in a modern platform, to help decision making and prioritization from a vulnerability standpoint.
Both of these feed our flagship product, Patchintel, which Foxguard has had for the last 10-15 years. Patchintel is centered around streamlined multi patch intelligence and management, as well as providing the binaries, compliance, and audit ready documentation back to customers—including evidence packages and so on. That’s also followed by Foxguard Deploy, which allows us to do patch distribution in a secure manner in order to get the patches where they need to be.
And essentially, we support these things with a number of services from Risk Assessments, Program Development, Audit Preparation, Post-Audit Remediation, Training, System Hardening, Patch Management as a Service (PMaaS), as well as other dedicated services that we offer to our OEM customer base. And of course, we do provide compliance and regulation expertise internally and consult in this space.
That’s a very long winded, description of what we do!
So, our first topic is going to be around why patch and vulnerability programs are mission critical. I’ll ask my esteemed guests to help me answer the first question, which is really the first topic. Let’s talk about the intersection of NERC-CIP compliance and real-world security threats. Scott?
Scott Crow: Yeah, thanks, Jay. You know, on my LinkedIn profile I’ve had for probably the last 15 years, you know, living at the intersection of people, process, and technology. And as I looked at that, and we were looking through these slides, I think it’s more than technology. I think it’s systems. And I think when you say systems, you’re talking about controls. You know, security and compliance used to be two different conversations, but hopefully today, they’re intertwined. But it really is that intersection of people, process, and systems, and the real goal of patching—especially in the OT world—is reliability. You know, we’re under attack, there’s lots of threats out there, and it’s a lot to orchestrate all of this. I heard a quote one time: it’s not one thing about NERC compliance that’s impossible; it’s that you’re doing 800 things all at the same time, with different dates and different triggers to kick things off. So, NERC compliance is really building your internal controls to map to the standards. And frankly, they’re not prescriptive in a lot of ways, which gives entities the opportunity to map it to their own procedures and processes. But it also gives ambiguity when you’re preparing for an audit, because everyone looks at this a little bit differently.
Jay Gignac: Very interesting point of view. Would you say that—and I can feel your answer because you and I have talked about this in the past—but I often hear the talk around compliance is enough, versus approaching this from a security standpoint. What would be your thoughts around that?
Scott Crow: Boy, you can be compliant but not secure. I mean, if we look back at several examples, you know, the SolarWinds—that was an authentic patch; you would have been compliant, but it would have taken you down. And so, they’re different, and I think when you’re building internal controls, I truly believe that you should not have separate controls for compliance and separate controls for security. They should be intertwined. They should support each other. You can document the things that you need for compliance, but if compliance is the goal, I think you’re in trouble. I heard something at EnergySec a few years ago, and it really made a lot of sense: compliance is the floor, not the goal.
Kathryn Wagner: I would say it’s a very good starting point for a security program, maybe because there are well-established rules and guidelines. But you start saying, look, I have 35 days to go and look for a patch and apply it like CIP says you can, but sometimes that’s simply not enough. You need to pay attention to vulnerabilities and learn what they are, react to them, and then prioritize your patching based on those vulnerabilities, which some of the other cyber security frameworks tell you to do, even though NERC-CIP does not.
Jay Gignac: Yeah. That’s a great point. And I’ve observed in many conversations that I’ve had with some of our customers, or even in the industry, that as a general guideline, NIST is being used to kind of supplement with the basic regulation that NERC-CIP mandates. Is that also your experience?
Kathryn Wagner: When I’ve noticed a good security program, it’s my experience that they’re taking the intersection of NIST and the CFC controls, and TSA has its own set. But when you start saying, you know, let’s pick the best and the strongest controls out of all these frameworks—that’s when you have a really good program.
Jay Gignac: Okay, great. So, managing patching in OT environments while minimizing reliability risk. Scott, can you give us your thoughts about this?
Scott Crow: When we’re talking about IT patching I think it’s patch velocity; that’s what you’re looking for. You’re looking to get those patches deployed, and quickly, because you can do it! With OT patching, you better evaluate your risk first. You’d better really do some diligence prioritization. Hopefully, you have a test environment, but frankly, I don’t think anyone can afford to have a digital twin of everything that they own. So, evaluate that risk.
You know, IT moves data, OT moves physics—and with data, if something bad happens on a patch, you can roll it back. You have data recovery plans. You have all kinds of backups. In an OT environment, if you break a 40-year-old OT device that was not built for security, that thing is down. And it can cause reliability issues. When I talked with one of the auditors a few years ago, I was kind of asking to try to get an understanding of the auditors’ disposition as they go into the audits. Are you looking to, you know, play gotcha? Are you looking to uncover something that you think is there? And what he told me was that we’re focused on reliability. You know, if you look at reliability first in the name of our regional entity here, it’s reliability.
Jay Gignac: Yeah, I agree. That’s also the feedback that we encounter in either many industry events or even the regional chapters. The discussions that we have are not around finding fault, but rather how to help the members be more resilient.
Scott Crow: Right.
Kathryn Wagner: I will say this: one thing that’s really nice about the Energy or Power Industry is that they all want to keep each other reliable, and they share knowledge, tips, and best practices to try and get there. AssurX also works with other industries like Life Sciences and Manufacturing, and they usually approach things with a competitive edge, “oh, I don’t want to give you my secrets,” whereas the Energy Industry shares everything, and it’s a very good healthy environment to work in.
Jay Giganc: Yeah, that’s such a great point. I think, if you’ve engaged with some of the E-ISAC industry—and I know that you guys are obviously engaged in more than just utilities—I was impressed, what was it, probably 12 years ago now, when I went to my first E-ISAC to see the collaboration efforts, the sharing of intelligence, the workshops, and really the engagement across industry, both private and public, to really collaborate towards a better outcome. And I think that tradition has been maintained. So, I’m glad to see us, for example—and I know you guys do the same thing—but to see Foxguard participate in the CIP-C meetings, the chapter events, and the regional events in order to support that collaboration and that education, essentially. We understand that—from the private industry perspective—there’s a higher skill level at times, it’s a little easier to maintain resourcing, and so on. And maybe from our customer perspective, those challenges can be very cyclical. Budgets are always hard to come by, and resourcing is always difficult to come by, so I see our roles really as supporting them with the challenges that they have. And that doesn’t always equate to, “I’m helping you, but there are dollars involved,” right? We try to maintain a very close relationship and partnership with the community.
So, here’s a big one from my perspective—and I think we’ve been talking about this for probably 25 years, in my case, supporting customers with security products, from IT back then to OT over the last ten years—but it’s really been one that’s hard to get past, and that’s shifting from reactive to proactive. And I think that’s given even more meaning now as we’re seeing adversaries leverage AI, for example, to automate many of the attack functions, and to be able to exploit as many gaps as possible within customer defenses. Then there’s timing, as there’s obviously a timing effect to closing gaps and managing your attack surface and vulnerabilities. But I’d love to hear from both of you on this topic.
Scott Crow: Yeah. I was at WECC and saw a presentation that was pretty sobering. It said, you know, we’ve been focused for the last ten years in this space on keeping people out, keeping the bad guys out—prevention, prevention, prevention. We’ve talked about resilience kind of as a passing thought. But what this gentleman said was, “you should probably assume that the bad guys are already in your network. You should probably assume that somewhere, there are bad things potentially happening.” So, you know, tighter controls, getting those patching vulnerabilities taken care of, and all the traditional things that we talk about in cyber security. But again, that tone has started to shift to where we’re really focused on, “gosh, what if they’re already inside our network?”
Jay Gignac: Yeah, definitely. And it’s interesting to see that the conversation has shifted over the last decade from what if we are compromised—to we are compromised, and essentially, how do we recover as quickly as possible? When I was with Cisco, probably around the same time frame of 10 to 12 years ago, we were having discussions around funding and where our customers were building their budgets and it was sobering, to your point, to see that 90% of the budget was being spent on prevention—from hardening systems to locking down, to putting solutions in place to manage the attack surface—but very few dollars were being assigned to help recover or even manage incidents as they occurred. And we see this still today in OT environments, where too often Incident Response plans or management plans are dated and not updated very often, and unfortunately, don’t necessarily reflect the reality of an OT environment.
So great points. Anything that you want to add on this before we move on?
Scott Crow: No
Kathryn Wagner: No, thank you.
Jay Gignac: Okay. Wonderful. So let me just bring up our next topic: Translating CIP-007 and CIP-010 into Actionable Workflows. I think that’s a challenging one and I’d love to get your perspective. Why don’t we start with practical steps to align patch schedules with compliance requirements?
Scott Crow: Kathy, you want to take that one.
Kathryn Wagner: Well, I would say the first thing is understanding the full scope of which compliance obligations apply to you. And that might be just NERC-CIP, and it might vary based on how many low-impact, medium-impact devices you’re trying to manage, that’s part of the story. But it’s also how many other cyber security frameworks or other regulations apply to you, and how to make sure that they get blended into the program. So first, understand that, document that, understand the schedules that you have to apply to, find the controls that cover all those bases, and then elevate it to a more secure framework.
Scott Crow: And with as much attention that has been paid to the medium and high-impact assets, the crown jewels—we’ve talked about that for years. We have to protect the crown jewels first. The reality is that ransomware is still the number one threat, and they’re not getting in through your EMS. They’re getting in through some low-impact device that lives within that network, and they’re going to penetrate that and pivot. So, a lot of people have their eye on the important stuff because, well, it’s important. But what if they get in somewhere else because you’ve left that door open? So, while they may have low impact on paper, they can still let the fox in the henhouse.
Jay Gignac: Yeah. Going back to your previous point, you talked about aligning security objectives and compliance objectives together—this is a great point. You might be paying a lot of attention to your high-risk assets or your crown jewels, as you mentioned them, but essentially, the compromise won’t occur there. It’s through lateral movement that you’ll end up being in a bad state because your controls may not be as tightly validated when it comes to these types of internal threats. By that time, they’re moving within your organization rather than trying to get through the window or the door, as was often the traditional attack method. I think that most compromise today would occur from that perspective, given that there’s a lot of effort that’s paid to secure the front door, the windows, the chimney—which are all the obvious entry points—but we don’t necessarily pay attention to the Ring doorbell that’s connected to the Wi-Fi, and so on.
Kathryn Wagner: So, one of the things that you said—you know, we’re talking about turning these into actionable workflows and how they interrelate—and that’s where paying attention to all the sources of data that you need to work with comes in some of those are automated systems; some of those are people. So, coordinating those efforts, automating as much of it as possible, and then providing that governance and oversight to make sure that, if things aren’t getting done or if things aren’t being touched in a certain amount of time, people are alerted through dashboards, through emails, through reports, through automated escalations. And that’s where pulling these things together is going to give you the best outcome.
Scott Crow: And you talked about security funding. The typical CISO goes and tries to pitch what they want for next year, and the folks above them don’t really understand why they’re asking for these things.
One strategy that I’ve actually seen work is to tie your security objectives to your compliance objectives, because compliance gets funded—you have to do it. They’ve read the news, they don’t want to be the next one in the news, and so if you can tie east-west traffic monitoring to CIP-15 compliances, well then you’ve got a better business case than, “hey, I’d like to buy this thing to monitor something I really don’t even understand.”
Jay Giganc: Yeah, I couldn’t agree more. And I think that’s one of the most tangible ones that makes a difference, and obviously, I have my own thoughts about how CIP-15 is being described, and I think it’s very open to interpretation. So, I’m curious to see how that’s going to evolve.
But I’m going to go back to something that you said, Kathy, because to me—and I was thinking about that previously when Scott was talking—compliance builds the muscle. We have many “low” customers, for example, that today are not mandated to comply the same way as a “medium” or “high” customer would. But they do anyway, because they understand that compliance builds the muscle from a security hygiene standpoint. And we talked about the fact that it doesn’t go far enough, or it’s not comprehensive enough, but it does help develop some of the habits, standards, and policies that help the organization be more secure, because you’re developing these assets and artifacts within the business.
I think that we agree that once you’ve built the muscle, you actually have to go and use it. It’s not just a point of having done the exercise. You need to understand how it relates to your bigger objectives, or your enterprise objectives, when it comes to tying security and compliance together, and you both gave great examples of that.
Kathryn Wagner: So that’s an interesting point. And one thing I’d like to raise: if you build it right, if you build a program to support your high and medium impact devices, you’ve got a strong controls program, you’ve got automation, you’ve got things going on. To extend that to the low impact is hopefully not a big lift because you’re just spreading the scope, right? But for those cases where they’re only low impact, they don’t have a strong program yet, and NERC has been expanding its reach so that those low impacts assets now have to do these things—it’s brand new to them. And they don’t have those strong, medium-high impact programs in place. So, bringing it down to a level where, yeah, this is all new to you, but you’ve got to do these things, you know? That’s been a challenge that I’ve seen customers face.
Jay Gignac: Yeah, 100%. I couldn’t agree more. Okay, let’s talk about building defensible documentation for auditors. This is a big one for me and where I see, unfortunately, a lot of entities struggle. It’s around not only doing what they’re doing, but actually having to prove it out, and maintaining that documentation in a way that the auditor doesn’t scratch their head when they show up, trying to understand what they’ve done here. So, I’d love to get your perspective on this as well.
Kathryn Wagner: Yeah, I’ll take that one, Scott. Okay. And that’s where, if you’re trying to store your documentation in files on a file share and sending them around through email, you’re going to lose track of what version is the right version, where you stored it, and who has the latest. You start putting it in something like SharePoint, which helps a bit, but I’ve tried to use SharePoint without a lot of control over it, and you still get lost in there. AssurX has a part where we have document control, as it’s part of the compliance program. So, tracking those documents, making sure that every single revision is part of the history and that the audit trail is in the solution, and then identifying the teams of people that contribute to those documents—you know, having formal review processes that can be applied to those documents when they need to, as well as calendar reminders or scheduled reminders that say, “this document has to be reviewed every year, two years, 15 months,” or whatever schedule it is—all those things kind of pull together, and they sit right alongside the rest of your compliance program.
Scott Crow: And I have found it super easy to save things in SharePoint, but it’s not always easy to find things in SharePoint. I did a webinar on how to prepare for a NERC audit and talked to a friend in the industry. This is a real example of auditors asking for information, and that piece of information was actually in 12 folders.
ow are you going to keep up with that? And then in SharePoint, you know, the cat walks on your keyboard, and there’s an autosave, and is that the version you give to the auditors? So, you know, being able to save information is one thing, but being able to find it is another. And that’s one of the things that I love about what we do and using meta tags, essentially, because there is documentation that goes into multiple compliance obligations. Whether it’s within NERC, whether it’s NERC and TSA—if you look at the NERC standards from 2 to 15 on the CIP side, they all interrelate. You know? You have assets, you have patches, you have to track changes, how did you get those assets, that supply chain? So, they all interact with each other and the key is to build controls, build your guardrails to where your compliance doesn’t drift, to where you meet the obligations, you can find things, and to where it’s not a panic, it’s just a “hey, we do this every day.”
Jay Gignac: And I think ownership of defining your own scope—and you mentioned Kathy, earlier, that not every organization is the same, right? Even if they might be regulated by the same standard, or they might be subject to the same controls, you’re going to have uniqueness within each organization, whether that’s how they grew, if they grew by acquisition, their assets, their generational sites, and so on, and so on. There are many aspects here that are going to be unique to how you’re going to comply.
So, a lot of board advisor conversations that I’ve had in the past are to define your scope, define the scope that you can take on as an organization, where you’re going to need to partner, and where you’re going to going to need to augment the solution side of things and give yourself the right tooling to do the mission critical things that you need to do. So, thinking that your team has to do everything, or that you have to take on everything yourself is a very easy pitfall to get into. Probably one of the areas we find is most difficult for customers is trying to make sense of how they’re going to organize themselves, in a consistent fashion, to deliver predictable and reliable outcomes to their compliance process.
And there’s going to be everything that happens, right? People leave. Unfortunately, there are changes to regulation, or there are changes to the business aspect, or the business element, or even the operational conditions of the business itself. There are a lot of things that will impact how we do things, and it’s not going to remain stable. It’s constantly going to be in flux.
So, when we do program buildouts—that’s one of the areas that we discuss and engage with to understand, you know, what are the things that you control, what scope do you want to retain, how do you want to move forward, and who are you going to move forward with? So, it’s really a team sport to get this thing done.
Scott Crow: Getting it started is the hard part of anything. But what I’ve seen is that there are lots of folks out there who—let’s just say—have overengineered The Mousetrap for this particular requirement. I like to keep it simple. The analogy that I give is: you’re at the beach with your family and you go play Putt-Putt the last night that you’re there. You’re at the 18th hole, you hit it up the ramp, it goes through the pipe and through the windmill, then comes back down on the pipe, and the ball lands near the hole just six feet from where you originally putt it. Why not build the six-foot putt instead of the game of Mousetrap?
Jay Gignac: Yeah, great analogy. Remind me to never play Putt-Putt with you, Scott.
Okay, common missteps and lessons learned from utilities. We all have war stories; I’d love to hear some of yours.
Kathryn Wagner: Well, leveraging off what you were just talking about—how utilities, all the time, are selling off a piece, buying a new piece, changing out their infrastructure, right? I mean, you look inside a utility in the OT space especially—you’ve got some equipment that was installed last year, and then you’ve got stuff that was installed, you know, 20, 30, 40 years ago—and it all has to somehow continue to work together as the threat landscape changes, as the hardware landscape changes, and as regulations change.
We did have a customer that purchased another utility, and both were customers of ours, yet they had completely different approaches to how they were doing compliance. So, when they merged together, we all kind of sat in a room, and they had us there to help. They were kind of like, “well, how are we going to bridge the gap between these two approaches?” And it was quite the conversation to try and, as you said, come up with something that was going to be the best of both worlds.
Scott Crow: I think what gets people in trouble is that they still have silos within their organization. You know, I’ve been in meetings where IT is screaming at OT, and OT is screaming at IT. I’ve even heard, “hey, if OT picks that piece of technology, we’re not going to use it.” And that’s not helpful. So, politics, the silos, people, territorial stuff—it affects things, and that’s why you need a strong compliance culture from the top down. I think that is the most important piece of what you do. You need visibility all the way up to C-level. Everyone has a different motivator. You know, the C-level is now on the hook for SEC filings, and if something bad happens and it could have been reasonably prevented, negligence comes into play, where the CEO is probably going to lose their job, the entity is probably going to get a big fine, and really, that trickles down. So, if you have buy in at the senior executive level, you have a solid communicator as that orchestrator of compliance, both in IT and OT. Many customers we have are very fragmented, where transmission doesn’t talk to generation. You know, there are entities within entities; people are sometimes managing multiple regions, and so, it’s just a lot to keep up with. Simplify it, work together, and have that compliance culture come from the top down, where everyone understands the goal, and that we’re not competing with each other. We’re trying to keep the grid reliable, safe, and secure.
Jay Gignac: Yeah, great points. I think one of the things I’ve learned in my journey with OT is that the biggest hurdle to securing OT environments is in technology. It’s not funding. It’s not the threats themselves. I think the biggest challenge that gets in the way is culture. Some of the most successful organizations that I’ve had the privilege to work with have recognized that merging their cultures and essentially making sure that they have collaboration from the top down in order to organize the common objectives, to understand that there needs to be a change, and recognition that it’s not them or us. It’s essentially “we,” and we’re tackling a common problem. Examples we refer to often are where something goes down in IT. It’s inconvenient and can certainly have a business impact when email goes down, people can’t work, And they can’t communicate with the rest of the business or the outside world.
But if a boiler explodes from a paper mill, we’re talking about considerable damage to the environment, loss of life, environmental impact, financial damages—there are a lot of things that come into play. Now, that’s a change; it doesn’t happen on its own. It’s connected to other things that lead to these cascades of events.
But all of these very often tie back to how we view security. Is it really a business objective, and if so, do we realize that uptime, availability, and performance are all tied to maintaining an operational environment, which ties to security risks but also operational risk? All these things are tied together. So often you see these different teams that are pushing for the same thing, but they’re doing it in their own way without adding each other’s strength to that objective.
So, let’s move forward. I know this is one of Scott’s favorite topics, so we’ll try to keep him to a good timeline: Risk-based prioritization with CVE and CISA KEV, how to interpret vulnerability scores in the context of critical assets.
Scott Crow: Yeah, this is a fun one. I did a presentation at ERCOT a few years ago, and I love the Dragos OT Year in Review, and what was crazy was that almost 50% of the CVSS scores were just wrong. And until a few years ago, all we really had to rely on was “okay, well, it’s in the National Vulnerability Database, it’s this CVE, and here’s the CVSS score.” Well, you can have a CVSS score of nine, but if the system is completely isolated, there are compensating controls already in place, and you’ve already thought about all this, then it may not be a nine. And then things that are understated, perhaps by a vendor that has a vulnerability, and they say, “well, it’s really a three,” but to you, it might be a nine. So, I think the KEV is fun, and I know Foxguard is pulling data from lots of different places, but the KEV is a great example, the known exploitability database where these are things out in the real world that bad guys have hacked or compromised, and that probably should be at the top of your list if those are on your asset list.
Jay Gignac: Yeah.
Kathryn Wagner: But you talk about risk-based prioritization, right, of what you do, how you patch your things, how you deal with things. It’s your risk. It’s how it affects you, you know, risk of cold weather in Texas versus warm weather in Minnesota. I mean, they are different based on your location, the risk profile of what you have is contributing to a lot of different factors. The KEV comes into that. The CVSS scores come into that. But it’s also what features of those assets do you use? What environment are they living within? Is it a high, medium, or low impact type of thing. So, all these different factors play into what that risk means for you, and how you prioritize your patching or your activities based on that information.
Scott Crow: And one of the things that I heard a few years ago that made me laugh was when I met with a customer, and her focus was CIP-7 and the patch piece. She tells me, “My life is like the movie Groundhog Day; it starts over every 35 days.” And it’s true. Jay, you alluded to this earlier, the people part of it. One thing I found in entities is that they never have enough people; you know—OPEX dollars are precious. You oftentimes can maybe go out to the industry to make more money, or jump somewhere else, and so people are a real constraint. So, you don’t have enough people to do what’s already too much, and you have to prioritize what you can do and what you need to mitigate, and then you have to document all of it so that you follow your process.
Jay Gignac: That goes back to pick your scope, right? Don’t try to do everything, don’t boil the ocean—decide on what you can effectually impact. So, I think probably one of the most long-term conversations that we’ve had as an industry is that we’ve all walked into environments where the customer has maybe thousands of assets or in some cases, hundreds of thousands of assets. Then seeing that they have specific vulnerabilities attached to these—whether they’re medium or high—is not necessarily helpful. I remember when I was selling IDS products and collaborating with customers, one of the first things they would say is, I don’t want noise. Please don’t tell me that I have 10,000 critical severity vulnerabilities in my environment; I know—you’re not helping me by telling me this. What I need you to tell me is which are the ones I should be paying attention to. How are you helping me with my decision assistance, updating my playbooks, getting me to a point where essentially, I have decision assist and risk-based prioritization. And let’s go back to basics: Risk is likelihood and impact. So, going back to your point, Kathy: tie it back to me. I care what my neighbor is doing, but my neighbor may have very different circumstances, conditions, history, asset mix, and generational asset mix. There might be a lot of things that impact their risk profile that does differently than I do here. So please tie this back to me, show me my data, and help me wade through what I have, as there’s a volume of information that I have to process. As security practitioners, the challenge isn’t necessarily not having the right information but picking the right information to make decisions on. I think that we’ve done a lot, and it has improved. KEV is a good example of trying to focalize around how you need to be aware that something is particularly impactful and currently active under threat campaigns. The challenge is doing this from an automated or very streamlined perspective so that it becomes part of those muscles that we build to help us improve continuous security.
I go back to some common sayings as an industry, but the question, just as much as it’s not, “am I going to be compromised,” should be rather, “I have to assume I am, and I have to be able to operate in this manner, and therefore have good recovery, the ability to validate my controls, and be doing this from a continuous perspective.”
The question that we need to answer from OT, which has been particularly challenging over the last decade, is that historically, we’ve been very bad at getting projects funded from a security standpoint, and you alluded to this, Scott. We’ve been very bad at getting the attention required to get the security dollars to be able to help these under-resourced and underfunded teams do the job they have to do.
I’ve had board individuals say, “yeah, but when do we get there, when do we become secure?” There is no end to that journey, and we need to be honest about that. It is going to be an ongoing cost, and this is because it helps you deliver your mission critical output to your market. Whether you’re generating power or you’re putting tuna in a can, essentially, there’s going to be responsibility towards ensuring that happens in a safe manner and you’re keeping your investors happy as well. Oftentimes, these
decisions seem tied to individual vulnerabilities, but it’s all a chain, a series of events and decision-making that if we don’t do in a healthy manner, or pay attention to the right derivatives that we have to handle every day, this is where we get lost in drowning in this information, in not tying back to mission-critical objectives.
I could go on, but I had a very long conversation at OT.SEC.CON a few years ago with one of our OEM partners. At the time, her point to her customer base and the audience was that we shouldn’t start with what problems we have in security; we should start by understanding our business and our business objectives.
What systems support these business objectives, and out of these systems, what are the critical assets that you have? Start with this from a viewpoint of saying, “if the business needs me to do this, I need to pay attention to whatever category of asset they are in.” Essentially, you are supporting these systems which are generating an output of revenue, shareholder happiness, whatever it is—your business conditions are going to be different from one organization to the next, but the criteria doesn’t change.
So, let’s talk about balancing speed, risk, and operational constraints.
Kathryn Wagner: So, a lot of that stems from if you had a KEV, if you got a notification that something was amiss, that should trigger not just, “oh, I got to go do a patch,” or “I’ve got to go figure out if I need this patch or not.” It really should feed into the entire program. Maybe it should trigger somebody’s alerts, but it should also trigger that risk assessment so that it gets interpreted into the right result, and you can decide based on your risk profile how fast you need to react to that particular incident.
Scott Crow: Jay, you talked about noise, you know—nobody wants more noise. And I’ve been doing this long enough to where I remember when we didn’t have enough data to make great decisions. And now we have alert fatigue; we turn off notifications. But if you’re doing that… Because the world gets more complex every day, the threats get more threatening every day, and you’ve got to figure out a way to distill that data and melt it down to what’s important. What ties to the business objectives? What ties to what makes us money? You know, all of these things matter, and if you’re turning things off, from a security perspective, that’s bad.
Jay Gignac: Yeah, but just as bad, essentially, as being drowned in information and not understanding where you need to pay attention. So, I think that, obviously, to do what you’re describing, Kathy, requires the right combination of—and this is why it’s challenging—the right awareness, the right attention and focus, the right skill set, the right collaboration, and the right program to systemize what you’re going to be doing. So, it’s not simple, definitely not simple, and I think paying attention to making sure that you have a conscious, intentional approach to improving the security program both helps your security and compliance objectives, from my perspective.
Kathryn Wagner: Absolutely.
Jay Gignac: Let us keep going. Low-impact systems – simple but effective management. Let’s talk about why even low-impact assets deserve attention, and I think that you hinted at this before, Scott, so I’d love for you to expand on that.
Scott Crow: Yeah. Really, a lot of ransomware is not going to come in through your crown jewels. It’s going to come in from some workstation that hasn’t been updated, some HMI somewhere that you’ve forgotten about. It could be a vendor in a hole that they’re poking through for remote access. There could be a hundred ways that you get in. I’ve done site visits where you could actually get to the IP or to the wireless from outside of the electronic security perimeter, and our engineers discovered that the passwords on the inverters were the default passwords. So, it’s all of these things moving at once, and these are low-impact, you know, big solar farms in the middle of nowhere. But it has an effect on the environment. And again, if you get in one place, you know that you can pivot—you can move; you can get inside and wait, learn, and watch how things go, watch that East-West traffic, watch all of these different things happening. And then the next attack those folks have is going to be even more sophisticated.
Jay Gignac: That’s such an interesting point from my perspective, twofold. So, I actually think something that utilities do quite well compared to the rest of the industry is managing risk. But we can always improve, and we can get better data and better decisioning, and we can always optimize programs, and so on. But I think that if you compared to the pack, and you measure all the industries together, then I think utilities by far are some of the most mature and better practiced out there.
And when you look at distributed energy resources, for example, that risk is always expanding, there’s always more stuff that’s coming online. And then there are more responsibilities, and that, I find, is a very unique challenge because there’s a business aspect to it and obviously, there’s going to be a risk profile attached to it. So, it’s interesting to me to see many of the traditional players in this space, like the meter manufacturers, now playing an essential role in managing risk for utilities. Every player now has a role to play in the security chain, which yes, can lead to confusion, and it can lead to conflict and perhaps some overlap or bad spending in some circumstances. But overall, I find that there is a positive movement towards managing that expanding risk, at least from a utility perspective, so, I’m glad to see that collaboration actually paying off in many environments.
The other thing that I want to mention is that you talked about low-impact assets and being able to get to where you need to go being the goal. So, I used to do talks many years ago on educating business owners or decision makers that there was never an unprofitable cybercriminal or criminal activity when you are able to penetrate an environment. If you’re able to compromise an environment from a cybercriminal perspective, there’s never a negative interaction. You’re going to extract some sort of value out of the organization, whether you can monetize them easily, whether you can resell them, whether you can save it for later, whether that can be used as an attempt to leverage against the organization, and so on. I had the opportunity a few years ago to work with a national CISO, and the perspective that they had from a national level—of course, they met with industry; of course they met with the public sector—but there’s this mindset of looking at not only what they call leverage versus effect, but the fact that you can leverage yourself into a position, from a ransomware perspective, from getting control of a specific environment, that even if you’re isolated and you don’t have the ability to reach the critical systems that you’re trying to get to—the crown jewels—you can apply pressure on the organization.
And a great example that he gave us was people turning off refrigeration and causing issues in warehousing and in data center management. And if you start playing with HVAC or the environment, you now have leverage against the organization, and that’s just as effective as having a direct effect on the organization.
So, the value of understanding the systems that support the business processes that you need to go right, gains importance in my mind, because then you’re looking at assets from a very different viewpoint to if you’re just paying attention to critical or high assets, from that perspective.
Scott Crow: And you hit on a pretty good point there, Jay. The energy utility space is the best—they’re the best out there doing this. And it’s because they have to. Now, the sad reality is that it takes an event to have this reaction, you know? It was the 2003 blackout—we needed more regulations. We didn’t have doors on cockpits until 9/11. We didn’t really have any cybersecurity rules until Colonial Pipeline. And all of these critical infrastructure sectors—are they waiting for something bad to happen to their neighbor to justify the risk and likelihood? Most often, it’s yes.
Jay Gignac: Yeah, I agree.
Kathryn Wagner: I also wanted to add that, you know, we’re talking about all these different systems and how they play-in together. I think it’s very critical that an organization has a way to get all this information comprehensively, and that they’re involved. And that’s where integration starts to come into play: systems talking to other systems, automatic data feeds, those tools that go out and query the network to find information. You know, all those things feed into building this really comprehensive picture of your organization and then using other tools to help distill that into what’s important, when is it important, and what is the health of those systems at any given time.
Jay Gignac: Yeah, definitely. I think that’s a great point. Integration, not only from a cultural perspective, but from a process standpoint and a technological perspective, can be a great time saver and, in fact, improve reliability and quality greatly. So, I completely agree with you. Great. So, we’re nearing the end, and I want to talk a little bit about the decoding a collaborative solution—what we do together, essentially. Scott, I’m going to reveal your LinkedIn profile that you have worked in the past for Foxguard, and so I think that you’re in a very unique position to actually understand very intimately, the value that Foxguard and AssurX have together.
Scott Crow: Yeah, I think Foxguard has done a great job at easing the burden of patching, especially on the OT side. So Foxguard is out there gathering data and gathering intelligence—whether that’s through Patchintel or some of the Cyberwatch capabilities, or whether it’s looking at East-West traffic in your substations—providing data is great. But what we do at AssurX is consume that data, so it’s that integration piece—we bring things in and connect all these pieces together. Essentially, we can orchestrate workflows, align the controls that the entities have built to the process itself, and then the most important part is to be able to capture the documentation and evidence along the way, where you can find it later at the click of a button when the auditors are asking for information.
So, Foxguard identifies the patch; our system initiates the workflow. The folks are out there, evaluating and testing if there are delays and where people don’t get things done in a timely manner. We have the ability to send up escalations, red flags, and alerts, and do all kinds of crazy things. And then, validation of deployment is a big one. I know Foxguard has worked with us in giant patch management ecosystems with entities where, you know, you’re validating, and the baseline has been changed! And then you create that new list of the make, model, and version that Foxguard needs to go out and do all the good work that it does.
Kathryn Wagner: I first started working with Foxguard, integrating it into AssurX, I think it’s been 11 years now, with one of our common customers. It was an eye-opening experience. It was new at the time, this idea that we’re going to get this automated patch information and turn it into workflows in AssurX. It’s something that has turned out fabulously and has been re-deployed by other entities, you know—people love this idea. You’ve got hundreds, thousands of different patches you have to check up on every month, and Foxguard’s service is perfect for that. And then what do we do with that? Our tool is very good at keeping that history, initiating human workflows. You got somebody to evaluate the patch and then review the patch, document the decision on why you said yes I do, or no I don’t need to install this, you know, keeping the patch mitigation plans and bringing all that data together with the approvals needed to be compliant.
Jay Gignac: So, thank you. I think in both cases, you both gave great summaries and examples. I’m very familiar with where my customers struggle from the perspective of the problems that we solve, right? So never enough time, quality is one of the first things that tends to be impacted, which leads to findings that are essentially based on the gaps that they have. It’s not easy to do patch management, and we realize that the burden of compliance is particularly heavy in NERC-CIP. But just as much as there are things that lead to—and that are essential to—being able to do effective patch management, effective patch management doesn’t end with us.
A conversation that I have with stakeholders or customers is that what you’re going to do with this information, essentially, is the most important output that you’re going to create. And this is where I think that AssurX is a great partner for customers and for Foxguard. With what comes now, what you essentially have is information, and a lot of the hard work still needs to happen to a certain extent. Organizing yourself for reliable, predictable outcomes is what I think AssurX does a great job of providing to customers.
So, now that we’ve tapped each other on the back and told each other that we do such a great job, I would love to engage with anybody who has feedback, or more interest in engaging with any of the stakeholders that we have today. Obviously, very well known in the industry, both very reputable individuals. It was a pleasure to be able to talk with you guys today. If we want to talk in more detail about what we do together, I’d be happy to do that, and I would also be happy to reconnect with both of you on another podcast or perhaps a webinar. So, we’ll explore some of those venues in the future. Any parting words for our audience, before I let you both go with a big thank you?
Scott Crow: Oui and Merci. But thank you, Jay. It’s always a pleasure. I really enjoy the Foxguard team and all the things that you do out there. AssuX—we’ve been doing this for 25 years and really are able to orchestrate all the compliance controls that you’re trying to juggle all at once.
Jay Gignac: Great. Thank you, Scott. Kathy?
Kathryn Wagner: Thank you for your time today. I thought it was a great conversation, and I do look forward to talking to you again.
Jay Gignac: Likewise. Thank you so much. Stay safe, and we’ll connect soon.