Familiarization with the Security Management Architecture (SMART)

Check Point's Security Management architecture is the foundational principle behind the centralized administration of multiple products and devices using common management interface(s).

Smart in the name of Check Point products dates back to when it was used as the acronym for Security Management Architecture. It is now present in the name of management servers and services, as well as Smart-1 products and their components: SmartLog and SmartEvent, Check Point's GUI, and the SmartConsole. There is also a migration tool for transition from competing solutions called SmartMove. In a nutshell, SMART could be described as a collection of the administrative stations, management, log, monitoring, and analytics servers that manage a variety of the gateways, endpoints, cloud-based inspection, and threat prevention products designed to seamlessly work together. It is practically infinitely scalable.

The following is a simple diagram depicting a basic implementation of the Check Point gateway and management infrastructure and their components:

Figure 1.3 – Basic components of Check Point's management architecture

Important Note

Although we commonly refer to it as a firewall, a correct definition would be gateway, where a firewall is just one of the components.

SmartConsole is the Windows-based management client application that is connected to all of your management servers, regardless of the components they are running. It will be your primary interface for managing the Check Point infrastructure.

In the context of network architecture, a basic implementation could look as simple as the following:

Figure 1.4 – All-in-one implementation. Management and gateway on a single device

In Figure 1.4, a single all-in-one device is acting as both a management server and a gateway. This is appropriate for the smallest environments that are aspiring to have world-class protection, but either lack the budget or justification to implement a distributed Check Point environment. It is also appropriate for small-scale labs where you may explore new release features and functionality.

In a slightly more demanding environment, which I would recommend as a good starting point, the management server running all of its constituent components resides on a separate appliance or a virtual machine. In this case, the gateway is running on a dedicated appliance as follows:

Figure 1.5 – Basic implementation with a dedicated management server

The advantage of this approach is the ability to manage many gateways from a common management server using a common object database.

Important Note

The functionality of the gateway is not dependent on the availability of the management server: even if it is down for maintenance or is being upgraded, the gateways continue to function and are logging locally. Once the management server comes back online, the logs are being automatically ingested by the management server.

Scaled further, SmartEvent is split from the management and log server to provide dedicated log correlation and reporting, as follows:

Figure 1.6 – SmartEvent log correlation and reporting on a dedicated server

This is a typical precursor for the expansion to either a multi-site or a hybrid environment, where a common SmartEvent server is used for log correlation, reporting, and analytics with multiple management and log servers. Since SmartEvent cannot be part of high-availability management, it should reside on a separate appliance or virtual machine. This is also one of the ways to offload your existing management server appliance if its utilization is consistently high.

And in a more typical data center environment, high-availability management and site-specific log servers are implemented to manage a larger number of gateways and clusters, as illustrated in the following diagram:

Figure 1.7 – Management high availability with dedicated log servers for multi-site environments

When your gateways and clusters under management generate a massive number of logs, it may be necessary to provide adequately sized log servers for each logically grouped location (typically based on geography or a specific data center).

The environment shown in Figure 1.7 allows you to ensure that the management servers used to create, manage, and install security policies in your environment will perform consistently, irrespective of the load on log servers.

Scaled even further, it may look like this:

Multiple SmartConsoles and API clients  multi-domain management servers/security management servers  multiple enterprise environments comprised of gateways, clusters, scalable platforms, hyperscale solutions, and/or endpoints  logging to dedicated log servers with monitoring and analytics provided by SmartEvent servers and forwarding logs to an SIEM of your choice

The more complex and expansive your infrastructure, the more granular implementation of Check Point management you may require to assure the necessary performance and redundancy.

Another option that should be specifically mentioned here is Quantum Smart-1 Cloud, a cloud-based management environment that is redundant and scalable on demand to accommodate your enterprise. Check Point takes care of the maintenance updates, upgrades, and high availability in the background, while you are simply administering your infrastructure from it. We will revisit management options in a later chapter to compare the advantages of different choices for specific circumstances.

As you go through this book, you will acquire valuable foundational knowledge equally applicable to all of the implementations described previously.

We now understand that the Security Management architecture allows you to grow your company and maintain the same level of protection, regardless of its scale or model. Before we go all technical, let's look at learning approaches, available options, and the reasoning behind this book's format.