Hello and welcome back to check point jump start training
in this module, we're going to get into creating a security policy.
So a security policy
we're gonna talk about what that is.
explicit and implied rules
sections, which allow you to visually organize your rules
objects, which are used in rules as,
for instance, matching criteria. Should this rule match well on Lee, If the source
is this network object,
then we'll look at policy layers and policy types.
there was a lot of new functionality added
then publishing and installing policy so that it is in production. It takes effect
and we'll demonstrate this.
So a security policy is
can represent hosts or networks or services or other things
which can be per policy
but also global property settings which
applied everything managed by this management server
and rules rules are sort of the meat of your policy. They decide
what traffic should be permitted,
what traffic should be dropped
and to do other things such as decide whether or not we want toe have mawr inspection of this traffic.
your policy is built
from rules that you explicitly ad
So in this screenshot is a very generic example
of a policy with rules.
note the number column
rules air sequentially numbered from one to the last rule. And when we get to rule for something interesting is happening, I'll talk about that.
The name column is yours to set. It should be something pneumonic that explains
intuitively what the purpose of this rule is,
because when you look at logs,
a log entry will have recorded which rule number
generated that log entry. But if I see okay, so this traffic was dropped by Rule 47. That doesn't really help me very much.
We'll also include the rule name. And so if I see that Rule 47 is the no file sharing rule, okay, that makes more sense.
Then we have matching columns, source
services and applications
data, and you can't see it because we haven't scrolled over to the right. There's also a time calling
and so source destination
post objects network objects
for source. You can also have identity based policy where we need to know
is the the user that is initiating this connection. What would group are they enter? Groups? Are they a member of the accounting group? For instance?
something that you see in the source column. Not really in the destination column.
VPN COLUMN does not decide if traffic should be encrypted
and transmitted via a site to site or remote access VPN instead.
The VPN column allows you to restrict a rule from matching
so that it can Onley match If the traffic is being sent through this specific VPN connection or
the set of VPN connections,
services and applications allow you to match well a service which is destination port and protocol
443 TCP. That's https,
your checkpoint deployment will come with all of the
internationally recognized services
already defined as service objects.
And then, if you have
other functionality enabled, such as licensed and enabled, such as the U R L filtering or application control features,
then you have additional
objects which can be used in services and applications such as, ah, very,
very broad risk categorization of the website that the user is attempting to access if that website
high risk or critical risked, and we're just not going to allow it.
categorize traffic by the application associated with that traffic. For instance,
Office 3 65 Twitter, Facebook and so one.
You may not see you have tohave
one of the features that looks at data such as content awareness or data loss prevention.
In order for that column to be displayed.
The Time column, which you can't see, allows a rule to match Monday through Friday 8 a.m. to 5 p.m. Local time. That's local to the security gateway
that's evaluating the policy,
but you can also have
in the time column and object that says
And that's a nice way to add a temporary rule, a rule that we gotta have for now. But
the rule should be turned off, and instead of a human administrator having to remember on that date log in turn that rule off, we can simply create a time object that specifies this expires on this date
and use that time object in the Time column of the rule. The rule will then automatically stop matching. It will be disabled
Now. The action column.
a rule is added to your security policy, the default action that set is dropped.
There are other actions available. For instance, Rule number one.
The action of that rule has been modified to be except and well, you need at least one rule that accepts traffic or your firewall
if you look down at Rule number five at the bottom, the file sharing rule
that rule says, if anyone is going out to the Internet
to a file storage and sharing application,
the action isn't except, er drop, its asked, and this is called a user check interaction.
is generated by the security gateway. And that Web page will have a message.
Are you sure that you want to be going to the side? It's categorized as such and such
Check this box to say yes, I'm sure and click this button
It gives the user a warning, but it's not a hard know If they have a reason,
then they can proceed.
But you know, this stuff is being locked
log so you can review logs and follow up. Well,
what were you doing at that file sharing site? Justify this?
by default is set to none. But best practice actually says
every rule should have a tracking action of log.
And with that, if the rule has attracting action of log and that rule is matched, then a log entry is generated with information about the connection that matched the rule
that had the log tracking action.
There are other tracking actions will take a look at those. So
in most deployments,
there are some just general rules that are pretty
For instance, management access rules that allow
authorized firewall administrators
security gateways and security management servers. Another checkpoint infrastructure.
The ah secure shell, or https.
is intended to catch all traffic directed at the security gateway itself.
So it'll have in the destination column
the security gateway object. If you have multiple security gateways,
all of their objects,
it has an action of drop
and a tracking action of log,
and that way if somebody your your security gateways air, often Internet facing their bastion hosts there directly exposed to the Internet. If somebody's port scanning your security Gateway
stealth rule will drop their traffic
and long the fact that this was happening
Critical sub net and tech support
You may, for instance, have network administrators who need access to layer three switches and routers and so on.
We can restrict access to these critical network infrastructure hosts
from, for instance, a trusted sub net or, if you're doing identity based policy, somebody in the Net Admin group
DNS. Male SMTP rules allow access to these fundamental services
whether the DNS server is internal and you want to block access to external DNS servers.
Male and Web servers are typically on a demilitarized zone. D M Z, which is
Internet facing host all of your servers that must accept incoming connections from the Internet. And that would be, for instance, and email server
Those servers are isolated physically on a demilitarized zone network,
you have security policy that
really limits what can come in and out
the Internet is only allowed to connect to the SMTP port
on my SMTP server. No other port,
the Internet is Onley allowed to connect to the https port on my Web server. No other port
and best practice is
you do not allow AH host on the DMC network to initiate
a network connection to your internal trusted networks.
Because since the D M Z host or directly exposed to the Internet there, it elevated risk of compromise.
That's not always possible. Sometimes you have to allow a D M Z host
who initiated connection internally.
least access. Allow Onley what must be allowed
and nothing else and definitely have an action of track on the rule that allows.
You'll also have, AH, rule to allow internal users out to the Internet, and you may limit the services
that they're permitted to use going out to the Internet,
for instance, you probably don't want them doing S and M P or
Windows file sharing across the Internet.
And finally, the cleanup rule
is another checkpoint. Best practice
cleanup rule should be the very last rule in your security policy.
It should always match so all of the matching columns are any
it should have an action of drop
and a tracking action of log.
The idea with the cleanup rule is
did not match any other rule. In your policy, we evaluated all of the rules one after the other, none of them matched. We get to the cleanup rule that will match,
will drop the traffic and logged
because traffic that made it through to the cleanup rule is really unexpected traffic.
You put rules in for the traffic that you were expecting.
So the cleanup rule is showing you unexpected traffic and that could be useful for threat intelligence,
Now it's not strictly necessary
if no rule matches, we have a connection
that would not match any rule in your policy. So it falls off the end. Well,
waiting for it off the end is an implied drop.
Check point will drop that traffic, but it doesn't log it.
allows you to log that traffic
allow you to visually organize or break up your rules.
So here we have the first section which we've named the section security gateways access
and inside of that section
is all of the rules,
from the section to the next section
or the end of your rules.
So the first section is just rule wanted to, because there's another section before rule number three, the VPN section
and so on. So if you have 100 rules,
you have just these two sections. The first
section would be ruled wanted to, and the second sexual would be ruled three through 100.
triangle box at the left of the section name
allows you to collapse that section. If you click on that triangle, it turns sideways faces, right, And
all of the rules in that section are not displayed. That gives you back a little bit. Mawr screen, real estate. A little bit more vertical vertical space.
So if I'm not dealing with security Gateway access, I'm working on VPN rules. I can collapse. The security Gateway Access section
rules that are collapsed.
You can't accidentally modify, so that's a nice thing.
So I've said that checkpoint is a default. Deny firewall. If we don't have a rule that matches and allows traffic,
the traffic is not allowed.
some things are still being allowed, for instance, connections from the management server to the security gateways to install policy
or from the security gateway to the management server to send log data.
in addition to the explicit rules that you see in your policy
checkpoint ads implied rules.
The's implied rules are there to allow checkpoint to function.
add or delete implied rules.
And some implied rules, specifically the ones that permit checkpoint functionality toe work,
are enabled by default. They're not displayed by default, so you don't see that these rules are there.
And most of these implied rules are first.
What that means is they go above your rule number one so they get to match before
and no, here we're viewing implied rules,
they looked a little bit different. They've got a different color background. You've got some weird objects in the source and destination columns,
but these implied rules
are put there by checkpoint to permit checkpoint protocols
I said that you cannot add, delete or edit implied rules.
You can turn them on and off
global properties, and we'll look at global properties later
have a rule that conditionally matches instead of matching all the time.
You never rule that matches on Lee. If the service is this
so the most common types of objects that you'll be working with our network objects, such as a host or sub net or a range of I P addresses
and service objects.
And if you have the URL filtering or application control or other access control blades enabled,
you are l filtering categories or application objects available as well.
I mentioned timed objects
and user check interactions, which, which is where you can present a Web page
to the user who is trying to connect somewhere and say, Are you sure
you can also present a Web page that says You can't go there?
And it's a little bit more user friendly than a drop action because of drop action? The connection times out
with the user check interaction that says no. Well,
they get a Web page that maybe explains why
so objects could be managed multiple places in smart Consul.
In this example, we brought up the Object Explorer window, which allows us to search for objects by name by I p address by any property of the object,
and we can limit our search in the categories menu off to the left.
I'm Onley searching for network objects.
So in your security policy,
you must have access control policy Access control policy includes ire, Wal Policy and, well, firewall policy is required. It's the fundamental
packet filtering at ST full inspection components
of a security gateway
Threat prevention policy is optional, and we'll talk about what those policy types are,
Checkpoint allows you toe have multiple policy packages.
Policy package is in a in effect, a wrapper around your access control and threat prevention policy
to have different policies for different groups or types of security gateways.
For instance, you might have set of security gateways that our Internet facing external
might have a different set of security gateways. That our internal compartmentalization
and 1/3 category of security gateways, which are used for VPN connections
the policies that each of these three types of
gateways should receive are different,
have different functions. They have different needs,
so you can create a policy package for each security gateway
or each group of security gateways
and tune the policy to the needs of that particular
class of security, Gateway
and within a policy package
policies on, and we'll look at that.
This is something that's new in our 80.
The ability for a policy package toe have, say,
three access control policy layers
and some of these layers, maybe more generally, applicability.
I have a policy layer
that actually it makes sense to use this on my internal compartmentalization gateways as well as my exterior Internet facing gateways.
So rather than reinvent the wheel and have
two copies of this policy in two different policy packages can have just one
policy. It's called a policy layer
and then use that in both policy packages.
And if you make a change to that shared policy layer, well, that changes reflected in all of the policy packages,
We'll talk about how layers can be ordered or put in line.
I mentioned there's Access control and threat prevention, focusing on access control
and your access control policy. You must have at least one layer, and that layer must
be at least a firewall layer.
That's a requirements. Gotta be. First, it's gotta have firewall.
And that firewall layer implements your
packet filtering state full inspection functionality. It can implement other layer seven functionality,
but it's needed for packet filtering and state full inspection.
but okay, You you have your firewall layer. That makes a preliminary decision about what traffic should be allowed. What traffic should not.
If we match a rule in this firewall layer that says drop, then we're done.
We don't need to continue looking at other layers
and again within a layer.
We checked the rules sequentially from top to bottom. Rule number one. Are you a match? If not, rule number two Are you match,
if not real Number three are you? Match your match.
What's the action? Action is dropped. Well, we're done. We're not gonna let the traffic through.
On the other hand, if the action is except
at this point, we're going to go ahead and allow the traffic.
There's another layer waiting to be run, so we'll start running the rules in that layer from rule number one.
So here we've got a second layer which implements application control policy
using the URL filtering and application control functionality,
first the traffic must be allowed by the firewall layer. And maybe that just had a general rule. That said of the services HTTP or https, the action is, except let it let it go.
But in our second layer, the application control policy layer, we take a more detailed look at layer seven.
here we look at what website are they requesting?
What's the category of that website? What's the risk factor of that website
allow or deny decision based on layer seven data?
And then the third layer, for instance, might be some sort of data awareness or AH,
or something else where if you are attempting to send out
an attachment that has payment card information or
or national identity number information,
something like a private key.
Then we can stop that in the third data control layer. And there's a couple of
features which which use that
a layer can be used in a policy package
either ordered layer one layer to layer three or in line,
and we'll take a closer look at
using a layer in line in a moment.
So if you have multiple layers that are ordered, layer one layer to layer three.
we must pass the first layer. You must match a rule whose action is, except
otherwise the traffic will not be allowed. We don't evaluate any further layers.
We got down to rule number 12 and rule number 12 match the connection and its action was Except
so right now, our choice. Our decision is we're going to accept this connection. We're gonna let it through.
Then we started evaluating the next layer in this policy package. Layer number two.
We got down to rule number 10 before we had a match, a rule number 10 matched and its action was dropped.
So final answer. We're going to drop the connection.
And we never got the layer three.
So in an ordered layer, we start with rule number one. We evaluate. It doesn't match. If not, we go to rule. Number two doesn't match. We do that until we match a rule in that layer.
you should have a clean up room so that cleanup rule will match. If nothing else did
then, once we've matched, we take the action. If the action is dropped or something similar, we're done.
If it's except then we continue on to the next
in the policy package.
Another way of including multiple layers in a policy package is to make one layer in line to another.
In this example, we have our firewall later,
and it has rule number one rule number 2345
But real number two of this firewall layer.
The action isn't except or drop.
layer in line and the name of the layer it's using in line is you are all filter
in the URL filter layer has two rules.
So first we have to match rule number two. So that implies that we did not match rule number one.
We evaluated Rule number two, the outer rule number two. And that's a match.
So we see the action of this rule is run this in line layer. So we bring up the U R L filter layer. We evaluate that
first rule of the U. R L filter layer,
which, since its in line is
got one, so rule 2.1
So we fall through to the next rule in that in line layer to dot to,
and it had an action of. Except
so that's going to be the decision of this layer. Now There may be other ordered layers behind this,
but as soon as we match rule number two, we were not gonna look below that for Rule three or four. We matched Rule number two,
and it's an in line layer, so we start running the rules off the in line layer.
And if we had matched 2.1 that said drop, we would be done.
We matched to dot to which says, except so provisionally, at this point, we're gonna accept and allow the connection.
But there may be another ordered layer next that
has a different decision.
Threat prevention policy.
A little bit different. Threat prevention policy
the intrusion prevention system, and I bought antivirus threat emulation
features that are optional.
You can have multiple threat prevention policy layers in a policy package
again. Remember that a policy package must have an access control air because you gotta have firewall layer.
it may have threat prevention layers. So, for instance, your VPN security gateways, perhaps they don't need threat prevention.
So the policy package for your VPN servers
as an include threat prevention policy.
if you do have threat prevention present and a policy package,
it can have one or more layers
access control policy layers there, either ordered or in line or both. You can have
or some of them have an in line layer,
and again we start with the first layer. Rule number one doesn't match. We do that until we find a rule in that first layer that matches. And if it's action is dropped, then we're done.
It's action is, except then we go to the next layer,
and if it's action is an in line layer will. Then we run the rules of the in line layer,
so it's very deterministic
What the order of evaluation will be in access control layers.
Threat prevention layers, on the other hand,
simultaneously apply to all of your enabled threat prevention features such as I PS
and I bought etcetera.
Traffic is matched against
all of those features in all of the layers simultaneously
is not a define herbal order for how that will be matched.
And if one layer has a verdict of don't allow this traffic
and another layer essentially simultaneously says, allow the traffic. Then we go with the safest option, the most strict option,
so we won't allow the traffic.
I mentioned Global Properties, Global Properties,
our settings that apply to all checkpoint devices managed by this management server
screen that you get when you bring up the global properties window
configures or controls the implied rules. So
control connections. The first option.
Those are the rules that permit checkpoint functionality.
And then there are some other
such as except outgoing packets originating from the gateway. And the purpose of that rule is if a security gateway wants to connect out to the Internet,
For instance, toe check for updates or download
antivirus signatures or what have you
Note. The positioning dropped down. Ah, some implied rules. You can't set their position. They're always first. But
allowing outgoing packets from a gateway
that actually you can control where it's placed first, which again puts it above your rule number one.
There's also this option before last. So that puts it above your last explicit rule, which again should be the cleanup rule.
And anything after the cleanup rule will never get to match because the cleanup rule should always match.
So we have this special case before last
put it above the cleanup rule. That way, it's blow all of your other explicit rules.
But above the cleanup role,
There is also a drop down option there last which you would not normally use because you have a clean up rule.
And at the very bottom there's a tracking option. Log implied rules. That's all or nothing. You cannot individually decide which implied rules to track.
All of them are none of them. And so if you check that box than
traffic, which is permitted by an implied rule,
If you don't check that box, it's not checked by default.
In traffic, which is permitted by an implied rule, is silently allowed, and there's no logging.
you're an administrator. You've signed into smart Consul,
and you're making changes or perhaps creating
When you are done with those changes, you must publish your policy for the management server
in effect, that updates the master database off checkpoint configuration on the management server. With your changes
and recall and an earlier module, I mentioned how you can have multiple simultaneous administrators
when an administrator makes a change to some rule or some object that becomes locked. Other administrators can't change it
until the administrator who changed it publishes their changes, at which point their changes become visible to everyone else.
We also need to remember to install our new policy.
Your changes are not in production. They're not effective on your security gateways until you install policy
and you must publish before you install policy.
However, if you click on the install policy button
and you have unpublished changes,
then it will tell you
you are required to publish your changes before installing. Click here to publish,
and it will just publish for you.
All right. Now, let's proceed with installing policy.
When you install policy, you designate the installation targets, which are the security gateways that you want this policy to be sent to.
And if you have multiple policy packages like an external Gateway policy package and internal Gateway Policy package of VPN Gateway Policy Package,
you can configure the policy package with
the set of installation targets for that policy package.
There were only installed to those security gateways, not everyone.
So when you click install policy
he currently selected installation targets. It's by default all of your security gateways. You can change that.
We'll start the process of getting this new policy policy. So any changes that have not yet been published, you have to publish first.
Then, for each installation target, the management server will construct an individualized
low level firewall policy
will transmit that firewall policy to that security gateway,
which will between packets switch from the old policy to the new policy, and it will then inform the management server
The management server will keep your smart consul application up to date your the security gateways that are still processing here, the security gateways that have successfully installed policy and here the security gateways that
Putin. Because perhaps they're down right now
or there's some error.
So I'm going to demonstrate creating a policy package and
then in that policy package, enabling both
access control and ah,
threat prevention policy
and then creating rules in the policy package.
by looking at the standard policy package. So selected security policies
I have two tabs displayed and won the Tabas labeled standard. That's the name of the policy package
and that standard policy packages created when your management servers first initialized. It just automatically creates a standard policy package
with a access control policy that contains firewall rules
the firewall rule that you get has.
It's just one rule, the cleanup room.
So I've slightly modified this access control policy. You
traffic from the management network out to the Internet,
What I want to demonstrate is creating another policy package and
customizing that policy package.
So if I click the plus sign here, there no other policy packages to manage,
so that automatically shows me the manage policies tab. And
here we can see that there is indeed Onley one policy package standard policy package.
I want to create another policy package. I have to click here in this
manage policies and layers.
here I can create a new policy package and its policy package. I have the two major policy types available Access control, which includes firewall that's required
and optionally threat prevention
tell it. I also want threat prevention policy.
under installation targets, I can customize which managed security gateways
should receive policy from this policy package. The default is
all security gateways, though at policy installation time, you can uninsulated specific gateways that they shouldn't be receiving this policy.
what's easier than uninsulated ing security gateways every time you install policy is to simply configure the policy package
for specific gateways. And I only have one gateway in this example environment.
when I installed this example Policy,
it will automatically know that the only gateway that should receive it is a gateway.
Well, that's the only gateway, but we're ignoring that for now.
under general is I can specify layers
both access control layers and threat prevention layers.
It doesn't really look like it right now, but
threat prevention does have one layer automatically. There's always at least one layer for the policy types that are selected.
So for access control policy,
I do want another layer
or application control.
There are currently no other layers available. I have to create that layer.
AP Control. Underscore u R l f
because I want this layer to contain
application control and you are l filtering or there's sort of a bundle you can't have just one or the other, but you can do is just not use any application control objects or use any URL filtering objects.
I'm probably gonna use both.
just for application control. You are l filtering policy,
if there are other policy packages that want to use this application, control your URL filtering layer.
I've enabled that this layer can be shared between multiple policy packages.
what should happen when
we run off the edge of the policy. We've. We've evaluated every rule in the policy,
and for this connection, no rule has matched.
So fall off the end of the policy.
behavior of the firewall be? When that happens, the default is we dropped the connection. If you don't have an explicit or implicit rule
to permit, then everything else is denied,
and that's appropriate for firewall policy. But for application control policy, that may not be appropriate. And so I want to change that to
well, if it doesn't match an application. Control your oral filtering rule
it already past the firewall policy that comes first
by the time we get here, just means that we didn't match anything that in an application control you are all filtering type policy.
You're usually blacklisting these air the sites that I don't want to allow.
So if I didn't match any of the rules in this policy that that
describe sites I don't want to allow,
perhaps I want to allow
again. As practices, you don't hit the implied cleanup action. You should have an explicit cleanup rule at the bottom of your policy layer
either accepts or or or drops the traffic and then has a tracking action.
And I'm gonna go ahead and set that up. But
still, I want the implied cleanup action for this layer to be except
a one Other setting gear available is permissions. This gets into checkpoint administrator permission profiles
so I can say that any checkpoint administrator who's currently managing policies
who is in this permission profile
should be able to edit this policy
that allows for even more granular control over which checkpoint administrators can make changes to which layers
for this application control your URL filtering layer. I'm just leaving the default.
Those that are in the Super User Permission Profile, which built an administrator I'm using, is
or another permission profile
read. Write all. But you can't manage other administrators.
Both of those permission profiles. Administrators who have been assigned those profiles can edit this layer.
created that layer, there's one more than I want to create
Ah, content awareness layer.
will contain just content awareness policy.
I also want to designate that this layer should be shared
necessarily need to change the implied cleanup action because I'm gonna have an explicit cleanup rule in this layer as well. But
and change it toe except
and I can also set the permission profiles that are allowed to modify this layer.
I've created this new policy or policy package, I suppose, is the old terminology.
Once it's actually been created, we're sort of waiting for my slow virtual environment here.
Then the next step is to populate this new
policy with well rules.
has been created, and you can see that there's now a tab external,
for example, co underscore policy.
That tab is selected. So I'm currently looking at that policy, and you'll note that, Ah, you see the layers that I added to this policy
over under access control on the left
and the network layer, which is firewall policy, has automatically been selected.
I'm gonna dismiss the layer management window here
maybe populate this layer. So again,
whenever you create a layer, you get a clean up rule
and the default action of that cleanup rule is to drop
in this firewall layer. That's what I want. But also, the default tracking action is set to none.
Best practices. It should be set the long
now This install on column by the way
it defaults to the vague term or object policy targets. And what that means is we want to install this rule
on every security gateway that we install the policy to.
You don't have to do that. If you have a rule that's really only appropriate for one of your security gateways,
then you can select that gateway, or you could have multiple gateways in the install. On column and that rule will essentially Onley be
sent to only be effective
on the security gateways that you've designated in the install on column. Now, other rules in this policy
that have the default policy targets
the other rules, but not this rule if they're not selected in install on.
So my firewall policy is very basic right now. In fact, it's not very useful because it's gonna match every connection and deny it. Drop it.
So I'm going to create
I will call this the demo rule
and this rule I want to match all traffic.
Oh, by the way, I'm still editing the name column. Here you can click somewhere else to finish editing or just hit the escape. Key
it in the escape Key says, I'm done editing that name field,
I want tohave this demo rule that allows traffic out
But I can't have a demo rule that the sources any the destination in is any the services and applications is any.
The time column over
that you can't see is ah is also any because that's a rule that will always match
a rule that always matches above any other rule because that means the rules below this demo rule would never get a chance to match. And that's actually an error.
The checkpoint policy installation process will evaluate the policy that you want to install for errors,
and that's an air If it sees that there's a rule that can never be matched because above it is a rule that would match in every circumstance.
But the lower rule would match
the above rule would always match, and we would stop evaluating the layer. And so the lower rule
can never match. That's an error.
So I I need to distinguish
demo rule in some way, and I could just disable the cleanup rule or do something else. But instead
I'm just going to put in a couple of conditions,
both your coming from the Management network
the internal Network
and in an earlier module I created this internal networks group, objects,
which contains both the internal net 192.168 that one
and another internal net 1 72 not 16 12
I'm just going to select that.
So now if the source of the connection is either something on my management network or something on my internal networks.
this first rule, the demo rule, should match.
But there's at least the possibility that there could be connections that don't match Rule number one, in which case we get down to rule number two. So this will pass that
that error check that policy installation does.
Yeah, and this is just a demo in a production environment. You would, of course, have many more rules
that have much more granularity.
Under the application control, you are all filtering layer
When a layer is created, it gets a cleanup rule
here. I want the cleanup rules action to be, except
I could just select it.
And I want to track when we match the cleanup crew.
recall that the tracking action here you have a couple of options under more
If I My mouse, is being a bit
and so the tracking action
still log. But I also get the option of detailed and extended locks, and I'm just going to choose extended logs.
really, what this does is it
creates the regular log entry, but it populates it with additional information, leaned from layer seven inspection.
So the URL application control blade here
has layer seven awareness of the http or, if you're decrypting SSL, the https requests.
category of website are they trying to get to?
application, if any, is that website associated with such as Facebook or
or in some other popular application, Twitter, LinkedIn? What have you
And if so, then the application control you are l filtering blade can contribute what it gleaned
to the log entry. And that's what this extended long does.
My cleanup rule says
anything is allowed will log that.
I wanna have some things that aren't allowed.
And these are things
according to the application control.
The problem spelling.
aptly named No dangerous or bad sites rule.
I don't care about the source of the destination when I mostly focused on. Here is the
though in the Service and Applications column,
many thousands of service objects automatically created
here. I I'm not really carrying so much about this service.
You are l filtering application controls on Lee Apple Global for a specific sub a sub category of the services http https and a couple of other protocols.
what's displayed here to just
you are l filtering categories. I can also limit what's displayed here to specific applications or sites.
I must start with u R L filtering
just select some high level
You are, oh, filtering categories
So here's a generic category the critical risk.
So this is applications websites that may bypass security or hide identity.
Is there these air known bad website?
Also, this is my default sorted alphabetically.
The high risk websites air those that may cause data leak or malware infection without the user knowing.
So I suppose websites that cause malware infection with the user knowing are okay, I'm not positive here.
Uh, and then maybe a couple of other
and also perhaps of applications should be listed here
again. This is something that the
application control you are l filtering blade is contributing thes objects
and the objects for application control represent
company or ah website
brand. So Facebook, Google being Microsoft, Twitter and and so on and so forth,
but also represents specific applications that
use http or https to communicate. And that's most applications today because most firewalls
don't allow other services out.
So we do allow http and https out.
with this application to communicate out to the Internet to do its thing.
just pick a couple of applications here that I want Teoh Block.
So if the outgoing connection
gets through the firewall policy, the network layer,
then we start evaluating the second layer in this policy package. The application control your L filtering layer,
and we started Rule number one. If we match any of those
applications or you are l categories in Rule number one, then we'll take the action of drop and again, best practices. The tracking should not be left at none,
should set at least log.
And again, I'll make this
No, finally content awareness.
My content awareness policy has an extra column
other policy layers didn't the content layer,
and again, it starts with a clean up rule, and I'm going to go ahead and ah,
that attracted action on this cleanup rule
except anything that hits the cleanup rule.
But I want another rule here to block specific types of content.
And in this rule, I don't care about source or destination. I'm focused on content here
when the content pol Um,
there are many different types of content
that can be selected. And for this example, I'm just going Teoh select.
Oh, maybe just private key files.
I have the option of which direction should I be looking at? Data going out, data coming in
here the default is either direction.
I'm going to change it to be just
data going out is gonna be examined. Data coming in this rule will not apply to.
So if anyone tries toe ex filtration private key data
over one of the protocols services that content awareness
knows how to look at,
then we're going to block that.
add more detailed logging,
block it, you know, I don't actually want to simply dropped the connection.
Instead, I'm going to inform the user
going to inform the user that they're not allowed to do that by giving them a Web page.
So they're going to get a Web page generated on the security gateway that's
denying the connectivity
No, you can't do that,
which is a little bit more informative than simply dropping a traffic and their browser, whatever application, eventually saying connection timed out.
And that's such a good idea that I think I will also do that in the application control layer,
though for some types of content in the action, the application you drill your URL filtering layer. I may, instead of just
I may want to give the user a chance to
continue if they know what they're doing.
So I'm gonna create a questionable content rule and in here,
if you are trying to go out,
a website that is categorized
as something that maybe you shouldn't be going to,
which has perhaps a medium risk website.
In this case, If you're going to a medium risk website, we're not going to drop your traffic.
Instead, we're going to ask you, Are you sure you want to go there?
So now I've sort of enhanced my URL filtering application control policy layer
populated all three layers with some
But actually, you know, thinking about it. I don't really want the content aware Awareness Layer to be executed. Number three in line.
So I'm gonna go ahead and modify the layer
example. Oh, policy.
I'm actually going to take this shared content awareness. Layer out
of this policy as an ordered layer.
Note that this doesn't delete the layer. The layer is still out there.
It's just not used right now. In this
under layers access control, you can see the content awareness layer is still present.
currently being used by the example co policy layer
or a policy package.
here I think I'll make it in
in line layer instead of an ordered layer.
But it changed the action from, except to
And now rule number one.
It's action is run this sub layer that I've already defined this content awareness sub layer.
And so if we match rule number one, then we will start evaluating the in line layer
and rule 1.1, which is the first rule of the in line layer,
says If you're trying to upload a private key, we're going to block that.
Otherwise, we hit the cleanup rule in this in line layer, which says everything else is allowed.
If we didn't match Rule number one the demo rule, we would skip the entire in line layer and proceed directly to remember to clean up rule.
So now the content awareness layer is going to be evaluated
before the application control you Morrell filtering layer
in the event that we match Rule number one the demo layer in this first network layer.
that's an example of how action access control layers work.
Now we'll take a look at threat prevention.
in this policy package, I have threat prevention policy type also enabled,
and a default rule is created for threat prevention policy.
And it's not exactly the same as access control rules Note that there's no
cleanup rule provided instead the default rule I get which is not named
or any protected scope and so protected scope could be, say, my internal network
or anything in the internal zone
for anything in the protected scope.
I want you to use whatever
Brett Prevention blades are enabled
on this security gateway that's
looking at this connection,
any threat prevention blade that's enabled that is appropriate for this service. For this protocol,
we're going to use the optimized
profile and I'll talk about what that is,
though, with threat prevention selected
this Ah, this left hand side, the
options have changed. Let me go back to access control and you can see at the bottom.
Uh, access tools are displayed when I'm looking at access control policy
with threat prevention. I have threat tools, and
options to examine under threat tools is profiles.
So this is threat prevention policy profiles,
which essentially just set the defaults
for whatever threat prevention,
pat threat, prevention component
I PS is one threat prevention component, or blade.
There is also, and I bought an eye virus threat extraction and others
by default. Three profiles are available for you to select you to use in your threat prevention policy.
Basic, optimized and strict
well, just I PS policy
all types of threat prevention that are available on the security gateway
and so is stripped the difference between optimized and strict is which protections are automatically enabled.
So with threat prevention,
really three criteria that could be evaluated to decide. Should this threat prevention, protection, whatever it is,
be applied to traffic.
And so the three criteria are performance impact, severity and confidence level.
Performance impact is how much of a CPU load is this going to be on the security gateway to perform this protection
by default, the optimized profile says anything with a performance impact of medium or lower is eligible to be used
if it's high or critical than it's not eligible.
And second, we look at the severity rating for the protection. How bad is the threat that this protection is protecting us against?
And so for the optimized profile, it says, any threat that has a severity of medium high or critical,
and then confidence level. That's false positives. How likely is it that this protection
a nine traffic on traffic that isn't actually associated with the threat that this protection is looking for?
with the optimized permission profile, if the confidence level is low, there's a high risk of false positives.
Onley detect the threat so they'll be a log entry generated by whatever threat prevention Blade
I just logged it. I detected it
or anything where the confidence level is medium or high. Fewer false positives, the optimized
profile says. Go ahead and actively prevent
and then the strict.
The big difference with the strict protection profile is we enable any protections with a performance impact of high, medium or low
and with the severity of low, medium, high or critical,
which is not exactly all protections. There are some protections with the severity
Hello, low, but it's most of them, almost all of them.
And then again, we look at the confidence level of the protection and those protections with low confidence level. We detect Onley. We don't actually prevent
anything. With a higher confidence level, we actively prevent.
profiles are pre defined.
You really can't do a whole lot with them. You can't delete them,
but you can do is clone them and then make your changes to the clone of the protection profile
and then in threat prevention policy.
You select which profile you want to be using. In this case, the default is we're going to use the optimized profile.
The threat Prevention policy Rule says.
When should we apply this threat prevention
profile? And right now,
all the time, every connection we should apply the optimized threat prevention profile.
One other thing I wanted to ah
quickly show is https inspection and other types of so called shared policies. These shared policies are global to all policy packages,
though one type of shared policy.
location based blocking,
determined by the source i. P. Address of the connection.
Different countries have different I p address ranges assigned to them,
and there's a data base of this country has thes I p address ranges. This other country has thes other I p address ranges.
We can draw on that database to make a mapping between source I. P address of the connection and origin country,
and here in this example, I am picking on the Democratic People's Republic of Korea
or is heading to, I can specify the direction
Democratic People's Republic of Korea. Then I'm going to block
by Anna Dean Row. Here we go so
you can select the direction
country. And there are,
well, literally hundreds of countries out there
for this particular country.
And again, this is a shared policy. So
geo protection rule, in effect, is ah, applied to all of my policy packages.
The other thing is https inspection. Https inspection policy currently is not
configurable viewable in smart Consul, you have to use the air quotes, legacy smart dashboard application
to look at or modify https inspection policy. So, in order for https inspection to even be offered here under shared policies, I have to have at least one security gateway
in the security gateways object
includes https inspection. I've gone to that security gateways object
and under https inspection in that security gateways object, I've turned it on.
So once that's done,
now I can look at https inspection policy.
So https inspection policy
determines when we should decrypt the https that the TLS
so we can see the http inside of it. And when should we not?
the inspection is accomplished using a man in the middle attack.
If we decide that we're going to inspect traffic
traffic, that is appropriate. Https traffic.
Normally your Web browser that's initiating a connection out to some HDB s website would get the websites certificate and use that
to securely arrive at a
symmetric encryption key that could be used to protect the data going back and forth.
is instructed to inspect that traffic,
it will see that you're going out to some website www dot sight dot com.
That information is actually included as part of the TLS handshake,
and we need to inspect that so it will on the fly create a public private key pair
and the public key it will use to create a certificate that says This is for www dot sight dot com
and it will digitally sign that certificate with a certificate authority that was created on the security gateway. So this is not
the internal certificate authority that is used by sick. This is a different certificate authority,
the biggest issue with https inspection is
the certificate that the client receives for the remote website
is digitally signed by a certificate authority that we just created on the gateway.
Your client Web browser doesn't know that certificate authorities. So it's gonna
https security warnings
to the end user Every time they go to a website that you are inspecting because the certificate they get
it says it's from that website is not properly digitally signed by trusted certificate authority.
What do you need to do as a security administrator is arranged for the certificate authority?
It's being used in https inspection to be trusted by your end user clients.
How you do that is beyond the scope of this class. If you have active directory well,
there's your clue. Active directory makes it
Having said all of that, the actual https inspection policy is pretty straightforward.
When do you want to inspect
decrypt and when do you not want to?
pre defined rule, which is sort of the cleanup rule here is
E. I added a rule above that. The do not inspect rule that says under these circumstances don't decrypt.
So if you're going to a website that the U. R L filter
part of application control you are royal filtering
has categorized as financial services or as a health site,
And that's because privacy
now, I might also say
Well, now a new rule number one always inspect if they're going to a website that is categorized as risky somehow
so that would override the fact that they're going to ah financial Services website. If it's a risky financial Web services website, there were still going to inspect,
but OK, currently, rule Number one says. For these categories, I pass
again the site that the client wants to establish. Https, too.
That site is transmitted in plain text during the TLS handshake,
and so https inspection congee get the website name without having to decrypt
and then make a decision.
Should I decrypt or not?
Down here, there's an option which is selected by default Bypass https Inspection of traffic
Do well known software updates services,
and that's a list of
destination websites that
checkpoint maintains and your fire, while your security gateway automatically fetches updates
so that would include checkpoints. Updates site for CP use,
but also things like Microsoft update site and anti virus updates site.
if I make changes to my inspection policy here in Smart Dashboard,
I can't install policy here. Really, There's ah menu option
that allows me to do a couple of things that are in the legacy. Smart Consul. But I can't really install policy now from smart Smart Dashboard because that functionality is now handled by smart Consul.
Really, all I can do is save any changes that I make
and then exit out of the smart dashboard out.
They could be back to Smart Consul, and any changes I made would now be reflected up here in the session,
you know, part of the number.
So I've demonstrated how to create a new policy
and populated with layers,
ordered layers do layer number one, then layer number two
as well as in line layers. If this rule in this layer matches, run another layer.
We also looked a little bit of threat prevention policy and how that works, how it selects which protections should be enabled,
and then some shared policies,
geo location and https inspection.
that's it for the demo. Thank you.
So in this module we looked at the checkpoint security policy
and rules both explicit rules that an administrator creates and maintains,
as well as the implied rules that Checkpoint maintains.
We looked a little bit it sections, which allow you toe more visually. Separate your rules
objects, which are used in your rules to decide if the rules should match or not.
And that could be objects in the action column, such as three user check interaction. Object.
We also talked about
policy layers and policy types. So policy packages or
just a wrapper around your policy layers that
a specific set of your security gateways. And we have a different policy package
with different layers included get installed on this other set of security gateways.
Then the two major types of policy.
We have access control and threat prevention.
We discussed briefly publishing and installing policy,
and we demonstrated how to create a policy package populated with rules
So thank you for attending this module