I can give you a list of vulnerabilities and you'd think that great. I
now know what my risk is. But the reality and ot is it's not
always directly applicable. That's a single external indicator. Welcome everyone to the Industrial
Security Podcast. My name is Nate Nelson. I'm here as usual with Andrew
Ginter, the vice president of Industrial Security at Waterfall Security Solutions. He's going
to introduce the subject and guests of our show today. Andrew, how are
you. I'm very well, Thank you, Nate. Our guest today is
Rick kN He is the vice president of solutions at Verve Industrial Protection. And
we're going to be talking about context for risk. We're going to be talking
about patching. We're gonna be talking about automation to help us figure out when
something is worth patching, when a vulnerability is worth patching, and you know
when we should probably let it ride. All right, then, without further
ado, here is the interview. Hello, Rick, and thank you for
joining us. Before we get started, could you say a few words about
yourself in your background and about the good work that you're doing at verb Industrial
Yes, thank you, Andrew, and to appreciate the opportunity to share with
you today and discuss. It's always a great time chatting with you as plugged
in as you are, It's always a great discussion. My name is Rickon.
I'm the VP of solutions for Verb Industrial Protection. We're a vendor neutral,
multi function shop that provides both software and services exclusively to the OT space.
We've been around for thirty years, actually privately funded, self grown,
organically grown. I personally have been in the OT business for twenty two years.
I started at a company called Majorcon building the ICs or industrial control security
consulting space. We then get picked up by a company called Honeywell, where
I was a global business development for them for a few years before coming back
to a vendernutual perspective where I am now and again appreciate the opportunity today.
Thanks for that. Our topic today is risk in context. Can you tell
us you know what is that? And you may maybe give us an example
or two. Yeah, this is the gist of what I want to talk
about today. We can be lots of lots of unpack here. The problem
that I'm seeing more and more organization not just me, that we as a
company in our industry took clients and their peers are all starting to realize is
that the traditional IT approach, where you have very cool tools, individual special
tools, and especially people, is interesting. But it's a singular point of
perspective. Right, So I can give you a list of vulnerabilities and you'd
think that great, I now know what my risk is. But the reality
and ot is it's not always directly applicable. That's a single external indicator.
It doesn't include anything to do with whether that's a big deal for you the
owner operator, or on its particular asset or in a particular facility. And
so what we're seeing is that people are needing more and more context. And
this is especially too true on a couple of fronts. Number one, we
don't have enough staff to address all the vulnerabilities. I mean, we turned
on our vulnerability mapping at a midstream gas company the other day and literally at
their flagship site was twenty three thousand vulnerabilities. And you're never going to get
that to zero. And you're not sure even where you should probably start unless
you have some sort of context. So a singular view isn't good enough.
And it's actually something we've been struggling with for many years. I remember about
ten years ago going into an air separation unit and the plant managers, you're
going to do an assessment, and you're going to tell me that they don't
change passwords and they don't patch. How the heck does that help me?
And so on the front of being able to take those scarce resources and focus
them on the things we need to either the lack of staff, the lack
of time, the ability to look at what truly is effective for OT,
which isn't always everything because and everything can't be Windows eleven and patched every Tuesday,
but also the nature of OT and that we can't do Plan A I
either patching necessarily, we need to do Plan B and C and B are
compensating controls or as some interestingly creative marketing people have started to call virtual patching.
If we can't apply blue keep, can we at least disable remote desktop
or the guest account. Well, I don't know the answer to that unless
I know what that system does and what function it provides operations. So the
gist of this is any singular indicator of risk i e. An external penetration,
denial of service attempt, or a list of vulnerabilities, or a patching
tool in and of itself is not enough to provide, you know, our
audience the detail that they need to be able to act appropriately and effectively inefficialty.
Andrew, the way that he's talking there, it reminds me vaguely of
an episode that we did some time ago with a guest who was talking about
like site specific vulnerability that that you can't categorize or that you shouldn't rather categorize
vulnerabilities in a broader sense that he was looking into specific sites and specific industries
and evaluating how they affected those specific plants. And it was sort of a
different alternative to the usual CV kind of way of doing things. Can you
remind me what the name of the guest was there? Yeah, that was
Thomas Schmidt from the BSI, which is the German Office for Information Security,
and he was talking about SSVC, so stakeholder specific vulnerability categorization. This was
a new standard, This was six months ago, a new standard to make
decisions about whether to apply patches for vulnerabilities. And you know, ver Verb
Industrial Protection is one of the vendors in the space. They have automation for
SSBC. And and Rick is going to say more, you know, much
more about that in just a moment. So, I mean I agree with
all that in principle, Um, you know, but it's sort of what's
the right word. These are great principles. But if I have you know,
thirty sites, each of them has you know, six hundred PLCs and
who knows what other kinds of you know, industrial internet, and you know
everything has a CPU nowadays. Um, you know, it's great to say
I can make risk based decisions like that. It's another thing to say,
do I actually understand all of my tens of thousands of devices and which of
them I should manage? How? How can you you know there is there
is there a way to get insight? Is the way to get automation instead
of saying, you know, evaluate every one of my fifty thousand nows that's
myself. Yeah, no, great question. And and you know you're right
like when I talk about the risk index or and it's an individual measure as
not being enough. I mean you look at you look at the NVD score
and it's it's got a ranking, and it's got why it got to that
ranking. There's there's components in there. But you've raised the other point is
how do I take that and scale it both in volume, but also there
are, as you know, nuances within those sixty sites or thirty sites in
the feel sees. Some of them do critical safety things, some of them
do other things. And so as soon as you start to unpack this a
bit, you realize that you need a great level of detail from multiple perspectives.
Um, so let me let me just sort of walk through how we
help clients to build that perspective and what we call a three dimensional you of
the asset. And so the first and foremost is going to the source.
There absolutely has to be an inventory. So you remember our last podcast,
we talked about building a proper inventory, and it never more Now more than
ever, it's the most important thing we're seeing that people are starting to realize
is you need to go directly to the asset. The first source of data
in building this bigger picture view to be able to provide context beyond a single
measure is to pull in multiple measures of the asset. And so the first
source is the asset itself. Can we figure out what it is, Windows,
Linux, Unix, networking gear, PLCs, relays, controllers, what
the manufacturer is, whatever we can glean from that endpoint the more data we
can get from that, the more equipped we are to pivot to different scenarios
and situations in ascertaining and actually measuring risk for our organization. That's the first
bit of data. The second bit of data once you've built that information,
and by the way, we advocate for a direct approach, going right onto
the OS and getting right directly to the plc's not going to intermediary databases or
relying on what I'm hearing through traffic. I want to go to the source.
I want to get answered the questions I need to know, not hope
that I hear them or hope that I'm listening to all of the devices.
So we get all that data we automated into a central database. At that
central database is where we invest to gather and collect and aggregate all the other
data sources that are available to these operators. The very first one is really
quite simple. We take that database once we've built it, and we work
with operations to say, let's put operational impact or user define tags on these
assets. Right, So a tri conics a refinery, clearly a safety system
that's a high impact asset. It gets a high impact label because when we
go to look at risk, whether that's assessing if it exists and is important
to us, or whether we want to turn to remediation tasks like patching or
compensating controls. We can and decide which ones we test on by either redundant
to safety one or not the safety ones but the redundant is not so impactful
ones, or which ones we need to prioritize in terms of budgets and resources,
etc. So we start with the inventory automatically from the endpoint, we
then add user define tags and information about it. We can calculate and for
these from the vendor name or from the subnet they're in or whatever. But
we usually like to make sure we loot the plant people in the tribal knowledge
that those veterans have on the plant floor is invaluable, very very powerful.
So two different data sources starting to build multiple dimensions on the asset. And
then the third thing we'll do is we'll go and get third party indicators.
And this is where we get to the National Vulnerability Database. We'll bring the
list of vulnerabilities in and we can map them one to one at the database
offline from the actual operational environment. So we're very frequently and very thoroughly mapping
vulnerabilities against that very detailed inventory. We can also bring in threat feeds and
known exploits, so we're going beyond by the way, You've got a vulnerability
and there's exploits out there for it, right that may increase or decrease your
urgency. And then the third thing we bring in, of course, is
the first line of defense, the patches that may be available for those devices.
So we start with the endpoint data first, the tribal knowledge around the
importance or impact a roll of those devices. Second, third party indicators of
risk in patch, threat feeds, and vulnerability data. And then the fourth
thing will do in that middle layer database that we are compiling all these different
dimensions of the asset about, we will go east and west and connect to
basic building blocks for security tools like the status of your backup or your antivirus,
and in multi vendor environments, the ability to abstract connecting into semantic versus
McAfee versus defender to see if your antivirus is up to data your white listings
in lockdown, to aggregate that into a central view is where the real magic
comes. Now, how we do this to your point in the scenario of
thirty sites is we then cascade any single site or database to a single reporting
dashboard. The reporting dashboard is a it's a singular view into the entire fleet,
and it's a read only view. So what we can do then is
we have all these different data sources consistently from all of our facilities and across
all of our assets. We've got multiple dimensions of potential risk, but not
just the risk, but the assets impact in compensating controls that may mitigate risk
or narrow down the concern. And we can see this with a small specialized
team fleetwide. This allows for an organization to build a standard response, a
standard threshold if you will, for various risks and activities that they need to
act on, and they can then start to remediate with this same technology where
it's ot safe. And we can do this in stages. UM. But
let's let's circle back there on that one. This is this is how we
want to build the context in the first place, UM, and we want
to aggregate it across multiple sites and now give all the power to a very
specialized team uh and and let them start to see what they're looking at all.
Right, So So that's I mean, that's a lot of data.
You know, It's it's useful to have that database. It's it's useful to
capture tribal knowledge. But still, if we have thousands of assets and you
know, even more data about each of the assets in a database, that's
just more information for you know, my poor, my poor brain to it
to to you know, try and suck in and and make informed risk decisions.
Is you know, is there is there a way to uh, to
work with the data once you have Yeah, No, that's an absolutely spot
on observation. I mean, talked about twenty three thousand vulnerabilities, and now
I added three other dimensions in those twenty three thousands. So what do we
do with that great question? Um, the most powerful thing that we're doing,
and you can actually do multiple things with it, but the most powerful
thing you can do with it is to calculate an actual what we call a
residual risk score. So if you were to take those different indicators, and
we do this with the clients and it's automatically done in the software to then
report on the dashboard. But the premise behind it is we build indicators of
risk and we build scores for things we don't like, and it's just like
my golf game. It gets really big and huge and ugly real quick.
So, for example, if devices consider a high impact, it gets the
score of ten. If it's considered lowan impact, it gets a five.
Tribal knowledge now has a score. If it has a critical vulnerability, it
gets seven points. For every critical vulnerability, it may have multiples if the
backup has failed. Right, So all these different data sources can be pulled
into a calculation and a score appended to them, and then the true what
we call residual risk after we've accounted for compensating controls, like the backup is
good and white listing is in lockdown, so the score comes off, we
can build an actual risk score that is ot or end user specific, and
then those scores can be put into thresholds which then drive governance around behavior.
So something that's considered a critical risk, maybe as an order we decide has
to be dealt with within twenty four hours, whereas something with a low risk
can be calculated to do something within a week or a month. And because
it's automatically updating the data and calculating, you are now always looking at a
live score, so you extract from the noise the stuff that is a five
alarm or firepeat have to deal with. Does everybody have their own scoring system?
I mean, we've been talking about SSPC, their CV. Now there's
this. I wonder whether all these different systems get confusing after a certain while.
I think the short answer is yes. The long answers in a sense,
this is why, in my understanding, SSBC was invented. It's because
the vendors in the space do all they you know, they did all have
their own system, and you know, the the users, the governments especially,
said you know, here are some minimum criteria that you should be using
for these risk decisions. You may be able to get sort of find a
grain decisions by doing you know, more analysis of the of the risk and
the context. But you know, here here's a minimum, and so they
put SSBC together. And of course, you know, why would the vendors
do not just SSBC and be done with it. It's I mean, I
worked, I've worked for vendors most of my career. One of the ways
vendors distinguish each other from each other is the feature sets in their product.
So you know, every vendor out there wants to say, yes, of
course we do SSBC, and we give you even more power because we do
X, Y and Z in addition. So yeah, it's not surprising that
everyone does it differently. This is part of why SSBC exists. In the
beginning of the Industrial city Revolution, engineers were told to use it security principles,
protect the information. We were told. We knew this was a poor
fit, but it was all we had. Today, the top security priority
at industrial sites is safety. Don't kill anyone, don't cause an environmental disaster.
And the second priority is reliability. Do not shut down our factory or
infrastructure. Today, safe and reliable operations use unhackable protections from cyber risks,
not just cybersecurity. For a deeper look at the evolution of the revolution,
we invite you to download Waterfall's report on the Emerging Consensus for Industrial Security Engineering.
You can access the report at the Waterfall website Waterfall dash Security dot com,
slash Engineering dash Consensus, or just go to the resources menu and click
on white papers and ebooks. So, just to clarify, um, these
these sort of characteristics, you know, did the backup work, you know,
what's the what's the impact of are these in a sense preprogrammed that that
users then populate or are they sort of user defined? Can the users to
find the calculation or sorry, the uh the characteristics? And you know if
if the characteristics I used to find out, I would assume the calculation has
to be user to find. How how you know? How? What's the
right word customized? Is this to every site? The calculation itself is something
that we ship with a basic sort of structure. If an organization wants to
change how it's calculated, or emphasize or de emphasize certain indicators one or the
other, they can. The precursor to that question, though, was the
user defined properties. User defined properties are usually set once, ie it's a
high impact asset to operations or it's an inconsequential asset operations UM and those don't
typically change. What does change, and therefore we automate is the presence of
vulnerabilities or the version of the software or the level of the patching. So
where we can automate technical gathering and technical data we do where we need user
to find, we usually establish that upfront. It doesn't typically change. I
mean, it's triconics, is the triconics, it's safety and safety. It
doesn't suddenly stop being something um And so we have a combination of sort of
set up the automation, set up the tags, and then the actual how
you want to calculate is absolutely customizeable, as are the labels up front.
I mean, if we think it's a high impact asset, the client disagrees
it's there, it's their database, it's their threshold, they can they can
customize it. So that makes sense. I mean, you know you've got
automation, you've got a calculation. You can see in your words where the
five alarm fires are. What do you do about those fires? Are we
talking you know, patch everything? Are we talking throw some more firewalls rules
in there? And and you know if you make those changes, what change
do you see in your system? How does can you give us an example
how this works? Yeah? Absolutely, And that's the natural following And as
you said in the intro, you can't always patch. You need to be
able to be creative. So this is where we sort of double down on
the value of that multidimensional view. So I've got to risk my risk score
is automatically calculated. I've got a bunch of really you know, sort of
heavy hitters that look like they're high risk and they need to act upon them.
And so now what I do is I go into those individual assets and
I look at the components that have added to what the problem is. It's
a vulnerability, there's a patch available for it, it's not been applied.
Well, that's your first that's your first path. We want to look at
that patch. Can we deploy that patch again? With our architecture, we
can then do a very safe OT stage sort of approach to the first pass
of potentially patching. We will patch you know, we're done that systems,
domain controller, spile servers and will bake in a certain version like twenty twelve,
make sure it works, and then potentially pass that on to the HIMIS
and engineering station. So we can do a very staged, methodical OT approach.
If we can't do the patch, though, we can then look at
our systems and say, well, what is the risk of this. And
one example we had with a client was blue Keep came out and they couldn't
patch for blue Keep on some other systems. But they didn't want to just
live with a risk. So the next thing they did was they said,
well, what's wrong with blue Keep? And so what they did then was
it well, it mostly attacks you know, the guest account remote desktop.
Well, their twenty four seven staff d hmi's probably didn't need remote desktop enabled
and they certainly didn't need the guest account. So then we use the technology
to start to disable remote destop and the guest account again in a very staged
approach. Now, if you build it properly in the thirty sites scenario that
you've shared with us, you can do this again from a central team that's
queues this up, tease it up for the endpoint, and can involve the
people at the plants to be able to go ahead and be involved in So
it's not a big brother push, but it creates very very precise or precision
in deciding what to do and where to do it and going beyond patching to
compensating controls. And there's two things in there that we may want to dig
deeper into and let you know if you which way you want to go.
There is you know, more examples of things you can do beyond patching,
but there's also the efficiencies gained by the way that this is architected. Perhaps
this is my naivete but coming from more of an IT background. I'm not
quite sure why a lot of the nuance in this discussion ends up factoring into
patching. UM. Generally, I've always thought about patching as something that you
should do as soon as possible, whenever the option is available. But here
we're talking about criticality and severity and all of these factors that seem to suggest
that you wouldn't otherwise patch an ever given scenario. So why is that?
I think it's it's easiest to answer with some examples. On your average you
know IT network. You know, let's let's leave the sort of leave the
specialized IT networks out of it, the banking systems and the even the SAP
servers, the ones that are handling payroll. Let's leave sort of that critical
systems out there. You're you're just your desktop network. You've got a bunch
of desktop machines. Um. They are reaching out to the internet every five
minutes to fetch email, to send email, to browse the internet to download
stuff. They're really very exposed, um, And in a sense, they're
all the same, They're all have the same level of exposure. So yeah,
you use the severity, and if it's a severity nine, you patch
it automatically, and there's there's not that much decision making going on on your
that that kind of it network kind of everyone's most familiar with UM. But
you know, on the on the back end here, safety systems are the
ones that prevent unsafe conditions from killing people, you know, over pressure conditions
on boilers from blowing up and killing people, over temperature conditions from you know,
causing explosions or fires. UM. And so let's say there's a vulnerability
that let's uh, somebody crash the machine, you send a message the magic
send the magic message to the machine, and the machine crashes and reboots and
it's down for you know, thirty seconds or five minutes, depends how long
it takes to reboot. How important is that on the main part of the
control system, It's fairly important. You're probably going to take the plant down.
It's it's a reliability threat. How important is that on your safety system.
Well, if your safety system is down for five minutes, human life
is at risk for those five minutes, and so the safety system is more
critical than the rest of the plant systems. Arguably, you know, even
if a you know, cause the machine to reboot, vulnerability is not as
bad as our execute arbitrary code and do nasty stuff. It's still on the
safety systems. It's they're that critical that you should be patching these lower,
lower priority vulnerabilities on the safety systems. On the other hand, if your
safety systems, and you know many of them are air gapped, you cannot
send them a message from any other machine, well, then that vulnerability really
isn't exposed on them, is it. And so you might say, yes,
normally I would patch it. But because you know these safety systems versus
those over there that are exposed, these ones are air gapped, I don't
need to patch these ones as urgently as I do those ones over there that
are on the network. So this is an example of where context drives the
decision of a given vulnerability that you might patch in some circumstances and not others.
I guess my question is, let's say I don't know I put a
firewall rule in, or I don't know I install whitelisting or something, I
take some other measure. What do I see in the system, How does
how does the system does it? You know, does it notice that I've
done this? And recalculate how you know how does this It's it's great that
the system tells me, hey, look I'm in trouble, but does it
come back and say you're not in trouble anymore? Good job? Or you
know how how does that work? You're right, the basic premise is in
that scenario, I'm going to look at something and my score, and you're
right, I overlooked some of the more simple sort of approach. Potentially the
risk score says that I have a high risk and when I dig in there's
a patch needed and maybe I can do a compensating control. Or maybe the
risk is because the backup or part of the risk score is because whitelisting isn't
currently in lockdown or not installed on the device, or the backup failed last
night, or you know, we got this porch or service that really just
need to disable and I can't do any with it. So to your point,
let's install a firewall or inline in a network access control type of thing,
or we can go rerun the backup, or we can enable and install
whitelisting. And to your question, because of the name ure of the way
we collected data, we're continually connecting to the end points, We're continually remapping
vulnerabilities, and we're continually connecting to antivirus and backup databases. You are correct.
Once I make those changes, rerun the backup and solid white listing,
configure the registry, that will then show up in my dashboard and I will
see a reduction in risk. I will see less devices in that higher or
critical category. I will see a trend over time that I had a whole
bunch of five alarm players and now I'm down to a couple. Then,
and you can actually see the improvement. And that's exactly what the dashboard is
for, is to give you that mere real time view into the current status,
which includes improvements as you do these things at recalculations, but it also
includes obstacles or challenges as new vulnerabilities or threats are included, because that's also
injected. So it's a continually moving and evolving line. It's just like looking
at at a trend line in an operational facility when you're making power or oil.
You're doing better, and you see the productivity go up and the tank
fill up and something goes wrong, you see it dropped down. The exact
same sort of scenario I was thinking about. An example you gave a little
while ago, you know, the remote desktop example, and the vulnerability that
you know, let's say, in remote desktop. I'm wondering your is your
system clever enough to say, hey, the vulnerability is in remote desktop,
and look they disabled the remote desktop on these devices. Therefore it automatically reduces
the risk. Is that how it works? Yeah, to an extent.
I mean, in in the scenario you just gave, there's a couple of
different indicators that would reduce the risk score. And those which are automatically gathered,
like the white listing status is now in lockdown or the backup is now
a success as opposed to a fail that's automatically gathered automatically updated. No problem.
When you get to the more creative ot needs around compensating controls like disabling
remote desktop, we would once we had done that, confirmed that it was
complete on however many assets we did it for, and then we would set
a flag in the software to then not show those systems as still being vulnerable
to that particularly vulnerability because the first pass of mapping the vulnerabilities, and as
a patchelor would say, no, but we know we've applied compensating controls.
So when I show the resulting dashboard to an OT practitioner, they see their
true risk, not again a false positive in that here's all these vulnerabilities because
we know we've got those those extra controls. And again that's just just another
reinforcement for why you'd want to have multiple indicators, not just the vulnerability,
but vulnerability plus how is it configured. Well, now we've got a different
answer. We've got the true answer. I wanted to come back. You
said there was another another topic. I think it was scaling. You know
how you use these numbers. Yeah, no, it's this is the really
powerful part. Right. So the architecture that we instill, and we touch
upon a little bit earlier, but the architecture that we instill means that you
can bring in multiple facilities and all of your assets into a single view,
which means you can have one small specialized team look at the fleet on behalf
of the whole organization. You don't have individual sites having to dig in and
the security experts and figure out what to do about this patch or that risk.
And then with that technology, you can then start to queue up activities.
And I wanted to circle back to this especially because OT always gets really
scared and you think some central it guy is going to do something. I
get it instead. I've been doing this for twenty years. I've seen a
wrench in a firewall in the field, through the physical hardware, through the
chassis. So let me just walk you through through a quick case study.
We have a Generation client that wanted to update a particular piece of software.
In fact, they wanted to uninstall the software. They were afraid of it's
origins and the risk that we're associated with it. And I'm not going to
name anybody, but we all know that there's been a number of companies that
have fallen on the foul side of many people's favor. And so there they
are in a Saturday afternoon. They've got six generation coal fire generation, very
complex environments, and they're needing to remove this piece of software and they're not
sure how they're going to do it. There's a deadline. So what they
do is they can go to the dashboard and in the software and they can
see there's one hundred and forty six copies of software I spread across these six
sites. The central team is able to then initiate a request to uninstall the
software. I say request because while I've said earlier we can make things like
registry changes automatically, we don't always want to be messing in the OT space.
Going to be very respectful and usually uninstall the software requires a reboot,
So we send request to one hundred and forty six systems to unstall the software.
We send a detailed list to each site of exactly which physical room and
wreck this device is in, and when they get to the console they will
see a flashing light saying would you like to accept this action? They are
then able to phone the operator in the control room. They are then able
to follow their own local change process. They're able to uninstall the software,
bring it back on line, and move to the next one and this particular
client. Anyone who's listening this knows that this sort of activity, removing one
hundred fifty copies of software from six locations would take probably weeks or even maybe
a couple of months in a lapse. Not expended time, but just hunting
and searching and finding the time. This activity was completed with a support person
of one at the central and one individual each of the six sites in and
around their day job. It was completed in ninety minutes and because of the
update mechanism, we could see that in the software dashboard updating as they went
around the flight. So this allows we have a client with seven hundred facilities
and a team of eight managing worldwide around the clock. So this is the
future to me of where VERVE sorry, where OT security is going and how
VERVE is helping their clients to do it is there's not enough people and we
need to start doing things. And so if we can combine context ability to
act and OT safe, we start to really move the needle. So that's
that's powerful automation is good automation on the security side. You know, I've
been thinking about this interview though, and I know there are standards bodies,
there are governments out there, There's a lot of debate going on saying what
are the right met tricks? How do you measure risk in in the OT
world? Um? You know, I see people out there saying, well,
you know, um, be careful how you measure risk? Uh?
You know, if if your risk just keeps going up, your your board
is going to be asking you why why they're spending money on security? If
risk keeps going up? If you know some people are saying use use measures,
like how many of the top twenty controls have I implemented? Uh,
you know, well, when you get to one hundred percent, you're done
Again. The question becomes, you know, why am I spending money on
this? The whole question of how do you measure risk seems hard? Yet
you have a dashboard, you are it seems to me you are measuring risk.
Can you talk about about metrics and the value of metrics and you know
how your how your your stakeholders, your customers respond to being able to see
sort of a number that moves around in a predictable way reflecting risk. Yeah,
and that's one of the things we haven't talked about yet, is is
the value of this insight. It goes from if you remember the example earlier,
the plant manager who told me you're doing an assessment night, I already
know I don't patch and I don't change passwords. How does that help me?
That's the answer to this is once you have this data and you have
the context, you can have empirical discussions about trends and you're right, you
know, the risk doesn't always go up, the risk does go down,
and so you can measure risk with what we primarily focus on today, which
is pure risk in terms of vulnerabilities on assets and the impact of that asset.
But once you go up a level, you can start to measure well,
I need to act in this behavior at this facility. But guess what
this flagship facility over here that either makes us more money or is more potentially
catastrophic if it goes wrong gets a different level of scrutiny and of support or
funding. And it's all empirically driven now. And you mentioned some of the
regulatory standards. Outside of the pure risk score, we are getting more and
more calls and more and more, more more engagements to be helping clients to
track and monitor compliance. And are we doing enough? Are we showing the
auditors, are we showing the board, are we showing senior management? Are
we using the money wisely? And are we making trends go in the right
direction? Things like the CIS controls. We have a dashboard that shows here's
your hardware inventory, here's your software, here's your configuration, here's your users,
and you can look at it as a glance and show the CIO,
look we're doing the right things, or look we're going the wrong way.
We need more help. And the most recent when they're quite proud of,
is actually that the federal government announced a CDM Continuous Diagnostics and Monitoring that all
federal entities shall be reporting on. We've actually been approved as the ot response
for that. So we're not only doing this internally within an organization or with
an organization towards helping them comply, but now we're also starting to share with
external and federal sort of entities to really consume this data. It's really starting
to catch on. Let me dive into this just a little bit. Visualizing
risk is you know, a Measuring risk is a is a big debate in
the industry. I gave you some examples in my question, but I don't
know if I don't know if my question made sense now that I listened to
it again, Rick obviously got it. But let me go through it once
more. Let's say you know there are people who out there saying, you
know, risk should reflect you know, what's what's happening in the world.
Well, there's always new vulnerabilities, thousands and thousands of vulnerabilities being reported every
every year. If you count them, your risk indicators going up, Your
chart keeps going up. Qualitatively, we get we get word that, you
know, the sophistication of the adversary is going up. They're using more and
more powerful tools. They're using more and more powerful techniques. Again, the
risk line keeps going up. If you show the board a risk line that
goes up steadily. They asked the question, why are we spending money on
you? You don't seem to be having any effect, so you can't show
them that risk line. You know, I've had I've had people tell me
what you should do is use something like the top twenty controls and say,
my goal is to get the top twenty controls implemented on every machine in my
network. So I see a risk, you know, I see a mitigation
line going up. But eventually, you know, saying I'm getting better and
better. Eventually I'm going to hit my twenty and I flatline. And again
the board goes your security the strength of your security poster seems to a flatline.
Why are we spending money on this? Again? Have you not solved
this problem? Can we start spending less money on this? And of course
you know you can't. That's that's the wrong measure as well. But what
ricks had described here. You know their dashboard. Imagine what the dashboard looks
like. New vulnerabilities are discovered in the world, and we do the risk
calculation, and some of them are relevant to our most critical systems, and
our calculation of risk goes up. You see the trend line going up,
and the OT security team springs into action, you know, presses the button,
figures out which machines most originally need to be patched, patches those machines
or applies compensating measures to protect those machines, and the risk line goes down,
saying good, good job, You've you've reduced your risk. And then
of course there's more vulnerabilities over time, the rescise going up and down.
You can see progress. You can see that the money you're spending is you
know, in the absence of spending money, the risk would go up unboundedly,
and you're spending the money and so it keeps coming down. You can
see, you know that something good is happening. This is a step up
from you know, waving your hands at the board. Um, it's still
a qualitative metric. I mean, in the engineering space, you might be
used to calculating like safety risk mathematically, you've got a you know, one
in a million chance of a death at the facility. You know in the
next year. You don't have that kind of mathematical precision, but at least
you've got something, and it's something visual and it's something that in a in
a real sense makes sense. So you know, I think this is a
step in the right direction. Risk is a dry topic. Um. A
lot of people, you know, I speak at conferences. If you know,
I've proposed, uh, you know, many presentations with risk in the
title. Most of them don't get accepted. If I get accepted, nobody
shows up because it's you know, people see it as as academic, as
as not actionable. But you know, metrics people are interested in, you
know, and concrete advice as to where you know the highest value investment.
Next is that's huge? So, UM, you know, thank you for
for for joining us. You know, these are to me, these are
are very positive developments in the in the field of the technology. Um.
Before we let you go, Uh, you know, did you want to
sum up for us? Is there are there words of wisdom you have for
us? Uh? Well, the things that I think are important, whether
the wise or not. Let the audience judge. But you know, I've
been in this business, as I mentioned the top of the the call,
for twenty two years, and I've seen a lot of attempts at you know,
the silver bullet, and you know it was white listing in oh nine,
and it's it's other promises since then, and even some notable public speakers
saying, well, we can't patch, why bother, let's just give up
and hunker down. But the reality is that this can happen. We just
need to be prepared to roll our sleeves up and get at it. Why
we've been avoiding addressing the technical and security that we continue to amass and compile
over adding more technologies and IoT and then being surprised at how much risk there
is is it's a bit baffling to me. You've been on the circuit as
long or longer than I have, Andrew, and you know that some of
the things we say, we've been saying for twenty years, and still people
nod their head and write it down as its stage advice. Right. So
I think that we're seeing a turn that people are embracing the fact that yeah,
I really do need to get into it. I really do need the
data because I need to make conformed decisions. There's only so many people,
so many dollars, and there's so much risk. I need to be I
need to be creative, I need to be precise, and I need to
be effective. And so I'm quite excited at what we're seeing, and I
would I would hardly recommend that you dig into how you actually get to those
end points, because that's where the data resides, it's where the risk resides,
and that's where the solution ultimately resides as well. And if you do
want to dig deeper, you know, we have always taken these case studies,
user testimonials, public presentations of how some of these things are from from
the end users, not from us our resource page. We just recently published
a couple of new white papers on exactly these types of topics, but also
again some of the use cases that actual frontline industry pairs of yours speaking to
the audience here that are doing this and realizing the benefits. We have some
that are accelerating five year programs down into two and a half to three years,
and I think there's some real valuable insights from people frontline, you know,
not the talking heads like me and Andrew, and you really probably should
dig into that. And you can also probably sign up for a webinar two
while you're there, because we do those every months as well. So I
hope this helps, and please do dig into the educational content we have up
there, and if anybody's curious, please feel free to reach out. Andrew.
That was your interview with Rick Kahn. Do you have any final thoughts
to take us out with today? I was really encouraged by the episode.
I mean, um, you know, this is automation. This is automation
for security. You know, it's it's a truism that our enemies attacks are
getting more sophisticated because they're automating their attacks, because our enemies are using more
and more sophisticated automation. Here is automation for our defenses. Uh, here
is a way to you know, this kind of automation. Can can you
know, take a lap a lot of time off of the analysis part of
our defenses, off of the the implementation part of our defenses. You know,
automating the defenses, you know, sounds extremely useful. You know,
this sounds like a very effective kind of automation. So you know, I
see this as good news, as a very positive development. Okay, well
then, thanks to Rick for enlighten us today, and thank you Andrew for
speaking with me. It's always a pleasure. Thank you, Nate. This
has been the Industrial Security Podcast from Waterfall. Thanks to everybody out there listening