He is actually in the news pretty much on a monthly, if not weekly
basis, examples of critical equipment being exposed on the Internet and being rich.
Welcome everyone to the Industrial Security Podcast. My name is Nate Nelson. I'm
here with Andrew Ginter, the vice president of Industrial Security at Waterfall Scurity Solutions,
who's going to introduce the subject and guest of our show today. Andrew,
how's it going. I'm very well, Thank you, Nate. Our
guest today is Robin Bertier. He is the CEO and co founder at Network
Perception, and he's going to be talking to us about machine analysis of network
zoning, so you know, basically analyzing our networks so we can understand attack
pads. Okay, your interview with Robin. Hello Robin, and welcome to
the podcast. Before we get started, can you tell our listeners a little
bit about yourself and about the good work that you're doing at Network Perception.
Thanks Andrew for having me. So. My name is Robin Buquier. I'm
the CEO and co founder of Network Perception, a cybersecurity software company. We
help hot networks to get understood, visualized, and analyze for risks. And
my background is in computer science and cybersecurity. I grew up in France,
moved to the United States in two thousand and five for grad school, and
then moved from grad school to Chicago to launch Network Perception and support the critical
infrastructure industry by developing solutions that helps practitioners in those OT and cyber physical system
environments. Thanks for that, and our topic today is analyzing networks analyzing zoning.
You were on the show six months ago walking us through your your network
modeling tools, your capabilities back then, you know, to remind our listeners.
You know, back then you were reading and analyzing config files and backups
for firewalls and routers in my recollection. These let you visualize the network.
It lets you, uh, you know, design a policy, express the
policy to your tool, compare all of these configurations to the policy. You
know, the policy this machine can be reachable by those networks, but not
by anything else, and then report on deviations. You know, is the
network configured the way we think it ought to be configured? And you know
you're back so you're talking about today. What's new? Is there a new
problem that you're solving? Yes, So two things are happening. One inside
netroperception and one outside. Let me start with the outside the driving force first.
So in the last six months, we've seen in uptake in terms of
interest by organizations with out networks to formally verify the segmentation of the environment.
It's becoming more and more of a priority for them, and I think that's
driven by both a more pressure from adversaries making sure you have the right access
policy in place to block attackers to prevent a breage from spreading to the critical
zones inside your network. And it's also driven by more stringent regulations we've seen
with no OXIP seeing now with the TSA Secretity directives, it's just more focused
being put around the importance of extremely robust network segmentation, good hygiene for your
firewalls, and having very precise rules to only allow traffic on a need to
know basis. And then the second thing that's happening inside that properception is that
we you know, I didn't mention in my background, but I really have
two passions. One is is cybersecurity, the other one is information visualization and
specifically how to present a large rim of data into concise reports that leads to
efficient decision making. So over the past couple of quarters, we you know,
reflected on the data analytics that MPVU provides, and we went back to
the you know, brainstorming and the white boat to really think how to best
present that information because sometimes, you know, you start importing file configuration files
and you will have thousands or even tens of thousands of network paths being discovered
by the modeling engine that tells you the exposure of your different critical assets.
So how do we compress and present and summarize this information in the way that's
helping you making better decisions in terms of risk, in terms of you know,
the risk really to your to your network. This is of course a
very important subject that Robin is heading on here. Network segmentation comes up in
any domain of cybersecurity at some point, relatively frequently. In it especially,
I can think of a million examples where an attacker started off with one network
resource and ended up moving their way through a network because wasn't segmented enough,
the classic example being the target breach back in twenty thirteen, when a phishing
email at a small HVAC provider in Pittsburgh led through target's client portal supplier portal
rather, attackers got into the network associated with the HVAC systems and ended up
burrowing their way through the target network through to their point of sale systems and
then stole a bunch of credit card information. The story goes on from there.
So all that is to say, this is very important. You and
I have talked about air gapping and unidirectional gateways and all of these relevant technologies
before. Absolutely, and you know where to begin. It is important.
This is why you know, the first volume, the first volume that was
published in the sixty four four three series. You know it's a it's a
fourteen volume set of standards. The first volume was you know, half of
it was about segmentation IT. You know, it's that important. And you
know on the OT side, you know, the to me, the classic
example was the ransomware attacks Snake got into Honda a couple of years ago.
I mean, there's been lots of ransomware attacks that had OT consequences, but
that was sort of the uh, the highest profile one that had you know,
enough enough detail published to be able to figure out vaguely what happened.
And in my recollection, it was the bad guys got into the IT network
through the IT to Internet firewall and pivoted from the IT network into the OT
network, and you know, contaminated the uh the production line with with ransomware.
You know, operated the ransomware remotely encrypted stuff blah blah blah. And
so you know, there were firewalls all the way along there, and uh,
you know what what people don't understand is, you know when people when
I entered the industry naively, you know, more than much more than a
decade ago. You know, I had sort of the same perception everybody else
did. You know, You take a little encryption, throw a few firewalls
at it, you know, some VPNs and you're good, right, question
mark. And you know it was once I started digging into it. I
mean now bluntly, I went to SANDS training on firewalls, and I was
appalled. And a couple of years later I put together my own presentation on
thirteen ways to break a firewall. You know, what's the low tech way
to break a firewall? Your shoulder surf as you know, the firewall that
enters the password and you enter it yourself later on and at a rule that
says allow all and it's all over. You know, what's the what's the
high tech way to break a firewall? You find a zero day a bug
that no one else has found in the firewall. You write code to exploit
the bug. You sneak your way through the firewall in a way that you
know there is no defense against because there's no patch for the bug. There's
there's no you know, attack signature for the attack. It's it's brand new.
You know what's the uh, the the modern way to break through a
firewall? Well, you know, we've talked about it countless times. You
get into the IT network, you you know, trick various ways into people
and technology into into getting domain credentials, and now you give yourself permission to
log in to systems through the firewall, and you know, work your will
upon the target system. You know. Here, here's a pop quiz.
What is the most widely known sort of the instinctive, the knee jerk reaction?
How do you break through a firewall? What's the most widely known way
through a firewall? Is it like they do in the movies where you type
a bunch of zeros and ones until you get a notification, pull the pops
up and says access granted. And your screen scrolls really fast. No good
one, I have no idea. Okay, you know it's it's the most
widely known is you don't attack the firewall itself. You you know, every
firewall. People imagine that firewalls protect industrial systems from cyber attacks. You know,
they give you access to industrial data, but they protect the industrial systems.
In fact, that's not what firewalls do. What firewalls do is they
give you access to some industrial systems and hopefully block you from others so that
you can ask those industrial systems for data. If you ask for data politely,
well you get data back. If you ask for data impolitely by let's
say, you know, guessing the admin password instead of going in as your
mere user password. Now you're attacking the OT system through the firewall. This
is sort of the the the way that that you know, everyone knows.
Of course, you can attack through a firewall. The firewall gives you access
to a handful of industrial systems and lets you send messages to those systems,
and some of those messages can be attacks. And so you know, this
is you know, back to the point here with with Robin. If you
can send messages to the OT systems through the firewalls, you can attack them.
You can pivot attacks into those systems. And so in my understanding,
this is, you know, the question he's asking of I have you know,
in a refinery, I don't know, dozens and dozens of subnetworks and
dozens of firewalls, and you know configuration for all of those firewalls. The
most complex would be the IoT firewall, but you know there's other configurations everywhere
else. And the question becomes, where can I pivot? How many steps
do I have to go through? How many systems do I have to compromise
before I get from where I am on the Internet or in the IT network
or whatnot to a target that has really high value? You know, how
do you do that that? And this is the kind of analysis that that
his tools are doing, So that makes sense, you know, pressure from
various kinds of regulators, uh, you know, pressure from the threat environment,
people caring more about about how their their networks are configured, and you
know which parts of it are more or less easily reachable. But if I
recall that was kind of what you were focused on on the last time as
well, What's what's changed that you know, you needed to build something new.
So yeah, good question. So so based on that reflection, we
had to improve presenting large room of data into concise reportata, you know,
leading to efficient decision making. We started to work on a new capability for
the platform that we call a zone segmentation matrix, and that feature takes your
entire set of connectivity paths in the environment that you're modeling and presenting it according
to a metrix of zone to zone path. So in one single screen you
can see like a pertside, you can see which access network access would present
a risk for your environment. So, for instance, that metrics will reveal
if someone from the corporate network will have direct access to your scaled environment,
and if so, on which pot Before you had to go one by one
into a subnet an asset and then look at the path in and out of
that asset. Now we're surfacing in that metris right away those different results,
and so that that gives you, you know, a faster way to identify
over re permissive rules, overly permissive segmentation, or gaps in terms of your
network segmentation. All right, So the ability to visualize at a glance and
see where problems are in larger network configurations. That that sounds good in theory,
you know, in practice? You know, you mentioned, you mentioned
standards, you mentioned drivers. You know, can you connect the theory the
capability to the practice. How would you use this for i SM? You
know, can you remind us what is NERK I in SM? I mean?
As as a general theme, network visibility has been a key challenge for
out infrastructure. You have geographically dispersed facilities and then some very legacy equipment and
so getting good visibility over those networks is just is difficult. So FIRK as
a year ago NERK to stop drafting a standard around internal network security Monitoring I
n s M, and the concept there would be that even if you implement
good cybo hygiene, even if you have good proactive defense initiatives in place,
if an adversary is able to breach your environment, you should have as part
of your defense in depth you should have capabilities to monitor suspicious netroalk traffic and
alert you and detect if an attack is going on. So NARK is in
the process the drafting team in the process of crafting a revision to the standard
to include a requirement around pulling sensors inside those critical networks in order to capture
the traffic and detect intrusions. It's still much work in progress. Actually two
days ago was the end of the voting period for the first version. I
don't think the that version was accepted, so it's going to go back to
the drafting team for some changes, and then we're going to know in the
next few months in the final version with actual enforcement data in the next couple
of years. But this ties into that big theme of network visibility, and
for us at Network Perception, it's really important that we support the industry gaining
a much more precise understanding of those tea networks, and we see our solution
as extremely complimentary to the network traffic monitoring product that on the market. We
call this the two sides of network visibility. So on one side you have
actual network traffic monitoring and then on the other side you have what will,
which is network modeling. So when you monitor network traffic, you can see
in real time what's happening and you can answer questions such as the something suspicious
occurring now in my network. When you do modeling, you can ensure a
different portion, which is what can connect to what we covered this in the
last episode of the podcast. Now with the I NSM, the push for
the NSM regulation, we're helping in two ways. Number One, we can
help organizations to better plan for the diplomat of their sensus because with NPVU you
can very quickly generate a reference architectural diagram for your environment just in the conflict
fire to your firewalls, barterers and switches and so once you have the diagram,
the decision of where to put sensors in order to capture the correct critical
traffic is easier, specifically with that zone segmentation metric that I referred to earlier,
where you have that Berks eye view and you see what are the critical
connectivity path which zones should be instrumented with those sensors. And then the second
value is to be able to build context around the event that you're going to
trigger through that network traffic monitoring sensor. So, for example, you have
a suspicious netro connection that connects to critical equipment, you want to know first
you know how cretical equipment is in which what what what's the source zone of
that traffic, what's the destination zone? And then if that equipment gets compromised,
Where could an attacker go? Like, what are the other paths that
could be taken for this attack to propagate in cell? Your environment? And
those are the that's the contextual environment, the contextual information that that we can
we can provide for for users. So, Andrew, it seems to me
that we have spoken with many guests before about modeling attack paths, about modeling
networks and such. What is the exact distinction in what Robin's talking about here?
Where to begin? Robin, I think actually later in the episode says
this, So I'm going to repeat what he says in a moment, but
I think I recall him saying drawing a distinction between intrusion detection looking at network
packets and the kind of analysis that his tools do. Intrusion detection looks at
what connections are happening, and if you see an unusual connection, one that
you haven't seen before, you might raise an alarm saying someone should look at
this. I've never seen this before. So it looks at what's happening the
attack. The analysis tool that Robin has doesn't look at what's happening. He
looks at what's possible. He looks at the firewall configurations and says, well,
this device here could connect to that device there. The firewall allows it,
whether or not it's currently happening. IDs is what's currently happening. And
you know, his tool talks about what could happen to you. I guess
I'm kind of surprised that that's actually never been covered before in all of our
previous discussions. You know, I could be wrong. I don't recall it
has been covered, but you know, we're at one hundred and twenty episodes.
My memory fails sometimes. I do remember that something like this we talked
about with Terry Inglesby at Amanaza. You know, his company does the attack
tree analysis where he says, well, you know, how could you get
from you know, a source the Internet, a source of an attack,
you know, or a malicious insider sitting at that workstation or whatever. How
could you get from a source of an attack to a high value target.
Well, first you'd have to break into this machine. Then you'd have to
get through that firewall. Then you'd have to and each step he assigns a
weight indicator how difficult it is to do that, how capable the adversary has
to be, and he puts together, you know, all of the possibilities
into a ridiculous number, sometimes literally over a billion possible attack paths, weighs
them all and says, here's the bit you should be worried about. But
in my recollection that I could be wrong. You know, his tool looked
at things sort of a little bit generally, whereas what Robin's tool is doing,
what you know network perception is doing, is looking at the config files
for the firewalls and saying, here's everything that's possible, not sort of generally.
Well, you know, you an attack could pivot through the firewall.
He would say, well, these machines here can talk to those machines there.
That's all the firewall allows. And so's he's doing that sort of detailed
analysis that I'm not aware that other people are doing. IDs is you know
what is happening? You're talking about context? Are you connecting? Are you
supplying that context in a sense in real time? Are you are you taking
the alarms in and analyzing the IP addresses and you know somehow augmenting them.
So step best step we are. So we started to develop integration with the
ideas vendors to be able to first and reach the topology map that we generate
with the asset and equipment that has been detected as communicating on the network.
Because you know, so far, when we create a map, we are
inferring the presence of endpoints based on references that we extract from the configurations of
firewalls, routers and switches. But we don't know for sure that those i
prcs there is an equipment behind it. But if you start integrating with your
network scanners, your asset inventory solution, your ideas providers, then we can
turn those inference into actual endpoint you communicating and being present on the network,
which which is enriching your map. So that pot is, you know,
you have prototype available today. The next phase in that roadmap is to be
able to also visualize the network traffic directly in study MPV map. So that's
something on which we're actively working right now. You can leverage NPVU to contextualize,
but that's not yet you know, automated through integration, So that makes
sense. Another thing that that you said that intrigued me. You're you're you
know, you said, figure out where the adversary can go if an intrusion
detection system and ideas is alarming about a particular asset that appears to have been
compromised and is now sending out probes and and attacks to other or you know,
suspicious traffic to other assets. This is pivoting. This is using a
compromise machine. It. You know, I heard you say that you could
figure out what what we're you know, what assets were at risk by a
pivoting attack, given you know that a certain asset might have been taken over.
Well, you know, in the worst case, if an adversarya is
you know, taking advantage of I don't know, known vulnerabilities, exploiting vulnerabilities,
and you know a lot of control systems are they have they're not fully
patched. It's hard to patch these systems because of reliability concerns, because of
safety concerns. Sometimes in the worst case, you can pivot to you know,
arguably everything on the local network and everything through firewalls that anything on the
local net network can reach. It does little good if you take over one
asset to take your entire you know, zoned network map and turn the whole
thing red and say this is where they can go. Eventually, I'm guessing
you've got something finer grained, can you talk about, you know, what
you actually show people is it? Is it one or two steps ahead?
Is it something thing else? What you know, other than the whole thing
lighting up. Yeah, that's a great question. So currently we're looking four
steps ahead. So what we do is to leverage our understanding of your network
sigmutation. So based on your access policy, firewalls, virus and switches,
what are the pivot from one subnet to another subnet now within the single local
area network. To your point, it's game over, right if you have
one, if you have one equipment compromised, and then that switch is not
segmenting the networking two villains, so you have pretty much everything can do to
everything else in that one net subnet. Then there's not much you can do
where where we're finding the analysis, there is to be able to ingest also
the reports from vunability scanners. So if you scan that environment either activity scanning
or past really monitoring to extract which I pracies is hosting application where you have
a vailability, then we were planning to refine that analysis to show you exactly,
you know, watch which cded it could be exploded on which portment services.
But that really leads to the discussion around actually the importance of reducing the
size of your segment you know, the whole macro segmentation movement, right,
So instead of having a giant, uh, you know, local area network
with dozens of vipiracies, segmenting with villains, or segmenting with actual firewall access
control to be able to group by level of criticality and function equipment, so
that if something is compromised, then you contain within a very small zone that
bridge. Mm hmm. So Nate, I don't know if it was it
was completely clear, But what I just heard Robin say there was that this
tool is helping us answer the question, you know, how should we design
our networks, how should we segment our networks? I mean, look at
you look at the Internet. You look at the threats out there. Nation
states are out there stirring the pot. Ransomware is out there. Some of
the ransomware is backed by nation states. They've got the capabilities of nation states.
Some of the ransomware is rich enough to buy their own nation state tools,
li rich enough to build their own nation state grade tools. So what's
coming at us across the Internet can be really nasty, and you know,
the bad part about these ransom where with nation state tools is unlike nation states,
they're not just going to go after important targets. They're going to go
after everybody with money. So if that grade of ransomware is coming after us,
we got to ask the question, you know, are have we designed
our networks in such a way as to defend them properly. So we look
at our networks, and you know, generally you've got two kinds of networks.
You've got networks where the worst case compromise, if it occurs, is
unacceptable, you know, rail switching systems, safety systems, and there's other
networks where, well, if we get compromised, you know, we kind
of want to recover quickly, and we want our insurance companies to pay us
out. But you know, it's it's a big deal, but it's not
the end of the world. So in both cases, in both kinds of
networks, we've got to figure out how exposed we are. If a bad
guy from the Internet wants to get in, how many steps do they have
to go through? How many machines do they have to compromise and then pivot
use the compromise machine to reach through the next layer of firewall to compromise another
machine. And what Robin's saying is that they're starting to integrate this tool not
just with the network diagrams to count the steps, but to look at the
vulnerabilities in each of these targets and ask the question, how hard is it
to carry out the next pivot. So, for example, if we have
a really important system, very deep in our networks, and it turns out
that we've designed the network, we've broken it not just into one big network
you're in, you're in. You know, Robin saying, let's talk about
finer grained segmentation, micro segmentation. If you break it into small networks and
you've got to get from one small network into another one into another one,
let's say three or four hops in, and two of those hops have to
pass through a machine that has zero known vulnerabilities in it. Well, suddenly
the bad guys, if they want to get in, they've got to conjure
up two zero days to punch through that kind of segmentation. That's expensive.
And so you know, it's not just how many hops that are being counted
here, but it you know, it sounds like what we can start doing
with this kind of system that Robin's putting together is getting insights into really how
thoroughly protected or not our networks are. So that all sounds good. You
know, I'm going to ask you in a moment for sort of examples and
experience. But before I get to that, let me ask you about about
availability this new capability. You know, I can't ask you for examples if
it hasn't been released yet or you know, at least be available in beta.
What's the status of this new development here? Yes, so we are
actively working with a fewer for different partner on finalizing that release, and we're
actually getting super close to raising that to the market. So we're planning to
have a launch of the later's version of ntview that includes the zone sigmaentation Metrix
at the S four conference early notch Okay, So then let me ask you
the hard question about about experience. You know, do you have beta customers?
Do you have you know sites where you've been trying us out? You
know, who've been working with you? How is it working? What are
these people learning? What kind of feedback are you getting? You know,
how how's it going? Especially this, uh, this whole pivoting concept sounds
interesting? Have you got any examples of that? Yes, so on the
RUB and partner we are you know, working closely with them too deploy that
solution and inform them with what we call the steppingstone map. And that's you
know what you read earlier with the pivoting. And so what's interesting is that
while we don't have you know, example of actual network bridge yet to illustrate
the value of it, we observe these just the initial value of enabling stakeholders
from different teams and different background to understand finally like how you know the network
environment is configured and what segmdation means and how things are protected, you know.
With the visual map and this, you know, lighting up the pyvoting
points, you put risk in context. And whether you are from compliance or
cybersecurity or networking, whether you are a technical person or you are in in
the you know, in the leadership, you know, the picture helps everyone
to have the same language to discuss about those concepts which can be pretty complex
with the size and sophistication of networks today. So the feature and the capability
and the visual edition of it has been received extremely well by all or in
sure you know better distance okay, So let me ask you what if I
mean, if I have a complex network and I've got high value assets buried
deep in that network somewhere protective relays or safety instrumented systems or I don't know,
leak detection systems. What do I know You've got high value assets and
you know the pivoting path that I worry about is from a command and control
center on the internet. Can I ask you, you know, is it
possible to take your tool and say I'm worried about an attack from the internet.
What's the shortest, the easiest path to get from the Internet into these
high value assets? And you know, is that possible? And you know,
do do people start seeing things that their eyes open and go, oh
shoot, I forgot about that. You know? Is that is that doable
with your technology? Yes? So it actually it's pretty interesting, like every
time we reminded analysis for the first time, you know, there are insights
I can't I can't remember like a single example where someone saw the result of
that stepping stone map and didn't tell us, Oh, I didn't know that
this was possible. You know this, I didn't know that this access was
you know, was doing board in that environment? But so the way we
do it, and often you know you have you start importing some conflict files
into the platform. They may not cover all your network path all the way
to the to the Internet, because you start with your own your critical environment,
with your criticals and an esp In the case of NERD, what we
do is that we when we passed the conflict files, we extract the raving
table and specifically the deffault routes, and so we know that Internet traffic or
external traffic would come from a specific gateway. We put the get in the
map and then we have actually default template routers that you can also import in
addition to your actual equipment in order to close the gaps between the environmental mapping
with the network that's connecting to the external world. And that allows us to
breach and connect the different islands that you could see in the network map.
And then we launched the stepping stone map from that external gateway and you're going
to see in one, two, three, or four hubs which nodes could
be used as pivot for an adversary standing from the external zone to go all
the way to your critical equipment. Right now, this analysis is agnostic of
your vulnerabilities, but we're working to be able to filter it down to prune
that set of capabilities, a set of possible path that we identified into you
know, to your point, the shortest or easiest path based on venomit information,
which hosts have an outdated application of something that could be exploded, and
matching a board or survey that's available based on your fireword wards like really connecting
the dots and combining those two data sets into an insight for you to know,
like which path is the risk testing in your network? So you know
what you're saying here, It actually reminds me of, you know, an
experience in my past. I was at Industrial Defender. I was working with
Jonathan Palaya, a very capable penetration tester. You know, we were not
doing a pen test. Uh, the business had been contracted with a customer
to look at some network diagrams and you know, some systems do a risk
assessment basically, and we did not have any kind of technology like this.
And so I remember Jonathan sat down with I don't know, you know,
seventeen three foot by five foot as built network diagrams, big massive things full
of you know, wiring diagrams and he's paging through these things one after another,
and he looks up and he says, you realize there's a path from
the internet into your deepest control system here without ever passing through a firewall.
Just routers, what do you mean? Well, on this network diagram,
it starts here from the Internet, and then you go to this machine and
that machine through here, and then you take this thing over here that you
know is kind of off in the corner, takes you over to this page.
Bang bang bang, You're in, you know. And the reaction was,
give me that and you know, snatch the network diagras back, kick
us out, go and fix the problem, and you know, bring us
back in a couple of months. Is this the kind of thing that you
know you're looking at? Is this this the kind of experience you're trying to
prevent? And it's it's interesting because I can't find in my memory like a
single example of you know, user we hasn't had this type of insight after
depraying our solution. This is always a weakness or some misconfiguration or overly permissive
rule that someone forgot inside that configuration that allows this type of of path may
be not always on the Internet, but for sure from an untrusting zone to
a trusted zone. So the key there is to do that, you know,
with the power of technology, right because for you know, the expertise
and experience that the genre is bringing, your example, we want to be
able to bring that that capability without the risk of human error to the mass
and to be able to have all of stakeholder's being able to identify those risky
paths. But yeah, it's it's fascinating, like we stop, you know,
important conflict files, the map is getting generated, and then you know,
in those firewalls we have in the ratios, we extract the default gateways
so we know we can infer wates the external access point into your environment.
We launch a stepping stone analysis from that access pondent. You know, just
a few seconds later you see the nose in your map lagging up, and
you know you're going to see your critical zone with everything little a specific color
that says you know, this is protected, this is mitigated by access control.
And then for sure there's always like one of the two nodes in bright
red that tells you there's a direct access from an external ip RAS all the
way to that critical equipment deep inside your environment that you have no idea about
them. You know, the causes are the very but often it's someone a
temporary fire or rule like six months ago and it was supposed to stay for
a couple of days, but they forgot to remove it. Or you know,
we thought that this rule was actually preventing external traffic from getting in,
but we had a misconfiguration. The rule never got attached to an interface,
so the rule was useless, you know, just a line in your confide
that the fire wasn't taken into account. Or we had examples of just object
groups not being correctly defined. You know, you have rules that are referencing
source and destination services using groups, and then it's pretty complex as a human
to keep track of that, right you have to use lookup tables and make
sure that you know what value is in which group, which sort of appearacies,
which sort of portant services, and so often we see you know,
an old ip or something forgotten that gives more access than they expect. So
the example that that Robin gave, there were misconfigured firewalls, and you know,
I just wanted to jump in sort of with a couple of examples of
misconfigured firewalls on my own. You know, I used to do a demo
at like trade shows how to break through firewalls. Uh, you know,
just an awareness thing, a threat awareness thing. One of the scenarios was
just misconfiguring the firewall. And we're not we're not talking about home you know,
small office firewalls here. We're talking about enterprise grade firewalls. And these
firewalls have operating systems and user interfaces that are designed for scale. They're designed
for big systems. Uh. You know, they're designed to deal with complexity.
And so you know, if you want to put a rule in there
that says Andrew's laptop is allowed to connect to you know, the Pie server
through the firewall, well you can't. It's not one rule. First you
have to define who Andrew is, and then you have to define what Andrew's
laptop is, and then you have to define what the Pie server is.
And then you put a rule together, not with Andrew's laptop's IP address and
the Pie server IP address and allow you put together. You have to partner.
You have to define service numbers, the port numbers as well. You
put a rule together that says roughly in English, Andrew's laptop is allowed to
connect to the you know, a Viva PI client server port on the PIE
server in the DMZ network. You use almost exactly those words. Okay,
there's no IP addresses anywhere, there's there's no user names, there's it's all
symbols. And they do this so that you know, these thousands of complicated
firebles are are comprehensible. But what it means, and you know my demo,
what it means is that you can look at that firewall rule and say,
there's nothing wrong with this firewall rule. Andrew's laptop is allowed to connect
to blah blah blah. The rule is right, yet I'm letting the entire
IT network connect to the PIE server. There's something wrong with this rule.
And you can stare at the rule till le cows come home and you won't
find it because it's there's nothing wrong with the rule. What's wrong is with
the definition of the IP address of Andrew's laptop. You've buggered up the definition
and you've included the entire IT network in the definition. You've got to look
in a different place. You got to look at the definition of each of
the symbols and you know, I forget the details, but there was another
thing where, you know, instead of saying I messed up the definition of
the DMZ network and now you can connect to anything you want. You know,
if you basically these these systems are complicated and it really is easy to
mess them up in ways that just aren't evident when you know, you look
at you look at the definition and you try and understand what it's doing.
So that's how fascinating. You know, have you got anything else for us?
I mean, you seem to be a fountain of examples here. What
what else you know? Can we can we get insights from using technology like
this? These actually in the news pretty much on a monthly, if not
weekly basis, examples of critical equipment being exposed on the Internet and being breached.
Right the latest that I have in nine is uh the water and West
Water treatment facility in i Equipped, Pennsylvania, and that that got compromised just
a few months ago, and the issue came from a PLC with the Human
Machine interface where you know there's a port on those equipment. Actually in this
kiss Ticipate pot twenty five six that was directly exposed to the Internet and then
to make it worse, the password on that machie that the piece of equipment
was a default password from the manufacturer that hasn't been changed, So that got
compromise pretty quickly. And you know, this is the type of finding where
if you have network modeling, you can very quickly, you know, you
import your firewalls, you import your list of equipment from yourdset inventory and you
can see, okay, what's exposed and what's not exposed. So another example
is last year May eleven when you had a cordin need attack against sixteen Danish
energy companies where an attacker exploded vulnerability inside a firewall to be able to craft
arbitrary command and run arbitrary command on those firewalls. So those equipment where netal
equipment were exposed to the outside. But then the neutronsgmentation for the rest of
the environment wasn't strong enough to contain those attacks. So the attackers on you
know what five hundred DP protocol of those six CEL devices were able to to
get compromised and then pivot to your discussion to get the critical equipment inside the
inside those sixteen facilities. And so that's the type of inside you want to
have prior to an attack, because you know the next zero that are going
to get published. You want to have the confidence that you segmentation and the
ZO thing that you put in place with access policy is strong enough to contain
any potential you know, zero day into a you know, vendor of network
equipment to a single zone and not propagetting to the rest of your critical environment.
That all makes sense. You know, we're coming up on the end
of the episode. I want to say thank you so much for joining us
before we let you go, can you you know, sum up for our
listeners. What should we take away from from you know, the changing needs
and the you know, the changing capabilities in the world of network segmentation.
Thanks Andrew again for having me andsure. So really, the the key one
I wanted to make is that verification of network segmentation is becoming more and more
of a priority, and it's it's it's not a one time thing, right,
because the networks of today's networks are just growing in size and complexity and
becoming more and more dynamic, even in inside traditionally more stadic environments such as
out environments. So it's a cyber hygiene best practice to frequently make sure that
the configuration of the equipment and forcing your segmentation so the firewalls, vatters and
switches is correct and you don't have overly permiency rules or gaps that could open
up access to your critical equipment. So to that end, we are about
to release the most capable vision product and PVU that includes that new zone segmentation
metrics to give you a birth sie view of your exposure for your environment,
really helping faster insight and decision making in terms of network risks. And I
invite folks to check us out at at network dash perception dot com for more
information about how we can we can have them. Andrew, that just about
concludes your interview with Robin Bartier. Do you have any final thoughts that you
would like to leave with our listeners. I mean, yeah, you know,
reflecting back on the episode here we're talking about network segmentation. This in
a sense is the oldest trick in the book. It's the oldest tool in
the trade. It's the first thing that was documented in the first volume of
six two four four three, Back when when you know, industrial cybersecurity wasn't
industrial cybersecurity, it was scat of security. It was you know, even
the terminology has changed, and you know, fireballs have been around forever.
Yet you know, this is a new development in the field. I mean,
when was the last sort of big new development in the field. It
was there was deep packaged inspection over a decade ago, is my recollection.
But here's a way to analyze networks, you know, here's a way to
add context to alerts when there's potential intrusions in progress. You know, we've
been talking to some some vendors of asset risk tools, asset inventory tools that
sort of they're working with the the intrusion detection vendors, the alarming vendors to
say, look, this asset is at risk from this attack. That's that's
coming in here because they have information about the asset. Here's an extra step.
The next step is okay, given that this asset is at risk of
potentially being compromised. If it were compromised, here's all of the other assets
that would be at risk because this one's at risk. You know, the
field continues to to to develop. It. You know, surprises me that
that something as old as the idea of network segmentation. You know, there's
there's there's still there's new inventions happening in the field, so you know,
it's it's an interesting development. Well, thank you to Robin for sharing that
development with us. And Andrew, as always, thank you 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.