Speaker 1: Lots of people have different data sets. They have done
some investment in y security, but they're all struggling to
identify what's the logical next step in that journey.
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, who's going to
introduce the subject and guest of our show today. Andrew,
how's it going.
Speaker 3: I'm very well thanking it. Our guest today is Vivek Panada.
You might remember him from an episode a little while ago.
He was the co lead on the top twenty Secure
PLC coding Practices document that came out a year ago
two years ago. Today, he's the senior vice president of
Growth and Strategy at Frenos and our topic is digital
twins for Managing Risk. And it sounds like a bunch
of marketing uh buzzwords, you know, digital twins managing risk,
but they've got some real technology behind this, so I'm
looking forward to this.
Speaker 2: Then, without further Ado, here's you with FIVEC.
Speaker 3: Hello Vivek, and welcome to the show. Before we get started,
can I ask you to say a few words about
yourself for our listeners and about the good work that
you're doing at Frenos.
Speaker 1: Sure, thanks Andrew. Hey everyone, my name is Vivik Ponada.
I am the SVP of Guden Strategy at Frenos. I've
been in the OT security space for quite some time.
Back in the day, I was a guest serve and
controls engineer for GE. Then I became a controls and
cybersecurity solutions upgrade sales manager for them. Initially covered power
and utilities and then of course added oil and gas.
I'm based in Houston, so that was a natural thing.
I uh. Before joining Friendo's worked at Tanozomi Networks as
the reginal sales director for three years. So I've been
in the OT security space for ques time and I
am happy to be on this podcast. And at Frenos
we're doing something cool. We're doing an attack path analysis
and risk assessment at scale, bringing autonomous risk assessments to
a space that's been lacking this kind of approach. So
you're looking forward to our conversation discussing more about that.
Speaker 3: Our topic today is risk, which a lot of people
find boring. I mean, people new to the field tend
to want to focus on attas attacks are interesting, attacks
are technical. You know, it's not until they have failed
to secure funding as a manager of you know, the
security team for the last ten years that they start
being interested in risk, which is the language and the
decision making of business. We're going to talk about risk.
You're talking about you know, we're going to talk about
digital twins, which is a real buzzword nowadays. But you
know this is our topic. And you've mentioned, you know,
risk assessments, you've made intioned attack path analysis. You know,
I'll approach to looking into all of this. You know,
to me, risk is fascinating. It's how we make progress.
It's how we shake the money loose. But you know,
before we start, can we can we before we dig
into it? Can we start at the beginning? What is
the problem the risk problem that you know we're trying
to address here?
Speaker 1: Yeah, great question, Andrew. The past ten plus years in
OT security has been let's find out what we have right,
So lots of people started figuring out that they need
asset inventory solutions. So the likes of Drago's Nozomi Clarity
have been the forefront of that kind of an approach
to necross security monitoring leading to passive asset discovery involved
the identification. So now ten plus years into this, people
have a lot of data sets. They have several sites,
especially the ones that they were considered important to their production.
They've install sensors, they have lots of information. Now they're
asking what next, right, the real use case is risk
identification and risk mitigation, as you mentioned, But there's a struggle.
We will struggle out there with different data sets, not
able to figure out what the actual risk is for
them to address next. So that's the problem trying to solve.
We are trying to aggregate information, provide contextual analysis of
what's their riskiest path to a crown jewel or what
might be the logical way to isolate and segment because
not every risk can be mitigated by just patching a
vulnerability for whatever reason. That's the main problem. So the
conclusion is that lots of people have different data sets,
they have done some investment in notty security, but they're
all struggling to identify what you do with that information
or what's the logical next step in their journey.
Speaker 3: It's one thing to sketch this is what you know
thens cybersecurity framework says a complete security program should look like.
It's another thing to say, I've only got so much
budget this year and you know, a comparable amount hopefully
next year. What do I do this year? What do
I do next year? What's sort of most important to
do first? That's that's a really important question. How does
a person figure that out?
Speaker 1: What?
Speaker 3: What's the decision pass there?
Speaker 1: Yeah, that's the real question. Lots of people in the
past used to say over isolated, or we are segmented.
You know, we're we have a DMZIN, I T n OT.
A lot of these assumptions have not been validated in
other cases where they have different data sets, it's not
very clear what the what the next problem that they
could solve is, right, So, everybody, like you said, has
limited budget or resources. So the honest question is, hey,
where we should focus next. It's not very clear. People
have done linear projects, right, They'll pick a firewall project
or a segmentation project or a volumetity management program, and
all these are are good, but overall not fixing the
immediate problem or not solving the immediate problem first. Right.
So the commonly requested feature of many of these tools,
like Drego's Nazumi or other vendors has been hey, can
you please tell me what my riskiest asset is or
what my riskiest path is and they have not been
able to do it because that's not in there in
their current portfolio. Is that contextual summarization? Right? So let's
say you have an asset at the Purdue model level
two for example, that is talking to another asset at
level three, and then there's a DMC about that with
some kind of firewall rules isolating it. And if someone
has a real world knowledge of this network, and that's
what we are talking about, right, a digital twin that's
kind of replicating that network, and you analyze if that
firewall rule and if that path is possible not to
get delivered two or you know, maybe they have other
composite controls in that path allowing them to say, yep,
my level to is secure this network, this location is
not reachable easily or it takes a lot of complicated
daisy stating of attacks to get to. Then that would
be an identification of what the what the risk is
and if you need to address something. So the common
consensus has been one, of course, you can really assess
these in real time in the production environment. Right, So
you need to build something that's a replica of that network,
and then you analyze all these scenarios to see if
that asset that you deem important, or that network that
you deem is is it critical for your environment is
reachable or not reachable from the outside or from any
other attack factor that you choose. Right, they assume briach
could be your corporate enterprise network, ork, could be a
wireless network, or it could be anything else that you
deem as a as an attack factor, and to assess
in this digital replica or digital twin if that acid
can be reached. So that's what in general, most people
have been asking for that's been missing in the currently
available set of tools.
Speaker 3: Vivic's answer there was a little abstract. Let me be
a little more concrete. You know, he's saying, Look, a
lot of people in the last ten years have deployed
dragossen ASOMI and lots of other you know, industrial defender
and you name it asset inventory tools. And in a
large organization, these tools come back and say you have
ten thousand, you might have fifty thousand industrial control system assets, okay,
and you know many of them are poorly patched because
they're you know, deep down in areas where you can't
it's really hard to patch them. Patching them is dangerous.
You have to test these patches, blah blah blah. So
you've got one hundred and seven thousand vulnerabilities in these
fifty odd thousand assets, Oh okay, and they're arranged into
you know, eight hundred two thousand whatever sub networks, and
the networks are all interconnected, right, So now you know
you're scratching your head going and the question is what
do I do next with my security? And you know,
one of the things the asset inventory folks have done
is they've allowed you to go through these assets, understand
what they are, and assign a criticality to them. These
are the safety instrumented systems. They're really important. Nothing touches them.
These are the protective relays. They prevent damage to equipment
and so on. And so what he's saying is you
can't just look at the list of assets and vulnerabilities
and figure out what to do next. You need a
more and so this is what he's talking about, a
digital twin that is, you know, looking at attack paths
and looking at which assets are really important and telling
you which really important to have assets have really short
and easy attack pads. That's probably what you need to
focus on next.
Speaker 2: Yeah, and I fear this is one of those things
where everybody else in the world knows something that I don't.
But like, what is a digital twin?
Speaker 3: You know, that word is a marketing buzzword and it
means whatever the marketing team wants it to mean. The
first time I heard the word was in a presentation
a few years ago at S four. The sales guy
from g got up and did a sales pitch, in
my opinion, a very smooth, a very what's the right word,
you know, cleverly scripted sales pitch, But he basically said,
a digital twin is a physical It's a it's a
computer model of a physical system. And you you know,
ge at the time had technology they probably still have
it that well. You know, let's say you've got a
chemical process. It's gonna it's got a physical emulator built in.
It can simulate the chemistry. It's got emulators built in
for all of the ge PLCs in the solution, for
all of the GEI Historian and other components. It's got
a complete simulation, and whenever the physical the measurements coming
out of the physical world they correlate against, you know,
the measurements that should be coming out based on the simulation.
Whenever there's a material discrepancy, they would say, oh, that's
potentially a cyber attack, investigate this, something has gone really
weird here, and would take all sorts of automatic action
to correct it. It was, you know, amazing in principle.
Yet I've heard dozens of other vendors use the term
digital twin to mean other things. The best definition that
I've heard is, look your cell phone, Nate, your cell
phone is a digital twin of you. What does that mean?
It's it's not probably not a biological simulation of your body,
though some apps kind of do that. They're measuring heartbeat
and whatnot. It is an enormous amount of different kinds
of information about you. Somebody who steals your cell phone
steals all that information, knows an enormous amount about you.
And so, you know, I like that definition because it's
much broader than the very specific original definition that I
heard at S four from ge. A digital twin can
be anything that is a lot of detailed information, and
so you know, I can't remember if it's on the
recording or not, but I remember asking Vivec, you know,
is your digital twin that kind of physical simulation And
he's going no, no, no, it's uh, it's a network simulation.
It's a different kind of digital twin than the physical
simulation that some people talk about. So and they use
it for different purposes. So again it's a marketing buzzword,
but it means generally speaking, a system that has a
lot of information, that uses and analyzes and you know,
does good things with a lot of information about another thing,
like my cell phone does for me. Can you talk
about you know, what you folks have, I mean, maybe
give us an example of you know, deciding what to
patch next, uh, and you know, using this this digital
twin and sort of you know, give us some insight
into into what data you have, what data you need,
and how you use that to make these decisions.
Speaker 1: Yeah, great question, Andrew. Patching has been a significantly challenging
problem to solve in OT as you're well aware, right
in it if it's vulnerable, you apply a path and
there's a little bit of downtime impact, but you know,
you run with it. In OT of course it's not
practical because the patch might not be available, an outreach
window might not be available, and of course RESK production
downtime issues to deal with. So patching has been really hard.
With what we're doing, though, it's actually highlighting what to
patch and what might be a skip for the moment. Right, So,
when we're doing this attack path analysis and we come
up with a mitigation prioritization score, and we say that, hey,
this particular network is easy to get to, the complexity
of the attack is pretty pretty low. In just one
or two hops from the enterprise network, I'm able to
get to this asset and this is vulnerable. We do
provide other options besides patching, right, We'll say maybe segmentation
or adjusting the fire wall rule might be a way
to go in some cases. But if you do decide
that patching is relevant and recommendation provides that, you'll see
that if something is not on that attack path, right,
so it might be another asset in the vicinity, but
the complexity of the attack of that to that asset
is much much higher, then you could deprioritize patching that asset.
Even if those two assets we're talking about have the
exact same vulnerability, right, So if something is on the
attack path and it's easier to execute an attack to
that asset, maybe you want to prioritize that more than
another asset that's exactly the same vulnerability, but it's not
on a critical attack path, if you will, and so
getting to it is harder, So you would want to
deprioritize that compared to the other one.
Speaker 3: All right, so you use the word reachable. Is that
loosely the same as are connected to the concept of pivoting,
where an adversary takes over an asset and you know,
a computer a PLC something and uses the compromised CPU
basically to attack other things. Pivot through a compromised device,
attack other things, and then repeat, use the newly compromised
things to attack other things. Eventually, you know, you find,
let's say, computers that have permission to go through a
firewall into a deeper network, and now you can use
that compromised computer to reach through the firewall. Is this
what reachable means reachable by a pivoting path?
Speaker 1: It certainly could be, right, So pivoting would be jumping
from one host or one asset to another, right from
one network to another. The concept of living off the
land means that you have ownership of an asset and
you're using native functionality and eventually get to another asset
from there because you have a direct connection or through
a firewall for example. Right, So reachable essentially means that
you're able to get to that asset. Now, how you
get to that asset or network? Is it because you
know a firewall rule? Has you know any any for example,
that allowed you to just get there, or in another
case you were able to use r DP or some
kind of secure remote access to get there, or in
other cases, you know maybe a USB. Right, somebody plugged
in the USB and now you have access to that asset.
So a lot of these scenarios are very much dependent
on what the end user is trying to evaluate the
risk for. So if they are, for example, heavily segmented
and their primary mediations are all segmentation and firewall roll based,
then they would want to know if those firewall rules
are working according to plant or is the last time
there was an exception that poked a hole in their
firewall and now they are allowing access from level four
to their critical networks? You know, not realizing that their
firewall has as a whole right or another case, as
they might have assumed that rDPUs disabled in this level
three device in this workstation, but it is actually enabled.
And so now suddenly someone from outside of their enterprise
network is able to get to that level three and
now once you're there, they could do a lot more
right for the exploration. So reachable essentially means that you're
able to get to a network that's of interest from
another area. That's your starting point.
Speaker 3: I remember a couple of episodes a year and a
half two years ago Robin Berthier was on from Network Perception.
He was doing it sounded like a bunch of similar stuff.
He wasn't, you know, taking the I don't think they
were taking the output of you know, Drego's tools, but
I could be wrong. What I remember was that he
was taking firewall configurations and putting a sort of a
reachability what's reachable from where map together for large complex
OT networks, and would issue alarms, would issue alerts when
sort of reality deviated from policy. You could say, policy
is this safety instrumented systems never talk to the Internet.
That's a reasonable policy, And he would ingest you know,
hundreds sometimes thousands of firewall configurations and say and router
configurations and come back with an alert saying these three
devices over here are safety systems and they can reach
the Internet. So that's what he was doing. What we're
talking Here's what seems to me to be different here,
but I could be wrong. Is you know, we're talking
here about pivoting paths, not only sort of network configuration,
not not just reachable, not not just reachability, but the
difficulty of pivoting as well.
Speaker 2: Yeah, and is the reason why pivoting becomes relevant in
a discussion about pocs security because these devices make for
such efficient means of you know, they connect your maybe
let's say lesser IT assets to more important safety critical systems.
So PLCs sort of seem like a natural point at
which an attacker would move through.
Speaker 1: Sort of.
Speaker 3: PLCs tend to be the targets of pivoting attacks in
ot sophisticated attacks, because they're the ones that control the
physical world. You want to reach the PLC to cause
it to misoperate the physical process. Pivoting through PLCs is
possible in theory, and it's you know a little bit
more possible in practice when the PLC is based on
a popular operating system, like a stripped down Windows or
a stripped down Linux. But a lot of PLCs are
just weird. They just you know, their operating system, their
code does one thing, it does the PLC thing. In theory,
you could break into the PLC and give it new code.
But you know, if I want to, if I want
to pivot through a PLS see to a Windows device,
what am I going to? How am I going to
you know, get into the Windows device? I might want
to get into remote desktop. There is no remote desktop
client on a PLC, it doesn't exist. And so pivoting
through PLCs, you the attacker might, depending on the version
of the PLC, might have to do an enormous amount
more work to get pivoted through a PLC. And so
if the only way into a let's say a safety
system target is, you know, a really critical system, is
to pivot through three different PLCs pivoting through firewalls each time,
you know, that's going to be really hard to do. Whereas,
if you know, I remember a presentation from from Dale
Peterson at S four last year year before, where he
you know, he was talking about network segmentation. He says,
you know, network segmentation. Firewalls are almost always the second
thing that you know, industrial sites do to to launch
their security program. And I'm going, excuse me, excuse me,
what second thing? What's the first thing? I thought fireballs
were the first thing everybody does. Andrew, he says, the
first thing is to take the passwordless HMI off of
the Internet. That's the first thing you have to do.
When I'm going, yep, you're right. And a tool like this,
we'll be able to look at you and say, here's
my network. If I want to go from the bad
guys into this HMI. It's on the Internet, it has
no password. That's your number one. It can tell you that,
you know, not just policy, but it says you know,
and the safety systems back there. You got to pivot
through three PLCs. That's going to be really hard to do.
You know, you might have some other security you might
want to deploy in between. So this is the concept
of pivoting that you know, I found very attractive in
this tool measuring the difficulty an attacker from the Internet
reaching a target inside of a defensive costume. We've had
guests on the show talking about attack paths. You know,
these these are tools that you know, build a model
of the system and count all of the ways that
an attacker can get from where they are into a
consequence that we want to avoid. And it's not just
count them, but evaluate. Let's call it the difficulty. I
mean risk talks about the classic approximation for risk is
likelihood times frequency. Sorry, likelihood times consequence or impact if
you wish, and you know, likelihood is a really murky,
you know, difficult concept for high consequence attacks. And so
what a lot of people do is they substitute likelihood
with difficulty and they try to evaluate how difficult are
really nasty, you know, attacks with really nasty consequences. It
sounds vaguely like you're doing this, You're you're you're talking
about attack paths, You're talking about difficulty. You know, is
this where you're going. The one thing you haven't mentioned
is consequence.
Speaker 1: Yeah, that's a good point, because we are doing something
unique in that we are allowing a user to evaluate
in this digital to enlist digital replica, how an adversary
might be not only pivoting but exploiting different components to
get to their crown. Jules right. The way we're doing
that is showcasing different views of TTPs that are well
documented with all the IOCs and the tread intel that
we aggregated. So if it's a power customer, for example,
they could use an old Typhoon view to see how
a old Typhoon actor might be able to leverage you know,
initial access to credential exploitation, to other kind of exploits
within the environment. And there might be a manufacturing customer
with a whole different set of interesting TTPs that they
want to evaluate. But the idea behind this is you
figure out what the generally documented t tps are for
a certain type of adversary and how they might go
about from you know, your your starting point which is
initial access or the starting point of your of your
thread analysis, to all the way to the ground jewels.
And in doing so, you're making assumptions, right because you
know we're not in this production environment, we're not actually
exploding something, but you're evaluating the different scenarios where you say, okay,
I have this Windows workstation and I'm going to use
r DP, right, I'm going to exploit something there. What
if RDP was just so these days, people have some
data sets where they can explot from an eder tool
and provide open porce and services. Right. Then we know,
for example, upfront that you know some of these services
like SMB or whatever that you think is typically exploited
by the TTP or the third actor of choice or
interest is exploding and you disable that, you now know
that at least that path is closed. Right. In other cases,
the attack path might show three or four different types
of exploits to be able to get to that ground
duel or the ground dual network. Then you know that
that layer of difficulty or the complexity the daisy chaining
is much higher compared to another network or another attack
path that is trivial. Right, So it uses native credentials
and it only takes one hop in the attack path
to get to that asset or network. Then you know,
for example, that the previous one was more complex to
even get to. Right. But the end of the day,
all this conversation so far is about you know how
difficult it is to get to that candual network or
the cundule asset, right, not talking about what the attacker
might do once they get there, because that part is
the impact or the consequence here we actually have a
an automatic assessment based on the types of PLCs or
types of controllers or the types of assets we see
in general, based on our threat intel and our initial assessment.
But an end user that's running this tool or a
consultant that's running this tool can adjust them, right, So
there's a manual way for them to say, Hey, this
network is of a higher priority for me compared to
this other network. Show me what the impact of getting
to this network is for me, because this is higher
for me. So to be fair, we're not doing quantification
yet in this In this tool, we're limiting ourselves at
the moment to how easy or difficult it is to
get to a particular crown duel network and what the
adversary might be able to do in that kind of
a network. Right. So it's one of those interesting aspects
of that analysis where you're not doing the analysis of
what an attacker would do once they get to a
crown duel because that's a whole different model game compared
to you're trying to break the kill chain, break the
path way before that. So you're assessing or analyzing what
are all the attack paths and how easy or difficult
it is to get to the crownd duels that you're
trying to protect.
Speaker 3: Good going. I mean, I have maintained for some time,
you know, and it's easy for me to do because
I'm on the outside. I don't have to do the work.
But I've maintained for some time that risk assessments. Part
of a risk assessment should be a description of the
simplest attack or three that remain credible threats in the
defensive posture, you know, threats able to bring about unacceptable consequences.
There's always a path that will let you bring about,
you know, an attack and bring about non acceptable consequence.
The question is how difficult it is, and so to me,
you know, the risk assessment should include a description of
the simplest such attack or you know, attacks plural. So
that's that's sort of what is this kind of what
you're doing? Can can you give me the next level
of detail on what you're looking at and how you're
making these decisions?
Speaker 1: Yeah, definitely. So the problem that you described is that
there might be some open ports or services that are vulnerable. However,
if those ports are closed or if those services are disabled,
then that problem is solved at least for the moment, right,
unless there's another vulnerability discovered on the particular asset. So
what we're doing is very ingesting information from the various
sources that they have. In other cases provide options to
add that in the tool so that you have the
context for information as to what attacks are possible with
what's relevant in that environment. Right. And in the past
people did this using questionnaires, asking people or evaluating subject
matter experts, you know, using a tabletop or something like that.
But the beauty of our final platform is that you're
actually able to do this in an automated fashion and
at scale, because if you have, like a typical customer,
dozens of customers, end user sites, and hundreds or even
thousands of networks, you're not actually able to analyze the
risk of each network, of each acid down to the
level of what's possible with the given boats and services,
or install software or not install software in that environment, right,
But if you're able to ingest all this information right
from the IP addresses and different types of assets, the
vulnerabilities typed to them, to the ports and services that
are enabled or disabled, or in other cases, you know,
making an exception to say I'm disabling this using some
kind of application whitelisting or some kind of segmentation, all
the information at scale can be analyzed and you can
get a view that shows a realistic and more or
less validated attack path versus someone that's just looking at
a piece of paper or a complex network in a
manual fashion. So this is where I think the big
difference is in that we're looking at the attack complexity
and the attack path at scale with whether it's tens
of sites or thousands of networks, and able to decipher
what the context is for exploitation or or just later
movement or whatever the path might be to get to
your crowndules.
Speaker 3: So you've mentioned a couple of times at scale. You've mentioned,
you know, a couple of times, the potential for ingesting
information about a lot of assets and networks. You know,
the asset inventory tools out there produce that knowledge already.
I'm guessing you your interface with them. Can you talk
about about that? How do you get data? How do
you get the data about the system that you're going
to analyze.
Speaker 1: Yeah, we definitely can ingest information from a variety of sources,
So the platform can ingest information offline. So drack and
drop a CSV or an example file or any kind
of spreadsheet, and we also have API hooks to be
able to automatically ingest information from the likes of Dragos
and Zoomi Clarity, which are the OT security product vendors.
We can also ingest information from cmdbs or any kind
of CenTra line data depositories like rapid seven or run
zero tenable. In other cases, the customers might have just
spreadsheets from the last time the data sidewalk, we can
ingest that too, so we're not restricted on ingesting any
specific type of format. We have a command line tool
that can ingust other sources as well. But the basis
the digital twin starts with the firewall and the canfig file,
So we ingest information from the likes of ford Net, Cisco,
Palo Alto, you name it, then ingest information from these
I or OT tools. At the end of the day,
the more information that's provided, the fidelity of the data
is higher. But the beauty of the platform is that
if you don't have any kind of information, we cannot
only create mitigating controls and options within the platform. But
we also built an extension of the Fringnese platform called
optica where you can quickly leverage existing templates for example,
debt servers or Cisco hours or Rockwell PLCs. Within a
few minutes, you can drag and drop and build a
template which then import interfrenos to replicate what might be
in the system already. So long through ashore any kind
of asset information, abound information out there, we can ingest
and if there is none or there's limited visibility in
certain sections or location, we can build something that's very
similar so that the customers can have a few for
what the risk is in a similar environment.
Speaker 3: And you mentioned a couple of times I remember here
compensating controls. I mean the compensating control everybody talks about
is more firewall rules, more firewalls, more firewall rules, keep
the bad guys away from the vulnerable assets that we
can't patch because you know, we can't afford to shut
everything down and test everything again. Can you talk about
compensating controls. What other kinds of comp sitting controls might
your your system recommend.
Speaker 1: That's a great question because, as we were discussing earlier
in OT not everything is fixable because a patch might
not be available or an out of the window is
not available, right, So historically most people have used a
combination of allowed listing or deny listing or some kind
of ports and services disabled or you know, to your point,
firewall rules and segmentation have a place in that as well. Overall,
the key is to figure out what the attack path
is and in how or which fashion you can make
that attack path. Right. So, if the consideration is from
level four through a DMZ or firewall, and the firewall
rule was any any or something that was allowing you know,
too much, maybe too many protocols or something that can
be disabled, you can start there as a preference. Right.
If that's not possible, or if that's not a project,
you can take the next thing could be averaging this
kind of SMB or other exploit at that level three
device before going to level two. Let's look at what
this service was on that particular asset, right, so you
can disable that. So within the tool, we built in
almost twenty or so different options for combinations of all
these composite and controls that are historically used in OT right,
So it could be a combination of our world rule
or service or poor disabled, or in other cases it
could be disconnecting them to put in a different segment. Again,
this is not new, right, This is how historically OT
has been able to mitigate some of the risk. We're
just bringing that to the forefront to see or show
you what other things can be done to break the
attack path versus strictly talking about vulnerabilding management and fixing
the problem by applying a patch, which is not practical.
Speaker 3: As we talked about, compensating controls are tricky made we
identify a vulnerability, a weakness in a defensive posture. There's
a new vulnerability announced from some piece of software that
we use on some POC or safety system or who
knows what, you know, deep into our architecture. You know,
the what do we do about that? Is an open
is a question everybody asks sort of the consensus that's
building up is that, you know, if that system is
exposed to attack, then we have to put compensating measures in.
If it's not exposed, or if it's you know, really
hard to reach, maybe we don't need to change anything
in the short term until our next opportunity to do
an upgrade or you know, a planned outage or something.
And a tool like this one like the Freeno's tool
is one that can tell us how reachable is it,
how exposed is this Compare that to our risk tolerance.
Are we running a passenger rail switching system? Are we
running a small bakery? You know, different levels of exposure
are acceptable in different circumstances, So you know, having the
tool give us a sense of how exposed we are
as useful in making that decision are we going to
patch or not? And if we have to do something,
it's useful to have a list of compensating controls and
sort of the list that I heard they go through,
but you know they're probably going to add to this
if they haven't already. You can change permissions. If you've
got a file server that sharing files is the problem
and the bad guys can put a nasty on the fileserver,
change permissions so that you know it's harder to do that.
Turn off services programs that are running on you know,
Windows ships with I don't know seventy three services running
most you know, industrial systems don't need all of these services.
They would have been nice to turn them off ages
ago if you haven't already turned them off. And there's
a vulnerability in one of these services and you're pretty
sure you're not using it, you can in it off.
Add firewall rules that make it harder to reach the system.
Add firewall rules that say, fine, if I need to
reach the system for some of the services, but I
don't think I ever need to reach this service from
the outside, even if I need to use it on
the inside. Add a firewall rule that blocks access to
that service on that host from the outside. None of
this is easy. Every change you make to an important system,
you have you know, the engineering team has to ask
the question, is this how likely is it that I'm
messing stuff up here? How likely is it that I'm
introducing a problem that's gonna that's going to bite me
with a really serious consequence? You know, how likely is
it that the cure is worse than the disease here?
So compensating controls aren't easy. But you know, what I
see this tool doing is giving us more information about
the you know, the the we've got a vulnerable system,
about how reachable is that vulnerable system. What are the
paths that will you know, that are easiest to get
to that vulnerable system if I can you know, turn
off I don't know remote desktop halfway through the attack
path and make the attack that much more difficult. Now
you have to go through I don't know, PLCs instead
of Windows boxes. That's that's useful knowledge. This is all
useful knowledge. We need as much ammunition as we can
get when we're making these difficult decisions about shoot. I
have to change the system to make it less vulnerable.
What am I going to change without breaking something? Well,
thank you so much for joining us, Vivik. Before I
let you go, can I ask can you sum up
for our listeners? You know, what are the most important
points to take away from this new technology?
Speaker 1: You know?
Speaker 3: And I don't know what can they do next?
Speaker 1: The quick summary is we're trying to solve a problem
that's been around for a decade plus. Lots of customers
do not have a risk assessment in place. They're not
quite sure where this ten currently, so some of them
are early in their journey with this lack of information.
They still need to figure out where they have to
invest their next dollar or next hour of resource and
the other cases. They had spent the past three or
five years in developing an ot security program, A lot
of information available, lots of alerts, but again they're not
so sure how they are compared to maybe their industry yeers,
or how they are compared to you know, where they
should be in their security positor management. So what Frenos
is able to do is to both leverage their existing
data sets and missing information by providing something that's a
replica of their environment showcase where they should be focusing
on in terms of breaking the attack paths, highlighting not
just where they currently stand, but also where they were
compared to yesterday. So overall, this is what most executives
I've been asking before investing in OT security. Where do
we stand currently? How good are we compared to an
existing known attack vector or campaign if you will, And
then how good can we be currently as in today?
Because the risks are not staying constant, so how do
we keep up with them? So the outcome of the
friendales platform is both a point in time assessment if
you like, and also continues posture management because you're able
to validate what compensating controls and prevent the measures that
you are deploying or implementing and if they're going well
or not. So conclusion is that we are a security,
posture management and visibility company that's able to bring out
the best in your existing data sets and provide your
gaps and the gap analysis and help you figure out
where to invest your next dollar or resource on what
site or what location And if you like to know more,
hit me up on LinkedIn. My email is vivid at
friends dot I or happy to connect with you on
LinkedIn to take it from there to like more information,
youet up on our website for you to start io
as well. You'll see all the information about our current
use cases, the different products and services we have to
offer them. So looking forward to connect with more of you.
Speaker 2: Andrew. That just about does it for your interview with
you Panada. Do you have any final word to take
us out with today?
Speaker 3: Yeah? You know this topic is timely, the topic of
risk based decision making. I mean this too is coming
into effect in a lot of countries in Europe. The
regulation in every country is different, but the directive says
you have to be making risk based decisions. And I'm sorry.
A risk assessment is, you know, should be much more
than a list of unpatched vulnerabilities. A list of unpatched
vulnerabilities does not tell you how vulnerable you are. It's
just a list of vulnerabilities to figure out how much
trouble you're in, you need a lot more information. You
need information about how you know which assets are most critical.
You need information about how reachable are those critical assets
for your adversaries. And you know, when new vulnerabilities are
announced arise that simplify the pivoting path, that simplify reachability
of a critical asset for your adversaries. You need advice
as to you know, that's what you need to fix next,
and here are your options for fixing that. So I
see this kind of tools, as you know, a step
in the right direction. This is the kind of information
that a lot of us need in not just the
world ofness too, in the world of you know, managing
managing risk, managing reachability. You know we've all segmented our networks.
What does that mean you can still reach bang bang bang,
pivot on through Well, then what does that mean? This
kind of tool tells us what that means. It gives
us deeper visibility into reachability and vulnerability of the critical
assets you know, risk opportunity to attack. You know, I
don't like the word vulnerability too often it means software vulnerability.
This talks about You know, this kind of tool exposes
attack opportunities and tells us what to do about them.
So to me, that's a very useful thing to do.
Speaker 1: Well.
Speaker 2: Thank you to Vivic for highlighting all of that for us.
And Andrews always thank you for speaking with me.
Speaker 3: It's always a pleasure. Thank you.
Speaker 2: This has been the Industrial Security Podcast from Waterfall. Thanks
to everyone out there listening.