Support Center > Search Results > SecureKnowledge Details
Best Practices: Connecting CloudGuard Gateway Virtual Edition as a perimeter Security Gateway Technical Level

Table of Contents:

  1. Introduction
  2. Best Practices
  3. Rationale
  4. Residual Risk
  5. Mitigation Controls
  6. Appendix
  7. Revision history


(1) Introduction

This article provides Best Practices for connecting CloudGuard Gateway Virtual Edition as a perimeter Security Gateway - i.e., in scenarios when the CloudGuard Gateway is deployed as an external enforcement point that mediates all traffic to and from the Internet.


(2) Best Practices

These Best Practices apply to CloudGuard Gateway Virtual Edition that is deployed in "Network Mode".

Using the configuration below, risk of compromise from the outside world is minimal, and an assurance argument can be made that it is near-equivalent to a dedicated Security Gateway appliance:

  • The ESX / ESXi host running CloudGuard Gateway should run only trusted VMs - ideally, dedicated for running security products, which presumably are trusted.

  • The ESX / ESXi host running CloudGuard Gateway should be connected to the external router via a dedicated NIC.
    PCI-pass-through ("Direct Path I/O" in VMware terminology) should be used to connect the Check Point CloudGuard Gateway virtual machine directly to this dedicated NIC.
    Note: Make sure the NIC is certified on the Check Point Hardware Compatibility List (HCL).

    ESX/ESXi Host
    | [Check Point CloudGuard Gateway VM]---("Direct Path I/O")---|-(Dedicated NIC)---[External Router]
  • Apply the relevant Mitigation Controls to address potential platform vulnerabilities.


(3) Rationale

When analyzing the risk of external attacks, we must consider the packet path.

On a physical Security Gateway appliance, Ethernet frames are DMAed from the NIC into memory, picked up by the network driver, and processed through a chain of logics that has been thoroughly analyzed and tested for its security properties by Check Point, as well as by third party labs (e.g., in the context of Check Point EAL4+ Common Criteria evaluations - sk97764, sk77840).

When using Direct Path I/O, the Check Point CloudGuard Gateway VM is allowed to access the dedicated external NIC hardware directly. It uses a certified Gaia OS network driver to do so. Therefore, the processing path (as far as we understand) is equivalent to that of a physical Security Gateway appliance.

We should also consider potential misconfiguration. When using Direct Path I/O, the only VM that can interact with the dedicated external NIC is the Check Point CloudGuard Gateway VM. Therefore, the risk of bypass is minimized.

If the primary network traffic path is outbound (through a NAT device), then attack surface is further constrained.


(4) Residual Risk

The Check Point CloudGuard Gateway is not running in a domain for its own execution that is protected against tampering and interference. It is dependent on the security and correct configuration of the VMware platform for such protection. This implies that there might be viable threats that target other VMs, the hypervisor, its management components, or the host's network-visible hardware (e.g., LOM card).

These residual threats may be categorized in three classes (see the next section "Mitigation Controls"):

  • Direct attacks on the platform from the internal network
  • Attacks on the platform from the external network - if we assume strict outbound, these would be piggy-backed on response traffic
  • Inherent flaws in other components running on the platform


(5) Mitigation Controls

  • Mitigating the internal threat

    First and foremost, VMware security recommendations should be adhered to, because it is the hypervisor that is trusted to ensure the separation property.

    Suggested resources:

    In particular, VMware recommends that you should physically isolate the service console - make sure that the network, from which the service console is isolated, is behind a firewall and is accessible only to authorized administrators. You can use a VPN or other access control methods to restrict access to the management network.

    Where remote access to the platform management components is required, the Check Point CloudGuard Gateway VM can be used to establish the recommended VPN trusted channel.

    The following recommendations can further address this threat vector:

    • Because the insertion of the Check Point CloudGuard Gateway into the traffic path depends on the correct configuration of the VMware platform, consider deploying a service on the internal network that periodically attempts to access a resource that is blocked by the Check Point CloudGuard Gateway policy.

      If this self-test fails (i.e., access is granted), an alert should be raised of a potential gateway bypass. One way to achieve this is to ping an upstream service on the customer's network that is protected by an upstream gateway, and have that gateway raise an alarm if it detects such a request.

    • If the site, protected by a virtualized gateway, accesses critical internal customer resources over an internal network, then it is recommended to protect these resources using an independent security gateway in order to enforce segmentation and prevent a security single point of failure.

  • Mitigating piggyback threats

    Any outbound communications from the platform (including its management components) and the VMs running on it, incurs risk, as crafted responses can trigger side effects that can be potentially leveraged by an attacker.

    Therefore, it is recommended to strictly curtail any such communications via the Check Point CloudGuard Gateway "Network Security" and "Application Control" policies.

    VPN can also be used, where applicable, to prevent session hijacking and server spoofing.

    On the Check Point CloudGuard Gateway, IPS blade should be enabled to prevent protocol misuse and exploit payloads.

    Anti-Bot and Anti-Virus blades should be enabled to provide pre- and post-infection protections.

  • Mitigating flaws in hosted components

    Where network traffic is processed by trusted VMs running on the ESX / ESXi host, processing failures might occur that could potentially lead to compromise of these VMs. Therefore, it is recommended that a DMZ approach be implemented, with the Check Point CloudGuard Gateway directly attached not only to the network interface leading to the external network, but to the internal network as well.

    If network traffic to the host contains file payloads, it is recommended to consider whether Sandblast Threat Emulation protections might be applicable as well.


(6) Appendix

Show / Hide this section

Check Point recommends employing a graded assurance and risk-based approach for security control selection. Risk can be managed. Best practice mitigations are identified in this section.

Check Point CloudGuard Gateway provides the same security functionality as a physical Security Gateway. Physical Security Gateway will always outperform virtual Security Gateway on level of assurance. Customers should use a combination of physical and virtual Security Gateways for establishing graded levels of separation.

It is important to differentiate between security and assurance. Functionally, Check Point CloudGuard Gateway provides the same security functionality as Check Point physical appliance or Open Server.

There is an obvious difference in terms of assurance that the Security Gateway cannot be bypassed or tampered with. This is because we rely on the security of the underlying platform, its correct configuration, and on the correctn integration with it.

Hypervisor vulnerabilities are not purely hypothetical.

In cases where the hypervisor is built-in to Check Point products, a quick response follows with fixes for discovered vulnerabilities (e.g., sk109700 and sk106060).

The same is true with Security Alert articles that relate to Check Point integrations with specific virtualization fabrics (e.g., sk96026).

However, where the vulnerability is in the underlying platform (e.g., see VMware Security Advisory VMSA-2017-0006 for critical virtual machine escape flaws), Check Point can only help if Check Point software security protections (e.g., IPS blade) are wrapping all communications in and out of the platform's attack surface; and even then not always.

Furthermore, covert channels are a real threat. For example, refer to Remote Timing Attacks are Still Practical. We should assume that malware running in a VM, could conceivably gain access to secrets held by other VMs running on the same machine, e.g., cryptographic secrets.


  • A standalone Check Point appliance provides the most assurance.

    (an Open Server direct install provides almost the same level, as we have established in the Check Point Common Criteria evaluations.)
  • VSX will provide higher assurance than VMware ESX running Check Point CloudGuard Gateway instances.

  • VMware running Check Point CloudGuard Gateways will provide higher assurance, if untrusted VMs are not running on the same ESX / ESXi host.

Again, this does not mean a lower level of security, as exactly the same protections are provided by all Check Point Security Gateways, physical and virtual.

Software-Defined Protection: Enterprise Security Blueprint eBook (page 13) has this to say about virtualized security:

"The main drawback for segmenting VLAN architectures is the reliance on the network
switch to enforce the segment separation policy, as these switches are also prone to attacks.
Misconfiguration may allow them to be bypassed by VLAN-hopping attacks which allow
a VLAN host to cross over to another. Therefore, combinations of virtual and network
separation should be used to provide graded levels of inter-segment separation."

Note: Also refer to Software-Defined Protection (SDP) page.

The key points here are:

  • Graded assurance - refer to Software-Defined Protection document (pages 8-9) on establishment of hierarchical lines of defense and the use of security profile differentials for modeling assurance requirements. It is recommended to use physical appliances as perimeter security devices, wherever the protected assets have significant value. It is recommended not to use the same ESX / ESXi installation for segments with different security profiles such as iDMZ and eDMZ. In addition, refer to Software-Defined Protection document (page 67) on the DMZ design pattern.

  • It is recommended that all access to platform resources (e.g., VMware management interfaces) is mediated by a Check Point Security Gateway. This improves the overall assurance of the system by addressing threats targeting the platform with a view to bypassing security controls.

  • Security misconfiguration is to blame for far more breaches than any that are attributed to security flaws in security products. This should concern the customer far more than the physical vs. virtual discussion. It just becomes so much harder when this is virtualized. One of the key value points of CloudGuard Gateway is that it moves the responsibility for the security policy from the platform administrator to the security administrator, because it is implemented on Check Point gold standard security management platform.


Important Note: Refer to Third-Party Software Disclaimer.


(7) Revision history

Show / Hide revision history

Date Description
19 August 2018
  • Changed vSEC to CloudGuard
24 Sep 2017
  • First release of this article

Give us Feedback
Please rate this document