When IT infrastructure translates into OT.

Elliott Peltzman: It's October 4, 2023, and you're listening to Control Loop. In today's OT Cybersecurity Briefing, Johnson Controls sustained cyberattack. Nearly 100,000 ICS services exposed to the internet. FBI anticipates an increase in Chinese and Russian targeting of the energy sector. Joint advisory warns of Beijing's BlackTech threat activity. CISA's push for hardware bills of materials. And cybersecurity in the US industrial base. We welcome guest Michael Toecker back to the show. He is a cybersecurity advisor at the United States Department of Energy's Office of Cybersecurity, Energy Security, and Emergency Response. He continues his discussion with Dave Bittner about community defense and also talks about Neighborhood Keeper. In the Learning Lab, we have the conclusion of Mark Urban's conversation with Alex Baretta, a senior solution architect at Dragos. They talk about secure remote access. A redacted version of a report by the Office of the Inspector General of the Department of Homeland Security has been released. The IG was looking into the Transportation Security Administration's, that's TSA's, formulation and enforcement of pipeline safety regulations after the May 2021 ransomware attack against the Colonial Pipeline. TSA responded with two regulations, Security Directive Pipeline 2021-01 called Enhancing Pipeline Security, SD-01, issued on May 26, 2021, required that operators of critical pipelines, those that carry hazardous fluids and natural gas, to designate a cybersecurity coordinator, report cyber incidents, and conduct a vulnerability assessment. The second regulation Security Directive Pipeline 2021-02, Pipeline Security Mitigation Actions Contingency Planning and Testing issued on July 19 of that year required owners and operators of pipelines designated as critical to implement additional and immediately needed cybersecurity measures to prevent disruption and degradation to their infrastructure in response to an ongoing threat. The IG found that TSA, while it properly worked with stakeholders to develop the rules, didn't effectively follow up to track compliance. The IG made three recommendations, all of them procedural enhancements. Number one, we recommend the TSA Assistant Administrator for Policy, Plans, and Engagement in consultation with interagency partners, such as the Department of Transportation, complete rulemaking that will permanently codify critical cybersecurity requirements for pipelines. Number two, we recommend the TSA Assistant Administrator for Surface Operations develop standard operating procedures in a formal tracking system to ensure consistent tracking and follow-up of the implementation of security directives and eventual regulations. Number three, we recommend the TSA Assistant Administrator for Surface Operations included in TSA's standard operating procedures developed in response to recommendation 2 a requirement to conduct follow-up inspections that ensure pipeline operators have completed mitigation activities to address cybersecurity vulnerabilities. TSA has concurred with the IG's report and its recommendations. Building automation company Johnson Controls International has sustained a major ransomware attack that's affected the operations of several of the company's subsidiaries, BleepingComputer reports. The attackers have encrypted the company's VMware ESXi servers and claimed to have stolen more than 27 terabytes of corporate data. BleepingComputer sites a source as saying that the attackers are demanding a $51 million dollar ransom. Johnson Controls confirmed a cybersecurity incident in an 8k filing with the SEC, stating, The company continues to assess what information was impacted and is executing its incident management and protection plan, including implementing remediation measures to mitigate the impact of the incident and will continue taking additional steps as appropriate. Lior Yaari, CEO and cofounder of Grip Security, commented, Johnson Controls is one of the leaders in digital technologies and services for buildings in key industries such as healthcare, airports, hotels, and stadiums. If the breach expands beyond the company itself to the systems deployed by their customers, this attack could wreak havoc on huge swaths of businesses. Their open blue platform is a SaaS application whose users could be targeted from compromised identities that result from this recent attack. JCI needs to thoroughly assess what data is at risk and advise its customers whether they may be affected. Bitsight has identified nearly 100,000 industrial control systems exposed to the internet, particularly in the education, technology, government and politics, and business sectors. The researchers note, however, that overall there's been a steady decline in internet-exposed ICS services since 2019. So, in some respects, this is actually a good news story. Bitsight adds, Exposed systems and devices communicating via the Modbus and S7 protocols are more common in June 2023 than before, with the former increasing the prevalence from 2020 and the latter more recently from mid-2022. However, exposed industrial control systems communicating via Niagara Fox had been trending downward since roughly 2021. Organizations should be aware of these changes in prevalence to inform their OT/ICS security strategies. The Record reports that the FBI has issued an alert, warning the energy industry to expect an increase in cyberactivity from Chinese and Russian hackers. The Record says, the alert cites several factors that may lead to such an escalation, including increased US exports of liquefied natural gas, changes in the global crude oil supply chain favoring the US, ongoing Western pressure on Russia's energy supply, and China's reliance on oil imports. As sanctions continue to bite Russian exports and as China's appetite for oil grows, US liquid natural gas facilities increase in value, and where there's greater value is also usually greater risk. A joint cybersecurity advisory issued by US and Japanese security and intelligence agencies warns of BlackTech, an industrial espionage activity cluster operated by China. The threat actor is targeting government, industrial, technology, media, electronics, telecommunication, and defense industrial base sectors. BlackTech has shown the ability to modify router firmware undetected and to exploit routers' domain-trust relationships. The campaign has begun by compromising routers in subsidiary companies and then pivoting from the subsidiaries to corporate headquarters in the US and Japan. The goal of BlackTech's collection has, for the most part, been the acquisition of intellectual property. Last week, the US Cybersecurity and Infrastructure Security Agency, that's CISA, released its Hardware Bill of Materials Framework for supply chain risk management. Created by the Information and Communications Technology Supply Chain Risk Management Task Force, the document provides guidelines by which tech manufacturers can clearly communicate with buyers about the hardware components of their products. The goal is akin to a nutrition label found on a food package, giving the consumer, in this case, tech purchasers, a clearer idea of the ingredients the product contains and, in turn, the inherent risks of using it. CISA National Risk Management Center Assistant Director and ICT/SCRM Task Force cochair Mona Harrington stated in a press release, With standardized naming, comprehensive information, and clear guidance, organizations can safeguard against economic and security risks, enhancing overall resilience. By enhancing transparency and traceability through HBOM, stakeholders can identify and address potential risks within the supply chain, ensuring that the digital landscape remains robust and secure against emerging threats and challenges. The framework offers a set of potential use cases that purchasers may have for HBOMs, a format that should be used to create consistency across HBOMs, and taxonomy of component input attributes that should be included in the HBOM. As Nextgov notes, adherence to the framework is voluntary. But in the absence of mandatory guidance, the Task Force hopes the document will lead to a more consistent approach. Aprio has released the results of a survey looking at cybersecurity in the manufacturing industry, finding that nearly two-thirds of manufacturers experienced unauthorized access to their company's networks and data in the past year. The survey also found that fewer than half of companies surveyed report having a cybersecurity policy, and only 36% have enhanced IT security. Aprio adds, Manufacturers can leverage digital tools to achieve competitive advantage by sharing information across functions and with supply chain partners to improve productivity and respond in real time to operational problems. But most companies are not utilizing this. In fact, 39% of surveyed manufacturers are using 5G networks, and only 21% are using edge computing. CISA has issued three advisories for vulnerabilities affecting Rockwell Automation PanelView 800, DEXMA DexGate, and Hitachi Energy's RTU 500 series. Up next, we welcome our guest Michael Toecker back to the show. He's a cybersecurity advisor at the United States Department of Energy's Office of Cybersecurity, Energy Security, and Emergency Response. He continues his discussion with Dave about community defense and Neighborhood Keeper.

Michael Toecker: Yeah. So collective defense, community defense, I -- I struggle with a good definition on it. It's one of these things that we all kind of know what it is. You know, it's the defense that comes from neighbors who are watching out for one another. It comes from neighbors who are, oh, you need a hose? I've got a hose. Or folks who come over on a regular basis and talk about -- and, you know, talk about the state of the neighborhood. And, hey, we need a stop sign. And how do we get a stop sign together? It's that whole notion of that level of community, that level of collective, that back and forth, that -- that sharing of understanding, and that respecting of a person, you know, and where they come from. And it is essential in the work that's being contemplated, the work that's being done in a lot of places because we all bring something new to the problem. Cyber itself has gotten incredibly complex. There are more protocols. There's more software. There are more vulnerabilities. There are more exploits. There are more threats. They get larger every day at different rates. I was just looking at a graph of CVEs since 2001. So that's the common vulnerability enumeration, so this is vulnerabilities in software. And this curve looks like an infinite asymptote curve, right? It's going up all the time because we're building new software all the time. And the vulnerabilities problem is just going to get bigger, and the exploits problem is going to get bigger alongside that as well. They're also -- you know, the level of threats has also gone up pretty considerably since 2015. Like, I remember, you know, social media at the time going, oh, ransomware is just the thing; and it will it -- you know, it's just people owning systems and asking for money to get off the system. And now here it is. It's a massive, quote, unquote, business at this point. The -- and the level of complexity, especially in energy systems, is going up, as well. All right. We're putting in new systems and new ways of managing these systems. And you can get trained on this stuff, but you're still behind the curve. So the place where you want to interact, the place where the hammer strikes the anvil the best, all right, is with the folks who are doing the work, right, the folks who are actually implementing the systems, who are responsible for maintaining them, all right and being a part of their day-to-day understanding of issues and problems and specifically about cyber. So I talk really broadly about that. But Christopher Ray brought up in some of his recent testimony that cyber -- cyber warriors associated with China, you know, outnumber FBI agents associated with cyber like 50 to 1. All right. So there's a scale problem here. And I think relying on just federal government in order to solve that problem, you know, with our current number of cyber defenders may not be scalable. And so this idea of community defense, collective defense is about -- it's about recruiting folks in the various sectors that have a lot of cyber. It's recruiting folks in sectors that have a lot of awareness of cyber, exposure to cyber, acknowledge risks within cyber, as well as unacknowledged risk in cyber, right, and bringing them in and saying, okay. Let's all have a conversation. And even better is when they solve a problem or when they noticed a problem, and they bring it up to everybody because, at that point, all eyes can be on it, right? Everyone can then bring in what they think is of value. Hey. I solved it this way. Or, oh, yeah. That particular IP address is associated with these other IP addresses. Have you checked these yet? Or, oh. That particular command? That's a great command, and that's a great rule to put in your SIM. But take a look here. If you alter it in this way, it'll pick up at least a dozen other variations of that command. And the idea here with collective defense is that you've -- you may have solved that problem yourself with -- without collective defense, and it's just solved for you. The idea here is to get it and solve it for everybody. Get the knowledge out. Get everyone working on it together. Get approaches and other things. And this is -- this is how the internet has changed all of human existence now for the past 20 years is that a bit -- or 25 years, even longer. Sorry. I'm thinking back to when I got the real internet when I got to college, which was, you know -- like, I had -- I had dial-up for a very long time.

Dave Bittner: Sure.

Michael Toecker: But the ability to be able to get a problem out and get everybody working on it. And then what you have there at that problem is that you no longer have a technical problem. Right. Your technical folks will be able to work on problems that are in front of them. What you have now is you have an organizational problem. One of my favorite fantasy authors at this point, Jim Butcher, has got a really great quote about -- he talks about how individual effort is great, so long as you have the individual. And I'm really paraphrasing him here. But in order to -- but bureaucracy and process are the things that hold up individual efforts and keep them from -- from degrading from time and entropy. Okay. Bureaucracy are the rules that we write for each other to ensure that we don't make the same mistakes again. So -- and I see collective defense as requiring a lot of process at that point. Hope that was not too disconnected.

Dave Bittner: No, no. It's really interesting insights. Help me understand to what degree does the energy community embrace this notion of collective defense and community defense? Has it historically been something where information has been readily shared? Or is this a recent recognition of its importance? Where do we stand there?

Michael Toecker: There have always been various levels of information sharing, right, within the energy sector. All right. And one of the -- one of the places that it first started, I think, and this could be biased on my fact and working in electric power for so long is, within electric power, there is mutual dependence within electric power. All right. Entities routinely hold -- routinely move electricity across their own boundaries to assist others in their work. And our markets are designed to allow that to happen. And, you know, it's nice to talk about this as in, you know, a very friendly, hey, I'm going to give you X amount of megawatts; and you give me this much money in return. All right. But there's real risk associated with that. All right. There's real risk in taking and moving energy outside of the boundaries of your control into someone else's boundaries. All right. That level of trust is something that we built in the electric power sector in order to develop markets. All right. And that's -- that is enforced by a set of rules and a set of processes. And, you know, that's the road upon which we all travel within electric power. And folks in other industries do this in a very similar manner as well. Like, when you put product into a pipeline, in many cases, that product is what's known as a -- I forget. I want to call it a fungible good, but it's basically an equivalent good. You get one widget on one side of the pipeline, you can potentially pull out the same equivalent widget, all right, a same equivalent product on the other side of the pipeline instantaneously, right? You put it in; you pull it out. That's how it works. Not all pipelines work that way, but many of them do. And that in -- that in and of itself is a trust problem because there's millions of dollars of product inside that pipeline at the time. And so we get to work through this in critical infrastructure and specifically in energy because of that, that mutual dependency and that trust that's been built over time and then enforced through these, you know, legal agreements and other processes that we have -- we have decided to hold ourselves accountable to. And then we just need to do it with cyber. And we do it with cyber in a lot of different cases. The IFAC was pulled in shortly after the 2003 blackout when they started pulling together the first version of the Critical Infrastructure Protection Standards, the CIP standards. These were called the Urgent Action 1200. And the idea was is that the IFAC would be the place where everyone could put all of their cyber information. Hey, I saw this. Oh, hey; here's the thing that you need to be aware of. Or, Hey; we found this particular exploit, all right. And it was going to be -- and it still is a good place to be able to pull together all that information. And a lot of other folks followed suit. And, again, this is where my bias coming from the work that I've done primarily in electric power shows. I know that these efforts were done, you know, across the board with a lot of other sectors. I know finance sector has done a really great job. The communication sector has done a really great job. The water sector, all right, is working really hard to -- to build their version of this, as well; aviation, etc. Like, all of these folks are realizing that there are benefits to doing this information sharing too. I hope I didn't go on too long.

Dave Bittner: No, no. So as we look towards the future, towards the horizon, I mean, what -- what sort of things are you looking for the various stakeholders to do here? If you could, you know, name some calls of action for the folks who have a stake in this, what sort of things would you like to see done?

Michael Toecker: So the state of the art right now when it comes to cyber is not to work within your silo. All right. The state of the art within cyber, all right, is to -- is to walk outside and engage. All right. It's to work with others. And sometimes working with others is actually just working with data that others have provided. For instance, I know that there are several really high capable energy sector members who do work on their own systems but also pull in data feeds from other places. I think Dragos is one of those. Izomi's one of those. I believe, you know, there's data that -- that is pulled in from other vendors as well, that allows them to be able to take information that they know and pivot it up against and prop it up against other information that allows them to do even more investigations internally. Here's where I want the call to action to be is that you don't drop any of that on the cutting room floor. All right. I want to see the deleted scenes. All right. I want to see that product. All right. That product that, you know, may not have been useful for you and your vision is still an amazing product that could help a lot of different people. You know, it may not be Henry Cavill's mustache cut. But, you know, it could be someone's really important thing that ends up knocking loose a piece of the problem. And then we come to the point of scale is, if we find and we bring all that information together, how do we organize it, right? How do we build a system that allows us to move it back and forth? How do we -- how do we, you know, be able to reference external data that may have come from other partners, you know, in that system in order to benefit everybody? And how does everyone -- How do you ensure everyone gets credit for the work that they're doing? You know, that's a -- that's a difficult problem. As far as a call to action on this one, reach out. All right. Have that discussion. Don't leave what you've done on the cutting room floor. All right. Bring it to one of the entities that's a part of this. The IFAC is a great place to do it. The ONG-ISAC, DNG-ISAC, if you happen to be in energy. Your vendors themselves, all right, often have really great relationships with a lot of different IFACs, and they may know better on how to share this than a lot of other folks do. And don't be afraid. There's a lot of -- there's been a lot of fear-related information sharing. Like, do your due diligence, yes. But there is an understanding within the federal government that voluntary information sharing is just that. It's voluntary. You know, and we understand that that voluntary information sharing can evaporate if we do bad things with that data. So -- or if we do things that you don't quite agree with, you know, or we use it in order to turn around and say, well, you did bad things. That's not the point. Right? If someone's making that point, you know, we have some serious work to do, you know, on our side of the house too.

Dave Bittner: So it sounds to me like part of what you're saying here is that the Department of Energy really wants to be an active partner here.

Michael Toecker: We'd like to be. We've engaged a lot of our National Lab resources on the development side, less on the research side but more on the development side to build -- the intention is to build capabilities that allow us to work together in a -- in organized ways, all right, so that we don't leave anything on the cutting room floor that's blocked -- that's brought to us. I know I've said that a lot of times. I've got to find a better way of saying that but -- and we do want to be that partner. And a lot of that is demonstrating that trust, you know, and being able to say, okay. When data comes to us, here's what we can do with it; here's what we can't do with it. Right. And basically saying out, okay. Here's our responsibility as a federal agency. This is what it is. All right. We can move in certain ways. And, you know, if there are things that you really, really hate about it, guess what? We can take it back and we can say, hey, look. We'd really like to do this other thing, Congress or -- or other organizations, you know. What can we do to make this happen, or is this just not part of the Zeitgeist at this point, in which case, you know, how can we then work with our private sector partners, you know, to set up something that they can let us know about? All right. And that can be less attributable and less invasive if that's the concern. So I think I'm actually getting into policy talk here. What's your -- what's your rank on this?

Dave Bittner: Let's all work to keep the lights on, right?

Michael Toecker: Yes.

Elliott Peltzman: Up next, we welcome Mark Urban and Alex Baretta back into the Learning Lab. Alex is a senior solution architect at Dragos. They talk about secure remote access. I'm Mark Urban with another Learning Lab. Today we're going to talk about secure remote access. And for that I'm joined by Alex Baretta. He's a senior solution architect at Dragos. Welcome, Alex.

Alex Baretta: Thanks for having me, Mark. Really, really glad to be here.

Mark Urban: So let me pick up on a point you made. It's increasingly important. And we talk a lot about how OT is different from IT because the systems are different. The network protocols are different. The end game of, you know, constant availability is different. The impact of, you know, potential incidents are different. How you have to troubleshoot, manage incidents are different. So there's a lot of difference. But you're saying this is one of the areas where IT infrastructure for secure remote access can translate well into OT.

Alex Baretta: Yeah. That's -- that's correct. And, really, it's due to several -- several factors. The first is going to be the level of familiarity that a team may already have with that remote access tool. If that remote access tool -- and I think it's important to clarify that it's worth evaluating and making sure that the remote access tool that's in place in IT is going to meet the needs of the OT team, right. There might be some features and functionalities that the OT team doesn't need that the IT team uses and vice versa, right. So it's important to make sure that that vendor that is already in place on the IT side is going to meet all of the use cases that are needed on the OT side. But it can be a really easy win and a really easy way to kind of expand and enable that secure remote access on the OT side because a lot of folks are probably going to be familiar with that tool to at least to some degree. It becomes really easy. You're familiar with the team that you're working with to, you know, make an expansion of a particular product, depending on the logistics of that. So it can be a really easy way to kind of transfer, and it's one of those few places indeed where you can kind of translate a technology assuming that the use cases are -- are accounted for with that tool in -- from the IT environment into the OT environment.

Mark Urban: Gotcha. So in -- when it when you say kind of can translate, you're talking about how it's set up, how it's integrated with, you know, existing SOC processes and other -- and other cyber hygiene going in. So what are some of those -- as you look at setting up SRA technologies, what are some of the important components or, you know, issues to address?

Alex Baretta: So the first kind of thing that I just addressed, right, potentially translating a tool into -- an existing tool into this deployment, you know, leveraging that existing infrastructure and expertise. Like we said, if that tool is in place for IT, if there's already some of this infrastructure in place and already some of the expertise in place on the IT side, that can be really valuable in terms of selecting a tool that can be used for SRA on the OT side. Another important factor is going to be making sure that the IT and OT environments are segmented. So that's -- that can be done with, as I mentioned earlier, a DMZ and making sure that there's a secure jump host within the environment. So DMZ, right, a demilitarized zone, that's going to have devices that are going to be -- that are going to need to be accessible from both the IT and the OT network. That can be accomplished with, you know, placing a firewall on either side of that DMZ, for example, and then making sure that one of those devices is going to be a secure jump host. That's going to provide folks with the -- folks that need access with an easier way of kind of accessing that -- those OT environments. You know, one of the other critical controls, and this is going to be something that a lot of folks are going to be familiar with, is going to be multifactor authentication, right? If someone's credentials were to be compromised and a third party were attempting to log in using those credentials, or I should say an unauthorized third party were attempting to log in using those credentials, then, you know, how are you going to make sure that the person logging in is who they say they are? As we discussed earlier, that's going to be one of the most highly used means that adversaries leverage in order to gain access into an environment. So it's important to make sure that whoever's accessing the environment is who they say they are. Another really important facet, and this kind of goes hand in hand with multifactor, is going to be defining clear remote access requirements for third parties. When we look at how third parties access these -- these remote environments, a lot of -- a lot of them are going to do it in an insecure manner. They're going to do it in a way that's the easiest for them. Indeed, in fact, in some of my customers, you know, we'll install a continuous monitoring platform like the Dragos clients, and what we'll see is remote access sessions taking place with a direct connection at one of these devices for reprogramming it. And that's a really insecure means of access. It's something that a lot of these -- a lot of organizations don't even know about, as being out there until they see it in one of these monitoring tools. So defining those third party remote access requirements, a lot of the tools will have the ability to schedule remote access, as well as kind of limit the amount of privileges that the third parties might have and the devices and protocols that a third party might be able to access. So it becomes really important to kind of define what those requirements look like and, you know, when someone can access the environment. And then, finally, I think it's really important to maintain monitoring and auditing logs for remote access sessions. That can be done in a variety of different ways. You know, a lot of these tools are going to have stuff -- they're going to have -- are going to have to impart some sort of monitoring and logging of these tools. You know, if you're accessing Windows endpoints, for example, you're going to have Windows logs as well. But one of the most critical aspects is going to be making sure that the remote access that is taking place is monitored. And so that can be accomplished with any really -- a continuous monitoring platform that's looking at all of the traffic traversing the network. And that's really critical and important to kind of monitor these SRA tools because, if there's an unauthorized remote form of remote access being used like an RDP session, right, we want to highlight that as a means of access that maybe was unexpected and, you know, isn't something that we would typically see in the environment. So it's important to keep that continuous monitoring aspect in place to highlight some of those unexpected connections that we might see in an environment.

Mark Urban: Gotcha. So you want to monitor the connections, validate that things are happening as they are. And I'm just going to do a recap because you covered a couple different things. So we've got -- you want to make sure that, when you're implementing secure remote access, you've got multifactor authentication attached to that where it's possible. You want to segment the IT network from the OT network and just provide, you know, good hygiene of that. You want to segment the credentials used in the OT network, make sure those are different than those used than the credentials, meaning login, password, MFA. Separate the OT and the IT logins. Want to be able to really put tight controls around third party access with policies, you know, limiting times and where they can go, as well as kind of limiting the privileges of, you know, what they're able to access. And then, finally, monitoring the connections with some continuous monitoring kind of solution. That's -- all right. That's, you know, that -- that's a list, but it's -- it seems like an approachable list. And, you know, we know that, you know, you've been working -- you work with customers in the field. You've been talking with some of our industrial consultants on the professional services side. And, you know, that's a, you know -- and I should mention, by the way, that we'll provide a link in the show notes. You can get some of this information on the Dragos blog. Alex Baretta, that's you, authored a blog with the -- captures a lot of this that you can reference if you're listening to your car. So Alex, you know, I sure appreciate the time today talking about secure remote access. Is there -- is there anything I missed in this discussion?

Alex Baretta: Yeah. Well, I just want to also highlight before we move on from those recommendations that I think you made a really good point, that it is an approachable list. I think the other thing that's important to highlight is that a lot of these -- these aspects are going to be in place in some way, shape, or form. And so it really becomes -- or I should say it really becomes a matter of that -- of going back to that first point of leveraging the existing infrastructure and expertise. So leveraging a lot of the existing infrastructure and things that are probably already in place. It just becomes, you know, another point that you can -- that you can have to have really good security practices in place. So I think that's important to call out.

Mark Urban: Yeah. That's a good point. You know, is there something in place -- you mentioned before, does it meet the needs of the OT environment? And, by the way, is it secure technology because we've even seen IP sec VPNs kind of going a little bit by the wayside because some of the inherent kind of vulnerabilities in that technology. It's not universally true, but that's why we see the growth in things like Zero Trust network access, you know, solving some of the issues that are associated with some of the older generation of remote access. So good, good consideration. As long as -- you know, if you've got stuff in place, it's instrumented into your IT environment that can meet the requirements of OT that is secure, that seems like a great -- you know, a great technology that you can integrate into. Alex, thanks very much. And, again, we'll provide the link to the blog in the show notes. And that's it again for today's Learning Lab.

Alex Baretta: Thanks for having me, Mark.

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