Hello, welcome to Check Point Jump Start module two, where we will look at deploying the check point security management solution. More than that, what is the security management server? What does it do? We'll talk about secure internal communication, which is used whenever any check point component communicates with any other check point component across a network. This is enabled by an internal certificate authority that is automatically created and set up on the management server. We'll also take a quick look at the check point operating system, Gaia. The web user interface the Gaia provides to an administrator to configure the device as well as update and maintain the operating system. Will also look at SmartConsole, which is a Windows GUI application that the administrator uses to manage the check point configuration and will demonstrate the configuration of a management server. In the check point security management architecture, it's a three tiered architecture. The administrator interacts with the SmartConsole GUI to create security policy, updates security policy, and so on. The administrator then instructs the SmartConsole application to communicate the changes to the security policy to the management server. Management server is sort of the keys to the kingdom. It has complete and authoritative copy of your security policy of your check point configuration. Then when instructed, the security management server, will send the current, probably updated security policy to each installation target, which is each security gateway that this policy needs to be sent to. Security gateways by default, send logged data to the management server. In a larger deployment, you may want to offload the overhead of processing logged data from your management server. There are options to allow you to do that. In order for the check point components in this three tiered architecture to communicate, secure internal communication is used and this is much like TLS or SSL that we're familiar with HTTPS are in the secure websites like TLS. Secure internal communication uses certificates to authenticate the peer, the other end of the network connection to ensure that it's the correct peer and not an impostor. Also, encryption provides more confidentiality and there are other protections being applied here, such as integrity checks, must have secure internal communication set up and working correctly for policy installation to occur, for log transfer from the security gateway to the management server to occur. So it depends on the version of check point that you're using. Current versions of check point have moved TLS and are using modern encryption algorithms such as the advanced encryption standard. You have older legacy check point deployments, and may still be using triple DES, which though very dated, is generally regarded as fairly secure, but we should think about upgrading. So secure internal communications, uses certificates just like HTTPS uses certificates, except that both ends of the conversation authenticate their identity using a certificate. So for this to happen, certificates must be digitally signed by a trusted certificate authority. In a check point deployment, a trusted certificate authority is an internal certificate authority that was created on the management server when the management server was first initialized. So the management server will handle digitally signing the certificates that it's issuing to new check point security gateways that you're deploying or other check point products that you're deploying on your network. It also by default, generates digital signatures for VPN, including site-to-site IPSec, VPN connections, so that the VPN peers can authenticate each other. But also remote access VPN connections. So an individual with a laptop who needs to have secure communications to headquarters to get to say their e-mail server, knows that the security gateway they're communicating with is the trusted peer. The internal certificate authority can also authenticate the remote user using certificate based authentication to ensure that they are who they claim to be. Now, the check point product is delivered as an appliance, and the appliance is running something very similar to Red Hat Enterprise Linux. It's based on Linux, and it's called Gaia. Gaia is the operating system that check point products run on. Gaia provides a command line interface that simplifies the administration of your check point device. But even better is the web user interface. The web user interface is an HTTPS, web browser, website that provides graphical administration capabilities, and in the top left, you can see the view mode drop-down menu with advanced selected. They have two modes in which to view the web user interface, advanced currently is selected. Basic just hides some of the less frequently used menu items. So the menu on the left-hand side is shorter and easier to navigate and you can switch between basic and advance it anytime. I talked about the three tier architecture. At the top of that is the SmartConsole application, this is like Windows. GUI application that the security administrator uses to create and manage security policies, but also to monitor what's going on with your check point deployment. You can be notified of software updates that are available and install those. You will also use SmartConsole to add new security gateways and other check point devices. In a very large deployment, if you have the multi-domain management server feature, SmartConsole seamlessly works with multi-domain management. That's beyond the scope of this course. Inside of SmartConsole, on the left-hand side, there's four major views or tabs. Then at the very top left corner, there's a main menu that allows you to access additional functionality in SmartConsole. Next to that under 3 or over 3 is the objects menu. This allows you to create, manage, delete, and find search for objects that are used in your rules to determine if a connection matches the rule or not. At 4 is the installed policy button, and you would click on that button when it is time to deploy your updated security policy to selected security gateways. When you make changes to your security policy in SmartConsole, they are not effective until you have successfully installed policy. Above number 5, the session details menu allows you to see details about the current administrator session logged into smart console, including changes that have been made or whether or not changes have been made. Over on the right-hand side with 6 is a configurable view, in this case objects are being viewed. So it provides another way of interacting with objects, creating, modifying, and deleting objects. At the bottom, the management activity bar shows the current administrator who is logged in at the very bottom right, you can see that it's CP Admin. This administrator currently has no unpublished changes pending. We'll talk about publishing. You can also see the IP address or host name of the management server that this administrator is connected to. Over on the bottom left you can see the status of tasks such as policy installation that have been performed. In this example two of those tasks were not successful. So we can click that message and get more information about what wasn't successful and why that wasn't successful. Finally in the left-hand side at 8 we can access command-line functions from SmartConsole including checkpoints, application, programming interface, which allows you to script operations that perhaps might be just too tedious or labor-intensive in the GUI. So in SmartConsole on the left-hand side there are four major views, and we've selected the first one; gateways and servers. There's also security policies, logs and monitor, and manage and settings. In this gateway and servers view you get an overview of your checkpoint deployment, all of the checkpoint products that this management server is managing. At the bottom you can see A-SMS, that's the management server itself, it knows about itself. Then there's above that A Gateway Cluster, which is not a physical appliance, instead it's a cluster object that represents your high availability cluster that you've deployed. That high availability cluster is implemented by two individual security gateway appliances, A Gateway 01 and A Gateway 02. On the left side you can see the status column which gives a quick indication as to the health of each checkpoint device. So the management server has a warning, that's the yellow triangle, whereas A Gateway 01 has a critical issue, that's the circle with an X through it. A Gateway 02 has a warning, but the cluster itself displays the status of the most severe warning of any cluster members, so given a warning and a critical issue, it's going to display that there's a critical issue. If you select one of the checkpoint devices listed in this status display at the bottom of this SmartConsole window, you will get additional information about that device. So in this case, on A Gateway 01 we can see that it's IP address is 10.1.1.2. The current policy package that has been installed on this security gateway is named Base Connectivity Test. That was installed on the date shown. Under license status if you click on that, that'll bring up a screen that tells you apparently what's wrong with four software blades which we'll discuss on A Gateway 01. Over to the right a little bit if you click on device and license information, you'll get more information which you can drill down. Up at number 2 is a search field where you can find a specific say security gateway by name or by IP address that provides a quick way of locating in a very complicated checkpoint deployment with many hosts, the specific host that you want to interact with. In the security policies tab you have one or more tabs, and in this case only one tab is really displayed, this tab is labeled Standard. That's the name of a policy package, which we'll talk about, and that's the default policy package that's created when you deploy your management server. This standard policy package contains both access control policy and threat prevention policy. We've highlighted one of the access control policies and you can see that that policy consists of one rule, and it's named the Cleanup rule. We'll talk about the cleanup rule a little bit. The cleanup rule is a best practice rule that Checkpoint automatically adds to new policy packages. The cleanup rule always matches all of the matching columns, such as source, and destination, and services, are set to any or the equivalent of any. So when we evaluate your rules, if we get to the cleanup rule, it'll always match. The way that checkpoint evaluates rules is it starts at the first rule, rule number 1, does it match? If so, I'll do what that rule says and then I'll stop evaluating the rules in this layer, and we'll talk about that. If it doesn't match, we'll go to rule number 2. Does it match? We'll keep doing that until we find a rule that matches. The function of the cleanup rule is to be the very last rule in your policy. So before the cleanup rule is encountered, we had to evaluate and not match all of your other rules. A cleanup rule should always match, so it's the last stop. It's action should be to drop traffic. So this provides a default deny security policy. If we don't have a rule that matches that explicitly allows a connection, then we will drop through all of our rules till we get to the cleanup rule. That rule will always match and so it will deny drop the connection. You can't see it, but over on the right past the action column is a track column. Best practice is the track column should be set to log connections that have matched the cleanup rule. Because if you get to the cleanup rule, that implies that you did not match any of the rules above, which really means that the traffic that matched the cleanup rule was unanticipated. Anticipated traffic we write rules for. So this would be traffic that we weren't expecting. It's useful to know, are we getting traffic that we weren't expecting? In order to know that, you have to log the rule. We'll talk about logging in another module. Also Number 3, you can see a couple of buttons to add rules. We can add a rule at the top of our rule set. We can add a rule at the bottom. Or if we've selected a rule, we can add a rule above it or below it. Then in four you can see additional tools, some of these may open up a related GUI application to control whatever functionality you've selected. Then on the left-hand side, if we select the logs and monitor view again, we get tabs. In this case, there are three tabs displayed and the one that's selected is general overview. This general overview tab is actually showing you information from a feature or a product named SmartEvent. SmartEvent analyses incoming security logs from your gateways, but also from other things such as Microsoft servers or network infrastructure, and does event analysis to determine the logs I'm scene, is there something significant here, something a human should be aware of? SmartEvent makes it really easy to prioritize your attention. For instance, events are categorized by severity, critical, high, all the way down to very low severity. So you would typically react first to the critical severity events. Also SmartEvent will tell you what specific types of attacks or malware got through your policy because you matched a rule that said allow or you don't have some functionality enabled that would've stopped it. This is something that we recognize, but it got through. The logs tab which isn't selected here, shows you firewall logs and we'll talk about that in a future module. Then on the left-hand side, the manage and settings view has the list of checkpoint administrators, and you can see that there is five displayed here with the first one admin selected. The admin administrator is actually or a special it's automatically created when your management server is initialized, and then you would launch smart console and authenticate as the admin administrator. For additional administrators have been created;Walter, Saul, Jesse, and Skyler. Additional administrators can be assigned to different administrator permission profiles. In this case, everyone has been assigned the super user profile, which has read and write access everything. But the principle of least privilege says you should give only the access, only the permissions necessary for an individual administrator to do their job duties and nothing more. So for instance, Skyler may be a help desk technician who doesn't need to be able to modify your security policy. They just need to be able to look at logs, and that's it. So you can create an administrator permission profile or say help desk technicians that limits their access to read only views of your logs, nothing more. In addition to the SmartConsole GUI application, which is your main interface into the checkpoint product, there are also other related Windows applications that are installed with SmartConsole that handle more specialized things, such as the SmartEvent Client, which allows you to configure the SmartEvent product. For instance, configure event policy, what should cause an event to be logged and what should we not bother with? SmartEview Monitor, which allows you to see what is going on on security gateway in real-time with detail. For instance, what traffic is my security gateway processing? Is it HTTPS? Is it Windows file sharing? It also allows you to see which users are remotely VPN into the security gateway, where are they coming from? What client are they using? SmartDashboard is the legacy predecessor to SmartConsole, and as such, it is still invoked by SmartConsole to handle some functionality that is either considered legacy or that SmartConsole doesn't implement, such as configuring HTTPS inspection policy. When should Check Point intercept and decrypt HTTPS traffic, and when should it not? Now when you log in to SmartConsole, you are authenticating as a checkpoint administrator, there is one built-in default administrator count by default to username admin, and in production, you're not going to have all of your firewall administrators logging into the same account. Principle of least privilege and other security concerns mean that as a best practice, you should have individual accounts for each checkpoint administrator, and those accounts are assigned permission profiles, which limit their privileges to just what they need to do their job. For instance, a given checkpoint administrator may not require the privilege of changing other checkpoint administrators passwords. So a permission profile can be applied that doesn't permit that. When you login to SmartConsole as an administrator, a session is created and that session tracks what you have done thus far. If for some reason you are disconnected from the management server, SmartConsole will tell you and it will exit. But if you reconnect and login as the same checkpoint administrator, you can resume that session, and so all changes that you've made thus far will still be there. On the other hand, if you say leave yourself logged in with your checkpoint administrator account on your work desktop, and then it's evening or you're at home and something arises that you have to sign in. So you start up your work laptop and connect via SmartDashboard over the VPN to management server as the same checkpoint administrator, it will tell you there is already an administrator within existing session who's currently connected, and you can take over that session, disconnecting the administrator who's logged in from your desktop. Or you can login read-only or abort that connection. So each checkpoint administrator can only be logged in once, only have one session. On the other hand, if you have multiple checkpoint administrators defined, those administrators can all have their own session, and they can all be making changes simultaneously. Now on the top screenshot here, the DMZ rule has a pencil icon. What that indicates is, the administrator who is logged in to that displayed Dan in this example, has made some change to the DMZ rule. So the pencil icon means that you have an unpublished change here. Other administrators who were looking at the same part of SmartConsole, they will see a padlock icon at the DMZ rule. The DMZ rule cannot be edited by them because it's locked for edits by the first administrator who made a change, in this case Dan. Now when Dan publishes his changes, other administrators will see those changes. So for instance, in this example, Dan changed the action of the DMZ rule from dropped to accept, and Dan can see that because well, it was done in his session. But since Dan hasn't yet published that change, other administrators such as Mike, we'll see the original status of the rule. In this case, it has an action of drop, and they'll see a padlock icon, which means somebody else is working on this rule, but they haven't published yet. That's a significant feature that RAD added the ability to have multiple read write concurrent administrators logged in simultaneously. So I'll demonstrate how to install a management server and download and install SmartConsole and then log in to the management server via SmartConsole. So in this scenario, I have a brand new management server appliance that has not yet been configured, except it has an IP address and it has Operating System Administrator credentials, using the default built-in Operating System Administrator Admin. I'm now going to open up the web user interface, and note, I get an HTTPS warning here that the certificate authority is invalid. That's not surprising considering that I'm talking to an HTTPS web server on a Linux host that just initialized itself. So it created its own certificate authority unrelated to the internal certificate authority that Check Point Management Server Software creates. This is just a web server certificate authority. The web server certificate authority signed the digital certificate for this HTTPS web server, but I don't know that certificate authority. So I get this HTTPS warning, and I'm going to do what pretty much every user does and just click through the warning. But I would say a best practice in production is you do not want to routinely be doing sensitive administration operations over untrusted HTTPS connections. It's unlikely that you're talking to a man in the middle or other malicious actor who is attempting, for instance, to steal your username and password, but why not be sure? So you might want to look into either adding the appliance web server certificate authority as a trusted certificate authority, which is easy enough to do, or having your web server certificates on your appliances digitally signed by a trusted certificate authority, such as perhaps, maybe your Active Directory Certificate Authority. Something that your web browsers will trust. Now, to do all of that is beyond the scope of this Jump Start training, just mentioned it as something you might consider. So when I first installed this management server appliance, as I said, I used the built-in Administrator account, a default Administrator account that it presents, and I set a password. Actually, there's very little password complexity checking done. It does want you to choose a reasonably secure password. Here I'm using an eight-character password with both letters and numbers and even some punctuation, but still eight characters is short. You may want to choose a more secure password. So this management server appliance has been installed, it has an operating system, but it has not yet had the first time Wizard run. So when I log in through the web user interface, it's going to require that I go through this First Time Configuration Wizard. So note I'm installing the RAD.30 version of the Check Point product, and I'm going to click through some of these options. So now it wants me to configure the management connection, the management interface that I'll be using to manage this management server, and I'm just going to take all the defaults. These defaults come from when I first installed the operating system on this appliance, I gave it an IP address, a subnet mask, and told it which network interface to use. Now, here with the host name, choose wisely, you don't want to have to ever change this host name, it's certainly possible, but it's something of a pain to do so. So I'm just going to use an example host name, A-SMS. You'll see that throughout the Check Point training material if you attend our CCSA, Check Point Certified Security Administrator Course, which I strongly recommend. You'll see A-SMS used there. Domain name is optional, that's used for DNS. What we do need, DNS servers, so I'm going to type in a couple or just one, I think. If you have a web proxy that must be used to get out to the Internet, you can configure that here. Best practice would be to use the Network Time Protocol, NTP, and set the time zone correctly. This is a trap, if you're in the United States, for instance, the time zone looks like it's right, but it's actually the time zone for Central Canada. I'm going to go ahead and for this demonstration, set the time manually, and we'll call this time good, and going to go ahead and choose the time zone appropriate for me, it doesn't really matter that much where you are, just choose the time zone for where you are. That way the times are all correct. Now, here on a management server, I have to tell it, are you going to be just a regular management server or a Multi-Domain Server? Multi-Domain Servers allow a large organization, or a hosting company or what have you to have essentially virtual management servers for their customers. One for Company A, one for Company B and one for Company C, that are all running on the same physical appliance. Then Company A can have their administrators log into their virtual management server and manage their appliances, so can Company B and Company C. If you don't know what I'm talking about, you're not using Multi-Domain. If you are using Multi-Domain, I'm not going to go into the details of Multi-Domain, but most of what I demonstrate is still applicable. Starting with RAD, you'll have to have the correct operating system or the type of appliance, this is going to be in a few purchase a Check Point appliance. Don't worry about it, it's already done. I'm not actually using a Check Point appliance, I'm using a virtual machine, so-called Open Server. So I had to download the RAD.30 Management Installation image, which is distinct from the RAD.30 Security Gateway image. Because of that, security gateway is not an option here. Also, since this is not a security gateway, Clustering is not relevant, but I have to define this management server as one of three choices, Primary, Secondary, or Log Server SmartEvent. Unless you already have a management server, you'll always want to use the default primary. Secondary is when you want to do so-called management high availability where you have two management servers, only one is read-write, only one is active at a time. But if one of your management server suffers say a hard drive failure, you don't lose everything because it automatically replicates changes that you make to the primary or active management server to a secondary management server. Well, I don't have any management servers deployed at this point, so I'm going to stay with the default primary, and then a checkbox here automatically download Blade Contracts and other important data. We're just going to leave that. Then for the Check Point level configuration, let me just backtrack a little bit. Check Point has two levels of configuration, a bit surprising. Once you wrap your mind around it, you can work with it. There's operating system level configurations, such as the IP address of a Network Interface, routes that you've defined, and are our operating system level users. So when I signed into this Web User Interface, I signed in as the operating system level user admin with the password for that operating system level admin. But this screen is asking me is we need to create that default Check Point administrator, built-in that's sometimes referred to administrator. By default here, I can just use the operating system administrator username and password, which is convenient. Now I don't have two different admin accounts, perhaps two different passwords. If I ever want to change password for the admin account, I don't have to worry about doing it in two places. When I sign in to the management server using SmartConsole, I will use my Check Point administrator credentials, but it lets them be the same as the operating system administrator credentials, which is convenient. But if I don't want to do that, then I can use a different username with unique password. Also, we can restrict which IP addresses can log in to the management server using the GUI Clients such as SmartConsole, and best practice would be to restrict the list of IP addresses to at least a subnet. You can also just give a specific range of IP addresses, 184.108.40.206 through 17. For the easy of this demonstration, we're going to ignore best practice and say any IP address. Now your management service should be behind a security gateway, and your security gateway should not be allowing, say, the internet to connect to your management server's IP address. This is another layer of security, and we like having multiple layers of security in case one layer is breached. So this device that I'm going to be installing, is going to be installed as a primary management server. There's another checkbox here, improve product experience by sending data to Check Point. So if you want more information, you can click on the provided link. But this allows Check Point to track, for instance, issues that are happening. I'm just going to go ahead and leave that checked and click Finish. I get prompted to make sure I want to continue with the First Time Wizard Configuration, I do, and it will run. I'll go ahead and pause while this configuration runs its course. So the first time wizard has successfully completed and the management server is ready for use. This were a security gateway and would have to restart the operating system. But management server doesn't need to do that. So now the First Time Wizard being completed, we'll get the regular web user interface. Again, you can see the View mode drop-down here. If we change it to Basic, really just hides, a point. It is not completely finished loading, so I'm just going to let it completely finish loading. It was just slow to load the basic view because it's a virtual machine, but you can see that the left-hand menu has shrunk, not as many things listed. So what is listed are the most usual things that an administrator would need to access. I'm going to switch it back to the full advanced view, and let it reload the web page, and then we'll talk a little bit about some of the functionality that the web user interface provides. So you can manage the network hardware on the appliance, and on a management server there's not usually a whole lot to manage. Management server typically has a Management Interface that's already set up, so that you can access the Web User Interface in the first place. One thing I'm going to do just for my ease of use is here under System Management Session, the Web User Interface will automatically timeout after 10 minutes of no activity, and I'm just going to ramp that up to some unreasonable value. If I log in to the Command Line Interface of the Gaia operating system, that too has a timeout defaulting to 10 minutes, I'm going to set that to something completely unreasonable as well. In production, in the real world, you would not do this, you would choose a more sensible inactivity timeout. Maybe 10 or 15 minutes isn't long enough, so we'll set it to 30 minutes or an hour, but multiple days is probably not reasonable. You need to apply your changes for them to be effective. So what we can apply, I just did was send my changes as essentially CLI to this Gaia Host, the management server, and it applied my changes through the CLI, saved the changes. So they're permanent. My changes are now in production and they're permanent, they'll survive a reboot. It also configure users. In this example, on a brand new server, there are two administrators by default, the admin account and the monitor account. The monitor account is actually disabled, but the admin account has assigned to it a role. So the roles, this is Role-Based Access Control, determine what privileges an account has. Only the privileges assigned to the admin role, which as it turns out is all privileges. But again, principle of least privilege. If I have an application or an employee who needs to be able to login to either the CLI or the web user interface of a checkpoint host, they don't need all privileges. I can create a role that specifically with granularity defines what that administrator can do. I define the role, then I create the administrator account for that employee and I assign the administrator role to that account. Now, some things here grayed out because this is the built-in admin account, which you're not allowed to mess with. One thing that I can mess with is the shell. By default, the administrator account is given what checkpoint calls the CLI shell, command line interpreter shell. This is a restricted shell that, among other things, doesn't really do file paths, but it allows you to do the administration via the CLI. But for a lot of things, I want regular command line access. So you can change the shell of the administrator account to be the standard Linux shell, Bash, the Boolean shell. You can also create an additional account, a new account, assign it the admin role, and give that account Bash as its shell. Third option is in CLI shell, there's an expert mode command. If you type expert in CLI shell, it will prompt for a password and then once successful, it'll just give you a Bash shell. If you exit out of the Bash shell, you're back in CLI shell. That's another option. This no login here at the bottom is one way to disable an account. Another thing I wanted to point out here under upgrades is CPUSE. CPUSE is fairly recent addition. The checkpoint upgrade service engine allows a checkpoint host, like this management server, to reach out to checkpoint servers and discover if there are any patches or hot fixes or new operating system versions that are available, that are appropriate for this host. If so, there will be listed here. You can configure the behavior to not automatically go out and check. Instead, check when I tell you to, but it will not install updates until you tell it to, with one exception. By default, updates to the CPUSE module itself are automatically installed as they are encountered. You can disable that if you want to, but best practice is allow that to happen and CPUSE will always be the latest version. So the default is we're not going to download, we're not going to install anything. You can tell CPUSE, it's okay to download, but you do not install. That's sometimes useful that way, you don't have to wait for the download to complete. Next, I want to install SmartConsole. I can download SmartConsole from checkpoints website, but it's also available here in the web user interface. So I'll just do that. I'm going to go ahead and pause while the download is running because that'll take a bit. This is a big executable and we'll continue as soon as it's done. At this point, the SmartConsole executable file has been downloaded from the management server to my Windows desktop. It's not a small files, 450 mgb or so. I started the installer, and as part of the startup process of the installer, it's detected that there are several prerequisites that I do not currently have installed. That's pretty common. So I'm going to go ahead and allow the installer to run and then we'll resume. SmartConsole has successfully installed all the prerequisites and then the application suite itself, and I told it to continue launching. So now it's presenting me with a login screen. So I have to provide the username of the checkpoint administrator and I'm using the built-in admin password for that administrator account. The first time I also have to provide the IP address or host name of your management server. Now, when I click Login, SmartConsole will initiate a SIC connection to the management server. SmartConsole doesn't have a certificate at this point, so it will use the password to authenticate. I'll pause while I'm waiting for my virtual machine to finish connecting. The SmartConsole has successfully connected to the management server. The management server provides a certificate for its site of SIC, but at this point, it's signed by the internal certificate authority that exist on the management server which my SmartConsole application doesn't know about. So I'm prompted to verify the fingerprint, which is a set of short words that are derived from the digital values of the certificate authority. What one would do, would be you would log in to the CLI of the management server and bring up the fingerprint of the certificate authority and compare. Is what I'm seeing on the management server the same string of words that I'm seeing here. That's the old school way of verifying the certificate fingerprint. With RAD, you can sign into the management servers, web user interface, and the certificate authority fingerprint is available there on the left-hand side menu, management server only. So at this point, SmartConsole has successfully launched for the first time. It brings up a What's New window, which you can dismiss, but you can also get back by clicking down here on What's New. That concludes the demonstration for setting up a management server. Thank you. So in this module we talked about management and checkpoints, security management architecture, which again has three tiers. The GUI SmartConsole application, which communicates with a security management server. That's security management server in turn, installs security policy on your security gateways, your firewalls when instructed. All of this is accomplished over secure internal communication, which provides secure communications between any two checkpoint devices across the network. Secure internal communication relies on the internal certificate authority that is created on your management server. We also looked at Gaia, the checkpoint operating system briefly, and the web user interface that Gaia provides to make it easier to administrate your Gaia operating system and SmartConsole, the windows GUI application that allows you to administer your checkpoint configuration. Thank you very much for attending this module of Jump Start Training.