Subscribe
Share
Share
Embed
Threat Talks is your cybersecurity knowledge hub. Unpack the latest threats and explore industry trends with top experts as they break down the complexities of cyber threats.
We make complex cybersecurity topics accessible and engaging for everyone, from IT professionals to every day internet users by providing in-depth and first-hand experiences from leading cybersecurity professionals.
Join us for monthly deep dives into the dynamic world of cybersecurity, so you can stay informed, and stay secure!
Kind: captions
Language: en
You just built Zero Trust,
and now you want to keep it that way.
Welcome to Threat Talks.
My name is Lieuwe Jan Koning.
And here from headquarters at ON2IT,
we bring you Zero Trust,
step five: monitor and maintain.
Specifically maintain. Let's get on to it.
Welcome to Threat Talks.
Let's delve deep into the dynamic world
of cybersecurity.
This is the final episode of the series.
Is it? Maybe we are going to....
We're probably going to
have more, huh Rob? Yeah.
The for now final episode on the
five steps of Zero Trust is here today.
And last time we talked about the
monitoring part of step five.
But step five is actually
about monitor and maintain.
Joining me today, Rob Maas,
he’s the Field CTO of ON2IT.
And he dreams about Zero Trust every day.
And his goal, one of his many goals in life,
is to make sure that everybody knows
everything about Zero Trust.
Welcome, Rob. Thank you.
We've been talking about the five steps
so far, at least, well, we are at,
last time we did 5A
and now 5B, if you will.
Correct.
Shall we briefly recap the five steps?
Yeah.
So, first step is, define
the protect surface.
So we look at what's important
for your organization,
and build protection around it
by defining it as a protect surface.
And also write down really the business context,
like who's the owner, how important it is,
what kind of data is in there,
those kind of things. Yeah.
So we know what to protect. Exactly.
And then step two, map
the transaction flow. Yeah.
So once we have these protect surfaces
we want to know which protect surfaces
are allowed to communicate with
each other, or maybe are required
to communicate with each other.
Because that gives us good insight.
And also if they are from different
business owners, they have to kind of
have a mutual agreement
that data is being exchanged.
Should we see data between those
protect surfaces in the first place?
Yeah, that's step two.
And then once we know this,
we go to step three.
Yeah. Step three.
So, architect your Zero Trust environment.
It's, I would say always one of
the most important steps,
because then we bring it really to life,
bring Zero Trust really into the operational.
So step one and two
is we define things.
And step three we say okay
these are the security controls
important to this protect surface.
And now we’re going to bring
them into the operation.
So we bring Zero Trust to life.
I know why you like it,
because it involves whiteboarding.
That's true. Yeah.
Make an architectural picture, right?
Okay, now then we know what
to put where, and we can budget
what controls we're
going to buy. Right.
And then we go to step four.
Yeah. Which is?
Yeah, once we have the controls,
so step four is create
your Zero Trust policy.
And it's all about who
or what needs access.
We typically do this
with the Kipling method.
So we get fine grained policies,
defining who's allowed
to have access into a protect surface
or allowing certain processes.
And it's not only policies like
in the firewall sense, but also how should
EDR configuration being configured,
what's allowed, what's not.
Yeah.
This is where it really is
operationalized, the actual [ ]
Here we’re going to really
enforce everything. Yeah.
That’s crucially important as well.
And then we are in step five.
Monitor and maintain.
We did monitor already. Yep.
So monitor is where, once we put
these security controls in place
and we activate them
and they are going to enforce
these policies, they are going
to throw a lot of events.
And we should judge every single event,
whether it needs action or not.
And then we get to maintain.
And that's for today.
And we have a couple of parts in this,
maybe the first we should talk about,
what we put a lot of effort
in, at least as an organization:
policy validation.
Yeah. So, what will happen over time?
Policies will change, the business
will change, it will evolve.
So that means policy
will also be adjusted.
By policy, what do we mean-
We don't mean the policy document
as for your ISMS, so this is
our encryption document.
No, this is really the operational policy.
So it's running in your firewalls.
It's running on your endpoint
detection and response system.
Access rules, netting rules.
That's it, yeah.
The technical policies, maybe is...
Which extensions to allow in
email, all those kind of things.
Yeah.
So and those will evolve over time,
because new access is required.
Maybe old access is not required anymore.
That’s also one of the things,
that you will typically see,
especially with firewalls, if
someone deploys a new server that needs
access to a certain other system,
and it doesn't work, they come
to the firewall administrator
and say, okay, can you open this for me?
This application is needed.
This user is needed. Whatever.
And it's then done.
But, if somebody cleans up a server,
then nothing breaks, because
nothing is being blocked.
And they typically forget
to inform the firewall- [ ] best works
if something does not work, right?
So, they will not inform
the firewall administrator.
And the rule will typically be there
for years because everyone is afraid
to remove rules from a firewall,
because they might break something.
Nowadays, luckily, we have good tools
in place to detect those rules, but
that's something you need to do, to detect
if the policy is still working correctly.
Yeah.
And validating that they’re actually
properly done in step four.
I mean, if there's no logging
enabled on a firewall or we exclude
the whole harddrive from scanning
with our EDR tool, those kind of things.
Yeah, we can easily- Yeah.
You want just constantly, or at least
after every change, check
if the policy is still- A bit related
with configuration management then.
Yeah.
But it's just really checking the,
not necessarily
documenting the configuration,
but the actual configuration
that's running in your environment.
So another example is, people
tend to make temporary rules
even on EDR systems,
that they forget to remove.
What also can happen is that
firewalls nowadays or any other
security solution are often
being managed or at least updated
automatically, by the cloud.
So in the cloud there’s a cloud delivery system
in place that will update your signatures,
but also sometimes push
new features to certain
security controls which you want
to check if you turn them on.
A very typical thing that
happens, for example to
firewalls and proxies is they
introduce new URL categories.
Maybe, so for example, newly
registered domains or a category-
So something that was not separately
kept track of before.
And now it's a new - So we are now
getting into the next subject, indeed.
New features that are available
in your existing equipment.
You're already paying for it.
Let's enable it. Yeah.
And then also, so they will push out these new
updates, but they rarely will activate them.
So for example, newly registered domains,
they will push it out
but normally they will set it;
hey, traffic is still allowed,
because a vendor doesn't
want to have a track record that they push
out an update and things get blocked.
Yeah, exactly.
So they typically push out new features
and then everyone, or at least
a lot of people will forget about,
oh, I can also get new features.
So it will all be allowed by default.
While you can improve your security
by taking a good look, or even maintain
your security, because maybe URLs in
this example, are placed from one
category to this new category.
But this is a good thing
to realize for everybody.
I mean, you have a security products,
it doesn't mean that it stays in the
best configuration after you did a ...
No, the quality will even go down.
Yeah.
So you will get this- Has to be a counterforce
against that then. There should be.
Yeah. So that's what we
tried to achieve here.
But unfortunately, you
see still a lot of people,
and then especially aiming at firewalls
because they are really evolved
over the last ten years.
We discussed this in
the last episode as well.
It's a bit of a pity that people
pay for a lot of features.
And they are typically good
security features. And,
yeah, I would say only
enable half of them.
Yeah.
Yeah, it can... but it makes
sense, because hackers
also evolve their techniques
and a firewall vendor,
endpoint protection vendor should evolve
their product to combat those as well. So.
Correct. Indeed there's some kind of
decay in effectiveness of your equipment.
Yeah. We really, we used to do it with,
I think everyone nowadays agrees
that a traditional antivirus
solution is not sufficient anymore.
And we should move to EDR or XDR tools.
But for firewalls, it's okay,
I need to have a new firewall.
But we often forget about
all these features that come with it.
Yeah, yeah, even if there's
a hardware refresh or
say you bought it three years ago
or five years ago, you want to refresh it,
don't simply copy the, well, you could copy-
Yeah, as a starting point it’s okay,
but then you need to look at
all these new features
and what they bring to you and evaluate if they
are applicable to that protect surface or not.
But that's not necessarily just
when you buy new equipment.
No, it's also in the running period,
because features will be pushed out.
Okay. Often overlooked, right?
I would say almost always, yeah.
Yeah, that's a pity.
Especially because it’s for free,
I mean, it's a security...
Yeah. You already paid for it.
Yeah, yeah.
Traffic flows.
That's another thing that
we need to maintain.
Yeah.
What do we mean by that?
So in step two, we define the
traffic flows from a definition phase,
which protect surface
should be allowed to communicate
with another protect surface.
That the business owners should agree up on,
so mutual consensus between those two.
And we define, okay, these are
the flows that we expect.
But then now we're in the running phase.
We can take a look at hey,
what flows did we see?
And maybe there is a flow defined
that we expect to see, but it's not there.
So where's the mistake, did we
maybe make a mistake in step two?
Or did we configure something incorrectly?
But also the other way around, if there is traffic
between protect surfaces, where there is
no flow defined, why is the traffic there?
Is it valid, or maybe it indicates something different,
that people are moving around laterally.
So we also want to investigate on that.
Yeah. Yeah.
But in theory if you do step two correctly,
you exactly know what you need.
And in step three and four;
in three put the controls in place
so you can actually block stuff that's
not compliant with step two outcome.
And in four you make the right policy.
Then you should not see anything here.
No, normally they should be perfectly aligned.
But like we said, in the running phrase,
things will change and evolve
and we will not do step two every time...
Plus people make mistakes.
People make mistakes, that as well.
But this is a good
way of checking the job
you have done before,
if it was correct or that maybe
things have changed in the
last couple of months or days,
depending on how often you check.
Yeah.
Another subject is a behavioral analysis.
Yeah.
So, with all these logs, so we discussed
this, also in the monitoring part,
you get a lot of information
on what's going on.
So with the monitoring part,
you typically focus on the events.
But all these logs can also indicate,
hey, there is something going on.
So if you collect the logs and typically
you do that in an XDR system
sometimes referred to as
next gen SIEM, or SIEM 2.0,
but in general, XDR was the
product that brought this feature.
And then SIEM vendors
also try to embed this.
But the idea here is
we have a lot of logs.
And if you put machine learning on that,
you can define baselines.
Hey, this is what's going on in my
environment, this is normal behavior.
And then if something changes
and there's a big enough delta
between the baseline
and the new seen traffic
or a new seen behavior,
then you can throw out an alert
and say, okay, here it looks like
there's something going on.
Maybe it's perfectly fine and
you just need to adjust
your environment a bit.
But it can also mean that there's really something
going on that you need to investigate.
The downside I would always say
with behavior analytics
is they can also come
with a lot of false positives.
So, for example, if you're a retailer,
then you have your normal traffic flows.
And then during the holiday period,
it will probably spike.
And if you don't do anything, then those
systems will cause a lot of alerts.
Yeah, yeah.
In spikes, if you fail over a portion
of your application [ ]
... a lot of false positives are involved here.
But once you have everything
set up, I think this is
one of the last steps you can take
to really get to a high level.
Okay.
Another one that we see
going in the wrong direction
a lot of times, is about
architectural changes.
For example, we are moving towards,
the cloud, or we are moving from
an on prem Kubernetes cluster
into the cloud or vice versa,
or from one cloud to another.
VMs are being migrated to containers, etc.
And then from a network perspective,
you may think that
you have a segmented
network, which is true,
but then all applications are getting
into this one platform,
when from a network perspective,
that is certainly no longer the case.
Yeah. Okay.
Can you explain a little bit about that?
What we typically see there?
Yeah.
So, what you already told,
everything is true there, but another one is
also within cloud, there's a lot of
evolvement going on and typically DevOps
teams are really on top of that.
So they also want to include
new features, are going to migrate from,
traditional security within Kubernetes,
for example, to go to a service mesh.
And now even the service mesh is
evolving, by removing sidecars.
So there's a lot of movements
within the architectural changes-
This is important, because with sidecars
we were able to see traffic, without
we cannot anymore, right?
[ ] At least you need to change
your controls on that.
So your controls should adapt as well.
And whether it is a control or not,
you should know that
before you make that change.
And then you can decide, okay,
we are going to accept the risk
that will be included or not.
But this basically means
if you have these changes
or these changes coming up,
you should go back to step one.
That the information is
probably still correct.
We said in the introduction that
five would be the last step,
but you're now saying
that we have to start over.
It's repetitive, especially if you're
doing big changes, you should go back,
step one, step two, step three.
And well, you’ve done the work already,
so probably there will not be
much change in step one and two.
Maybe the owner will change,
or maybe a few flows will change,
but especially in step three,
if you really move from one
environment to another
with different possibilities.
So for example, on prem to cloud or from,
VMs to containers or to a
hosted Kubernetes service,
you get a lot of different tools
at your disposal.
So it's up to the architects
in step three.
Hey, these are all the measures
that we want to take.
Our complete environment is going to change
now, how do we implement implement them?
How do I migrate all these security
controls also to this new environment?
Yeah. So then in step five
you detect these things.
So step five there is a trigger
to start over at step one.
Yeah. Maybe they moved
things, for example you don't
receive any logs anymore
about two surfaces that used to
communicate between VMs.
And going with the firewall in between.
And you see all this traffic.
And now they moved everything
into a Kubernetes
cluster, where there's no firewall involved,
because the network team was not
involved in this whole migration. Aware.
Yeah.
And then you see nothing anymore,
and you even might see if you do,
if you have your processes right,
you see, hey,
this rule is no longer used, i can simply
remove it, hey that’s strange, two very important
business processes.
And then you should ask yourself,
okay, what's happened here?
And then you probably find out, okay,
they moved it and we need to-
[ ] ... so in the transaction flow
you defined the two protect surfaces
cannot talk to each other.
And suddenly because of
the migration, they now can.
Yeah, you don't see it.
So you used to see the traffic there
and now you don't see it anymore.
So the network team, so in a lot of companies,
especially the bigger ones, we have different teams.
You have a network team,
you have a cloud team, etc..
Then maybe the cloud team
implemented something
and now the network team is blind.
Yeah.
Important then, to make sure
that the Zero Trust
philosophy is actually embedded and on
a higher level in the organization even,
not at the CIO level or even the CISO
level, but actually beyond that.
Right? Yeah. On every level it should be..
people should be included.
And if a developer thinks, hey, I'm now
going to use cloud native tools
that are at my disposal,
hey, this might impact security.
Maybe I should discuss, if you need
to adjust something here.
All right.
A lot to maintain. Yeah.
Unfortunately, it's ongoing.
But it’s for a good cause.
But what you said,
maybe let's highlight that.
Once you've gone through those
five steps and you need to redo it,
the big things are already done.
So it's like an adjustment, you just have-
So maybe the owner changes, or maybe
some of the controls change,
but typically only a few things change.
Yeah. Or a different brand of firewall.
You still need to implement
similar features. Yeah.
Okay. Well, Rob, thank you very much.
This concludes the second
part of the fifth step.
Monitor and maintain, the maintain part.
And now we start over at number one.
So we will actually provide
a playlist on YouTube.
You can set it on repeat. If you really want to experience
full Zero Trust, then put it on repeat, indeed.
Yeah, okay. Thank you.
And to our listeners and viewers,
thank you as well.
We enjoyed that you tuned in for us
and if you like this as well,
please like this video, because
we would like to spread the word further.
And if you also press the subscribe
button, the next episode of Threat Talks
will also be in your inbox.
From headquarters here at ON2IT,
I thank you once again. Bye bye.
Thank you for listening to Threat Talks,
a podcast by ON2IT cybersecurity and AMS-IX
Did you like what you heard?
Do you want to learn more?
Follow Threat Talks to stay up to date
on the topic of cybersecurity.