Speaker 1: That's really the key is understanding your assets gives you
the ability to understand your attack service.
Speaker 2: Welcome listeners to the Industrial Security Podcast. My name is
Nate Nelson. I'm here with Andrew Ginter, the vice president
of Industrial Security at Waterfall Security Solutions. He's going to
introduce the subject and guest of our show today. Andrew,
how's it going.
Speaker 3: I'm very well, Thank you, Nate. Our guest today is
Brian Derico. He is the founder of Trident Cyber Partners,
and he's going to be talking about using asset inventory tools.
I mean, we've had a lot of people on vendors
mostly talking about what's available, how it works. He's going to,
you know, look at the problem from the point of
view of the user using these tools, and you know
why using these tools turns out to be a little
harder than you might expect.
Speaker 2: Then, without further ado, here's your conversation with Brian de Rico.
Speaker 3: Hello Brian, and welcome to the podcast. Before we get started,
can I ask you to say a few words of introduction,
tell us a little bit about yourself and about the
good work that you're doing at Trient Cyber Partners.
Speaker 1: Good morning, Andrew, Brian de Rico been in the critical
infrastructure sector for about fifteen years. Spent my entire career
at a large utility solely focused on the cybersecurity requirements
for nuclear power plants, and my last role there was
actually was the program manager responsible for the entire cyber
program across the fleet, again all really dealing with OT
type stuff and regulatory requirements. I left in October, started
my own business, Tried and Cyber Partners, and mainly aim
to help other critical infrastructure sectors with their cyber problems.
Speaker 3: Thanks for that, And our topic eventually is going to
be acid inventory. But you know, let me ask you.
You've spent a lot of time working at nuclear You've worked,
you know, in very old plants in you know, you've
done some work recently with very modern plants. Can you
talk about, you know, in terms of automation, what's the
difference between sort of very old automation and very new
automation that you've been exposed to.
Speaker 1: Yeah, so there's there's a lot of similarities. Right at
the end of the day, whether it's a new plant
or an old plant, it is still a nuclear power plant.
So there is a nuclear reaction that is heating some water.
That water is heating some other water, and a secondary
loop that is flashing to steam spending a turbine making electricity.
So that is nuclear power one oh one. It doesn't
matter how new or old the plant is. They've all
generally worked that way for a long, long period of time.
To your point, what you do see is the amount
of digital assets in those plants is drastically different from
new to old. So in my previous role, I had
done some industry benchmarks to try and figure out what
is sort of the average number of you know, digital
devices that are in a plant, and it came in
around seventeen or eighteen hundred per unit. These new plants
that they're building, they're an order of magnitude larger than that.
There are you know, potentially ten thousand devices on a
single unit because everything is digital. You know, I don't
know how many people have had an opportunity to tour
a nuclear plant. I would certainly advise if you have
that opportunity, is a really really cool thing to see.
And most plants are all analogy. There is a lot
of analog equipment, a lot of analog indication, and the
new plants that's not that case anymore. So trying to
keep track of all of your digital devices becomes a
very important and critical problem. For example, you know, and
some of the older plants that we worked in, you know,
as you're going through getting asked at inventory, you open
up a cabinet, you kind of look for what is digital?
What are the blinky lights? And you know, you go
through and that is generally a manual way that we
did a lot of asset inventory. These newer plants, you
open the racks and everything inside is digital. Everything inside
could be considered, you know, an attack pathway, and you know,
there were some discussions and there's some thought process out
there that essentially calling locations critical is going to be
an easier way to do it, because saying this entire rack,
no matter what's in it, is going to be a
critical digital component, is an easier way than trying to
label an inventory all fifty or sixty devices. So that
was a thought process that was considered. But again, at
the end of the day, every device was considered on
a case by case basis. But it kind of gives
you an idea of just the scale of how much
digital equipment there are in newer plants nowadays.
Speaker 2: Andrew, I'm glad we're getting the opportunity to talk about
nuclear because it seems like a pretty relevant and highly
important field, and yet it never seems like we get
a guest on who wants to talk about it. So
where does nuclear stand in the paneple that is industrial security?
For you?
Speaker 3: We're going to be talking mostly about asset inventory, but
let's talk about nuclear for a while. I mean, you know,
Brian said a few words, you know, in a sense
he's lived a lot of this stuff, you know, without
even knowing how unusual it is. Nuclear is an extreme.
You know, when we talk about worst case consequences of compromise,
what's the worst case The worst thing that can happen
in a coal fired power plant? A boiler bowson, people die. Okay,
what's the worst thing that can happen in a nuke?
The nuclear core explodes, you know, Chernobyl and hundreds of
square kilometers become unlivable for centuries. Oh that's very bad.
So you know, the consequences drive the intensity of your
security program. And nukes are an extreme. I mean, the
only thing I can imagine that's possibly more sensitive than
nukes's I don't know nuclear weapons targeting systems and you know,
launch launch protocols. It's just it's that extreme. You know,
what does that mean for cybersecurity. Well, you know, let's
start with physical security. In different parts of the world,
there's different rules. In a lot of the world, you
need a security clearance to visit the site. You know,
in North America you can get tours of the site.
But you know, in a lot of places, you you're
a lot of stuff is classified. I don't have a
security clearance. I've never seen network diagrams for a nuclear site.
I'm guessing a bunch of this stuff is classified. It's
you know, it's national secrets. It's it's it's that intense.
On the cybersecurity side, again, I talk to people, uh,
you know, we we serve nuclear customers at Waterfall, and
you know, they do things that seem, again, seem extreme.
They might have all of their OT systems in one
room in one building, and all of their IT systems,
all our IT servers, email servers and whatnot. They do
have IT networks. You know, in nuclear plants you need
to you need to schedule work crews, You've got to
pay your people. So they have IT networks and all
of the IT servers are in a different room, in
a different building. Why. Because they cannot afford someone any
time someday to make a mistake and plug a cable
from an IT network into an OT asset. That's completely
unacceptable cybersecurity wise, And so they physically separate it so
that as much as possible, they make these kinds of
errors impossible. You can't do it, you can't plug the
wrong cable and it's in a different building. You know.
Another example, you might imagine that there would be multiple
security levels. You might imagine that the technology that controls
the core, you know, the control rods into the core
that keeps the core from exploding, is more sensitive than
the OT systems that control the steam turbines. I mean
a coal power a coal fired power plant has steam turbines.
Steam turbines have steam turbines, you imagine. In fact, again,
when I talk to these people, a lot of nuclear sides,
in my understanding, have only two security levels absolutely highest
critical and business, and nothing in between. Again, why why
would the steam turbines be protected to the same degree
as the core control system? In part, it's because you
know the physics of these systems the steam, you know,
there are distant physical connections. You know, the liquid from
the core heats up the liquid in the steam, and
so you know there's a theoretically a risk that something
happening to the steam turbines could leak back into the core.
But more fundamentally, these people just say, we cannot afford
to make mistakes with security, and so we're going to
dumb it down. We're not going to have seven or
eight or thirteen security levels. And you have to remember
which is which and apply the right policies to the
right equipment. It's going to be absolutely critical or business,
end of story, and you know which room you're in.
That's the policy you apply again as much as possible.
They eliminate human error. You know regulations. I'm most familiar
with the North American regulations. You might imagine. I mean
NERKSIP handles the power grid. If you fail to live
up to your obligations under NRKSIP, what happens you can
be fined as much as a million dollars a day.
It's never been levied, but you know, you get fined
with the nukes if they fail to live up to
their regulations. They're shut down, they lose their license to operate.
It's that simple. If you cannot operate safely, you cannot operate. Bang,
you're down. So again, intense attention is paid to the
detail of cybersecurity and cybersecurity regulations.
Speaker 1: Uh.
Speaker 3: You know another example, I'm not aware of any nuclear generator.
Now I might, I don't know all the generators in
the world. I'm not aware of any nuclear generator that
has any kind of OT remote access period. Nothing remotely
gets into OT. You want to touch OT, you walk
over to the server room. So again intense in a
sense though, you know what I what I what I
see of the nukes is that they are leaders in
the cybersecurity field. You know, they they do things extremely intensely,
and as other parts of the field other you know,
power plants, other refineries, other you know, high consequence sites.
As the threat environment continues worsening, as cyber attacks keep
getting more sophisticated, they look over at what is nuclear
doing and they pull one after another technique out of
the nuclear arsenal and start applying it in their in
their circumstance. So you know, even if you're not required
to follow the nuclear rules, I would encourage people to read.
You know, it's ANYI the Nuclear Energy Institute eight nine
standard or the NRC Nuclear Regulatory Commission five seventy one.
I'd actually recommend eighth nine. It's it's more readable, it's
got more examples. The five dots seventy one is sort
of more terse and saying here's the regulation. Follow it.
But yeah, they are leaders in the space, and over
time I see people drawing on their expertise and the
way they do things. And our topic is asset inventory.
And so you know, we're talking about how much automation
there is, we're talking about how hard it is to count.
Can we back up a minute, you know, in principle,
you know, the the truism is you cannot defend what
you don't know you have. And so that's why we
do inventory. Is that it or is there more to it?
Why are we doing these inventories? What good is an
asset inventory?
Speaker 1: So it's a great question, and I'm going to give
two answers, right, So one is on the nuclear space.
The first answer is we have to right, and sometimes
that is an answer. I don't think it's a good one,
but it is an answered. So we do have regulatory
compliance around an asset inventory because to your point, it
does sort of fuel other aspects of your cyber programs,
such as supply chain vulnerability management, configuration management, et cetera.
The flip side is, it's just it's a smart thing
to do, right. You can't build a vulnerability management program
if you don't know what software is out there that
you're potentially vulnerable to. So trying to build a vulnerability
management program when you don't know what's out there is
it's a fool's errand because you're never going to be
able to understand your total risk. And that's really the
key is. Understanding your assets gives you the ability to
understand your attack surface. And once you understand your attack surface,
you can then figure out what are my vulnerabilities? What
do I need to mitigate? What is a you know,
possible you know threat vector an adversary could use to
attack you know, this device or this process. And you
can't do any of that without having the asset inventory first.
Speaker 3: There's tools out there to do asset inventory. You know,
we don't have to do a manual walk down and
count the blinky lights in the cabinets, you know, do
the tools not solve the problem is is there still
a problem when you've deployed one of these tools.
Speaker 1: Yeah, So there are a number of tools that do
this and some are better than others. Right, make sure
of the these but they do a great job of
asset inventory. So I currently do professional services for a
software company and a lot of their deployments in the
OT space are generally for people that want to use
the tool as their asset inventory. Now, the issue is
sort of becomes a couple of pieces. One that comes
up can come up often, and I saw this in
nuclear all the time. Is a lot of those tools
that we're talking about, they depend on network traffic, right,
so they're looking at source and destination and they're passively
trying to piece together these are their assets on your network,
and this is what they do and how they do it.
So one problem is going to be you have assets
that are not networked. If you have safety critical devices,
they may be isolated. So you're not going to be
able to deploy a tool to do that. So you
are going to have to manually enter those in and
manually keep track of those in some way, shape or form.
And then the second piece is a lot of these
tools that we talked about, they can't just be deployed instantly.
You can't just throw a box in a rack and
you call it macaroni. You know, there are architectural changes
that have to happen to your network. You have to
get traffic from switches, you have to open span port,
you have to deploy sensors, and that's where things can
get a little difficult on the ot side of the house.
Speaker 3: Modern switches, any kind of managed switch has got a
span port or a mirror port. You lug into the switch,
you turn on mirroring, and off you go. You can
start seeing the traffic, and you know, a lot of
these these asset inventory tools can start figuring out what
are the assets based on their traffic. You know, I
get that some some systems are are not on the network,
the safety systems. That makes sense, but is it is
it more complicated than that? I mean, I imagine you're working
with some older systems, older switches, or you know, do
any of these plants use non managed switches?
Speaker 1: So I'm sure there are some non managed switches out there.
I would not be surprised if there are some, you know,
hubs that are still out there and kicking. While in theory, yeah,
opening up a span port is a is a simplistic idea.
Where that turns into and where it becomes difficult is
a lot of these OT vendors and even environments that
you're in. Nobody wants to change the system without vendors
involvement because everybody scared about what are the consequences, Because again,
this isn't an IT system, this is an OT system.
There could be some huge process changes in huge impacts
and risk if whatever you want to do doesn't go
according to plan. And that's where I have seen the
most amount of struggle come from. Is you know, you
want to get some a span port. You reach out
to the vendor, you say, hey, this is what we're
looking to do. We just want to span this traffic.
And the vendors don't want to budget. The vendor, you know,
hasn't deployed that they don't know what that's going to
look like. They tell you that, hey, we're going to
have to refat the entire system. You know after making
this change. Now you know, meanwhile, is there going to
be an impact? No, we can look at switch utilization
and see, you know, hey, even if we double. You know,
we'll double the switch utilization. You know, you're not going
to see a huge impact to that because your switch
is only at five or ten percent utilization. But it's
just it's the there isn't an understanding on the vendor side.
So for some of these big control system vendors, it
becomes difficult for them to bless as it were making
these changes. And that's where we have seen the most
amount of struggle. And we even had projects where we
had to provide a lot of the testing and we
provided you know, this is what needs to happen because
the vendor just didn't have the knowledge. And I think
as time goes on, for you know, the control system
vendors that are out there, I think that's going to
be more and more of an issue because more and
more of their deployments are going to have a requirement
for some form of higher detection capability. We can't just say,
you know, these things are you know, they're in an
OT environment, they're safe, that this system the case right
There needs to be higher level of detection and the
vendors need to be more willing to work. And as
time goes on, I think it'll be easier but retrofitting
this sort of technology in existing systems becomes increasingly difficult
because nobody wants to touch the system that isn't broke.
Speaker 3: So a couple of quick points there. You know, Brian
used a couple of acronyms people might not recognize. He said,
you know, you might have to refat the entire system.
What's that FAT is factory acceptance test. It's set everything
up and test every function of the system, emergency recovery
every function of the system, and make sure that it
meets the requirements that were laid out when you issued
the contract to get the system built. Typically days you
have to shut the plant down to do it. So
nobody wants to refat anything. So that's that's what the
vendors are threatening, saying, well, if you make a change
that we haven't tested, we have to retest it, don't
we You know. Another point he made was about bandwidth.
And you know, for anyone who's not real familiar with
how mirror or span ports work, you've got to switch
with I don't know, twenty four ports on it forty
eight ports. It has to be a managed switch. You
log into the switch with a username and pass word
and you can configure the switch. And one of the
things you can configure is it's called a mirror port
or a span port. It's a port or you know,
multiple ports where you send copies of stuff. So typically,
if you're going to do an asset inventory, you can
figure one port and say every message that anybody sends
to anybody else on the system, send a copy of
the message out this port. And now the asset inventory
system can look at the messages and say, oh, there's
IP addresses in use. I wonder what kind of machine
this is. It's using this t CP port number, and
it figures out what kind of stuff is on the
network based on the network traffic, and the mirror port
gives you that traffic, and the throughput consideration is you know,
I thought, and now I'm not an expert on switches,
I assumed that modern switches you would put you know,
they have ports twenty four ports out the front, and
every message that comes in goes onto a backplane. It's
a very high speed backplane. And I thought that the
message went to every one of the other ports, and
the ports decided do I send this out or not,
and so it would go to the mirror port as well.
That's what I assumed, And so you know, turning on
the mirror port would not in fact increase the amount
of traffic on the backplane because every message is visible
to every port. You know, what I didn't get clarification
from from Brian, but what it sounds like is at
least some of the switches he's dealing with, if you
enable the mirror port, then the source. If Port A
is sending a message to Port B, it first puts
on the backplane address to Port B, and a second
time puts the same message on the backplane addressed to
the mirror port, because it's been configured to send everything
to the mirror port, and that would tend to double
the amount of traffic on the backplane. But these backplanes
are massively high speed because they have to support all
of the twenty four ports simultaneously. So he's saying, look,
your average backplane is, you know, barely loaded, and doubling
the load is immaterial. What he did not say was that,
you know, configuring the switch causes the switch to malfunction.
I would imagine ancient switches that you know, were were
around sort of at the beginning of the concept of
mirror ports and span ports might have defects in their
software that if you turn on the mirror port it
might malfunction. But you know, he didn't say that. I
forgot to ask him, and the fact that he didn't
say it says to me he's never run into it,
or you know, he would have mentioned it. So that's
I'm putting words in his mouth there. But I'm guessing
that's not so much a concern. The concern is to
put The concern is testing. That's just you know, people
worry about things working the way they're supposed to if
you make a change that has not been anticipated. This
is the essence of the engineering change control discipline that
is again used intensely at nuclear sites and used but
maybe just a little less intensely at other critical infrastructure
sites in the modern day. You're saying, you know, the
control system vendors don't get acid inventory. I mean span ports,
mirror ports. They're also used for intrusion detection systems. This
is what Dragos uses, this is what Nasomi uses. You know,
the six pillars of the cybersecurity framework, and this framework
include detect, respond recovery. You've got to be able to
look at what's happening on the hosts. You got to
be able to look at what's happening on the networks. Really,
you know, the the vendors in the modern day don't.
Speaker 1: Get this credit where it's due. Do get it better
than others. However, you know, there have been some vendors
we've worked with that did not want to make any
changes because they just wanted to give us the same
system that they gave us twenty years ago, you know,
with one version you know, higher than what we deployed
again decades in the past. And you know, when pressed,
while the people on the vendor side are experts in
what they are doing, they are experts in safety design,
they are experts in PLCs and how all of these
things talk together, they're not IT people. So when you
start talking, you know, hey, I want to open up
a standport, it's different. They don't understand. They think it's
going to cause an impact to the system. Meanwhile, as
people with an IT background, we can see that, Hey,
you know you're using managed switches, you can enable a
stand port. The inputs are one hundred meg and you know,
even if all of your PLCs are completely maxing that throughput,
the backplane of the switch is going to be nowhere
near utilization and even doubling that, you're not going to
see a decrease. And it just it takes a long
time to get the vendors on board. And again, you know,
we even offered to do some testing and show what
the utilization changes were, and you know we have seen
that again with some vendors are better than others. But
you know, I feel like at the end of the day,
it's we just want to give you the same system
that you've already had, and mayking changes to that as scary.
And you know, we're an isolated system, so you know,
we don't need to deploy a lot of that technology
because we're just going to stay isolated and not connected
to anything. And the reality is that isn't as effective
either because you while you lose the sort of network
attack path, you still have several other such as physical
supply chain and portable media. So having detection capability is actually,
in my opinion, it's worth the risk of plugging that
thing in as long as you have a sound architecture.
And that's where some of the struggles begin with, with
changing sort of that mindset from on the vendor side.
For example, you know, some of the control system vendors
that you know there's workstations and stuff there. They understand that, yes,
there are detection pieces. You're going to deploy some level
of network contrusion detection. You're going to deploy some level
of scene agent. Right, so I need to sense this
log and we've had good luck, you know, again with
particular vendors. There. Some vendors will actually included with their
control system they will also include a security suite, so
they will have their own you know, hids or nids,
your seam and that's all included. You know, they have
a patching server that distributes you know, Microsoft quick fixes
and all that stuff.
Speaker 3: It's great.
Speaker 1: However, when you get to that lower level of your
PLC type stuff where you know, again we were working
with a PLC vendor and they would not bunch. They
did not want to change their design. They thought that
the switch there would be a loss in time of
communication which would affect the safety related aspect of the design,
and they did not want to budge.
Speaker 3: And you know, it.
Speaker 1: Took two years for us to work with them, for
them to understand that we have requirements and you know,
when the programs were implemented, specifically across nuclear it was
understood that you're not going to go in and bolt
this stuff onto existing systems. But when you're starting fresh,
when you're building a system from the ground up, it
has to have all of these components. You know, there
is no longer an excuse to say, oh, you know,
it's already working. You know, we're not going to go
play around with it. It's going to that could obviously
cause issues. Everything has to be baked in from the
ground up. The cybersecurity keys has to be foundational. And
again with the p LC vendors, we found it to
be again one particular vendor, very difficult for us to
get that through and it took a number of people
you know, trying to work there. You know, the PLC
engineers through why this is okay, you know, we promise here,
you know, here's some data to back it up, and
they finally did agree to use the architecture that that
we were you know, we had kind of specified from
a design.
Speaker 3: Perspective, we sweat blood, we fight with the vendors, we
get our asset inventory system deployed, we you know, augment
it with with manual inventory for the air gap or
the isolated networks, and we use it for managing patches
and vulnerabilities. Is there anything else we use it for?
Speaker 1: Yeah? Absolutely, to your point, vulnerability management is a big one,
right because I think at the end of the day,
your asset inventory is going to give you what your
you know, what your risk profile is, what your attack
surface is. Vulnerabilities is one part of that. You know.
There there is uh, you know, another piece of it
that is supply chain, right, so we talked about that
a little earlier. Being able to understand what are the
important devices that I Am going to produce, you know,
procure h and procure those with certain sets of requirements.
That's also critical. Another thing that we would use it
for is configuration management. So understanding what is your configuration?
You know, you can build tools, You can use tools
that tell you, you know, this is the configuration on
the device. And some of those tools out there, you know,
some of those network contrusion systems that are OT centric
can also give you alerts and understandings on you know,
what is when changes happen. You know, you have a
code download to a PLC, is that expected? And then
also you know, this is the running code of that
PLC and this is what changed, and you would have
visibility into all of that and again all based on
their asset inventory and having as much information as you
can about those assets.
Speaker 3: You know, the latest automation systems have a lot of
devices and acid inventory counts them. This is great, but
there's a lot more we need to do with the information.
So you've talked about patching. You know, there's a lot
of We've had people on the show talking about s
bomb uh, you know, software bill of materials, keeping track
of sort of embedded software when vulnerabilities are announced. Is
there automation for tracking s bombs and vulnerabilities? And you know,
doing the mechanics of patching, and you know, arguably counting
the asset is the easiest part of managing the inventory.
You know, is there more in sort of that we
can expect of modern tools.
Speaker 1: I think there is. And you know, vulnerability management is
always going to be one of the most difficult things
to conquer because if you don't have an updated software inventory,
you're never going to know what's out there. You can
do all the Windows patches in the world, but you know,
there are obviously tens and tens of thousands of non
Windows vulnerabilities where if you're running again insert whatever software
product right, there are huge vulnerabilities around a lot of those.
So can you automate it? I think it comes down
to you can automate the visibility right, so you can
at least understand and have up to date dashboards of this.
These are the devices that you need to worry about, right,
this particular device has five critical vulnerabilities, and then that
gives your you know, your internal cyber engineers something to
go after to mitigate to overall reduce that risk. I
also think it's important from a business perspective to understand
what are we going to do?
Speaker 3: Right?
Speaker 1: On the IT side, there's a lot of patching processes,
and there's you know SLA is associated with is your
you know, is the vulnerability critical, high, medium, low, et cetera.
On the OT side, in general, OT is very adverse
to patching and mitigation. And I agree with that in
some senses, and I don't agree with that in other senses.
And I think as a business, you guys like you
need to understand what is your tolerance for that risk?
What are you willing to accept and are there areas
where you know, yes, we we're comfortable we're not patching
because we have all these controls in place, and you know,
in order to get the device, you know, there's guns,
gates and guards in the middle of it. You know,
but hey, maybe if something really, really really big comes out,
we are going to take care of it. And we
do have to come up. So I don't think there
is a way to fully automate it, but you can
at least automate the visibility so you don't have people,
you know, just manually searching NVD with a software list
that they don't even know as accurate. You can get
that part out of the way. There are tools out
there that will help you, and then becomes a business
decision and sort of a business process around Okay, with
all that information, here is your overall risk profile. What
are you going to do about it? And that, you know,
that becomes the deeper discussion again around what specifically the businesses,
how much risk tolerance you do have, how much risk
avoidance you want to have, and you know kind of
go from there.
Speaker 3: Well, Brian, thank you so much for joining us today.
Before I let you go, can I ask you can
you sum up for our listeners, what should we take
away in terms of you know what we're doing with
asset inventory?
Speaker 1: Absolutely, I would say asset inventory is the most important
part of your program because if you don't know what
assets are out there, you're never going to be able
to protect your organization from somebody that maybe they know
what's out there and you don't. So asset inventory is critical.
You cannot build upon your internal program without understanding what
your attack service is. I think another point is there
are tools to help you. This is not something that
we need to do manually anymore. You do not have
to go into cabinets and count every single blinky light.
There are tools and you know, products out there that
will help us get closer to where we want to be.
And then at the end of the day, you still
need an internal team that understands what the information coming
back gets. So if if you you know, if you
do need help in deploying these tools or selecting tools
or understanding what the risk is, I'd be happy to help.
You can connect with me on LinkedIn. Brian de Rico.
I'm I think I'm the only one, uh and I
can help you with those problems because again once we
once we conquer assets and get the tools in place,
a lot of pieces of the program become a lot easier.
And my goal and what I love is just driving efficiency.
So let's automate, automate, automate, use tools to kind of
help us see what we can't and just do what
we can to protect vertical infrastructure.
Speaker 2: Andrew, that just about concludes your interview with Brian. Do
you have any final thoughts about what he talked about
there that you can leave our listeners with?
Speaker 3: What I took a wave here is is you know
the importance of inventory and the need for automation. I mean,
if a modern nuclear generator has you know, ten thousand
plus devices in it that have CPUs in them that
have to be managed, that have software that have to
be managed, you know, I don't know that a nuclear
generator is that much more heavily instrumented than the average
industrial thing. If you buy a steam turbine, it's a
modern turbine is heavily instrumented. If you buy any kind
of physical equipment, it's going to be heavily instrumented. This
is you know, there's there's three hundred plus CPUs and
a modern automobile and that's you know, that's something that
fits in your living room. We're talking about massive installations.
You know, I would imagine that a big refinery has
as many as one hundred thousand plus devices if it's
been upgraded recently. You know, when was the last time
you tried to manage a spreadsheet with ten thousand rows
in it? When was the last time you try to
manage the spreadsheet with one hundred thousand rows in it?
Just manually counting the blinking lights takes a long time.
Automation to me is essential. I mean this is you
look at the cybersecurity framework sort of the grand compendium
of everything that is cyber what's the first thing you do? Well,
the first thing you do is figure out who's responsible
for the program and you know, assigned budget responsibility. Okay,
what's the second thing you do? You take asset inventory.
You've got to understand what you're protecting. So yeah, this
this all makes sense that you need the inventory and
in the modern world you need automation. There's no way
you can do this anymore manually. So you know, my
thanks to to Brian we Go and you know, learn
something here.
Speaker 2: Yes, our thanks to Brian and Andrews always thank you
for speaking with me.
Speaker 3: It's always a pleasure. Thank you, Nan.
Speaker 2: This has been the Industrial Security podcast from Waterfall. Thanks
to everyone out there and listening.