Navroop Mitter:

[00.00.03.21–00.00.31.15]

Hello! This is Navroop Mitter, founder of ArmorText. I’m delighted to welcome you to this episode of the Lock & Key Lounge, where we bring you the smartest minds from legal, government, tech and critical infrastructure to talk about groundbreaking ideas that you can apply now to strengthen your cybersecurity program and collectively keep us all safer. You can find all of our podcasts on our site armortext.com and listen to them on your favorite streaming channels. Be sure to give us feedback.

Matt Calligan:

[00.00.31.17–00.00.58.19]

Hey there! Welcome to the show! I am Matt Calligan, your host for today. Today’s topic is going to be an interesting one. As always, red teaming — but red teaming from the perspective of operational technology, the OT environments, those pipes and wires and valves and gears and sensors that do all the critical things like give us water and electricity, keep our stoplights running.

Matt:

[00.00.58.21–00.01.25.12]

Those have to be red teamed. They do have to be tested for security reasons. And if you ask most red teamers what the hardest part of testing these OT environments are, they’re not going to say protocols or legacy gear or lack of documentation. They’ll say getting into the room is the hardest thing. Just being able to convince these engineers, whose entire job it is to be suspicious of anything touching these systems.

Matt:

[00.01.25.12–00.01.51.23]

These systems have been running in some cases for decades, and they can’t stop. They literally are providing that lifeline, that critical infrastructure service, and that trust that has to be built between two humans to allow these kinds of testing and security validation to happen. It can’t be scripted. It definitely cannot be automated, or fast-forwarded, or skipped.

Matt:

[00.01.52.00–00.02.14.12]

It has to be built person by person as a human process over time. So, my guest today, he has actually spent his career doing this, bridging that gap between the offensive security and the requirements that he has to meet, and the OT engineers who have every reason to tell him to bugger off. He also just came off of SANS’s brand-new ICS613 course on OT.

Matt:

[00.02.14.13–00.02.20.13]

So, I do plan on getting into that as well. Brian Tejeda Quezada, welcome to the show.

Brian Tejeda Quezada:

[00.02.20.18–00.02.29.03]

Thanks, Matt. Happy to be here. Ever since we talked about it, I’ve been looking forward to this. I’m so excited to talk about this crucial topic.

Matt:

[00.02.29.05–00.02.56.04]

Yeah. No, timely — more and more timely every day. It’s like, oh, I’m glad we’re talking about this right now. So, for folks listening, Brian is a Red Team Senior Cyber System Analyst at Con Edison up in New York, where he conducts offensive security assessments across both IT and OT, the operational technology environments serving one of the largest utilities in the country.

Matt:

[00.02.56.06–00.03.29.15]

Brian just, as we mentioned, recently completed that SANS course, the ICS/OT Penetration Testing and Assessments course, which I hear is a banger, and it’s one of the first courses built specifically to teach that safe, purpose-built pen testing methodology for industrial environments. Before moving into red teaming, Brian’s background included engineering and STEM education: experience that shows up in how he approaches OT engineers, as people right to be understood first and then tested, but understanding is key.

Matt:

[00.03.29.15–00.03.54.23]

Brian and I first crossed paths when I was getting a tour of the Con Edison SOC several months back, and he presented his piece, and that’s what started this conversation, because it just grabbed me: this idea of how the human element is so crucial to what we all see as a very technical, engineering kind of environment.

Matt:

[00.03.54.23–00.04.18.23]

So, the conversation is going to start with a simple premise, trust, as the infrastructure, I like to say trust as the substrate, right? It’s the foundation, which you can’t automate, there’s no shortcuts. And in OT environments, where engineers are professionally paid to be suspicious, you can’t test you know, what you haven’t earned the right to even approach or interact with.

Matt:

[00.04.19.00–00.05.02.11]

So, we’ll get into how Brian and his team actually build this trust with OT stakeholders who’ve seen outside consultants come and go, what breaks trust just as fast, and how that relationship holds up under pressure and over time. We’re also going to get into AI, because of course that’s touching everything right now, specifically around how it’s closing some of the expertise gaps that used to make OT environments hard to reach. We’ll also talk about what it means for how fast Brian has to build those relationships, and whether trust becomes more or less important as all these tools continue to speed up.

Matt:

[00.05.02.13–00.05.29.01]

So, diving right in here with you, Brian, we’re going to set the stage of getting in the room, as we say. Let’s pretend that the listener doesn’t really even understand OT and red teaming and that relationship. So, walk us through what red teaming OT looks like day-to-day, just as your job. It doesn’t have to be specific to Con Edison, just the broader strokes.

Matt:

[00.05.29.03–00.05.32.19]

And how is it different from just a normal IT environment?

Brian:

[00.05.32.19–00.06.01.15]

So, starting off with the term or phrase red teaming OT, that’s the biggest difference. You can say you’re red teaming corporate networks or IT, but red teaming is actually not the approach that we take. It’s not done because just to make sure that we’re all aligned on the definition of red teaming: it’s actually something that, if you talk to different offensive security professionals in the industry, is a pet peeve of theirs when you interconnect or overlap.

Brian:

[00.06.01.15–00.06.26.09]

Red teaming with pen testing, with security assessment. They’re actually each their own bucket, or their own vertical, of testing. So red teaming in and of itself is doing an assessment where you are emulating a threat actor. You’re doing it from the perspective that the team you’re assessing is not informed of what you’re doing, and you are taking the approach of assessing the environment without any prior knowledge.

Brian:

[00.06.26.10–00.06.48.01]

It’s what we would call a black box assessment. So, you’re going in blind, not knowing the IPs associated with the assets you’re testing. It’s more so, hey, this is the range or the IP subnets that you’re focused on — try to find a way in. You can see why that is a concern in OT, because in OT, if you don’t know what you’re

Matt:

[00.06.48.03–00.06.49.01]

No surprises.

Brian:

[00.06.49.02–00.07.12.01]

If you don’t know what you’re accessing, you could be scanning a PLC or attacking an account that is crucial for operations. So that’s why in OT we take a more collaborative approach. When we’re doing our assessments, we do what we would call penetration testing, or somewhat of what we consider a purple team exercise, where the blue team and red team, blue team being the defensive side.

Brian:

[00.07.12.01–00.07.42.01]

And there we loop in the OT stakeholders. Everyone is informed of what’s going on. So, from that perspective, not going into the details of the inner workings, but at a high level, that’s what we do. And it’s actually very timely because we’re in the season where we do a majority of our OT assessments. We have about four lined up for the rest of the year, and the biggest thing that we do is that we make sure that it’s very clear what is going to be part of the assessment.

Brian:

[00.07.42.01–00.08.01.19]

So, we talk to our OT stakeholders and we inform them ahead of time in the beginning of the year, which has been very fruitful for us. Whenever we know, okay, this year we’re going to be doing these three sites, OT sites as part of our assessment for the year focused on OT in the beginning of the year. We give them that respect.

Brian:

[00.08.01.19–00.08.24.04]

We give them that acknowledgment that, hey, OT assessments, or the cyber red team assessments against OT, are a second priority compared to their day-to-day operations. And in OT, operations are of the utmost importance. It takes priority. That’s something that I learned as I did my assessments, and it’s something that’s crucial for us as offensive security professionals.

Brian:

[00.08.24.04–00.08.49.12]

Taking into consideration that we must prioritize operations, to the point that if you’re doing an assessment during storm season, or there’s a heat wave going on, you must prepare for alternative dates or alternative options for testing. If you’re in the middle of a weather event, that means that the OT stakeholder team has to delay testing because the priority is keeping the system up right.

Brian:

[00.08.49.13–00.09.12.08]

So, from that perspective, what we have done is send out surveys of, hey, what dates work to assess your environment? What dates align with quote-unquote downtimes? There are never really full downtimes, but there are times where the systems that they’re managing are less utilized or are under less constraints when it comes to what you can do and what you can test.

Brian:

[00.09.12.09–00.09.34.07]

So, we take that into consideration, because one builds that trust because it says, hey, we acknowledge that operations are more important than what we’re trying to do. But at the same time it shows that, hey, we want to make sure that we do this assessment. So, once we have that date scheduled, a few months before, we do our assessment kickoff calls.

Brian:

[00.09.34.07–00.10.01.00]

This is where we make sure that the testing we do is very safe and coordinated. So, we talk about what’s in scope, what’s not in scope, most important, what’s not in scope. So, we have strict rules of engagement drafted, and we make sure that we’re consistently keeping our stakeholders in the loop. If we get documentation and there’s something that we didn’t discuss that looks to be interesting for us to include as part of the scope, we mentioned it to them ahead of time.

Brian:

[00.10.01.00–00.10.20.02]

So it’s a lot of meetings. And I’ll talk more about that later on. As we go through, when we talk about what you mentioned, the ICS 613 course. But when it comes to keeping stakeholders in the loop, that’s crucial for the success of this assessment. So, to answer that second question of what’s the main difference between IT and OT:

Brian:

[00.10.20.04–00.10.37.23]

The biggest difference is that in IT, it’s a lot more common to do these engagements where it’s black box. You’re not informed of what’s in the environment because you want to see what are the low hanging fruit, or what are those assets that, without you knowing, an adversary could target. And in OT, it’s crucial for it to be very transparent.

Brian:

[00.10.38.00–00.10.46.19]

Ideally, it’s a white box approach. Now, the question is, how do you gain that trust to do that, because the OT groups are always going to be hesitant.

Matt:

[00.10.46.21–00.11.08.12]

So, Brian, your comment about it needing to be a white box instead of a black box, and building that trust with OT engineers — I describe them as folks who are paid to be suspicious. What does that first meeting with the OT team feel like, and how do you nurture that trust through the process?

Brian:

[00.11.08.12–00.11.29.16]

The ones we do now are a lot more smooth than when we first initiated these conversations. But I want to take the approach of, let’s say we’re doing a first meeting as an OT or IT professional that hasn’t engaged our stakeholders before, because I think for a majority of the audience, this may be the first time they’re engaging their OT teams.

Brian:

[00.11.29.18–00.11.55.05]

The key is that actually your first meeting should not have anything to do with the assessment. I’ve seen it happen before where the OT stakeholders are approached initially with, hey, we have this cyber problem, we need to resolve it. And they immediately get pushback. The process that I’ve seen that has worked is reaching out to these OT groups with curiosity.

Brian:

[00.11.55.07–00.12.13.06]

Instead of going to them with a problem, go to them with a thirst for knowledge. Humbly go to them and say, hey, I just want to learn about your environment. I want to learn what your group does, not only from an operational level but from a strategic perspective. And also, can I get a tour of the OT site that you’re responsible for?

Brian:

[00.12.13.07–00.12.38.09]

If it’s an OT site, like a gas environment or a plant that you’re testing against, go in curious, because what that will do is shift the relationship from being solely one of an auditor going in to audit their environment, to one of somebody curious to learn about their environment and bridging that relationship between operations and cyber.

Brian:

[00.12.38.11–00.13.02.10]

The reason why is because, as you mentioned, they’re paid to be suspicious. OT gets a lot more audits compared to IT due to different regulators and different constraints that come with OT environments. They’re used to audits. So, the first challenge that we face as offensive security professionals is trying to disassociate what we do with auditing and make it more collaborative.

Brian:

[00.13.02.10–00.13.25.22]

And the way I’ve seen that is most effective is going at it so that your first meeting is, hey, I want to learn about your environment. Can you tell me what your group does, and how your system is architected? Now, I do want to acknowledge there’s times where we have time constraints. So, if your first conversation has to do with the assessment, I’d say focus on emphasizing what the goal of the objective is.

Brian:

[00.13.26.00–00.13.28.13]

Don’t get too technical. Don’t go, hey, we’re going to scan.

Matt:

[00.13.28.13–00.13.30.12]

In human terms. Yeah.

Brian:

[00.13.30.13–00.13.38.20]

It’s more of making sure that they are bought into the mission. Because if they’re bought into the mission, everything else is a lot easier. Because if there are…

Matt:

[00.13.39.00–00.13.39.13]

Right.

Brian:

[00.13.39.15–00.13.58.15]

Situations where you butt heads, or there are disagreements with the approach, you can just refer back to, hey, our mission is that we want to make sure we find security gaps before the bad actors do. So, in order to do that, the most effective way that we see to do this is x, y, z. And we’ve actually done that recently.

Brian:

[00.13.58.15–00.14.13.01]

And that’s helped lower their guard a bit and helped them understand that, hey, he’s right. The point of this is for us to find these gaps before the bad guys do. And that’s where we see more collaboration. So, looking at it from that dual approach.

Matt:

[00.14.13.05–00.14.42.10]

Let’s freeze that initial conversation, where you have to repeat that first-time conversation again. Do you find the engineers, the OT operators on their side, becoming more amenable to the concept over time, just as their awareness of why it matters evolves? Or is it pretty much always the same?

Matt:

[00.14.42.12–00.15.00.16]

Is the starting point always the same? Because ultimately what you’re trying to do is guide them to the conclusion that we’re in this together. And the outcome is something that makes both of our jobs easier. Does that first conversation get easier over time with engineers as they evolve?

Brian:

[00.15.00.16–00.15.23.04]

Yes, it does, because over time they are going to see the fruits of the labor. That’s why it’s so crucial. If it’s your first time assessing in an environment, don’t focus so much on we have to cover everything. We have to make sure we assess everything in their environment. Your first assessment should be focused on how can I give them the most return on investment.

Brian:

[00.15.23.04–00.15.42.07]

And it may just be, hey, let’s assess your perimeter. What assets on corporate are communicating with your OT assets? Let’s make sure that there is that proper segmentation. Did you get into the environment? No. But you’re immediately establishing

Matt:

[00.15.42.07–00.15.43.09]

That trust.

Brian:

[00.15.43.09–00.15.55.11]

Where, hey, we didn’t assess OT, but we’re slowly making our way there. I think sometimes as offensive security professionals or cyber in general, we’re hyper-focused on that PLC, that we’ve got to make sure they’re patching it properly.

Matt:

[00.15.55.12–00.15.56.18]

Getting in the weeds. Yeah.

Brian:

[00.15.56.18–00.16.34.03]

Let’s take a step back and prove ourselves, build that trust and slowly make our way into their environment. Now, it’s always good to acknowledge situations in which maybe you have to assess the entire environment due to a regulatory requirement. But in that case, even if there’s a regulatory requirement, I would look at the requirement and see what is the minimum amount of OT and the OT environment that I need to go into to start off building that trust, because I’ve seen it consistently when cyber goes in like, I’m from cyber, I need to scan that PLC.

Brian:

[00.16.34.06–00.16.58.17]

They’re going to be like, whoa, whoa, hold on. You haven’t even told me how my DMZ is. So, let’s take a step back and look at that. That’s been our approach. We started off building that trust by starting from the most exposed assets and going into the deeper layers, closer to the operational.

Brian:

[00.16.58.17–00.17.20.01]

So, in the Purdue model, getting to that Level 1 of the Purdue model, that just comes with time and building that trust. The conversation gets easier. But there still is a hesitance. There’s an environment that we’ve been testing for multiple years. And every meeting there’s still that, okay, we’ve got to reestablish that trust and make sure we’re all aligned. So, it gets easier.

Brian:

[00.17.20.01–00.17.21.22]

But there is still that pushback.

Matt:

[00.17.22.00–00.17.30.13]

Without naming names, what’s the worst example you’ve seen of somebody taking the opposite approach?

Brian:

[00.17.30.14–00.17.37.05]

So, in the context of somebody on their side that’s been hesitant?

Matt:

[00.17.37.06–00.17.41.06]

No, like the cyber guy that comes in like a bull in a China shop kind of thing. I’m curious.

Brian:

[00.17.41.06–00.18.08.12]

I’ll use myself as an example. Unfortunately, I was a victim of this mentality. During an assessment we actually had a scope defined, and it was this same approach:, corporate assets going into the OT environment, doing that assessment. What happened was we actually found a firewall management interface that was exposed to corporate. Now in any other IT assessment we’d say, okay, let’s try default credentials.

Brian:

[00.18.08.12–00.18.11.16]

We don’t even tell anyone, because we’re doing red teaming.

Matt:

[00.18.11.18–00.18.12.09]

Or red teaming.

Brian:

[00.18.12.10–00.18.39.20]

Yeah, I applied that same approach to the OT firewall management interface. We tried some default credentials. They didn’t work, thankfully. But the person that administers that firewall comes in the door and says, I’m seeing some failed login attempts, and they’ve actually gone to our OT group. What’s going on? This was not in scope. And we got a talking-to, to the point where they were threatening to shut down the entire engagement.

Brian:

[00.18.39.20–00.19.01.12]

So, the lesson learned there is, if you do find something that is not in scope but is interesting, pause and talk to your stakeholders. It builds trust. And if they don’t want it assessed, make a note of it for a future engagement. But yeah, I’ve been a victim of that cyber guy coming into OT wanting to be like a bull in a China shop.

Matt:

[00.19.01.14–00.19.23.22]

Obviously, as you work through the Purdue levels, the goal at some point, I’m sure, is to approach at least Level 1 assets. But are there always just, like, don’t you dare touch that? Like, no, that PLC will crash if you do anything to it, that kind of stuff

Brian:

[00.19.23.22–00.19.53.14]

And actually, that’s something that was covered a lot in the training for ICS613. It’s shifting the mentality toward security assessments being the main way to assess OT security posture, because to be honest, it will be very rare — and I’d say you’ll never be able to test one of those devices, a PLC or RTU, that’s in production, because now we’re going into the territory of safety is the priority in OT.

Brian:

[00.19.53.16–00.20.22.09]

So, you are scanning or interacting with a PLC that’s utilized for operations can lead to loss of property or loss of life. So, safety of the people that are working the system and safety of the system itself is of the utmost importance. That’s where we go into the conversation of bench testing. So, if you want to test those assets, like an RTU or a PLC, the best way to do that is actually to coordinate.

Brian:

[00.20.22.10–00.20.38.11]

Hey, is there a lab environment? Can we have the firmware that’s running on this PLC put on a PLC that’s in a lab environment. Let’s set it up and test it there. And then if we find something, we can then coordinate to see, hey, when there’s downtime, maybe we do.

Matt:

[00.20.38.11–00.20.40.05]

Do it on a downtime system.

Brian:

[00.20.40.06–00.20.58.14]

That way it’s less about investigating and doing testing that could be damaging, and more, hey, there are these two things that we found here, we just want to see if they’re replicable. And you’ll see on the test environment if it actually causes damage. And if not, that should be enough proof that what you’re doing is not going to cause damage to the system.

Brian:

[00.20.58.14–00.21.15.02]

So, you can transfer that over. But bench testing is something that’s crucial when it comes to that level of asset. The actual security assessment aspect is more at that DMZ level and other layers, before you get to that Level 1 of RTUs and PLCs.

Matt:

[00.21.15.02–00.21.46.17]

Right! Yeah. As I’ve gone down the rabbit hole on OT myself, it seemed like the overarching concept that makes sense is that, as a pen tester, getting down to that PLC level isn’t necessary to do the job. There are layers above it where you can basically test for the outcome you want without getting down in there, scanning something and blowing it up.

Matt:

[00.21.46.19–00.22.01.04]

So, there’s ample opportunity to — not check the box, but fulfill your obligation without having to go super in the weeds, which is kind of counterintuitive to what a cyber pen tester wants to do, right?

Brian:

[00.22.01.05–00.22.24.17]

Yeah. And to be honest, Matt, I don’t blame the cyber professionals who want to do that. I was in their shoes. When you take your first OT training and learn about how these systems work and how cyber can turn into physical, you want to see that in play. But we have to take a step back. And like you mentioned, it’s what value we can bring to the organization.

Brian:

[00.22.24.17–00.22.38.02]

It’s not what’s the coolest thing to do. It’s how can we do it in the safest way to make sure our OT systems are secure. And at the same time, we’re building that trust with our OT stakeholders.

Matt:

[00.22.38.04–00.22.48.07]

Absolutely. How much of this has come from the SANS course that you’re covering here? How much of this have you just learned?

Brian:

[00.22.48.11–00.23.10.03]

A lot of it. And I just want to start off by shouting out Don Weber, Jason Daly and Tyler Webb, who created and authored the course. It’s one of the first ICS and OT pen testing courses, from what I’ve understood. So, it’s been very beneficial for myself: a lot of the technical concepts when it comes to the testing aspect

Brian:

[00.23.10.08–00.23.32.23]

I already knew from the experience that I had, but what I liked is how much they emphasized what we’re talking about today with respect to building that trust with OT stakeholders. A good amount of the class, you might think, would be how do you dissect network traffic of DNP3 or Modbus? And I’ll be honest, I went in thinking that that was going to be the majority of the course.

Matt:

[00.23.33.00–00.23.35.12]

Get way in the weeds. Yeah.

Brian:

[00.23.35.14–00.23.57.17]

They reiterated the same point we’re talking about today, which is how important it is to manage your OT stakeholders and how you build that trust. A large chunk of the training is focused on preparation for the assessment: that you’ll have meetings upon meetings upon meetings to make sure that you’re in line with your stakeholders.

Brian:

[00.23.57.17–00.24.22.19]

And talking about the same topic we talked about earlier, that red teaming is really a big-risk, very-small-reward approach to OT, where the best approach may be doing an architecture review and discussing the security controls without being hands on keyboard at all. That may be the best way to actually build that trust with your stakeholder, and they walk through how to do that.

Brian:

[00.24.22.23–00.24.40.08]

The bench testing aspect was something we had done once before the training, but now it’s something I’ve taken away, where it’s like, hey, maybe we should do more bench testing, where we talked to teams that have lab environments and look at, hey, how can we mimic what you have as a setup in OT in a lab environment?

Brian:

[00.24.40.10–00.25.09.06]

Another topic that they covered a lot that impacted me, and that has shifted how we see OT assessments in general is having that mentality. Is a common phrase that’s utilized, which is shifting left. It’s not only assessing OT environments once they’re deployed, but looking at how you can get integrated into the planning and building process. There’s acceptance testing that is done by the OT stakeholders.

Brian:

[00.25.09.07–00.25.32.21]

Maybe that’s the point where you can assess that environment. If they’re doing a whole new build of a distributed control system, and they have it set up at the vendor’s location, maybe see if you can get hands on with that for a week before it’s deployed, to find everything before it’s in production. That type of perspective was something that I didn’t even know was possible and was out there, so the course really brought that to the forefront.

Brian:

[00.25.32.22–00.25.56.13]

It also emphasized leveraging living-off-the-land binaries instead of the shiny new tools. A lot of people think about all these different tools that you have at your disposal. But in OT, really a lot of the access is restricted behind a firewall. So, a lot of it may require physical access. And even if you have remote access, the tooling you have at your disposal is very limited.

Brian:

[00.25.56.14–00.26.23.05]

So, focusing on using those living-off-the-land binaries, the tools that are already built into Microsoft, to do your assessments instead of focusing on the shiny new tools, was very effective. And lastly, two things, actually: packet analysis. We hadn’t really done packet analysis as part of our assessment. So doing this as part of our approach to OT is something that we’re going to be implementing.

Brian:

[00.26.23.07–00.26.46.17]

So, it’s actually a dual benefit when using packet analysis. Because not only will it help you find if there’s any low hanging fruit of plant text credentials being sent out over the network, but more so you can also help to build an asset inventory list for the OT team. So not only are you giving them findings, but you could also be like, hey, from the packet capture you gave us, we actually found that there are these hosts.

Brian:

[00.26.46.18–00.27.02.18]

This is what they are. And that is a goldmine for these OT stakeholders because they’re always being asked, hey, what’s your asset inventory, what’s your asset inventory? So helping them out by giving that to them even when they don’t ask for it,, saying, hey, we got this. Let me know if this is helpful and if we can provide additional context.

Brian:

[00.27.02.20–00.27.23.00]

That’s something that they’ll see and be like, wow. And it’ll help build that trust once again. And one aspect that I think is overlooked a lot by us in the offensive security world is remote vendor access. Whenever we approach OT teams now, we ask, hey, do you have any vendors that remotely access your systems, and if so, how are they doing it?

Brian:

[00.27.23.00–00.27.47.13]

And now what we’re trying to emphasize is part of our team will actually try. If they’re open to the idea, is that part of our team will actually start from that access. So, starting from the perspective that the vendor is compromised. And now we’re getting into the perspective of how can we cover our supply chain risk. So that’s something that honestly is always in the background of your mind.

Brian:

[00.27.47.13–00.28.10.07]

But this brought to the forefront of now it’s a sticking point whenever I’m talking to our OT stakeholders. Hey, how does your vendor, if you have a vendor remote access, how is that done? And can we get that access and start from that perspective and see what constraints are there on that connection? Are there ways that we can bypass it, and is there any monitoring for that access?

Brian:

[00.28.10.07–00.28.30.02]

Do we have the proper monitoring in place so that if the vendor goes rogue or their supply chain is compromised, could we detect that? So that was — and honestly, it’s a great course. I’m saying this as Brian; my views do not reflect the views of Con Edison. I got to say that. But from my perspective, it was a great course.

Brian:

[00.28.30.02–00.28.46.13]

And I highly recommend anyone that’s interested in OT testing to join that. Even if you’re not an offensive security professional, just someone overseeing the third party. I think it’s even more important for you to do that, because now you can have more context as to what the third party will be doing in your environment.

Matt:

[00.28.46.15–00.29.09.06]

Talking about trust, and the vendor access piece you mentioned — do you find that that’s a concept they’re okay with, like, it’s fine, Rockwell does this all the time? Or is it, oh wow, I didn’t realize they could do that? On a scale,

Matt:

[00.29.09.06–00.29.11.03]

Do you find things tilting one way or the other?

Brian:

[00.29.11.03–00.29.16.11]

So right now we haven’t gotten to do that type of assessment. But when…

Matt:

[00.29.16.11–00.29.16.18]

Got it

Brian:

[00.29.16.18–00.29.44.21]

We asked the question, it sparked interest. Like, okay, our environment doesn’t have that, but that’s an interesting approach. And through that mentality of asking about vendor remote access, we’ve actually been able to talk to different groups and get exposure to, overall, hey, what vendors have access not only to OT but, in general, as an organization, what’s our vendor remote access posture, what’s our exposure?

Brian:

[00.29.44.21–00.30.13.18]

And we should note these down in order for us to assess: if that vendor is compromised, could that remote exposure lead to something further? Do we have the proper visibility? So, I would actually extrapolate this to overall, it’s a good idea to look at what remote vendor access do you have provided to your organization and doing offensive security assessments based on that perspective to make sure, one, you have the proper visibility into it.

Brian:

[00.30.13.18–00.30.23.06]

And two, that there are proper detections — if that access is compromised, can we detect the malicious activity going on in that pathway?

Matt:

[00.30.23.07–00.30.52.15]

What legit access versus something else would look like. Yeah. So, we’re talking about the methodical, human process of developing this relationship, so that trust enables you to do your job and to improve outcomes overall. With AI — I mean, we just saw the Monterrey water utility situation there.

Matt:

[00.30.52.16–00.31.18.09]

And the Dragos capture the flag where the AI actually won. These are indications of an increasing speed at which an adversary can quickly get themselves to without needing to become a PLC expert, or something like that without having to know how to write ladder code or whatever.

Matt:

[00.31.18.11–00.31.42.08]

How do you balance those out? Is there more urgency to move faster because of the speed that, theoretically — and knock on wood — adversaries now have that capability of? Is there more urgency around that? And how do you maintain that trust relationship, or build it, in the face of the speed of AI?

Matt:

[00.31.42.09–00.31.42.14]

Right.

Brian:

[00.31.42.15–00.32.07.21]

So, it actually helps us build that trust because many times OT stakeholders rely on security by obscurity. So, a lot of times what we were told, especially before the AI era, is yeah, but knowledge about the system is very limited, only people in this plant know. Now, with AI — an example that I can talk about is actually part of the SANS ICS course.

Brian:

[00.32.07.21–00.32.35.10]

You get access to the summit that’s prior to the course. And in the summit there was actually a workshop by Don Weber, who authored the pen testing course for OT. There was actually a workshop, which was a fantastic part of the summit, where it was focused on AI programming of ICS, or I believe it was AI testing, but nonetheless you were leveraging AI in order to understand ladder logic.

Brian:

[00.32.35.12–00.32.49.13]

I came in not knowing anything about ladder logic at all. I signed up for the workshop because my brain started spinning: hey, could I use AI to lower that barrier of entry and learn? The answer is yes.

Matt:

[00.32.49.15–00.32.50.15]

Yes.

Brian:

[00.32.50.17–00.33.07.16]

What we were able to do through that AI workshop is take screenshots of this ladder logic, upload it to AI, and say, hey, can you explain to me what’s going on here and what are the potential gaps? And it gave me all of that. It gave me a nice formatted report telling me, hey, these are the gaps. This is where it could be abused.

Brian:

[00.33.07.16–00.33.32.02]

And not only that, we were able to take information from a PLC, the network capture that we were taking, and create a custom NMAP scan. So NMAP is Network Map Scanner. It’s a common tool as part of the offensive security toolkit. We were able to build a custom NMAP script that was able to gather a good amount of information about this asset that specific to that asset all through AI.

Brian:

[00.33.32.04–00.33.40.02]

And he even pointed at me. I told him I have no idea about ladder logic, and he said to everyone: you see, this is the point.

Matt:

[00.33.40.04–00.33.41.00]

Yeah.

Brian:

[00.33.41.00–00.34.04.04]

And that is the key here, that AI significantly lowers the barrier of entry, not only for insight into OT but for being able to do the actual exploitation. You don’t even need to know what NMAP is to have AI tell you, hey, run this tool to get this information, and build the chain so it not only lowers the barrier of entry to OT insight, but also offensive security approaches.

Brian:

[00.34.04.05–00.34.19.18]

So overall, we’re now in a new era where AI has lowered that barrier of entry and allowed anyone to start looking at, hey, how can we leverage offensive security tooling to specifically target OT?

Matt:

[00.34.19.23–00.34.37.04]

So, Brian, with this whole new world of AI kind of making everybody an instant expert, do you see opportunities where AI could be used on the defensive side in these scenarios?

Brian:

[00.34.37.05–00.34.59.20]

Yeah, it definitely could be used on the defensive side. And I’ll start off on how I’m personally using it. It has personally helped me a lot with my OT knowledge, because as we mentioned previously, bad actors are leveraging it to lower that barrier of entry. But myself, as I’m developing my OT base and understanding of OT assets, I’m leveraging AI to get more context right.

Brian:

[00.34.59.20–00.35.35.18]

Always double checking against other sources, right? Because you don’t want to just take the AI output immediately. But it does help me to do more research and expedite a bit of my testing. We’ve had third parties come in, and I’ve seen how they’re using AI as well. So, across the board, from an offensive security perspective, AI is being utilized to research and find information, instead of me looking through a manual to find some latent feature that maybe they weren’t knowledgeable about, like, hey, this has Wi-Fi, or another aspect that they were not utilizing.

Brian:

[00.35.35.21–00.35.59.22]

AI helps lower that barrier of entry and expedite that to make sure that we maximize that time. Now, from a defensive perspective, it also helps out, because a lot of times the OT CSOC or OT SOC working on these environments comes from an IT background, ideally in the perfect world, right? You would bring in people that mostly have OT backgrounds.

Brian:

[00.35.59.22–00.36.21.13]

But from what I’ve been seeing in the industry, a lot of your OT SOC are IT professionals that have converted to OT. So, it’ll also help them lower that barrier of entry to be able to understand as they’re triaging different alerts, or as they’re trying to fine-tune different detections. They can leverage AI to help that fine tuning process.

Brian:

[00.36.21.13–00.36.50.18]

And actually, during our purple team assessments that we’ve done with our OT SOC, I’ve mentioned at times, hey, maybe look at how you can fine-tune this a bit more, and AI is an option there. Obviously always want to give that precursor. Exclude all of your OT data before using AI. There’s actually a talk about this, where with AI the human is now your biggest concern — as always, phishing. But you want to make sure you extract all that information before you put it into AI.

Brian:

[00.36.50.19–00.36.59.19]

But we have seen fruitful results where it helps expedite a lot of the detection engineering aspect of things.

Matt:

[00.36.59.21–00.37.18.09]

Yeah. Just like it can help somebody trying to figure out where the vulnerabilities are from a malicious standpoint, from an offensive standpoint — it’s like, I need to quickly understand where I need to focus my time, as opposed to reading this book, if you can get the book at all.

Matt:

[00.37.18.10–00.37.48.11]

I mean, sometimes these things are quite black box as products go. Well, let me rephrase this differently. AI can help even though it’s not like, go buy this automated AI tool and integrate it. You’re not even at that level. You’re just saying, I’m using it as a source to quickly facilitate pattern recognition and highlight things I need to focus on.

Matt:

[00.37.48.16–00.38.01.11]

So you can already use this as it is designed, without having to worry about actually launching an AI tool in your environment itself.

Brian:

[00.38.01.13–00.38.24.07]

Yeah. And especially with OT, as we talked about from the beginning, in red teaming and assessing OT, humans in the loop is of the utmost importance. And I think it’s one of those areas where it’ll be some time. I’m not going to be super pessimistic when it comes to AI — there may be a time where it’s a bit more trustworthy. But when it comes to OT testing, I see it going…

Brian:

[00.38.24.08–00.38.53.12]

It’s going to be very difficult to just say, hey AI, can you test this environment, due to the safety implications? So how will AI impact OT operations or OT security? It’s by adding it as a third team member, or a fourth or fifth member, depending on how many people are on your team, to be that additional SME when it comes to OT topics, to help upskill the team in learning more about OT.

Matt:

[00.38.53.13–00.39.28.13]

Sounds like, as a capability description, if AI is going to be useful in an OT security application, it needs to be much more auditable than what we’re aware of right now, as far as how we’re used to interacting with it. As far as humans seeing how the decision is being made, what choices it’s making, and being able to either interrupt a process, or be leaned on or queried for input before a certain process kicks off.

Matt:

[00.39.28.13–00.39.34.19]

Sounds like that process itself needs to be less black-boxy, as far as AI vendors go.

Brian:

[00.39.34.21–00.39.53.18]

Yeah, as I talked about, OT should be a white box. You can’t trust a black box to do a white box test. So, everything should be fully transparent. And unfortunately, as things are set up right now, that’s not the case. So that’s what makes it difficult in this current state of how AI is being utilized to do those types of automated tests.

Matt:

[00.39.53.19–00.40.21.22]

Do you see the sort of rapid capability scaling that AI brings to both a threat model and an offensive model? Going back to your comment a second ago, this is kind of where my head is going, about how security by obscurity has been an actual security model.

Matt:

[00.40.22.00–00.40.50.09]

That’s how a lot of OT environments have operated: nobody knows what’s happening, including the bad guys. Sometimes it’s also good guys. It’s just blind. But do you see the security by obscurity model shaping or changing the way vendors make products moving forward?

Matt:

[00.40.50.09–00.40.54.14]

Do you see that shifting at all from your perspective?

Brian:

[00.40.54.15–00.41.28.03]

So, I think the security-by-obscurity approach and mentality will stay. Even though AI does lower that barrier of entry, there are items like, let’s say, proprietary protocols or technologies that will be safeguarded, because AI may have difficulty getting the data associated with that. So, I do think there’s a middle point, right. Not fully relying and saying, hey, I’m secure.

Brian:

[00.41.28.03–00.41.46.09]

I don’t need anything else because everything I’m doing is obscure. Actually, we had a situation like this where we had a third party come in and our OT stakeholder was like, there’s no way you’re getting in here. Because in order for you to access this device, you need a specific license, and you only get the license key from the vendor.

Brian:

[00.41.46.10–00.41.50.23]

I’m pretty sure we can all think of ways to get license keys.

Matt:

[00.41.50.23–00.41.53.05]

We’re already mapping this out. Yeah.

Brian:

[00.41.53.08–00.42.19.17]

Just not the official way. So that type of security-by-obscurity approach, I feel like, is going to be going away. But leveraging proprietary protocols helps because it decreases that ability to have that information analyzed by AI. Because it’s a lot more restricted, who has access to that information right now. Devil’s advocate could always be what if somebody uploads that information and now it’s part of the training database?

Brian:

[00.42.19.19–00.42.51.06]

That’s correct. But my biggest concern with the security-by-obscurity approach by vendors is that the only way that’s going to be fruitful is if there’s collaboration between the vendor and the companies buying the product, where the vendor is sharing enough information, where the security teams are able to defend these. Because if you’re doing security by obscurity from a vendor perspective, you have these proprietary protocols but you’re not sharing that information with the defensive teams, and the blue teams are trying to build detections

Brian:

[00.42.51.06–00.43.03.06]

And gain a better understanding of how the protocol works to set up those detections. Now you’re not only a challenge to the offensive side, you’re also a challenge to the defensive side.

Matt:

[00.43.03.07–00.43.05.21]

Yeah. Everybody’s blind. Yeah.

Brian:

[00.43.05.22–00.43.25.17]

And with the nature of business, security contracts, legality — that goes by the wayside for some offensive actors on the black hat side of things, where they’re not worried about breaching contracts. Meanwhile, the defensive side needs to make sure that everything they do is in line with the terms and conditions.

Matt:

[00.43.25.17–00.43.40.11]

It’s fascinating. You don’t want to invalidate the warranty on something because you’re trying to figure out what the vulnerabilities are in it, but malicious guys don’t care. Sure, let’s break it.

Brian:

[00.43.40.12–00.44.13.08]

Exactly. So, if vendors are going to have proprietary protocols or technology, there should at least be a minimum baseline of how much information they’re giving, to the point where the defense can set up protections around their configurations. So, if I come to you and say, hey, we had a team do an assessment and they found a gap in proprietary technology, your response shouldn’t be, well, it’s going to be difficult for them to have access to this.

Brian:

[00.44.13.08–00.44.36.23]

No, the response should be, hey, let’s collaborate on how we can update our proprietary software protocols systems in order to improve the security. So, I think that collaboration between vendor and product purchaser is crucial in order for us to be able to stay with that proprietary approach, but also not fully depend on, it’s obscure, that’s why it’s secure.

Matt:

[00.44.37.00–00.45.03.06]

Exactly. I spend a lot of time on the vendor side, procurement and installations and things like that. And so, I see the obscurity approach — the proprietary approach, I should say — in the OT tech world as something that certainly at one point did deliver that security.

Matt:

[00.45.03.06–00.45.37.08]

But the resistance moving forward on the vendor side is going to be more of a protecting a, an existing business model as opposed to doing the thing that is the most secure. So it sounds like guys in your seat are almost going to be the catalyst to drive evolving change on the vendor side, because we all know vendors are trying to keep the lights on and make a profit. We’re not going to just start making changes to our business model ahead of time.

Matt:

[00.45.37.10–00.45.49.14]

So it sounds like guys in your seat are going to be building the case for pushing vendors to evolve in some of these scenarios. Correct me if I’m wrong.

Brian:

[00.45.49.16–00.46.10.20]

Yeah, definitely. As an industry overall cybersecurity, it’s all about collaboration. Going back to our initial point, it’s the people making sure that everyone’s aligned on that same mission of what we’re trying to get to and making sure that we are collaborating with each other to make sure that we can protect against and be one step ahead of those that are trying to cause malicious harm to our environments.

Matt:

[00.46.10.21–00.46.34.00]

You’ve got to be bought into the mission. It doesn’t matter if you’re profit-oriented or not. At the end of the day — from a cyber threat intelligence sharing side of the house, it has had the benefit of the STIX/TAXII format being sort of universally adopted, which doesn’t really exist in OT.

Matt:

[00.46.34.02–00.46.59.01]

Are there opportunities to share wider lessons learned across different industries, and across subsectors, if you will, similar to how CTI is done on the IT side? Do you see an opportunity for that? Or is everything so proprietary, and there are so few OT incidents right now to learn from, that there isn’t much to share?

Brian:

[00.46.59.03–00.47.22.19]

So, Matt, it seems like you might have dropped the mic there, because a lot of these questions are very timely. We actually had a conversation internally about this very topic, of is their value in having an OT-specific threat intel platform. And the way I can see this is actually using an analogy.

Brian:

[00.47.22.19–00.47.44.11]

So, I’m a huge football fan. Go Bills. Excited to see them win the Super Bowl this year. But from a football perspective, there may be teams that prepare for a generic offense or defense, have their plays planned out, and in any sport, you build a game plan when you’re facing an opponent, and a lot of times they don’t just do it on, hey, we’re facing any team.

Brian:

[00.47.44.11–00.48.12.06]

We’ll be ready for any team. They plan out to be on a week to week or game by game basis, to plan a strategy around the offense and defense of their specific opponents. I think that’s the same approach that we should take in industry and in OT. We need to prepare for those threat actors that are specifically targeting your environment. The teams that prepare in sports for the specific adversary,

Brian:

[00.48.12.08–00.48.55.22]

A lot of times their games are a lot smoother, because they know what the opponent is going to do. They’re two steps, three steps ahead of their opponent. That’s the way we should approach it. Just because some of the OT TTPs, or tactics, techniques and procedures, may overlap with IT attacks — knowing what those adversaries, those nation-state actors, those threat actors targeting you specifically what they’re doing, it’s crucial for us to have insight on that and share that information across different utilities. Because that way we can prepare and see, okay, this threat actor is doing this TTP, do I have the detections for that in my environment?

Matt:

[00.48.55.23–00.48.56.18]

Yeah, yeah.

Brian:

[00.48.56.19–00.49.30.14]

And that way you prepare so that if that TTP is used, which we know is actually being exploited in the wild, we’re ready. We have a detection ready for that, so that if it triggers we know we can prevent it, or look into preventing it from even being executed. And if it’s not something you can prevent, at least you’re ensuring that for any TTP that’s out there for your vertical — not only OT but in general, from a cybersecurity perspective, it’s important to know what the threat actors in your vertical are doing so that you can prepare for those since you’re actively seeing them in the wild.

Matt:

[00.49.30.15–00.49.56.00]

So, okay, I hear; I see two threads coming off of this then. One, you can’t sit back on, the OT industry can no longer sit back on the assumption that we have such uniquely snowflake proprietary environments different from each other that we have nothing to learn from each other because AI has just turned that into a flat surface, right?

Matt:

[00.49.56.01–00.50.14.12]

You can instantly become an expert on whatever particular configuration exists, theoretically. So, learning how an adversary is approaching a different environment is still useful. That’s the first thing I heard. Is that accurate?

Brian:

[00.50.14.14–00.50.39.12]

It’s true. And honestly, even though the fundamental technologies may be different, a lot of the frameworks that we’re utilizing, a lot of the approaches, are universal across utilities. So, knowing how each one maybe has been impacted by an adversary, targeting the framework is crucial for us to be able to take lessons learned, even if it’s not one to one. For example, the recent incident

Brian:

[00.50.39.16–00.50.51.20]

That happened with the grid, where through a modem that was compromised through the wind farm, they were able to pivot to, if I’m not mistaken, one of their substations. How many utilities are leveraging modems in general?

Matt:

[00.50.51.21–00.50.56.02]

Modem to substation sounds like a pretty standard configuration.

Brian:

[00.50.56.08–00.51.17.23]

So, taking lessons learned: if they didn’t share that information, it’s not something you would think of potentially looking into. So that’s an example of where information sharing helps bring novel approaches that are being taken to the forefront of how you’re investing in protecting your environment.

Matt:

[00.51.18.00–00.51.58.01]

And the second thought I had gets to your previous comment, and that is a shift in collaboration and a mission orientation with OEM business models and the clients that use their tools. The reason I’m saying that is I read a recent analysis of CTI, and the conclusion of the paper was that CTI sharing is not really useful, because analyzing all of these various attacks and TTPs, half of them didn’t even have the ability to be scanned for and detected.

Matt:

[00.51.58.06–00.52.41.06]

The proprietary nature of the product itself prevented it. And so, the big takeaway was, yeah, that should change, but because of that, CTI is almost not useful, because you can’t just turn around and scan for it. So, it sounds like there’s some work that can be done on the vendor side — speaking as a vendor, though we’re not specific to OT — that the old security-by-obscurity models that have helped proprietary vendors build little islands and moats around their business should be reevaluated if they’re creating friction for end users to learn from each other.

Matt:

[00.52.41.07–00.52.46.19]

Maybe that’s the best way to put it. Is that accurate? Thoughts on that one?

Brian:

[00.52.46.22–00.53.11.19]

Yeah, and I think that’s in line with the overall shift, as an industry, from taking threat intel as simply, hey, what are the indicators of compromise, and let me scan my environment for them — IPs, hashes — to, let me actually look at this threat intel report of an attack and extrapolate the tactics, techniques and procedures that the adversary used, and analyze those instead.

Brian:

[00.53.11.23–00.53.22.16]

Because a lot of times, as a cybersecurity organization and as an industry, we want to focus on those, because frankly a lot of times those are easier. You do a quick scan, okay?

Matt:

[00.53.22.17–00.53.25.17]

That is so specific. It’s boom, done. Yeah.

Brian:

[00.53.25.22–00.53.52.17]

But really what we should be looking at are those tactics, techniques and procedures, those TTPs. And actually I’ve talked with my director about this topic, because we’ve constantly discussed how this shift is where the industry is going, and that everyone should start looking at it from this perspective. We want to drive that point in: that we should shift away from just focusing on those IOCs, and extrapolate as much as we can from any threat intel that we’re getting.

Brian:

[00.53.52.17–00.54.06.08]

What are those TTPs? How do they line up with MITRE ATT&CK in general? And how can we, as an organization and as an industry, make sure that we’re defending against those, because it will change?

Matt:

[00.54.06.09–00.54.06.20]

Yeah.

Brian:

[00.54.06.22–00.54.23.09]

You’re maybe never going to see that IOC used again. A lot of times these actors are smart. They’re not going to use the same IP for one organization as for another. But they will use the same TTP. So how can you detect that, and not solely focus on the indicators?

Matt:

[00.54.23.09–00.54.49.07]

Right. So dialed into the tree that you kind of miss the forest. 100%. As a kind of closing here, what’s the one piece of advice for someone sitting in a similar seat as you, tasked with trying to work with the OT side on — not red teaming, but pen testing and things like that?

Brian:

[00.54.49.09–00.55.19.07]

So, the best piece of advice I have for somebody that’s starting this journey of assessing OT environments is to be humble and curious. OT stakeholders really respect when you show true interest in their environments. So, if you’re going to be doing this line of work, just go all in on it. Research OT, understand what OT is, the difference between operational technology and industrial control systems, what they mean, and really show respect for the work that they do.

Brian:

[00.55.19.09–00.55.48.05]

Don’t only focus on, hey, I’m assessing this environment because it’s part of my role. Take into consideration the bigger picture. I think that’s sometimes what we lose sight on. If you’re working on assessing a water treatment plant, think about the fact that if that site goes down, who’s impacted. Take that into consideration when you’re speaking to your stakeholders: hey, I just want to say thank you for what all of you do in order to make sure that we have that clean water.

Brian:

[00.55.48.06–00.55.56.06]

If they’re working on gas: thank you for making sure that the gas we have flowing to our stove is working.

Matt:

[00.55.56.08–00.55.58.11]

Or generation of electricity.

Brian:

[00.55.58.13–00.55.58.23]

There we go.

Matt:

[00.55.59.00–00.55.59.21]

Yeah, yeah.

Brian:

[00.56.00.00–00.56.12.09]

Keeping the lights on. Taking that perspective, I really think, helps build that trust, because you’re not going in with, hey, I’m information security and I have the authority to do what I need to do.

Matt:

[00.56.12.10–00.56.12.23]

Yeah.

Brian:

[00.56.13.04–00.56.27.23]

That’s never worked. What I’ve seen consistently work is somebody that’s humble and goes in curious, wanting to learn and wanting to help — not wanting to force themselves in, but offering a service, not something that is required.

Matt:

[00.56.28.01–00.56.33.00]

Brian, you should teach a psychology class on red teaming.

Brian:

[00.56.33.02–00.56.34.08]

That’s for the next podcast.

Matt:

[00.56.34.14–00.56.45.18]

That’s right. On a personal level, what’s something, an idea, that’s got you excited? I like to get into where your brain is headed next.

Brian:

[00.56.45.20–00.57.12.14]

So personally, for me, my excitement is trying to get more into the weeds of OT in our organization. But in general, just trying to continue developing that OT insight and perspective, really becoming that SME within our red team. So, I’m really trying to dive deeper on those types of topics, trying to do more labs, and trying to leverage a tool that was mentioned out there.

Brian:

[00.57.12.14–00.57.36.22]

And I’ll give them a shout-out, since they gave me the shout-out: it’s LabShock. There’s this tool that’s been created that actually allows you to emulate different OT environments and to assess them from a defensive perspective, but also an offensive perspective, OT environments and develop that skill set. So really trying to go more into that concept.

Brian:

[00.57.36.22–00.57.56.18]

I’ve been bitten by the OT bug. I’ve told people I’m very interested and just overall motivated to continue going down this path. Like I mentioned, from my perspective, personally working for an organization like this, it’s just thinking about the fact that we’re protecting the greatest city in the world. And I’m partial, because I’m New York raised.

Matt:

[00.57.56.20–00.57.57.16]

Yeah, I can’t help it.

Brian:

[00.57.57.19–00.58.21.01]

But you’re protecting the gas that flows through the streets of Manhattan, making sure the lights are on at 42nd Street, when you’re doing these types of assessments. So, knowing how the systems work in the background, that infrastructure that keeps the greatest city in the world pumping — that’s what makes me get up in the morning, grab my coffee, and get excited to get to work.

Matt:

[00.58.21.02–00.58.31.22]

How could it not? What’s something that you’ve found yourself changing your mind on, or a topic you’re wrestling with?

Brian:

[00.58.32.00–00.58.55.14]

So, the challenge that I’m wrestling with right now is how can I increase and continue developing that trust of stakeholders on a continuous basis? We have an approach called OT Security Champions, which I think is something that, if you don’t have it in your organization, is interesting to explore. It’s a monthly meeting where we have a platform for information sharing.

Brian:

[00.58.55.14–00.59.21.11]

So, each month we have a speaker highlight a specific topic. This month we’re talking about insights from DEF CON specific to ICS. So, it really allows that platform to have a continuous touchpoint with our OT stakeholders. So, what I’m grappling with and wrestling with right now is, how can I continue to drive value to our OT stakeholders in a way that doesn’t rely on us doing assessments?

Brian:

[00.59.21.14–00.59.39.01]

How can we do it where, hey, if you want to test a new detection, let us help you with that? Extending that olive branch so that our relationship is not only that of red team and OT, but more of, we all work for the same organization. How can we continuously help and develop each other?

Matt:

[00.59.39.02–01.00.02.23]

Just one team. Yeah. All right. So, the closing question we always ask here at the Lock & Key Lounge has the lounge theme to it. But I understood you were a coffee connoisseur, or lover, so I’ll pivot on this framing a little bit. You’re at a coffee shop. It’s your favorite coffee shop.

Matt:

[01.00.03.00–01.00.23.01]

It’s that one you always think of when it’s like, I really need that Americano or what have you. Across the room is somebody in security that you’ve been dying to talk to. So, what is the coffee that you’re ordering at this place, and who’s on the other side of that room?

Brian:

[01.00.23.03–01.00.39.18]

Well, Matt, it may surprise you. Like you mentioned, I love coffee. I make my own coffee, I have a Breville Barista Express, so I make coffee for myself and my wife. My drink would be a cortado, and it would be with four shots of espresso. When I tell…

Matt:

[01.00.39.18–01.00.42.22]

Four shots? I have found him. Yes, okay.

Brian:

[01.00.42.23–01.01.13.20]

So, four shots, equal amounts of espresso and milk, the perfect amount, so you can cut some of the bitterness but still taste the coffee. And the person I’d like to talk to — something from the SANS ICS Summit that I regret not taking more advantage of — is Rob Lee. The reason being that I want to learn from both facets of his approach to cyber. I would love to hear stories of the incidents he’s been a part of the ones that he can share.

Brian:

[01.01.13.21–01.01.31.09]

But in addition, with everything going on with his organization, just learning more of the business side of cybersecurity. I finished my MBA a few years ago, so the business aspect of things, and connecting that to the technology side, and how that’s balanced. In addition, as a father: how do you balance all of this?

Matt:

[01.01.31.13–01.01.33.12]

Right? He’s a brand-new dad, too.

Brian:

[01.01.33.15–01.01.41.18]

It’s something I like to ask all dads that have a lot of these responsibilities: how do you balance it all, and give me some insight? I have a two-years old, so.

Matt:

[01.01.41.19–01.01.42.00]

Yeah.

Brian:

[01.01.42.01–01.01.59.09]

Learning how to balance it all. It’s fascinating. So that’s whose brain I’d like to pick, just because of the incidents that he’s been a part of, but also the business side of things, with the merger and everything going on with his organization. I think it’s a great time to just have a coffee with him and talk about these things.

Matt:

[01.01.59.10–01.02.11.14]

He was on my podcast a while ago. Maybe we could do a joint thing where I just let the two of you lose and go for it.

Brian:

[01.02.11.16–01.02.12.18]

Yeah, that’d be awesome.

Matt:

[01.02.12.20–01.02.31.17]

Awesome. Well, Brian, I really appreciate you taking the time here today. We usually expect the conversation to wrap up quickly, and I’m glad we didn’t. I really took a lot of information and concepts from this. So, I appreciate you taking the time to join us today.

Brian:

[01.02.31.19–01.02.40.19]

Yeah, Matt, thank you for the invitation. Door’s always open, and I’m always happy and excited to talk about these topics and share them with a wider audience.

Matt:

[01.02.40.19–01.03.10.06]

You can feel it. You are down for the mission, for sure. And for the listeners, thank you for your time as well today. If there’s a big thing, and it’s always a theme if you’ve listened to more than one of mine on the podcast side, it’s that trust isn’t just an essential component of relationships. It actually enables critical response teams and responders to move more quickly and to respond faster.

Matt:

[01.03.10.06–01.03.34.13]

It is the lubrication, if you will, that allows teams to respond at speed as opposed to having to get over that friction. It doesn’t come with a quick patch note. It doesn’t get faster just because you’ve deployed AI. If you’re the one asking an OT engineer to let you into these environments, that is still on you to earn.

Matt:

[01.03.34.13–01.03.48.17]

And one conversation, one engagement, one kept promise at a time is how you do it. And that’s how you do it. That’s how you do life. So, until next time be well, stay curious, and do good work.

Matt:

[01.03.48.19–01.04.21.18]

We really hope you enjoyed this episode of The Lock & Key Lounge. If you’re a cyber security expert or you have a unique insight or point of view on the topic, and we know you do, we’d love to hear from you. Please email us at Lounge@ArmorText.com or our website armortext.com/podcast. I’m Matt Calligan, Director of Revenue Operations here at ArmorText, inviting you back here next time, where you’ll get live unenciphered, unfiltered, stirred—never shaken—insights into the latest cybersecurity concepts.