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 going to talk about what that is. We'll also dive into 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, only if the source is this network object. Then we'll look at policy layers and policy types, in R80 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 the set of objects which can represent hosts or networks or services or other things. Settings, which can be per policy, but also global property settings which apply to 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 can do other things such as decide whether or not we want to have more inspection of this traffic. So your policy is built from rules that you explicitly add to the policy. So in the screenshot is a very generic example of a policy with rules. Rule number 1, note the Number column, rules are sequentially numbered from 1 to the last rule. And when we get to the rule 4, something interesting's happening, I'll talk about that. The Name column is yours to set, it should be something mnemonic 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. It'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, Destination, VPN, Services & Applications, Data. And you can't see it because we haven't scrolled over to the right, but there's also a Time column. And so source, destination, that can consist of host objects, network objects. For source, you can also have identity-based policy where we need to know what group is the user that is initiating this connection. What group are they in or groups, are they a member of the accounting group, for instance? That's something that you see in the Source column, not really in the Destination column. The VPN column is not intuitive, 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 only 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. And 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 license and enabled, such as the URL Filtering or Application Control features, then you have additional objects. Which can be used in services and applications, such as a very, very broad risk categorization of the website that the user's attempting to access. If that website is categorized as high risk or critical risk, then we're just not going to allow it. Also, you can categorize traffic by the application associated with that traffic, for instance, Office 365, Twitter, Facebook, and so on. The Data column you may not see, you have to have 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, 8am to 5pm local time. That's local to the security gateway that's evaluating the policy. But you can also have in the Time column an object that says this object expires on January 1st. And that's a nice way to add a temporary rule, a rule that we gotta have for now, but as of this date the rule should be turned off. And instead of a human administrator having to remember on that date, login, turn that rule off, well, you simply create a time object that specifies this expires on this date. And use that time object in the Time column of the rule and the rule will then automatically stop matching. It will be disabled when we hit that date and time. Now the Action column, when a rule is added to your security policy the default action that's set is drop. There are other actions available, for instance, rule number 1, the action of that rule has been modified to be accept. And well, you need at least one rule that accepts traffic or your firewall doesn't do much. If you look down at rule number 5 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 and the action isn't accept or drop, it's ask. And this is called a UserCheck Interaction. So this will give a Web page back to the user that is generated by the security gateway, and that Web page will have a message. It says, are you sure that you want to be going to the site? It's categorized as such and such. Check this box to say yes, I'm sure, and click this button. And that way, it gives the user a warning, but it's not a hard no. If they have a reason, then they can proceed, but this stuff is being logged, so you can review logs and follow up. Well, what were you doing at that file sharing site, justify this. The Track column by default is set to none, but best practice actually says every rule should have a tracking action of log. And with that, if a rule has a tracking 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. We'll take a look at those. So in most deployments, there are some just general rules that are pretty universal. For instance, management access rules that allow authorized firewall administrators to access security gateways and security management servers, and other Checkpoint infrastructure via Secure Shell or HTTPS. The stealth rule is intended to catch all traffic directed at the security gateway itself. So it'll have, in the destination column, the security gateway object, and if you have multiple security gateways, all of their objects. It has an action of drop and a tracking action of log. Your security gateways are often Internet facing, your bastion hosts, they're directly exposed to the Internet. And if somebody's port scanning your security gateway, the stealth rule will drop their traffic and log the fact that this was happening. Critical subnet and tech support. You may, for instance, have network administrators who need access to layer 3 switches and routers, and so on. We can restrict access to these critical network infrastructure hosts from, for instance, a trusted subnet, or if you're doing identity-based policy, somebody in the net admin group. DNS, mail, SMTP rules allow access to these fundamental services, whether the DNS server is internal and you want to block access to external DNS servers, Mail and web servers are typically on a demilitarized zone, DMZ, which is a separate physical network that all of the Internet-facing hosts, all of your servers that must accept incoming connections from the Internet. And that would be, for instance, an email server and a web server. Those servers are isolated, physically, on a demilitarized zone network. And you have security policy that really limits what can come in and out of that DMZ network. The internet is only allowed to connect to the SMTP port on my SMTP server, no other port. The Internet is only allowed to connect to the HTTPS port on my web server, no other port. And best practice is you do not allow a host on the DMZ network to initiate a network connection to your internal trusted networks. Because, since the DMZ hosts are directly exposed to the Internet, they're at elevated risk of compromise. That's not always possible. Sometimes you have to allow a DMZ host to initiate a connection internally. If that's the case, well, least access, allow only what must be allowed and nothing else. And definitely, have an action of track on the rule that allows. You'll also have a 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 SNMP or Windows file sharing across the Internet. And finally, the cleanup rule is another Checkpoint best practice. The 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, if traffic did not match any other rule in your policy, we evaluated all of the rules, one after the other, none of them matched, when we get to the cleanup rule, that will match. It will drop the traffic and log, because traffic that made it through to the cleanup rule is really unexpected traffic. You put rules in for the traffic that you are expecting. So the cleanup rule is showing you unexpected traffic, and that can be useful for threat intelligence, for example. Now, it's not strictly necessary, because 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. Checkpoint will drop that traffic, but it doesn't log it. So the cleanup rule allows you to log that traffic. Sections 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 1 and 2 because there's another section before rule number 3, the VPN section, and so on. So if you have 100 rules, you have just these two sections. The first section would be rule 1 and 2, and the second section would be rule 3 through 100. The little 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 more screen real estate, a little bit more 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. Also, 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. However, 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. So the answer is, in addition to the explicit rules that you see in your policy, Check Point adds implied rules. These implied rules are there to allow Check Point to function. You can not edit, add, or delete implied rules. And some implied rules, specifically the ones that permit Check Point functionality to 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 any of your rules. And note here we're viewing implied rules, and they've looked a little bit different. They've got a different colored background, they've got some weird objects in the source and destination columns. But these implied rules are put there by Check Point to permit Check Point protocols where needed. I said that you cannot add, delete, or edit implied rules. You can turn them on and off, in global properties, and we'll look at global properties later. Objects allow you to have a rule that conditionally matches instead of matching all the time, we can have a rule that matches only if the service is this. So the most common types of objects that you'll be working with are network objects such as a host or a subnet or a range of IP addresses, and service objects, HTTPS, SMTP. And if you have the URL filtering or application control or other access control blades enabled, then you may have URL filtering categories or application objects available as well. I mentioned timed objects and user check interactions, which is where you can present a web page to the user who's 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 a drop action, the connection times out. With a user check interaction that says no, well, they get a webpage that maybe explains why. So objects can be managed multiple places in Smart console. In this example, we've brought up the Object Explorer window, which allows us to search for objects by name, by IP address, by any property of the object. And we can limit our search in the categories off to the left, I’m only searching for network objects. So, in your security policy, you must have Access Control Policy. Access Control Policy includes firewall policy, and well, firewall policy is required. It's the fundamental, packet filtering that stateful inspection components of a security gateway. Threat Prevention policy is optional. And we'll talk about what those policy types are. So, Check Point allows you to have multiple policy packages. A policy package is in effect a wrapper around your Access Control and Threat Prevention policy that allows you to have different policies for different groups or types of security gateways. For instance, you might have a set of security gateways that are internet facing, external, you might have a different set of security gateways that are internal compartmentalization. And a third category of security gateways which are used for VPN connections. And the policies that each of these three types of gateways should receive are different, they 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, you can have multiple policies, and we'll look at that. This is something that's new in R80, the ability for a policy package to have, say, three Access Control Policy layers. And some of these layers may be more generally applicable. 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, I can have just one policy, it's called a policy layer, that is shared, and then use that in both policy packages. And if you make a change to that shared policy layer, well, that change is reflected in all of the policy packages which include it. We'll talk about how layers can be ordered or put in line. So I mentioned there's access control and threat prevention. Focusing on access control. In your access control policy, you must have at least one layer, and that layer must be at least a firewall layer. That's a requirement, it's gotta be first, it's gotta have a firewall. Now that firewall layer implements your packet filtering stateful inspection functionality. It can implement other layer seven functionality, but it's needed for packet filtering and stateful inspection, must be number one. But, okay, 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 check the rules sequentially from top to bottom. Rule number one, are you a match? If not, rule number two, are you match? If not, rule number three, are you a match? You're a match. What's the action? Action is drop, well, we're done. We're not going to let the traffic through. On the other hand, if the action is accept, then, 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, which is optional. So, 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 accept, let it go. But in our second layer, the application control policy layer, we take a more detailed look at layer seven. So here, we look at what website are they requesting? What's the category of that website? What's the risk factor of that website? And then make an allow or deny decision based on layer seven data. And then the third layer for instance might be some sort of data awareness. Or something else where if you are attempting to send out an attachment that has payment card information, or national identity number information. Or something like a private key. Then we can stop that in the third data control layer. And there is a couple of features which use that. A layer can be used in a policy package either ordered, one layer, layer two, layer three, or inline. And we'll take a closer look at using a layer inline in a moment. So, if you have multiple layers that are ordered, layer one, layer two, layer three. Then as I said, we must pass the first layer, you must match a rule whose action is accept. Otherwise, the traffic will not be allowed. We don't evaluate any further layers. In this example, we got down to rule number 12. And rule number 12 match the connection, and its action was accept. So right now our choice or our decision is we're going to accept this connection. We're going to let it through. Then we started evaluating the next layer in this policy package, layer number two. And we got down to rule number ten before we had a match. And rule number ten matched, and its action was dropped. So final answer, we're going to drop the connection. And we never got to layer three. So in an ordered layer, we start with rule number one. We evaluate it, does it match? If not, we go to rule number two, does it match? We do that until we match a rule in that layer. And again, you should have a cleanup rule, so that cleanup rule will match if nothing else did. Then, once we've matched, we take the action. If the action is drop, or something similar, we're done. If it's accept, then we continue on to the next ordered layer in the policy package. Another way of including multiple layers in a policy package is to make one layer inline to another. In this example, we have our firewall layer. And it has rule number one, rule number two, three, four, five. But rule number two of this firewall layer, the action isn't accept or drop. It is use this layer inline, and the name of the layer it's using inline is URL filter. [COUGH] 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 inline layer. So we bring up the URL filter layer. We evaluate that. First rule of the URL filter layer, which since it's inline is .1, so rule 2.1. That didn't match. So we fall through to the next rule in that inline layer 2.2, and that matched. And it had an action of accept. 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 going to look below that for rule three or four. We matched rule number two, and it's an inline layer so we start running the rules of the inline layer. And if we had matched 2.1 that said drop, we would be done. We matched 2.2 which says accept, so visionary at this point we're going to accept and allow the connection. But there may be another ordered layer next that has a different decision. Threat prevention policy is a little bit different. Threat prevention policy controls the intrusion prevention system, anti-bot, 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 layer because you've got to have a firewall layer, it's a requirement. 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 doesn't include threat prevention policy. But if you do have threat prevention present in a policy package, it can have one or more layers. Access control policy layers, they are either ordered or inline, or both. You can have ordered layers, or some of them have an inline layer. And again, we start with the first layer. Rule number one, does it match? We do that until we find a rule in that first layer that matches. And if its action is drop, then we're done. If its action is accept, then we go to the next layer. And if its action is an inline layer, well then we run the rules of the inline 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 IPS, anti-bot, etc. Traffic is matched against all of those features in all of the layers simultaneously. There's not a definable 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 the safest option, the most strict option. So, we won’t allow the traffic. I mentioned global properties. Global properties are settings that apply to all checkpoint devices managed by this management server. And the default screen that you get when you bring up the global properties window configures or controls the implied rules. So here, control connection is the first option. Those are the rules that permit checkpoint functionality. And then there are some other implied rules, such as accept outgoing packets originating from the gateway. The purpose of that rule is if a security gateway wants to connect out to the Internet. For instance, to check for updates, or download antivirus signatures, or what have you, then it's allowed. Note the positioning drop down, 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 the 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 clean up rule should always match. So we have this special case before last, put it above the Cleanup rule. That way it's below all of your other explicit rules, but above the Cleanup rule. There is also a drop-down option there last which you would not normally use, because you have a Cleanup 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 or none of them. And so if you check that box, then traffic which is permitted by an implied rule, will be logged. If you don't check that box, it's not checked by default. Then traffic which is permitted by an implied rule, is silently allowed and there's no logging. So you're an administrator, you've signed in to SmartConsole and you're making changes, or perhaps creating a policy. When you are done with those changes, you must publish your policy to the management server. In effect, that updates the master database of checkpoint configuration on the management server with your changes. And recall in an earlier module, I mentioned how you can have multiple simultaneous administrators making changes. 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, are 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, an internal gateway policy package, a VPN gateway policy package. You can configure the policy package with the set of installation targets for that policy package. It will only install to those security gateways, not everyone. So when you click Install Policy, the currently selected installation targets, it's by default all of your security gateways. You can change that. Will start the process of getting this new 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. It'll transmit that firewall policy to that security gateway. Which will, between packets, switch from the old policy to the new policy. And and it will then inform the management server, Done. And the management server will keep your SmartConsole application up to date. Here are the security gateways that are still processing, here are the security gateways that have successfully installed policy. And here are the security gateways that couldn't, 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 threat prevention policy. And then creating rules in the policy package. So we start by looking at the standard policy package, so I've selected Security Policies. And I have two tabs displayed and one, the tab is labelled Standard, and that's the name of the policy package. And that standard policy package is created when your management server's first initialized. It just automatically creates a Standard policy package with an Access Control policy that contains Firewall rules. And the Firewall rule that you get has just one rule, the Cleanup rule. So I've slightly modified this access control policy to allow traffic from the management network out to the Internet, but nothing else. But what I want to demonstrate is creating another policy package and customizing that policy package. So if I click the little plus sign here, there are no other policy packages to manage. So it automatically shows me the Manage Policies tab and. And here, we can see that there is indeed only one policy package, the Standard Policy package. If I want to create another policy package, I have to click here in this little Manage Policies and Layers. So here I can create a new policy package, and in this policy package, I have the two major policy types available. Access Control, which includes Firewall that's required, and optionally, Threat Prevention. When I tell it I also want Threat Prevention policy. Then, 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 Unselect specific gateways that they shouldn't be receiving this policy. But what's easier than unselecting 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. But I'm going to include that. So now when I install 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. Another thing under general [COUGH] 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, [COUGH] 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. I'm going to call this. AppControl_URL F. Because I want this layer to contain application control and URL filtering, or the sort of a bundle, you can't have just one or the other. What you can do is just not use any application control objects, or use any URL filtering objects. I'm probably going to use both. So this layer is just for application control URL filtering policy. And if there are other policy packages that want to use this application control URL filtering layer, I've enabled that. This layer can be shared between multiple policy packages. Another thing is what should happen when we run off the edge of the policy. We've evaluated every rule in the policy. And for this connection, no rule has matched. So, you fall off the end of the policy. What should the behavior of the firewall be when that happens, the default is we drop 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 URL filtering rule. It already passed the firewall policy, that comes first. By the time we get here, it just means that we didn't match anything that, in an application control URL filtering type policy, you're usually blacklisting. These are the sites that I don't want to allow. So if I didn't match any of the rules in this policy that describe sites I don't want to allow, perhaps I want to allow. Now again, best practice is, you don't hit the implied cleanup action. You should have an explicit cleanup rule at the bottom of your policy layer that either accepts or drops the traffic and then has a tracking action. And I'm going to go ahead, and set that up but still I want the implied cleanup action for this layer to be accept. One other setting here 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 group, if you will, 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 URL filtering layer, I'm just leaving the default. Those that are in the super user permission profile which a built-in 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. So having created that layer. There's one more that I want to create, a content awareness layer. And this layer, not surprisingly, will contain just content awareness policy. And I also want to designate that this layer should be shared. Necessarily need to change the implied cleanup action because I'm going to have an explicit cleanup rule in this layer as well but, and change it to accept. And I can also set the permission profiles that are allowed to modify this layer. So I've created this new policy or policy package, I suppose is the old terminology. [COUGH] 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. Now the new layer has been created. And you can see that there's now a tab external or example, co_policy. That tab is selected so I'm currently looking at that policy. And you'll note that 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 going to dismiss the layer management window here, and maybe populate this layer. So again, whenever you create a layer, you get a cleanup rule, automatically provided. 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 practice is, it should be set to log. So, that's what I'll do, I'll just 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 installed 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 can have multiple gateways in the install on column. That rule will essentially only 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, they will get 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 going to match every connection and deny it, drop it. So I'm going to create another rule above, I will call this the demo rule. In this rule, I want to match all traffic. 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. Hitting the Escape key says I'm done editing that name field. So I want to have this demo rule that allows traffic out. And also tracks, But I can't have a demo rule that the source is any, the destination is any, the services and applications is any, the time column over, that you can't see, is also any, because that's a rule that will always match. And I can't have 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 error. 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 means that 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 need to distinguish the demo rule in some way, I could just disable the cleanup rule or or do something else. But instead, I'm just going to put in a couple of conditions. Though if you're coming from the management network, Or the internal network, And in an earlier module, I created this internal networks group object, which contains both the internal net 192.168.1 and another internal net 172.16.12. So 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, then 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 error check that policy installation does. Yeah, and this is just the demo. In a production environment, you would, of course, have many more rules that have much more granularity. Now, under the application control URL filtering layer, again, when a layer is created, it gets a cleanup rule. Here, I want the cleanup rule's action to be accept. I could just select it. And I want to track when we match the cleanup rule. Now, recall that the tracking action here, you have a couple of options under More, if I could, my mouse is being a bit, And so the tracking action still logged. But I also get the option of detailed and extended logs, and I'm just going to choose extended logs. And really what this does is it creates the regular log entry but it populates it with additional information gleaned 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, what category of website are they trying to get to? What application, if any, is that website associated with, such as Facebook or in some other popular application, Twitter, LinkedIn, what have you. And if so, then the application control URL filtering blade can contribute what it gleaned to the log entry. And that's what this extended log does. So my cleanup rule says anything is allowed and we'll log that. I want to have some things that aren't allowed. And these are things that are specified according to the application control. Problem spelling. So my, Aptly named No Dangerous or Bad Sites rule. I don't care about the source of the destination. What I'm mostly focused on here is the application. So in the service and applications column, I can specify service objects, and there are many thousands of service objects automatically created. Here, I'm not really caring so much about this service. URL filtering application controls only applicable for a specific subcategory of the services, HTTP, HTTPS and a couple of other protocols. [COUGH] So I'm going to limit what's displayed here to just URL filtering categories. I can also limit what's displayed here to specific applications or sites. I'm going to start with URL filtering and just select some high level URL filtering categories that I want to block. So here's a generic category, the critical risk So this is applications websites that may bypass security or hide identity. These are known bad websites. Also, this is by default sorted alphabetically. I'm going to add high risk website So high risk websites are 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. And then maybe a couple of other categories will be included. And also, perhaps some applications should be listed here. Again, this is something that the Application Control URL filtering blade is contributing these objects. And the objects for the application control represent a company or a website brand. So, Facebook, Google, Bing, Microsoft, Twitter 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. Though, we do allow HTTP and HTTPS out, we'll just use that for this application to communicate out to the Internet to do its thing. [COUGH] So, I'll just pick a couple of applications here that I want to 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 URL filtering layer. And we start rule number one, if we match any of those applications or URL categories in rule number one, then we'll take the action of Drop. And again, best practice is the tracking should not be left at None. Instead, should set at least log and again I'll make this detailed that of just basic log. Now finally, content awareness. My Content Awareness policy has an extra column that other policy layers didn't, the Content layer. Then again, it starts with a cleanup rule, and I'm going to go ahead and let a tracking action on this cleanup rule, and accept 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. That when in the content column, there are many different types of content that can be selected. And for this example, I'm just going to select, Maybe just Private key files. So, I have the option of which direction, should I be looking at. Data going out or data coming in? And here, the default is Either direction. I am going to change it to be just Uploading, though. Data going out is going to be examined, data coming in, this rule will not apply to. So if anyone tries to exfiltrate private key data over one of the protocols services that content awareness knows how to look at, then we're going to block that. We're also going to add more detailed logging. But block it, I don't actually want to simply drop the connection. Instead, I'm going to inform the user, That here, I'm 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 webpage generated on the security gateway that's denying the connectivity, that tells them no, you can't do that. Which is a little bit more informative than simply dropping traffic and their browser or 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 actual the Application Control URL filtering layer, I may instead of just denying, I may want to give the user a chance to continue, if they know what they're doing. So I'm going to create a questionable content rule. And in here, if you are trying to go out to say, a website that is categorized, As something that maybe you shouldn't be going to, 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? Now, one detailed logging. So now, I've sort of enhanced my URL Filtering Application Control policy layer. And populated all three layers with some example rules. But actually thinking about it, I don't really want a content awareness layer to be executed number three in line. So I'm going to go ahead and modify the layer a little bit. This policy, my example policy, I'm actually going to take this shared content awareness layer out of this policy as an ordered layer. And note that this doesn't delete the layer, the layer is still out there. It's just not used right now in this example co-policy. Under layers access control, you can see the content awareness layer is still present. It's just not currently being used by the example co-policy layer or policy package. So here I think I'll make it an inline layer instead of an ordered layer, going to change the action from accept to content awareness. And now, rule number one, its action is run this sublayer that I've already defined this content awareness sublayer. And so if we match rule number one, then we will start evaluating the inline layer. And rule 1.1, which is the first rule of the inline 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 inline layer which says everything else is allowed. If we didn't match rule number one, the demo rule, we would skip the entire inline layer and proceed directly to rule number two, the cleanup rule. So now, the content awareness layer is going to be evaluated before the application control URL filtering layer in the even that we match rule number one, the demo layer, in this first network layer. So that's an example of how access control layers work. Now we'll take a look at threat prevention. So 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 says for 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 threat 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. So with threat prevention selected, down here under this left hand side, the options have changed. Let me go back to access control, and you can see at the bottom, access tools are displayed when I'm looking at access control policy. With threat prevention, I have threat tools, and one of the options to examine under threat tools is profiles. So this is threat prevention policy profiles, which essentially just set the defaults or whatever threat prevention, Component or blade I designated. So IPS is one threat prevention component or blade. There's also antibot, antivirus, threat extraction, and others. By default, three profiles are available for you to use in your threat prevention policy. Basic optimized and strict, and basic is, well, just IPS policy. Optimized is all types of threat prevention that are available on the security gateway, and so is strict. The difference between optimized and strict is which protections are automatically enabled. So with threat prevention, you have really three criteria that can 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. And 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, then 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 the severity of medium, high, or critical, medium or higher, is eligible. And then confidence level, that's fault positives. How likely is it that this protection will protect on benign traffic? On traffic that isn't actually associated with the threat this protection is looking for. So with the optimized permission profile, if the confidence level is low, there's a high risk of fault positives. Then we only detect the threat, so there'll be a log entry generated by whatever threat prevention blade saying I saw this threat, but I didn't stop it. I just logged it, I detected it. For anything where the confidence level is medium or high, fewer fault 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 below 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 a low confidence level we detect only, we don't actually prevent, anything with a higher confidence level we actively prevent. So these profiles are predefined. You really can't do a whole lot with them. You can't delete them. What 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 Though 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 quickly show is HTTPS Inspection and other types of so-called shared policies. These shared policies are global to all policy packages. So one type of shared policy, this geo policy is location based blocking. So the location is determined by the source IP address of the connection. Different countries have different IP address ranges assigned to them, and there's a database of this country has these IP address ranges. This other country has this other IP address ranges. We can draw on that database to make a mapping between source IP addresses of the connection and origin country. And here in this example I am picking on the Democratic People's Republic of Korea, aka North Korea. If traffic originates from or is heading to, I can specify the direction The Democratic People's Republic of Korea. Then I'm going to block that connection. By editing the rule, here we go. So you can select the direction and the country and there are literally hundreds of countries out there. For this particular country, I'm going to drop. And again this is a shared policy. So this geo-protection rule in effect is applied to all of my policy packages. The other thing is HTTPS Inspection. The HTTPS Inspection policy currently is not configurable, viewable in smart console. You have to use the air quotes legacy SmartDashboard 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 whose configuration 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 the TLS. So that we can see the HTTP inside of it, and when should we not. As I said, the Inspection is accomplished using a man in the middle attack. If we decide that we're going to inspect traffic, and this is traffic that is appropriate, the HTTPS traffic. Normally your web browser that's initiating the connection out to some HTTPS website will get the website's certificate. And use that to securely arrive at a shared secret, a symmetric encryption key that can be used to protect the data going back and forth. However, if the security gateway is instructed to inspect that traffic, it will see that you're going out to some website www.site.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.site.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 SIC. This is a different certificate authority. And 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 authority. So it's going to grow HTTPS security warnings to the end user every time they go to a website that you are inspecting. Because the certificate they get says it's from that website is not properly digitally signed by a trusted certificate authority. What you need to do as a security administrator is arrange for the certificate authority that'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 easier. So having said all of that, the actual HDTV Inspection policy is pretty straightforward. When do you want to inspect decrypt and when do you not want to? The default predefined rule which is sort of the clean up rule here, is do the Inspection. [COUGH] 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 URL filter part of application control URL filtering, has categorised as financial services or as a health site, do not decrypt, and that's because privacy. Now I might also say above that, 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 a financial services website. If it's a risky financial services website, then we're still going to inspect. But okay, currently rule number one says for these categories, bypass. And again, the site that the client wants to establish HTTPS to that site is transmitted in plain text during the TLS handshake. And so, HTTPS inspection can get the website name without having to decrypt and then make a decision, should I decrypt or not? [COUGH] Down here there is an option which is selected by default, bypass HTTPS inspection of traffic to well known software update services. And that's a list of destination websites that Check Point maintains and your firewall, your security gateway automatically fetches updates. So that would include Check Point's update site for CPUs, but also things like Microsoft update site and antivirus update site. So if I make changes to my inspection policy here in Smart dashboard, I can install policy here really, there's a menu option that allows me to do a couple of things that are in the legacy Smart console, but I can't really install policy now from Smart, sorry, Smart dashboard. Because that functionality is now handled by Smart console. Really all I can do is save any changes that I make. And then exit out of the Smart dashboard app, taking me back to Smart console, and any changes I made would now be reflected up here in the session as part of the number. So, I've demonstrated how to create a new policy and populate it with layers, including ordered layers, do layer number one, do layer number two as well as inline layers, if this rule in this layer matches, run another layer. We also looked a little bit at 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. So, that's it for the demo, thank you. >> So in this module we looked at the Cbeck Point Security Policy. And rules, both explicit rules that an administrator creates and maintains as well as the implied rules that Check Point maintains. We looked a little bit at sections which allow you to more visually separate your rules. Objects which are used in your rules to decide if the rule should match or not. And there can be objects in the action column such as the User Check interaction object. We also talked about policy packages, policy layers and policy types. So policy packages are just a wrapper around your policy layers that can be installed on a specific set of your security gateways, and we have a different policy package, with different layers included, that get installed on this other set of security gateways. And then the two major types of policy, you have access control and threat prevention. We discussed briefly publishing and installing policy. And then we demonstrated how to create a policy package, populate it with rules, and so on. So thank you for attending this module.
