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!
One of the most powerful modern
firewall features is often not used.
In today's episode of
Threat Talks, the Deep Dives,
we dive deep into identity based
firewalling and why it's so powerful.
So let's get on to it.
Welcome to Threat Talks.
Let's delve deep into the dynamic world
of cybersecurity.
With me today is Nicholai Piagentini.
He's our technical enablement
engineer here
at ON2IT. Welcome.
Thank you. Rob. Happy to be here.
My name is Rob Maas.
Field CTO at ON2IT.
And like we said, we dive deep
into identity based firewalling.
And, before we dive really deep in,
if I was a manager
or at least a non-technical person,
what would be your one sentence to explain
what identity based firewall is?
Yeah, that's an excellent question. Right?
Identity based firewalling I would say, an easy
sentence is that it's defining security policy
based on who the user is
rather than where the user is.
So you more or less answered already the first
question I have here, is what is an identity?
So you refer to a user,
can it also be someone or something?
Very good point, there's
many types of identity.
There could be device based identity.
Is it a BYoD device?
Is it a laptop? Is it a tablet?
There could be AI agentic identity.
Oh that’s a good one. Right?
So it's an AI process that's going to do
something on behalf of a user.
Is it going to act as that user
and have that user's identity,
or does it have a unique identity
that represents it?
That’s a very good one.
Because we now see the agents
all act as the user.
Yes. Yeah, exactly.
And then it becomes
no way to really understand
what is being done by the user and
what is being done through the automation.
So perhaps we'll see those there.
And then there's, I know you do
a lot of work on like Kubernetes. Right.
And there it could be the idea
of containers.
Yeah. Deposit in container. Okay.
Makes sense. [ ], you know, with tagging
right within an infrastructure
as a service environment.
Okay. Makes sense.
So we have all kinds of identity.
Yeah. All sorts of signals.
Identity based firewall well, in
most cases will go with users.
Yeah. But they can be different things.
Yeah. Yeah certainly.
So and you explain it
a bit in your sentence I think.
But why is it so powerful?
I think the thing that makes it really
powerful is twofold, right?
The first thing is that when we define our security
outcomes, we imagine them based on people.
I need Accounting to have access
to the accounts payable records.
And then we have to translate that to usually
IP addresses or something else within policy.
So being able to use the same language
in security policy as we do
in defining what our security requirements
are, is very powerful, right.
Because we don't lose something
in a translation, we can be more accurate.
It can be more dynamic.
Yeah. So instead of saying,
VLAN X or subnet 10.1.2/0/24
has access to accounting software,
we can just say do group accounting users
has access. Absolutely. We'll see often
when they create that address book entry
that 10.1.2.4, they'll name it like accounting VLAN.
Oh yeah. But we don't really know.
Right. It doesn't really actually represent that.
So they name the subnet. Yeah.
But what we really want to do is say
people that are in the accounting group.
Right. So being able to use
that becomes very powerful.
And then the second I think
part that people forget is
having that data in your logs, right.
Understanding who generated it
rather than the IP they generated it
from, becomes very helpful
for following up on anomalies
or any kind of threat hunting.
Right. Or anything you're
doing through the SoC.
It helps to know who is involved, right?
It gives us an idea of what's happening.
So for example, if you got
a firewall log that says,
IP address 10.1.2.3 downloaded malware... Right.
Where are you going to run to. Exactly.
You're going to have to figure out
who was there at that time. Yeah.
What system, what user.
Yeah, exactly.
And how dangerous is it. Was it somebody
that's, you know, on the guest network?
Not important. Is it, you know, the CEO...
Yeah, or even maybe more user related,
someone uploaded a big file
or maybe a confidential file to a
foreign file share, maybe China
or Russia or at least something...
What kind of things
do they have access to?
And how dangerous is that?
You know, if you think about it,
we see a lot of, anomaly based
detection mechanisms being used now,
especially with AI and machine learning.
That is useless if I can't correlate
the activities of an individual user.
Right.
So if I don't have the user identity, it's
very hard for me to build good
anomaly based triggers, right?
To understand that the user is acting
in a way that's different,
because I wouldn't know what the user
was doing without that data.
So those two things.
So first of all, the policies driven by the business,
driven by the users and the user groups.
And the second thing is the insights.
So the logging, the monitoring -
Yes. - are very powerful.
Why is not everyone doing this?
Because this is a really
underutilized feature.
It is underutilized.
Which is just a shame because it is so powerful
and it gives you so much information
right out of the gate.
I think a lot of times people assume
it's going to be difficult, right?
It seems like a difficult process,
but the reality is it's all about finding
where the data is,
where the thing that maps
the user to the IP or the
the tags or whatever it might be.
And then being able to access that.
And while it might be work up front,
once you put it into place
right, it tends to be low overhead.
I'm sure that you've done a lot of deployments
of identity based firewalls,
what are some of the problems that you've seen?
Yes, I've seen numerous
problems, all fixable.
What I always did with customers is
when I replaced the firewall
for an identity based firewall,
I always enabled the identity based
aspect of it, the identity based feature,
so that they can at least see
in the logging the results of it
so they can get confident in
hey, this actually works
and bringing me real value.
Yeah.
But, for example,
a problem I found is that,
if you use Active Directory as a source,
then you log in, in the morning,
in your Active Directory environment
and if you have a desktop, so a static
workplace, the IP doesn't change,
and your computer will
be on for the whole day.
Then the IP address with the username
is being entered into the firewall.
But the firewall has the time
to live next to it.
So okay, after, so Rob is using
this IP address for four hours.
That's my time to live,
and it starts counting down.
But what Active Directory there’s
no renewal of your session. Right.
Unless you log in really
again to Windows.
So if you sit there for eight hours,
then after four hours,
my identity is not known anymore.
Exactly.
So that's one of the problems.
You need to tailor it a bit.
So saying, okay, in this scenario,
you can have it for eight hours
or maybe find a different mechanism
to renew that mapping.
Yes. I've often described this identity
as an opportunistic hunter. Right.
You need to give it, multiple methods
are better than single methods. Right.
So the more you can feed it,
the more accurate it'll become.
That's not always the case, [ ]
... that's the design part that you want.
You should design it upfront.
I won't say it's difficult.
Just requires some knowledge of it. Right.
And doing the work. Okay.
What about,
So we are now focusing on IP addresses.
Another common, I would say
misconception is terminal services
where multiple users are
working on one server
and therefore in most cases
one IP address. Yeah, absolutely.
So the idea of how can I
now map them to that
and what we've seen in
the industry to address that is,
some kind of agent on the terminal
server that can map
not just IP, but source port
to a particular [ ],
so I know the following range of source
ports on the shared IP is a particular user.
Other mechanisms I've seen is,
if we're mostly dealing with web
based traffic, a proxy upstream, right?
Would then maybe interrogate
the user for identity.
And now we have mapped, you know,
a user identity to that session, right?
Even though it’s the same IP address.
It will be in the header of the request then.
And then we can put it
in the header of the request. Right.
I can imagine that will only work for-
Very specific web based tools.
Right. And it has to
be in that environment.
Otherwise you really do need to have
that agent on the terminal server.
Yeah. Where source port
mapping will work for all
network traffic, because that's
just how networking works.
Yeah.
You initiate a session and you
get allocated the source port.
So if you have a specific range
attached to your user...
Then we can always tell.
He's always there. Okay.
The other problem
we see is with NAT, right?
So we have a number
of users behind a NAT.
It's really impossible for an upstream
device to accurately identify those users.
Right.
Because we’re no longer in
a situation where we can,
you know, usually map the source IP.
So that would need to be done
downstream of the NAT, right?
But it would still allow us to do that. Right?
Ideally we have firewalls
in more than one location. Yeah.
And another problem might be good to add
here is the use of service accounts.
Yeah.
So I've seen, a lot of customers
using service accounts,
which is really a good thing.
So don't stop with that. Yeah.
But, if you log into a server, who's the identity
belonging to that IP, is that you logging in
at the server or the service account
running a process on that server. Yes.
And what happens when
sometimes it is under the service account
and other times it's under you.
How do we separate those two
within the IP address?
And that can be very difficult.
That's a very difficult one.
Often we find out that the service
needs to run locally.
So what we say then is
okay, the server
is there, but we ignore the service
logging in to the Active Directory.
So we ignore that account.
And then only people who log in often
the administrators will be met on,
in the IP address mapping. Right.
And then that, you know,... exactly,
exactly that way. I think that becomes
one of the more difficult
kind of points. Right.
Is how many different accounts
might be on the same system.
Or what you see more
and more, sometimes there's
a jump host that they use or bastion host.
But you see also a lot of administrators
working on their own machine.
They have a normal account
without administrative privileges.
But then they do a ‘run as’ if they need to do
administrative tasks and then ‘run as’ an administrator.
This came up all the time when
we were first doing this right.
And the policy that we came up with
was, you know, we don't care
which of the users accounts
they use log in,
whether they're using their administrative
version of their account. Right.
Or they're kind of like, the grated version of the account,
it has to do with who that person is in my organization.
So we would always suggest, not mapping
the,.. ignoring administrator mappings.
Right. It's still the same person.
It's still Bob. Right.
And so Bob whether he’s Bob administrator
or Bob regular user is Bob.
And we write the policy around that. Okay.
Did you ever come across a customer where
you were unable to implement user ID?
So never unable. Just, some were
more work than others.
And I clearly remember
a customer that used,
Novell NetWare
rather than Active Directory,
and we had no tools to
extract data from there.
But sure enough, there was a place
that had great user to IP mapping
and that was in their wireless
access points, right?
They used enterprise
WPA, people authenticated
to the wireless access point.
So it actually gave us
a very tightly coupled mapping
between exactly where a user was
at that moment with an IP address.
And I thought it was actually more
accurate than AD. Right.
Because as long as people were on the wireless access point,
we knew exactly who was at each different IP address.
And the beauty of the
whole solution in general
is that you only need the IP address
and username, and it doesn't matter
where it comes from.
Absolutely.
Maybe you need to tailor it a bit,
but that's all you need.
Yeah. Yeah. That's the
opportunistic hunter.
We want to feed it from as many sources
as possible and let it do disambiguation.
Right. Figure out what is occuring.
Okay.
So what if you're, suppose I'm a user having identity
based firewall, but not using any of these features.
Sure.
Where should I start?
So I think what's really great about it is
you can turn it on and it doesn't
need to be complete day one.
It it doesn't need to, as long as
you don't use it in policy,
you won't be blocking anything.
You can incrementally enable it.
So start with whatever
the default setting type is.
Oh okay. I'll put it in Active Directory
and start getting that.
And that gives me a chance
to start seeing the logs
and validating that it's working.
And if maybe I'm seeing that, oh, I'm having
this problem where they timeout after four hours.
Well, I haven't broken anything,
because my policies aren’t using it. You’ll only have
gaps in your logging where the user name is missing.
And you wouldn’t have had
any data with that before.
So you're still ahead of the game
and now you can fine tune it right.
So you could always turn it on.
Yeah, right.
So you at least get that data in there.
And that's what would be my suggestion,
turn on whatever the default basic configuration is.
And at least start there.
Okay.
And then try to fine tune it.
That sounds like an easy start.
Absolutely.
It breaks nothing. [ ]
Yeah. Exactly.
And what the beauty,
at least in my opinion is
also it doesn't require, for example,
decryption because a lot of next
gen features and modern firewalls,
you need decryption and decryption,
well, you can implement implement it,
but it can be really hard especially outbound.
And it can just, you know,
can block certain kinds of things.
It can break certain
kinds of applications.
It is by no means easy to do, right.
But you're right, this doesn't require
any kind of- In user ID,
it's kind of like flipping the switch
and it more or less starts working.
And after that.
So I have enabled it, I start with it.
I see the logging. What should I do next?
So what you're gonna want to do is once
you start having those user identity
in there, you're going to start
matching them to see if,
things are happening
as you expected. Right?
Am I seeing accounting users on the accounting VLAN,
or do I see other users there? Right.
And it gives you a chance to understand
whether your current policy
set, purely IP based is actually working. Right.
And if it's not, that's
telling you exactly
where you're gonna start implementing
those first user based policies.
Then you already had a problem.
Yep.
Only now you're able to solve it.
Exactly. Yeah, what I normally did
with a lot of customers is,
when I implement this, start
with smaller groups for the policy.
So and then mainly the IT people
because I can easily explain
hey, this as a new feature.
We're testing it out.
Come to me if it fails.
And then when I'm confident that
it really works, I, go to the next user
user group, maybe HR
or whatever department.
Right. And that's what
is great about it, right?
It can be incrementally turned on as fast
or slow as you want for as broad
or as specific as you need.
And that really makes it very low risk.
So it's really easy to start with,
the hard thing is
that you need to think before,
where do I have this information?
Is it AD?
Exactly.
Is it your wireless access point, etc..
Or is it both?
Right. Any kind of sys log...
Oh, yeah. You can override...
These are all consuming
so many different things.
Dynamic groups, tagging from,
you know, cloud environments.
We have so many ways of
getting that data in. Yeah.
Would you say it's an optional feature
to enable nowadays?
You know, it's a great question.
And I would say no.
This technology exists.
Nearly every firewall vendor out
there has some form of it
now, you couldn't claim to be
doing your due diligence
and not at least enable it
to get into the logs, right?
That time has passed. In the modern world,
we really expect identity to be part of our firewall policy.
It's certainly part of our logs.
Yeah, one of the problems
I see here is, still a lot of people,
they migrate an existing firewall
to the new firewall.
But then it’s an ‘as is’ migration.
So they take the rule set that’s in there,
copy it to the next one, and then they sit down
for four years, have the license expire,
renewals coming up, and then they start
with the next migration.
Yeah.
And not looking at any of the features
that these modern
firewalls come with. Because things
are always in such demand.
So once you've migrated it, it's very hard to take
the time to go back and look at it when it's working.
Right. But it's important to do so. Right.
Otherwise you curate that technical debt. Right.
Your policy is old
it’s no longer accurate.
And then that is where we see problems
and we see...
So this is definitely one of the features
that you should enable immediately,
especially, even if it is only for logging.
Exactly, exactly. Okay.
So before we wrap up,
if you need to give one piece of advice
for people that are now thinking, hey,
I should start with this, I should start
with this identity based firewalling
what would that be?
I would say, consider it a success
as soon as you turn it on.
Right. It does not need to cover everything.
It does not need to be absolute.
You don't need perfect
mapping of every moment,
every user. Just getting some of that data
in there is better than the state before.
It's an immediate win.
It does not need to be perfect, right?
You just need to start seeing it in there
and then you'll find that
you want it in there, right?
Once you can start
writing policy based on who the person is
that's going to save you a lot. Right.
I think a good example that we've
discussed, before is, I travel for work.
I need the same access, whether I'm,
you know, here in the Netherlands,
whether I'm in office in Plano,
whether I'm in a hotel in New York.
But all of those are different IPS.
They might be connecting to the office
through different mechanisms.
I would need three different policies
or four different policies, or five depending
how many places I could go.
But if I can write it saying
Nicholai gets this access,
then that follows me wherever I go.
So it cleans up the policy set,
it makes it easy to follow. Yeah,
what we see a lot with customers
for these use cases
that every user that's traveling
gets the same permissions.
And then at the application level
we're going to look at hey
this is user X or user Y.
Yeah.
Instead where we can do it already
at the network level.
And doing it at the network level is critical
because it stops lateral movement
and, you know, activities on target.
Yeah, it stops it immediately
it’s more or less the first
line of defense. Yes.
Yeah, absolutely.
And it should be done there.
Okay. That makes sense.
So then let's wrap it up.
So we said that it's relatively easy,
but it needs a bit of work
up front. Where's my data?
How do I get it in there? Low risk.
But it is no risk.
Low risk or even no risk
I would say. No risk, I agree.
Because it's an immediate
win, you get the logging there and
great insights in who’s doing what.
And then you can slowly expand from there.
So if you have an identity based firewall,
then why wait?
And just start today by
flipping the switch, turn it on
and see what your users
are actually doing.
With that, Nicholai,
I would like to thank you.
Thank you. That was a pleasure.
Great insight. Thank you.
And to you listeners, enable user ID
and I hope, to see you next time.
If you like what you just heard,
just press like and subscribe
and I hope to see you next time.
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.