National Cybersecurity Strategy released.

Tré Hester: It's March 8, 2023. And you're listening to "Control Loop." In today's OT cybersecurity briefing, the White House has released its National Cybersecurity Strategy. MKs Instruments discloses a ransomware incident that spread to some of its vendors. Ransomware hits the Dole Food Company. CISA runs a red team assessment against a critical infrastructure organization. And LockBit has claimed responsibility for an attack on a water utility in Portugal. Today's guest is Tom Winston, Dragos's director of intelligence content. Tom spoke with Dave about Dragos's recently released 2022 Year in Review report. In the Learning Lab, Dragos's VP of product and industry market strategy, Mark Urban, completes his two-part discussion about the importance of incident response planning with Vern McCandlish, who is a principal industrial incident responder at Dragos.

Tré Hester: The White House last week released the National Cybersecurity Strategy. The strategy refocuses roles, responsibilities and resource allocations in the digital ecosystem with a five-pillar approach. The White House shared that two primary goals of this strategy are to rebalance the responsibility to defend cyberspace by shifting the burden of cybersecurity away from the individuals and onto specialized organizations in the sector, as well as to realign incentives to favor long-term investments by balancing threat defense with smart planning and investment. The strategy is planned to prioritize ease and effectiveness of cybersecurity implementation, quick recovery from incidents and reinforcement of digital values in three points highlighted by the administration - defensibility, resiliency and values alignment. The strategy has five core tenets - defend critical infrastructure, disrupt and dismantle threat actors, shape market forces to drive security and resilience, invest in a resilient future and forge international partnerships to pursue shared goals.

Tré Hester: The U.S. government is concerned that Chinese-made ship-to-shore cranes could pose a national security threat, The Wall Street Journal reports. The cranes in question are manufactured by the Chinese company ZPMC, which a U.S. official said makes around 80% of ship-to-shore cranes at U.S. ports. The Journal explains that these cranes, quote, "contain sophisticated sensors that can register and track the provenance and destination of containers," prompting concerns that China could capture information about material being shipped. The government doesn't point to any instances of cranes actually being used for these purposes, but the defense policy bill passed by the U.S. Congress at the end of last year requires the Transportation Department's maritime administrator to conduct a study to determine whether these cranes could pose cybersecurity threats. Note that the immediate risk being reported is a threat to information security, not necessarily to the operation of the cranes themselves.

Tré Hester: The U.S. Environmental Protection Agency on Friday issued a memorandum, quote, "stressing the need for states to assess cybersecurity risks at drinking water systems to protect our public drinking water," end quote. The memorandum requires that states include cybersecurity when they conduct audits of water systems. The agency said in a statement, quote, "While some public water systems have taken important steps to improve their cybersecurity, a recent survey and reports of cyberattacks show how many have not adopted basic cybersecurity best practices and are at risk of cyberattacks, whether from an individual, criminal collective or sophisticated state or state-sponsored actor." The memorandum requires states to survey cybersecurity best practices at public water systems. 

Tré Hester: MKS Instruments, a Massachusetts-based supplier of instruments, systems, subsystems and process control solutions that measure, monitor, deliver, analyze, power and control critical parameters of advanced manufacturing processes, has filed a Form 8-K with the U.S. Securities and Exchange Commission disclosing a ransomware attack and describing the attack's consequences. John T.C. Lee, president and chief executive officer of MKS, said, quote, "We are well into the recovery phase of our manufacturing and service operations following the ransomware incident identified on February 3. And we expect these operations will be restored over the coming weeks," end quote. 

Tré Hester: Since the ransomware will have a material impact on the company's first quarter results and it's still unclear what the impact will be, MKS is delaying its first-quarter guidance. The Silicon Valley Business Journal reports, quote, "The company currently estimates the impact from the incident on first-quarter revenue to be at least $200 million out of the revenue expected to amount to $1 billion." The effects weren't confined to the initial victim. The attack disrupted supply chains, as well. Semiconductor technology giant Applied Materials saw financial losses of $250 million in sales this quarter due to a cyberattack. A ransomware attack impacted one of the company's third-party suppliers, deduced by industry analysts to be MK Instruments, The Record reports. The Record quotes Applied Materials CEO Gary Dickerson as saying in a conference call, quote, "Very recently, one of our major suppliers encountered a disruption that will impact our second-quarter shipments," end quote. In a recent earnings report from Applied Materials, the company anticipates the second fiscal quarter of this year to net $6.4 billion and cites "ongoing supply chain challenges and a negative estimated impact of $250 million related to a cybersecurity event recently announced by one of our suppliers," end quote. 

Tré Hester: A ransomware attack on fruit and vegetable distributor Dole led the company to interrupt operations at its North American processing plants, CNN Business reports. A February 10 memo from the senior vice president of the company's fresh vegetables division said, quote, "Dole Food Company is in the midst of a cyberattack and have subsequently shut down our systems throughout North America," end quote. The shutdown affected deliveries of salad kits to food retailers. The specific strain of ransomware involved has not been publicly disclosed. But on February 22, the company posted the following disclosure to its website. Quote, "Dole announced today that the company recently experienced a cybersecurity incident that has been identified as ransomware. Upon learning of the incident, Dole moved quickly to contain the threat and engage leading third-party cybersecurity experts who have been working in partnership with Dole's internal teams to remediate the issue and secure systems. The company has notified law enforcement about the incident and are cooperating with their investigation. While continuing to investigate the scope of the incident, the impact to Dole operations has been limited," end quote. 

Tré Hester: CISA has published the findings of a red team assessment the agency carried out against a large critical infrastructure organization last year. The operation, conducted at the request of the organization, lasted three months. The red team was able to gain access to two workstations via spear phishing attacks. The team was also able to move laterally within the network, but were unable to gain access to the organization's sensitive business systems after running up against multi-factor authentication measures and time constraints. However, CISA believes that, quote, "by using secure shell session socket files, they could have accessed any hosts available to the users who workstations were compromised," end quote. 

Tré Hester: The LockBit ransomware gang has claimed responsibility for an attack against a water utility in Portugal. The record reports that Aguas e Energia do Porto, which serves as the country's second largest city, said that neither the water supply nor wastewater services were affected. But some of the customers' data may have been exposed. LockBit has given the utility until March 7 to pay the ransom, at which point, the gang says, we'll release the stolen data. 

Tré Hester: Dave Bittner sat down with Tom Winston, Dragos' director of intelligence content, to discuss Dragos' recently released 2022 "Year In Review" report. 

Tom Winston: This report is actually a thesis of all of the work that we've done during the past year. So it's - really what prompts the creation of it is sort of a way to summarize what we've seen, what we think is happening, what we think the trends are, what we think we need to pay attention more to and to some degree, what are the new and emerging topics in the ICS/OT space? 

Dave Bittner: Well, in the time we have together here, let's go through some of the highlights. So what are some of the things that rose to the top and really grabbed your attention? 

Tom Winston: I think that the CHERNOVITE PIPEDREAM was probably the largest thing that grabbed everybody's attention, mostly because this toolset represented - the PIPEDREAM toolset represents something that the CHERNOVITE actor is able to deploy across a wide variety of platforms and industrial verticals. It's still active as far as we know. And there's no fix. There's no Suricata rules or IoCs we can send out to people and say, here, this is the magic bullet. It leverages native protocols such as OPC UA and Modbus. So in other words, it uses those protocols that devices, say - it's level zero, level one in the Purdue model - would be using to communicate with each other on a normal basis, conducting normal activity, running processes, that sort of thing. 

Tom Winston: So it's a cross-platform multi-industrial vertical toolset that really - it's the first time we've ever seen anything quite like this. It's the seventh known ICS-tailored malware. We've seen others and we've seen TRISIS, certainly, and Stuxnet and things like that. But those were designed for very specific functions, very specific platforms with a limited range of capability, not under - not downplaying the importance of those, by any means. And even with the CHERNOVITE's PIPEDREAM, we're not trying to hype this, but it was actually a really interesting development - very, very far-reaching, could be horrendous effects if employed. 

Dave Bittner: Well, given the reality of that, what are you and your colleagues recommending in terms of organizations preparing and best defending themselves against it? 

Tom Winston: We're always - you know, we always talk about this sort of as having like an incident response plan in place, understanding where your assets are - you know, clear asset visibility, having a risk management-based approach to IT and OT sort of environments. A lot of times we find that - and this is actually a problem in several other ways. When a company focuses on their enterprise IT and not their operational technology or their ICS, that's fine for the enterprise IT but we find with things like particularly a toolset like this or a toolset like those ransomware actors employ, they cause a lot of trouble for those. 

Tom Winston: So typically, we want to tell people to sort of be aware of that, you know, doing things like having a good defense-in-depth plan in place - in other words, creating an architecture in your organization that's defensible. There truly is no silver bullet. No matter what you might want to do to stop all these attacks, there's never really any one thing. It's just a combination of many things. And really, what we would - we encourage owner-operators to do is to sort of consider not just the system 'cause you can look at IT - enterprise IT is a system of routers and switches and servers and databases and things like that. But - and you can also do the same thing with operational technology. You could say, well, there's controllers. There's PLCs. There's, you know, master terminal units and things like that. But what we want to - what we're really trying to encourage people to consider is that this is a system-of-systems problem, not just a systems problem. So we want to encourage people to look at this. It's a complex systems problem with a rather complex solution. 

Tom Winston: Mathematically speaking, these - solving a system of systems is actually very difficult. It's more complicated in some ways than looking at how networks interact with each other, how, for instance, meteorology works. Just - so what we're really telling folks to do is to look carefully at how your system of systems in your OT environment is interacting with your system of systems in your IT environment and to sort of have a very sanguine conversation with both the stakeholders - all the stakeholders across those areas, and, you know, to say, OK, well, this is not just an IT problem. This could be something that comes into the OT environment as well. 

Dave Bittner: Well, let's get back to the report. What are some of the other things that you think deserve attention here? 

Tom Winston: Well, there's a couple other things. Threat group activity was definitely steady, maybe slightly increased in 2022. When Dragos looks at threat groups - we track 20 of them right now - we're looking for activity that shows either an increase in activity, a change in tactics, techniques and procedures or a combination of both. So we did see Industroyer2, which we at Dragos referred to as Quatram (ph). According to ESET, the Slovak technical company, we found that they had updated the tactics, techniques and procedures for Industroyer, so that's why it's referred to as Industroyer2. And sometimes other organizations refer to Industroyer2 as CRASHOVERRIDE. And this is something that has to do with IEC 104. It's connecting and disconnecting electric substations. While there was no activity in the U.S., there was activity elsewhere. And related to that, we actually look at something called KAMACITE, which is - it appears to be an access development operation for ELECTRUM. So it's something that we - we're always looking for sort of evidence that there's more research being done for more targets if there's a growing target set. 

Tom Winston: Other areas of interest were XENOTIME. XENOTIME, of course, was the TRISIS malware from 2017 targeting safety instrumented systems. That's something we saw some activity in as well. It was against ports, oil, natural gas, key electric sites, things like that. And so we're always looking for threat groups that are presenting themselves as opportunistic. And there's a couple others that I would like to draw attention to as well. KOSTOVITE, this was that SCADA as a managed service type attack. Got in the SCADA systems, but not Ukrainian but similar idea. We don't know what the plan was. We're still watching that very carefully. And finally, BENTONITE was opportunistic, looking for information. There was - there is no evidence of disruption from BENTONITE at this time, but there appears to be some sort of concerted reconnaissance effort. 

Tom Winston: So if we see the steps, you know, sort of the MITré ATT&CK steps happening, you know, starting with recon and then moving to things like lateral movement or persistence, those are things that we're always interested in providing more detail on for everybody who reads the Year in Review. And of course, the other thing that I would like to draw attention to - and I don't really need to draw attention to this 'cause everybody talks about this frequently - is ransomware. And ransomware is clearly still a problem. And in fact, some of the ransomware-as-a-service providers have created a more difficult sort of threat landscape in that the ransomware-as-a-service can be packaged up as a platform. And, you know, the barrier to entry to use the ransomware has been removed because the ransomware adversaries have decided to sort of package this up as a platform and make it more accessible to a larger variety of criminal groups, state actors, whoever. 

Dave Bittner: One of the things that the report touches on that I found interesting was the increasing complexity of some of the regulatory environments here. As operators, you know, continue to face these increasing threats, balancing that or perhaps in addition to that, there's a lot of things they - a lot of boxes they have to check on the regulatory side as well. 

Tom Winston: Yeah, it is a complex regulatory environment. And sometimes, as we saw with the TSA regulation, they very quickly and rightfully updated their initial regulation to sort of cover some of the more detailed issues with providing overall guidance for safety and control in these environments. So TSA-2C was the one that was sort of the improvement that was much, much better as opposed to what we were looking at before. And it is a complex thing to do because the owner-operators in countries like the United States and, you know, even Europe to some degree, the Middle East - they're not always - it's not one company. It's many, many, many companies. So having a regulatory environment that allows - not only allows but is robust enough to get everybody involved to sort of take protective measures is difficult because it's - sometimes the environment isn't conducive to doing that, necessarily. If you look at the - sort of the way the electrical grid is set up in the United States, we have regional sort of control zones, and, of course, we have NERC and FERC that look at these things. But, again, the interconnects sometimes are different, and sometimes they're not well understood. And sometimes the dependencies between the regions aren't necessarily well understood. So, yes, it is an incredibly complex regulatory environment. 

Dave Bittner: Based on the information that you all have gathered here, are there any sort of overarching recommendations as we look ahead towards the rest of this year? 

Tom Winston: You know, we always sort of tell people to be aware of their assets, be aware of, you know, what their environment looks like, really. Know what you have in your environment. Know what that thing or things does. Know how that thing interacts with other things in the system. Know how those systems interact with each other. Have a response plan for your industrial control systems and your operational technology environment. Have something that basically revolves around not just defense in depth for, you know, enterprise IT, but defense in depth for operational technology. Know where and how either your IT environment is accessing your OT environment, you know, sort of automatically. Understand every remote-access touchpoint - in some instances, work-from-home arrangements or monitoring remotely arrangements. 

Tom Winston: Understand that multifactor authentication is always a requirement, and have some conversation about how you're going to manage the vulnerabilities. There should be some sort of life cycle that identifies vulnerabilities, assesses the vulnerabilities and then, in the like manner, addresses the vulnerabilities. If there are hardware vulnerabilities, that needs to be discussed. If there are software vulnerabilities, of course, that feels more like enterprise IT, but you always want to make sure that those things are being addressed in a reasonable fashion and often. There has to be more conversations, more communication between the enterprise IT and the operational technology parts of any industrial environment. And really, that conversation should include things like the five things I've just mentioned. It should be a hard conversation. It should be something that not only considers the regulatory environment, but considers the safety of the physical processes, the safety of physical systems and systems of systems in the organization. 

Tré Hester: In today's Learning Lab, Mark Urban completes his two-part discussion about the importance of incident response planning with Vern McCandlish, who is a principal industrial incident responder at Dragos. 

Mark Urban: I am Mark Urban, once again, with the Learning Lab here at "Control Loop." And I'm joined by Vern McCandlish, one of our incident responders here at Dragos. In fact, Vern, what are some interesting stories that can highlight the importance of planning? What are, you know, some stories that can highlight things to avoid? So a company that has external service providers coming in to manage their environment - an external management company management in an industrial system - can you do the same thing with remote, you know, incident response? Can - you know, if we're helping a customer, if they're somebody in the industrial space, can you do that remotely? 

Vern Mccandlish: I'm going to give the classic incident-response answer, and it depends. A lot of it will depend upon whether we have actually prepared for it or not, whether we actually have the - does the vendor have the permissions to come in and do it remotely? Do they have the capability of doing it remotely? And then once they do the collection remotely, how do they get us the data in a manner that would be consistent with what we would consider secure for an investigation? All of these things - this is where I just harp and harp and harp on doing the preparation and then exercising your plan with a tabletop exercise to make sure that you haven't missed anything or that the things that you think you're capable of, you can actually perform in a simulated game environment. 

Vern Mccandlish: But it really comes down to - that it-depends part is, are you prepared? Because you might have an incident where the vendor can do it right away, and it's not a problem. But I have been in enough situations where having to work through the logistics of how does the vendor now gain access 'cause I - maybe the site has blocked all external access as part of their thing, and now we need a third-party vendor to come in and do it. They can't even do it remote at that point. Do you have a contingency for how to do that? Then once they collect their data, how do they get it to us? How do they hand it off to us? Are we just sharing thumb drives at the scene or, if it's remote - or what type of storage? What's our encryption criteria for storage for data at rest and data in motion? All of these types of things come into play, and I'd rather have those things all agreed to and in writing as a plan before an incident than trying to figure those out in the middle of an incident. 

Mark Urban: As we talk about incidents, especially if you think about large, industrial organizations that are operating plants or pipelines and having interruptions, impacts to production, can you tell a little bit - talk a little bit about a situation where you were trying to manage that balance of resolving an incident and maintaining productive capability and availability of the plant? Obviously, maintaining safety is No. 1. You know, managing impacts to the environment is No. 2. And then there's always that productive capacity and revenue generation that's on everybody's mind, as well. Have there been any situations where you've had to kind of manage that balance? 

Vern Mccandlish: Oh, absolutely. And the production can get into the millions of dollars a day type of category. So we're not talking small money. But you definitely had it correct - safety first, environmental damage second, then maintaining operational resilience. And the thing that we encounter most often is a lot of equipment designed to provide operations in an industrial space are running at their resource capacity. When I build my gaming system at home for my personal use, I overbuild the system because I am a huge geek. But if I'm going to build a thousand factories, I'm going to make sure that I do not overprovision the CPUs and the memory and the hard drive storage that I need. So a recent case that I had, we were in and - during an incident, we wanted to do collection from a system that was part of production. 

Vern Mccandlish: And we were discussing whether we could actually run our collection tool on the system without disrupting production. We examined the system, and it was running at 95% CPU utilization as a flat line. That's it's steady state. And out of eight gigs of memory, it was using 7 1/2 gigs of memory for all of its services and applications right now. If I tried to introduce something running this route with high priority to collect memory and artifacts off of the system, I would absolutely disrupt that operation. So we had to change plans. While that system would have been vital to collect information from, it became a business decision of when we could actually collect the data. When was the next time they could take this system offline? How quickly could they get a redundant system built and put in place so we could take this one offline type of question? I'm going to go right back to the visibility part. This can also be part of your plan because if some of that information had already been exported off of the system as part of a collection plan prior to the incident, I might not have had to collect from the system. 

Mark Urban: So meaning you've got operating industrial systems that, you know, they haven't been over specced because, you know, that's added cost to a project. And typically, you want to spec that equipment to run as needed, maybe a little bit of overhead but not a lot a bit of overhead. And if you wanted to do some host executable to do log collection or even reach into process, that might put it over the edge. That might put it over the utilization. Is it fair to say that, like, a passive network kind of collection is helpful in avoiding those sorts of situations where you're over-stressing specific hosts that are part of the operation of the industrial systems? 

Vern Mccandlish: Well, passive network collection has - one of its greatest benefits is the fact that it does not introduce anything to the environment. You still have to make sure - and this is something that we will do during an incident - that the switching or the routing or the firewall equipment that I want to put my tap on, if I'm going to put it on an appliance and not just tap directly into the line - so the span port, actually - that I would want to create will not cause a CPU utilization process problem on that piece of infrastructure. 

Vern Mccandlish: So I would like to see - if I see a switch that's running 80 or 90% utilization, maybe, at that point, I think about a different way to collect because I could run into the same issue. But that's a rare issue. I come across industrial systems all the time that are running at 90% plus their available resources as just their flat baseline, normal operating speed. But switches, routers and network, they're still using - most of that's still much more modern and it's easier to replace. They're 10, 15, 20% utilization on this type of equipment. So I've never had a problem getting a span port assigned on a piece of equipment because of resource exhaustion. And then that allows me to collect network telemetry, which at least gets me started on who's talking to whom, how much are they talking and what types of protocols. And if I can see inside, what are they actually talking about? So I can start to get some information without actually interfering with production at all. 

Mark Urban: To bring it back, 'cause you went a little bit geek there. But the end result is, like, hey, these systems are running at near full capacity. You don't want to do things that tip over that capacity, that shut down the systems, that shut down production that could impact not only revenue but also environment and safety, as well. So that's the chain of you want to avoid that. Is that fair? 

Vern Mccandlish: Yeah. And one other nail to hit on the passive monitoring part is even if it isn't something that is done routinely, it's not a continuous process, what I will oftentimes work with my customers to get them to do is to do the change management ticket to add the SPAN port to the equipment so that the SPAN port exists and I don't have to go through an entire change management to get it turned on, or I don't have to ask for an exception so we can do it quickly and bypass their normal change management. So we can actually - by thinking about this ahead of time, where we would want to have visibility in a crisis - on those pieces of equipment, designate a port and say this is the port that will be used for passive listening - in the case we need to do PCAP collection during an incident - and just have that predefined on the network infrastructure so when I show up, I can just plug in and do it. It doesn't require any type of change-management ticket to take place. 

Mark Urban: Plan ahead. Plan ahead. Plan ahead. OK. And so you did say, though, that - we're exchanging a couple notes, and you said we could even go lowbrow and talk about how, during the chaos of an incident, things can happen out of order. So I'm all about the lowbrow, Vern. So give me a horror story. Entertain me a little bit with - and that's unfair to say because you don't want the misfortunes of the past to be funny, necessarily. But I think sometimes we have to look at those. But go lowbrow for us. What is the chaos? 

Vern Mccandlish: The chaos comes in because we have to realize that our first jobs as incident responders is to get information to the people that make business decisions so that they can make the best decision possible under the circumstances. Would I love to be able to very quickly get perfect information in the perfect order to the businessperson to be able to make those types of decisions? Absolutely. But oftentimes in these, we might set a - I need an answer within two hours. You need an answer within two hours. I might not be able to do my proper order of operations, of collecting memory first or doing some type of data preservation. I'm going to very - I'm going to move fast and quick to get that answer. And we have that luxury. 

Vern Mccandlish: While I have a law enforcement background and I know how to do digital forensics in that type of environment, we rarely are even going to civil court, let alone criminal court. So if I am gathering data - and I'm not doing it haphazardly - but I have a time crunch. I need an answer within two hours. To do this the proper order takes eight hours. If I just log into the system right now and take a look at the event logs and look at them real quick, I can get you the answer in 15 minutes. Those are the types of things that happen where we have to think about what the actual impact is to the operations, what the business need is for being able to make decisions. 

Vern Mccandlish: And I will oftentimes get challenged with a - we have a particular time that we need to be able to make a decision because we need to tell a regulatory body something. We need to be able to put out a public statement, or leadership needs to make a decision about whether we're going to maintain operations, slow down, shut down. Here's the deadline for that decision. And then we have to go do those things. The other thing - and this will get - I'm going to - the collection management framework. I absolutely love the collection management framework as a concept because it helps me enumerate all the possible logs that are in an environment. 

Vern Mccandlish: But some of the other problems I will come across is I might get called on Day Five of an incident, and I find a piece of equipment that only has seven days' worth of logs. It would be a low priority to collect from that device, except I'm about to lose the evidence that might be on that device, so I have to change its priority. So these are all the types of things that trained incident response team - and having a plan of action for an incident response team - they'll know how to do these things, and they'll be able to make these real-time adjustments based on circumstances because no two fires are the same. 

Mark Urban: So no two fires the same. We started out - we had Lesley talking about - kind of an in-depth through two episodes - like, how to create an incident response plan, reasons for doing it, which you reinforced here. As we close out, like, give us your top, like - 'cause I know you feel strongly about this. I know that this is your life's work and passion. So give us those bullets - a couple of those bullets for us to kind of take away and make sure the folks that are listening here that are responsible for those or contribute to those to keep in mind. What are those key things? 

Vern Mccandlish: Have an incident response plan. Yes, I know no plan has ever survived first contact with the enemy. But there's also the - you know, those who fail to plan, plan to fail. Have a plan. It will at least guide your incident response team and your leadership on what your aspirational goals are. And it allows you to state those at a much calmer time than in the middle of a crisis. Second, exercise that plan. I cannot emphasize enough - I use the word aspirational. Incident response plans, if they are not tested, are aspirational. We will do these things. This shall happen. This is how we will contain systems. This is how we will restore from backup. If those things aren't actually tested, then they are just aspirational statements. 

Vern Mccandlish: So go through a tabletop exercise where those aspirations can be properly challenged. And then make sure that you take that as feedback into your plan. You might learn. You might be able to restore one system in 15 minutes. But now I challenge you, and I say, well, you have 40 systems that all got ransomware on them. How do you restore 40 systems? What order would you restore them? And how long is this going to take? How much of a disruption to production will this ensue? So the big ones are, have that plan, exercise the plan. And part of the plan - 'cause, I mean, the plan's fairly comprehensive - is to make sure that you know who's going to do the response. What do you expect of them? Tell them what you expect them to do. 

Mark Urban: Right. And then within those plans, within the exercise, are all the details, like what are the systems? There's a collection management framework. What are the external vendors that, you know, might have super - privileges locked down to their own specific systems, etc., etc? Vern, thank you. Vern McCandlish, principal industrial responder here at Dragos, thank you very much. 

Vern Mccandlish: Thank you. I've enjoyed this. 

Tré Hester: And that's "Control Loop," brought to you by the CyberWire and powered by Dragos. For links to all of today's stories, check out our show notes at thecyberwire.com. Sound design for this show is done by Elliott Peltzman, with mixing by me. Our senior producer is Jennifer Eiben. Our Dragos producers are Joanne Rasch and Mark Urban. Our executive editor is Peter Kilpe. And I'm Tré Hester, filling in for Dave Bittner. Thanks for listening.