©2025 Check Point Software Technologies Ltd. All rights reserved | P. 1 This document may be freely reproduced and distributed whole and intact including this copyright notice. Check Point R82 for Gateway and Maestro Configurations Common Criteria EAL4+AVA_VAN.4+ALC_FLR.1 Security Target (BSI-DSZ-CC-1207) Revision 015 04 April 2025 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 2 This document may be freely reproduced and distributed whole and intact including this copyright notice. © 2025 Check Point Software Technologies Ltd. All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. TRADEMARKS: Refer to the Copyright page http://www.checkpoint.com/copyright.html for a list of our trademarks. Refer to the Third Party copyright notices http://www.checkpoint.com/3rd_party_copyright.html for a list of relevant copyrights and third-party licenses. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 3 This document may be freely reproduced and distributed whole and intact including this copyright notice. References [AIS20] Anwendungshinweise und Interpretationen zum Schema (AIS) AIS 20. Anwendungshinweise und Interpretationen zum Schema AIS 20, Bundesamt für Sicherheit in der Informationstechnik, 15 May 2013 [SP800-90A] Recommendation for Random Number Generation Using Deterministic Random Bit Generators, Revision 1 [SP800-90B] Recommendation for the Entropy Sources Used for Random Bit Generation, NIST Special Publication 800-90B, January 2018. [RNG_Classes] A proposal for: Functionality classes for random number generators, Wolfgang Killmann and Werner Schindler, 18 September 2011, Version 2.0 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 4 This document may be freely reproduced and distributed whole and intact including this copyright notice. Contents Check Point R82 for Gateway and Maestro Configurations .....................................................................1 Common Criteria EAL4+AVA_VAN.4+ALC_FLR.1 ..................................................................................1 Security Target .........................................................................................................................................1 1 Security Target Introduction..............................................................................................................8 1.1 Security Target Reference ........................................................................................................8 1.2 TOE Reference .........................................................................................................................8 1.3 TOE Overview...........................................................................................................................9 1.4 TOE Description......................................................................................................................10 1.4.1 TOE Architecture.............................................................................................................10 1.4.2 Required non-TOE Hardware/Software/Firmware ..........................................................14 1.4.3 Physical Boundaries........................................................................................................15 1.4.4 Logical Boundaries..........................................................................................................25 2 Conformance Claims ......................................................................................................................30 2.1 Common Criteria Conformance Claims ..................................................................................30 2.2 Protection Profile Conformance Claims ..................................................................................30 2.3 Packages Conformance Claims..............................................................................................30 2.4 Conformance Rationale ..........................................................................................................30 3 Security Problem Definition.............................................................................................................31 3.1 Assets .....................................................................................................................................31 3.1.1 Primary assets ................................................................................................................31 3.1.2 Secondary assets............................................................................................................31 3.2 Threats....................................................................................................................................31 3.2.1 T.NETWORK_DISCLOSURE .........................................................................................31 3.2.2 T.NETWORK_ACCESS..................................................................................................31 3.2.3 T.MALICIOUS_TRAFFIC ................................................................................................31 3.2.4 T.UNAUTHORIZED_ADMIN_ACCESS ..........................................................................31 3.2.5 T.UNDETECTED_ACTIVITY ..........................................................................................32 3.3 Organizational security policies...............................................................................................32 3.4 Assumptions............................................................................................................................32 3.4.1 A.PHYSICAL_PROTECTION .........................................................................................32 3.4.2 A.LIMITED_FUNCTIONALITY ........................................................................................32 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 5 This document may be freely reproduced and distributed whole and intact including this copyright notice. 3.4.3 A.TRUSTED_ADMINSTRATOR .....................................................................................32 3.4.4 A.CONNECTIONS ..........................................................................................................33 3.4.5 A.LOCAL_NETWORK_PROTECTION ...........................................................................33 4 Security Objectives .........................................................................................................................34 4.1 Security objectives for the TOE...............................................................................................34 4.1.1 O.ADDRESS_FILTERING ..............................................................................................34 4.1.2 O.PORT_FILTERING......................................................................................................34 4.1.3 O.INTRUSION_PREVENTION .......................................................................................34 4.1.4 O.TOE_ADMINISTRATION ............................................................................................35 4.1.5 O.AUTHENTICATION.....................................................................................................35 4.1.6 O.SYSTEM_MONITORING ............................................................................................35 4.2 Security Objectives for the Operational Environment .............................................................36 4.2.1 OE.PHYSICAL ................................................................................................................36 4.2.2 OE.NO_GENERAL_PURPOSE......................................................................................36 4.2.3 OE.TRUSTED_ADMIN ...................................................................................................36 4.2.4 OE.CONNECTIONS .......................................................................................................36 4.2.5 OE.LOCAL_NETWORK..................................................................................................36 4.3 Security objectives rationale ...................................................................................................36 4.3.1 Security objectives rationale tracing................................................................................37 4.3.2 Justification for the effectiveness of the security problem solution .................................38 5 Extended Components Definition ...................................................................................................40 5.1 Security Audit (FAU) ...............................................................................................................40 5.1.1 External Audit Event Storage (FAU_EAS_EXT) .............................................................40 5.2 Intrusion Prevention System (IPS)..........................................................................................40 5.2.1 IPS Analyser analysis (IPS_ANL_EXT) ..........................................................................41 5.2.2 IPS Analyser React (IPS_RCT_EXT) .............................................................................41 5.3 Firewall (FFW).........................................................................................................................42 5.3.1 Stateful Traffic Filtering (FFW_RUL_EXT)......................................................................42 5.4 FCS_RNG Generation of random numbers............................................................................44 5.4.1 FCS_RNG.1 Random number generation ......................................................................44 5.5 Extended Components Rationale ...........................................................................................45 6 Security Requirements....................................................................................................................46 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 6 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1 TOE Security Functional Requirements..................................................................................46 6.1.1 Security audit (FAU)........................................................................................................47 6.1.2 Stateful Traffic Filtering Firewall (FFW)...........................................................................49 6.1.3 Intrusion Prevention System (IPS) ..................................................................................50 6.1.4 Identification and authentication (FIA).............................................................................51 6.1.5 Security Management (FMT) ..........................................................................................51 6.1.6 TOE access (FTA) ..........................................................................................................52 6.1.7 Protection of the TSF (FPT) and Trusted Path/Channels (FTP).....................................53 6.1.8 Cryptographic Support (FCS)..........................................................................................53 6.2 TOE Security Assurance Requirements .................................................................................55 6.2.1 Rationale for TOE Assurance Requirements Selection ..................................................56 6.3 Security Requirements Rationale............................................................................................57 6.3.1 Security Functional Requirements for the TOE...............................................................57 6.3.2 Security Functional Requirements Dependency Rationale.............................................57 7 TOE Summary Specification...........................................................................................................59 7.1 Security audit ..........................................................................................................................59 7.2 Packet Filtering and Stateful Traffic Filtering Firewall.............................................................60 7.3 Intrusion Prevention Systems .................................................................................................62 7.4 Identification and authentication..............................................................................................64 7.5 Security management .............................................................................................................64 7.6 TOE access.............................................................................................................................66 7.7 Protection of the TSF ..............................................................................................................66 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 7 This document may be freely reproduced and distributed whole and intact including this copyright notice. Tables and Figures Table 1 TOE firmware packages ............................................................................................................16 Table 2 TOE Component versions – SGM appliances...........................................................................18 Table 3 TOE Component versions –Maestro appliances .......................................................................20 Table 4 TOE Component versions – Smart-1 Security Management Server.........................................23 Table 5 TOE Component versions – Maestro Orchestrator appliances .................................................25 Table 6 Threats and assumptions tracing...............................................................................................37 Table 7 TOE threat prevention rationale.................................................................................................39 Table 8 TOE Security Functional Requirements ....................................................................................46 Table 9 Security Functional Requirements and Auditable Events..........................................................48 Table 10 EAL 4 Assurance Components................................................................................................56 Table 11 SFR Dependencies..................................................................................................................58 Table 12 TOE Cryptographic services....................................................................................................69 Figure 1 TOE deployment – single appliance.........................................................................................11 Figure 2 TOE deployment – Scalable Platform, , the NTP and Syslog log servers are on the same network as admin PC ...........................................................................................................................................12 Figure 3 Connection of Maestro components in Scalable Platform deployment ....................................12 Figure 4 Security Functionality provided TOE components....................................................................26 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 8 This document may be freely reproduced and distributed whole and intact including this copyright notice. 1 Security Target Introduction This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST conformance claims and the ST organization. The TOE is the R82 firmware providing Firewall, IPS Blade Pattern Matcher, and Security Management Server functionality for Check Point Software Technologies Ltd Security Gateway Appliances. The TOE is being evaluated as a network infrastructure device. The Security Target contains the following additional sections: • Conformance Claims (Section 2) • Security Problem Definition (Section 3) • Security Objectives (Section 3.4.5) • Extended Components Definition (Section 5) • Security Requirements (Section 6) • TOE Summary Specification (Section7) Conventions The conventions used in descriptions of the SFRs are as follows: • Assignment: Indicated with [italicized] text surrounded by square brackets; • Selection: Indicated with [underlined] text surrounded by square brackets; • Refinement: Indicated with bold text and strikethroughs, if necessary; • Assignment within a Selection: Indicated with [italicized and underlined] text surrounded by square brackets; • Iteration: Indicated by addition of a string starting with “/”. 1.1 Security Target Reference ST Title: Check Point R82 for Gateway and Maestro Configurations EAL4+AVA_VAN.4+ALC_FLR.1 Security Target (BSI-DSZ-CC- 1207) ST Revision: 5 ST Publication Date: 04 April 2025 1.2 TOE Reference TOE Identification: Check Point R82 for Gateway and Maestro Configurations ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 9 This document may be freely reproduced and distributed whole and intact including this copyright notice. TOE version: R82 TOE Developer: Check Point Software Technologies Ltd. TOE Type: Network and Network-Related Devices and Systems – Firmware- only TOE Stateful Traffic Filter Firewall, IPS Blade Pattern Matcher TOE Sponsor: Check Point Software Technologies Ltd. 1.3 TOE Overview The Target of Evaluation (TOE) is Check Point R82 for Gateway and Maestro Configurations. The TOE is a combination of the firmware for Security Gateway Module(s), a Security Management Server and (when deployed in Scalable Platform configuration) the firmware for the Maestro Orchestrator appliance(s): • The Security Gateway Module (SGM) is a managed packet filtering firewall application, with IPS pattern matching (software) blade. The TOE provides controlled connectivity between two or more network environments. It mediates information flows between clients and servers located on internal and external networks governed by the firewalls. The SGM can either be deployed using instances of a single Security Gateway appliance, which incorporates the SGM or a combination of Security Gateway Modules (SGM) operating in a cluster as part of a Scalable Platform (SP). • The Security Management Server is used to manage and deploy the security policies and rules to SGM. • When operating as part of a Scalable Platform (SP), the Orchestrator appliance provides load balancing services for the SGMs. The Security Management Server is located on a logically protected LAN behind the firewall in single deployment mode, and behind the load-balancing Orchestrator in Scalable deployment mode. All management traffic is communicated between TOE components over secured channels provided by the TOE. The purpose of the firewall blade is to protect the assets operating on a customer’s network from malicious attempts to control or gain access to those assets. The IPS pattern matching blade provides protection against signatures defining malicious and unwanted network traffic, focusing on application and server vulnerabilities, as well as in-the-wild attacks by exploit kits and malicious attackers. The firewall filtering rules, and IPS rules are defined, managed and deployed by the Security Management Server. When in Scalable Deployment, the Orchestrator appliance(s) provide load-balancing across the gateway resources. Besides the aforementioned main security features, the TOE also provides functionality • for identification and authentication (based on passwords), • to limit TOE Access (i.e. to logout users after a certain period of inactivity) and • to generate audit logs of security events (Security Audit). ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 10 This document may be freely reproduced and distributed whole and intact including this copyright notice. 1.4 TOE Description Check Point Security Gateway Appliances R82 firmware provides a broad range of packet filtering services, features and capabilities to be delivered by the SGM. This Security Target (ST) makes a set of claims regarding the product’s security functionality, in the context of an evaluated configuration. The claimed security functionality is a subset of the product’s full functionality whereas all other functionality must be disabled for certified use. The evaluated configuration is a subset of the possible configurations of the product, as defined in this ST and established according to the evaluated configuration guidance (CC Installation Configuration and Administration Guide, see Section 1.4.3 below). The Check Point Security Management Server software provides management functionality for the administration of the Security Gateway Appliances. When in Scalable Platform deployment, the Maestro Orchestrator firmware provides load- balancing services for the Security Gateway Appliances performing the traffic inspection. The administration of the Orchestrator appliances is performed directly via the Orchestrator WebUI. This part of the Security Target describes the physical and logical scope and boundaries of the TOE. This description relates to the claimed security functionality that is evaluated in the context of this ST. The TOE Description consists of the following subsections: • TOE Architecture – describes the high level TOE components, their deployment and their relationship to each other. • Required non-TOE Hardware/Software/Firmware – specifies hardware, software and firmware required for the TOE to operate correctly that is not included within the TOE boundary. • Physical Boundaries – describes the firmware and software parts that constitute the TOE, and identifies the guidance documentation that is considered to be part of the TOE. • Logical Boundaries – describes the claimed logical security features offered by the TOE. 1.4.1 TOE Architecture The TOE is the Security Gateway Appliances R82 firmware providing firewall capabilities for filtering traffic based on packet rules. It is a distributed system with support for a security management server deployed on a dedicated management LAN behind the firewall. The TOE includes the software executing on the hardware components: • Security Gateway – Security Gateway Appliance firmware with Firewall and IPS Blade Pattern Matcher functionality installed on either a single appliance or on Security Gateway Modules configured in a cluster (managed by an Orchestrator appliance). • Security Management – Security Management Server software. • (When in Scalable Platform deployment) Maestro Orchestrator – Orchestrator appliance firmware providing load balancing for traffic filtering according to Security Groups. All management traffic communicated between TOE components is transmitted over secured channels provided by the TOE and must be established from internal networks. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 11 This document may be freely reproduced and distributed whole and intact including this copyright notice. Check Point Security Gateway R82 Security Gateway firmware is installed on a hardware platform (appliance or Security Gateway Module). The firmware includes the Check Point GAiA operating system (OS), which is an integral part of the Security Gateway firmware and as such is included within the TOE boundary. The OS is responsible for providing storage for audit trail, an IP stack for in-TOE routing, NIC drivers and an execution environment for daemons and security servers. The same GAiA OS (R82) is also deployed on the Security Management server and the Orchestrator appliances. 1.4.1.1 Single Security Gateway configuration Check Point Security Gateway Appliances mediate information flows between clients and servers located on internal and external networks governed by the firewall, as shown in Figure 1 below. The TOE imposes traffic-filtering controls on mediated information flows between clients and servers according to the site’s security policy rules. By default, these security policy rules deny all inbound and outbound information flows through the TOE. Only a Security Management Server administrator has the authority to change the security policy rules. Figure 1 TOE deployment – single appliance 1.4.1.2 Security Gateway Scalable Platform The traffic-filtering controls on mediated information flows on mediated information flows between clients and servers according to the site’s security policy rules are enforced by the gateway in the same manner, whether the TOE is configured as a single appliance or as part of a Scalable Platform deployment with Maestro components. In Scalable Platform deployment traffic is received from untrusted networks by Orchestrator appliances and the Orchestrator appliances distribute the traffic to the SGMs (the SGMs in Scalable Platform deployment are also known as Maestro appliances). The security and threat prevention ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 12 This document may be freely reproduced and distributed whole and intact including this copyright notice. policies are enforced on the traffic by each SGM, before the SGM forwards the traffic to the trusted networks via the Orchestrator appliance downlink. Every SGM in the cluster has the same security policy. Figure 2 shows an example Scalable Platform deployment and Figure 3 shows the connection of the Maestro components (Orchestrator appliance and Maestro appliances) within a Scalable Platform deployment. The Orchestrator appliances must be physically located in the same protected environment. Figure 2 TOE deployment – Scalable Platform, , the NTP and Syslog log servers are on the same network as admin PC Figure 3 Connection of Maestro components in Scalable Platform deployment ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 13 This document may be freely reproduced and distributed whole and intact including this copyright notice. To operate in a Scalable Platform deployment Security Groups are established. A Security Group is a logical group forming an active / active cluster segregated from other Security Groups. Security groups include network interfaces (uplinks), Management interfaces and Appliances (SGMs). A single IP address is assigned per Security Group for management communications and policy installation. This is concept is known as Single Management Object (SMO). There is a relationship between a downlink ports and SGM, so in this way an Orchestrator appliance determines which SGM will inspect the traffic. The Orchestrator appliance provides traffic load-balancing mechanisms across Security Group members, calculating traffic distribution dynamically so that members of the security group can be seamlessly added and removed. HyperSync is used as the Cluster Synchronization mechanism. Within the same cluster (Security Group) each connection is synchronized to two Security group members (Active and Backup). One of SGMs is Active per given connection (it enforce security policy with all related inspections and protections), another one is Backup (keep connection in its connection table) and will replace Active in case of failure. The SGM receiving the connection will decide which is its backup SGM, and will forward connection information to that backup SGM over the SYNC-VLAN. The REST API is used by the SGM to inform Orchestrator if a SGM is unavailable. The Security Groups are managed from an MHO Administrator PC using the administrative WebUI provided on the Orchestrator appliance. The MHO Administrator PC must be located on the internal network, which is the only network connected to the management port of the Orchestrator appliance. Furthermore, this communication between the MHO Administrator PC and the Orchestrator appliance is protected using TLS v1.3. The browser on the MHO Administrator PC must be configured to only support TLS v1.3 connection requests. When a new SGM is added to a cluster, Orchestrator uses LLDP (Link Layer Discovery Protocol) to discover it and notify the other SGMs that a new SMG has been added. In a Single site deployment, all components (SGMs, Orchestrator appliances and, Management Server) are all physically connected using Direct Attached Copper (DAC) or fibre cables, within a single secure location. Use of multiple Orchestrator appliances within a single site deployment is supported in the evaluated configuration. The Orchestrator appliances communicate between each other using REST API. In a dual site deployment, a direct (tunnelled) connection is required between the two Orchestrator appliances, which again is communication in the environment of the TOE. However, this dual site deployment is outside the TOE configuration. 1.4.1.3 Security Management Server Security Management Server Administrators also need to authenticate to the TOE before they can use the Management APIs to access Security Management. This is achieved using a password-based authentication mechanism. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 14 This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Gateway Modules or one or more Security Gateway appliances are managed by a Security Management server installation (includes GAiA operating system and Security Management application). The Security Management server maintains security policy information for the gateways, and collects audit records from the gateways for review by Security Management Server administrator. The audit records may also be sent to an external log server (which in the evaluated configuration must be hosted on the logically- protected dedicated management LAN hosted behind the firewall). The Security Management Server administrator (remotely) communicates with the Security Management server via the Check Point REST API over TLS v1.3 or (locally) via a directly connected console to the CLI. • Local administration is only supported during initial installation or troubleshooting when the TOE is taken out of operation. • Remote administration using REST API must be performed from an Administrator PC located on the internal network and the browser on the Administrator PC must be configured to only support TLS v1.3 connection requests. Only the internal network can be connected to the management port on the Security Management Server. Communication between the Security Management server and the SGMs is protected by SIC (a proprietary Secure Internal Communication protocol). Use of the Check Point SmartConsole is not supported in the evaluated configuration. In Scalable Platform deployment, all traffic for the management of the SGMs is transmitted over the network connection between the Security Management server and the SGM, via a separate VLAN provided by the Orchestrator appliance. The Orchestrator administrator (remotely) communicates with the Orchestrator appliance via the Orchestrator WebUI over TLS v1.3 or (locally) via a directly connected console to the CLI. • Local administration of the Orchestrator appliance is only supported during initial installation or troubleshooting when the TOE is taken out of operation. • Remote administration of the Orchestrator appliance using WebUI must be performed from an MHO Administrator PC located on the internal network and the browser on the MHO Administrator PC must be configured to only support TLS v1.3 connection requests. Only the internal network can be connected to the management port on the Orchestrator appliance. 1.4.2 Required non-TOE Hardware/Software/Firmware The TOE requires hardware platforms for it to operate, but these are not part of the TOE; they exist within the TOE environment. These hardware platforms are Check Point Security Gateway Appliances/Security Gateway Modules and Security Management Appliances, which execute firmware installed from the applicable R82 firmware image, and the Orchestrator appliances if the TOE is deployed as a Scalable Platform. There are separate firmware images for: • Security Gateway appliances • Scalable Platform (Maestro) Gateway appliances • Security Management Server appliances • (when in SP deployment) Maestro Hyperscale Orchestrator appliances. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 15 This document may be freely reproduced and distributed whole and intact including this copyright notice. The differences between the appliances are mainly in hardware makeup and physical ports. All platforms are x86 based hardware. The hardware platforms are as follows: • Maestro appliances running R82 firmware (Scalable Platform image): o Maestro Hyperscale Gateway § 9100, 9200, 9300, 9400, 9700, 9800, 19100, 19200 • Security Gateway appliances running R82 firmware (Security Gateway appliance image): o High End Enterprise Data Center: § 19100,19200, 29100, 29200 o Perimeter: § 9100, 9200, 9300, 9400, 9700, 9800 o Small Business and Branch Offices: § 3600, 3800 • Smart-1 Security Management Server appliances running the GAiA R82 firmware (Security Management Server image): o 600-M, 600-S, 6000-L, 6000-XL o 700S, 700M, 7000L, 7000XL, 7000Ultra • Orchestrator appliances o Maestro Hyperscale Orchestrator 140 o Maestro Hyperscale Orchestrator 175 The following additional IT environment components required to support the secure operation of the TOE. All of these components have to be hosted in the secure Management LAN: • Administration PC – This PC is the machine used by the Security Management Server administrator to issue the management commands to the SGMs over REST API. • MHO Administrator PC – This PC is the machine used by the Orchestrator administrator to manage the Orchestrator appliances via the Orchestrator WebUI. • NTP Server – This server provides NTP time services to the TOE (Security Manager Server and Orchestrator appliances). • Syslog log Server – This server provides storage for audit logs exported by the TOE. Tools such Postman can be used to issue the REST API commands from the administration PC to the Security Management server, as described in the CC Installation Configuration and Administration Guide. 1.4.3 Physical Boundaries The physical boundary of the TOE is the Security Gateway Appliances R82 firmware and Security Management Server firmware (i.e. it is a software only TOE boundary). There is a single variant of the R82 firmware .iso package depending on which GAiA operating system is supported by the appliance: ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 16 This document may be freely reproduced and distributed whole and intact including this copyright notice. Firmware Package Download file SHA-256 hash value Security Gateway or Management Server Check_Point_R82_G aia.iso 71d71b33f1f5b64e4ee9c93bb00d4d0d5c 512c577ff8181d5e836c314dfabd65 Scalable Platform (Maestro) Gateway and Maestro Hyperscale Orchestrator QLS Security Gateway MLS Security Gateway Table 1 TOE firmware packages The above firmware packages contain the software components that of the TOE. The unique version of the TOE is determined by the execution of two commands on the console during installation: cpinfo -d -D -i -y all This is Check Point CPinfo Build 914000250 for GAIA [CPshared] No hotfixes.. [IDA] No hotfixes.. [CPFC] No hotfixes.. [MGMT] No hotfixes.. [FW1] HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_AUTOUPDATE HOTFIX_GOT_TPCONF_AUTOUPDATE HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE HOTFIX_INEXT_NANO_EGG_AUTOUPDATE FW1 build number: ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 17 This document may be freely reproduced and distributed whole and intact including this copyright notice. This is Check Point's software version R82 - Build 005 kernel: R82 - Build 005 [SecurePlatform] No hotfixes.. [PPACK] No hotfixes.. [CPinfo] No hotfixes.. [AutoUpdater] HOTFIX_INFRA_CONFIG_AUTOUPDATE [DIAG] No hotfixes.. [CVPN] No hotfixes.. [core_uploader] HOTFIX_CHARON_HF [CPUpdates] BUNDLE_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE Take: 32 BUNDLE_UCA_SSH_TUNNELING_APP_AUTOUPDATE Take: 32 BUNDLE_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE Take: 29 BUNDLE_UCA_INFRA_LOG_SERVICE_AUTOUPDATE Take: 23 BUNDLE_UCA_INFRA_AUTOUPDATE Take: 56 BUNDLE_GOT_TPCONF_AUTOUPDATE Take: 137 BUNDLE_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE Take: 21 BUNDLE_INEXT_NANO_EGG_AUTOUPDATE Take: 13 BUNDLE_HCP_AUTOUPDATE Take: 74 BUNDLE_CPSDC_AUTOUPDATE Take: 34 BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE Take: 17 BUNDLE_INFRA_CONFIG_AUTOUPDATE Take: 3 BUNDLE_CPVIEWEXPORTER_AUTOUPDATE Take: 34 BUNDLE_QUID_AUTOUPDATE Take: 14 BUNDLE_CPOTLPAGENT_AUTOUPDATE Take: 26 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 18 This document may be freely reproduced and distributed whole and intact including this copyright notice. BUNDLE_CPOTELCOL_AUTOUPDATE Take: 97 [CPotelcol] HOTFIX_OTLP_GA [CPotlpAgent] HOTFIX_OTLP_GA [CPquid] HOTFIX_QUID_AUTOUPDATE [CPviewExporter] HOTFIX_OTLP_GA [cpsdc_wrapper] HOTFIX_CPSDC_AUTOUPDATE [hcp_wrapper] HOTFIX_HCP_AUTOUPDATE Table 2 TOE Component versions – SGM appliances This is Check Point CPinfo Build 914000250 for GAIA [CPshared] No hotfixes.. [IDA] No hotfixes.. [CPFC] No hotfixes.. [MGMT] No hotfixes.. [FW1] No hotfixes.. FW1 build number: This is Check Point's software version R82 - Build 005 [SecurePlatform] No hotfixes.. [PPACK] ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 19 This document may be freely reproduced and distributed whole and intact including this copyright notice. No hotfixes.. [CPinfo] No hotfixes.. [AutoUpdater] HOTFIX_INFRA_CONFIG_AUTOUPDATE [SMO] No hotfixes.. [MHO] No hotfixes.. [CPotelcol] HOTFIX_OTLP_GA [CPUpdates] BUNDLE_HCP_AUTOUPDATE Take: 74 BUNDLE_CPSDC_AUTOUPDATE Take: 34 BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE Take: 17 BUNDLE_INFRA_CONFIG_AUTOUPDATE Take: 3 BUNDLE_CPVIEWEXPORTER_AUTOUPDATE Take: 34 BUNDLE_QUID_AUTOUPDATE Take: 14 BUNDLE_CPOTLPAGENT_AUTOUPDATE Take: 26 BUNDLE_CPOTELCOL_AUTOUPDATE Take: 97 [CPotlpAgent] HOTFIX_OTLP_GA [CPquid] HOTFIX_QUID_AUTOUPDATE [CPviewExporter] HOTFIX_OTLP_GA [core_uploader] HOTFIX_CHARON_HF [cpsdc_wrapper] HOTFIX_CPSDC_AUTOUPDATE [hcp_wrapper] HOTFIX_HCP_AUTOUPDATE ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 20 This document may be freely reproduced and distributed whole and intact including this copyright notice. Table 3 TOE Component versions –Maestro appliances This is Check Point CPinfo Build 914000250 for GAIA [CPshared] No hotfixes.. [IDA] No hotfixes.. [CPFC] No hotfixes.. [MGMT] No hotfixes.. [FW1] HOTFIX_WEBCONSOLE_AUTOUPDATE HOTFIX_VCE_R81_20_AUTOUPDATE HOTFIX_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE HOTFIX_INEXT_NANO_EGG_AUTOUPDATE HOTFIX_GOT_MGMT_AUTOUPDATE HOTFIX_GOT_TPCONF_MGMT_AUTOUPDATE FW1 build number: This is Check Point Security Management Server R82 - Build 005 This is Check Point's software version R82 - Build 005 [SecurePlatform] No hotfixes.. [CPinfo] No hotfixes.. [AutoUpdater] HOTFIX_INFRA_CONFIG_AUTOUPDATE [DIAG] No hotfixes.. [Reporting Module] ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 21 This document may be freely reproduced and distributed whole and intact including this copyright notice. No hotfixes.. [CPuepm] No hotfixes.. [VSEC] No hotfixes.. [CPDepCon] No hotfixes.. [CPRepMan] No hotfixes.. [SmartLog] No hotfixes.. [R7540CMP] No hotfixes.. [R76CMP] No hotfixes.. [SFWR77CMP] No hotfixes.. [SFWR80CMP] No hotfixes.. [SFWR81CMP] No hotfixes.. [SFWR82CMP] No hotfixes.. [R77CMP] No hotfixes.. [R8040CMP] No hotfixes.. [R8120CMP] No hotfixes.. [core_uploader] HOTFIX_CHARON_HF [CPUpdates] ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 22 This document may be freely reproduced and distributed whole and intact including this copyright notice. BUNDLE_DC_CONTENT_AUTOUPDATE Take: 20 BUNDLE_WEBCONSOLE_AUTOUPDATE Take: 120 BUNDLE_VCE_R81_20_AUTOUPDATE Take: 42 BUNDLE_TUNNEL_AUTOUPDATE Take: 107 BUNDLE_DANA_AUTOUPDATE Take: 170 BUNDLE_INFRA_CONFIG_AUTOUPDATE Take: 3 BUNDLE_INFINITY_CRA_AUTOUPDATE Take: 32 BUNDLE_PUBLIC_CLOUD_CA_BUNDLE_AUTOUPDATE Take: 21 BUNDLE_INEXT_NANO_EGG_AUTOUPDATE Take: 13 BUNDLE_HCP_AUTOUPDATE Take: 74 BUNDLE_GOT_MGMT_AUTOUPDATE Take: 132 BUNDLE_DC_INFRA_AUTOUPDATE Take: 30 BUNDLE_GOT_TPCONF_MGMT_AUTOUPDATE Take: 39 BUNDLE_MINMUS_AUTOUPDATE Take: 23 BUNDLE_KERBIN_AUTOUPDATE Take: 47 BUNDLE_CPVIEWEXPORTER_AUTOUPDATE Take: 34 BUNDLE_QUID_AUTOUPDATE Take: 14 BUNDLE_CPSDC_AUTOUPDATE Take: 34 BUNDLE_CPOTLPAGENT_AUTOUPDATE Take: 26 BUNDLE_CPOTELCOL_AUTOUPDATE Take: 97 BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE Take: 17 [CPotelcol] HOTFIX_OTLP_GA [CPotlpAgent] HOTFIX_OTLP_GA [cpsdc_wrapper] HOTFIX_CPSDC_AUTOUPDATE [CPquid] HOTFIX_QUID_AUTOUPDATE [CPviewExporter] HOTFIX_OTLP_GA [diff_report_wrapper] ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 23 This document may be freely reproduced and distributed whole and intact including this copyright notice. HOTFIX_MINMUS_AUTOUPDATE HOTFIX_KERBIN_AUTOUPDATE [MGMTAPI] No hotfixes.. [itp_wrapper] HOTFIX_GOT_MGMT_AUTOUPDATE [hcp_wrapper] HOTFIX_HCP_AUTOUPDATE [icra_wrapper] HOTFIX_INFINITY_CRA_AUTOUPDATE [sho_wrapper] HOTFIX_DANA_AUTOUPDATE [infinity_onprem_wrapper] HOTFIX_TUNNEL_AUTOUPDATE Table 4 TOE Component versions – Smart-1 Security Management Server This is Check Point CPinfo Build 914000250 for GAIA [CPshared] No hotfixes.. [IDA] No hotfixes.. [CPFC] No hotfixes.. [MGMT] No hotfixes.. [FW1] HOTFIX_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE HOTFIX_UCA_SSH_TUNNELING_APP_AUTOUPDATE HOTFIX_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_LOG_SERVICE_AUTOUPDATE HOTFIX_UCA_INFRA_AUTOUPDATE ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 24 This document may be freely reproduced and distributed whole and intact including this copyright notice. HOTFIX_GOT_TPCONF_AUTOUPDATE HOTFIX_INEXT_NANO_EGG_AUTOUPDATE FW1 build number: This is Check Point's software version R82 - Build 005 kernel: R82 - Build 005 [SecurePlatform] No hotfixes.. [PPACK] No hotfixes.. [CPinfo] No hotfixes.. [AutoUpdater] HOTFIX_INFRA_CONFIG_AUTOUPDATE [SMO] No hotfixes.. [MGW] No hotfixes.. [DIAG] No hotfixes.. [CVPN] No hotfixes.. [core_uploader] HOTFIX_CHARON_HF [CPUpdates] BUNDLE_UCA_SSH_TUNNELING_SERVICE_AUTOUPDATE Take: 32 BUNDLE_UCA_SSH_TUNNELING_APP_AUTOUPDATE Take: 32 BUNDLE_UCA_INFRA_MONITOR_SERVICE_AUTOUPDATE Take: 29 BUNDLE_UCA_INFRA_LOG_SERVICE_AUTOUPDATE Take: 23 BUNDLE_UCA_INFRA_AUTOUPDATE Take: 56 BUNDLE_GOT_TPCONF_AUTOUPDATE Take: 137 BUNDLE_INEXT_NANO_EGG_AUTOUPDATE Take: 13 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 25 This document may be freely reproduced and distributed whole and intact including this copyright notice. BUNDLE_HCP_AUTOUPDATE Take: 74 BUNDLE_CPSDC_AUTOUPDATE Take: 34 BUNDLE_CORE_FILE_UPLOADER_AUTOUPDATE Take: 17 BUNDLE_INFRA_CONFIG_AUTOUPDATE Take: 3 BUNDLE_CPVIEWEXPORTER_AUTOUPDATE Take: 34 BUNDLE_QUID_AUTOUPDATE Take: 14 [CPquid] HOTFIX_QUID_AUTOUPDATE [CPviewExporter] HOTFIX_OTLP_GA [cpsdc_wrapper] HOTFIX_CPSDC_AUTOUPDATE [hcp_wrapper] HOTFIX_HCP_AUTOUPDATE Table 5 TOE Component versions – Maestro Orchestrator appliances All firmware is delivered from the Check Point User Center (https://usercenter.checkpoint.com) by user initiated download over an HTTPS protected connection with a 2048-bit RSA certificate. For verification of integrity of the delivered image hash values are available separately and a software tool is supplied to allow a customer to check the hash values against the supplied image. The hash values are also reflected in Table 1 above. The TOE includes the guidance: Check Point R82 for Gateway and Maestro Configurations, Installation and Configuration, BSI Administration Guide, Revision 008, 03 March 2025. The TOE and its guidance documentation (as PDF) is delivered to customers from the Check Point User Center (https://usercenter.checkpoint.com) by user download. The TOE guidance and any specific TOE HotFix is provided via a SecureKnowlege SK entry – SK181211. A User Center account is required in order to download the TOE. If a user does not possess a User Center account, then one can be created. 1.4.4 Logical Boundaries This section summarizes the security functions provided by R82: • Security audit • Stateful Traffic Filtering Firewall ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 26 This document may be freely reproduced and distributed whole and intact including this copyright notice. • Packet Filtering • Intrusion Prevention Systems • Identification and authentication • Security management • TOE access • Protection of TSF The following table shows which TOE component is responsible for the implementation of each of the SFRs: Requirement Class Security Gateway Appliance/Maestro Gateway Management Server Orchestrator Appliance Firewall blade IPS blade GAiA Management Server application GAiA GAiA FAU: Security audit X X X X X FFW: Stateful Traffic Filtering Firewall X X IPS: Intrusion Prevention Systems X FIA: Identification and authentication X X X X FMT: Security management X X FTA: TOE access X X FPT: Protection of the TSF X X X Figure 4 Security Functionality provided TOE components 1.4.4.1 Security audit The Security Management server generates audit records for all changes to configuration of the TOE relating to filtering policies. In addition, audit records are generated for changes to authentication credentials and all administrative login/logout activities at the Security Management server. The SGMs generate audit records of the application of rules configured with the ‘log’ operation. The SGMs can be configured to store these logs locally, forward logs to the Security Management Server, or both. If configured to send logs to the Security Management Server, in the event of a loss of network connectivity to the Security Management Server, then the SGM will store locally until the connection is restored. The Management Server generates audit records for specified events, recording at least date ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 27 This document may be freely reproduced and distributed whole and intact including this copyright notice. and time of the event, type of event, subject identity, and the outcome. The SGM can be configured to send audit logs to a log server (hosted in the dedicated management LAN) as well. Finally, note that the SGMs can be configured such that if they run out of disk space for local logs, they can block all connections. The audit records include a timestamp of the event using the clock provided by the operating system. When in SP deployment, the Orchestrator appliance generates audit records for all changes to configuration of the Security Groups. In addition, it generates audit records for changes to authentication credentials and all administrative login/logout activities on the Orchestrator appliance. 1.4.4.2 Packet Filtering and Stateful Traffic Filtering Firewall The SGMs support many protocols for packet filtering including ICMPv4, IPv4, TCP and UDP. The firewall rules implement the SPD rules (permit, deny, bypass). Each rule can be configured to log status of packets pertaining to the rule. All codes under each protocol are implemented. Routed packets are forwarded to a TOE interface with the interface’s MAC address as the layer-2 destination address. The TOE routes the packets using the presumed destination address in the IP header, in accordance with route tables maintained by the TOE. IP packets are processed by the Check Point Security Gateway Appliances/Modules software, which associates them with application-level connections, using the IP packet header fields: source and destination IP address and port, as well as IP protocol. Fragmented packets are reassembled before they are processed. The TOE mediates the information flows according to a Security Management Server administrator-defined policy. Some of the traffic may be either silently dropped or rejected (with notification to the presumed source). An IPS engine is integrated with the product’s traffic-filtering functionality, matching traffic with predefined attack signatures and providing reaction capabilities. The TOE’s firewall capabilities are controlled by defining an ordered set of rules in the Security Rule Base. The Rule Base specifies what communication will be allowed to pass and what will be blocked. It specifies the source and destination of the communication, what services can be used, at what times, whether to log the connection and the logging level. 1.4.4.3 Intrusion Prevent System (IPS) The SGMs provide a multi-layer IPS engine that is integrated into the product (see Section 1.4.4.2 for a description of the TOE’s IPS related packet filtering mechanism). Traffic that has been allowed by the firewall security policies is matched against a combined set of protocol enforcement and pattern matching logic that identifies suspicious network traffic and assigns Confidence Level (that the traffic indeed contains an attack) and Severity (potential impact of the attack on protected resources) security attributes to the traffic. Based on these attributes and on Security Management Server administrator-specified ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 28 This document may be freely reproduced and distributed whole and intact including this copyright notice. security policy settings, the IPS engine (blade) may take action by generating applicable log records (detect) and optionally blocking the traffic (prevent). 1.4.4.4 Identification and authentication The Security Management Server and (when in SP deployment) Orchestrator appliances implement a password-based authentication mechanism that identifies Security Management Server and Orchestrator (when in SP deployment) administrators via usernames. Three sequential failed authentication attempts made by an administrator will result in a lockout of the administrator account for 30 minutes. 1.4.4.5 Security management The Security Management server allows both local and remote administration for management of the TOE’s security functions. The single Security Management Server administrator profile “read write all” is supported in the evaluated configuration. A Security Management Server administrator can log in locally to the TOE using a serial connection. The Security Management Server administrator is greeted with a console environment, where configuration is mainly done through command-line syntax. The local login operates in a Check Point shell (based on top of a Unix shell). Remote administration of the SGM security policies is available via the Security Management server using the Check Point REST API (as defined at https://sc1.checkpoint.com/documents/latest/APIs/#web). Again, the Security Management Server administrator has to authenticate to the Security Management server before being able to successfully initiate any management functionality. This management functionality includes configuration of network objects (hosts, NAT, etc), firewall policies, IPS policies, Security Management Server administrator accounts, auditing functionality. In the evaluated configuration the management workstation must be connected to the same dedicated management LAN as the Management Server. When in SP deployment, administration of the Orchestrator appliances is performed using the WebUI provided by the Orchestrator appliance1 . This WebUI provides functionality to manage the Security Groups, as well as the Orchestrator administrator accounts and auditing functionality. 1.4.4.6 TOE Access Remote Security Management Server administrator sessions with the Management Server (i.e. those established via the Check Point REST API) will be terminated after defined periods of inactivity or when termination is initiated by the administrator. Similarly, when in SP deployment, WebUI sessions with the Orchestrator appliance will be terminated after defined periods of inactivity or when termination is initiated by the Orchestrator administrator. 1 The Orchestrator appliances can also be managed using the Orchestrator CLI over SSH, but this is not supported in the evaluated configuration. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 29 This document may be freely reproduced and distributed whole and intact including this copyright notice. 1.4.4.7 Protection of the TSF Each TOE component (Security Gateway, Security Management Server and Orchestrator) provides a system clock that is synchronized with a time server (provided in the IT environment). The TSF data transmitted between TOE components (Gateways and Management Server, and when in SP deployment with Orchestrator appliances) will be protected using VLANs to separate management traffic from user data and encryption of the management traffic using SIC. The TSF data transmitted (on internal networks) between the Security Management Server administrator and Security Management Server (and when in SP deployment between the Orchestrator administrator and Orchestrator) will be protected from modification and disclosure using TLS v1.3. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 30 This document may be freely reproduced and distributed whole and intact including this copyright notice. 2 Conformance Claims This TOE is conformant to the following CC specifications: 2.1 Common Criteria Conformance Claims • Common Criteria for Information Technology Security Evaluation Part 2: Security functional components, Version 3.1, Revision 5, April 2017. o Part 2 Extended • Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components, Version 3.1 Revision 5, April 2017. o Part 3 Conformant 2.2 Protection Profile Conformance Claims This Security Target does not make any claims to conform to any published Protection Profile. 2.3 Packages Conformance Claims The TOE claims conformance to Evaluation Assurance Level 4 (EAL4) and augmented by AVA_VAN.4 –Methodical vulnerability analysis and ALC_FLR.1 – Basic Flaw remediation. 2.4 Conformance Rationale The Security Target makes no Protection Profile conformance claims and so there is no requirement for a conformance rationale. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 31 This document may be freely reproduced and distributed whole and intact including this copyright notice. 3 Security Problem Definition 3.1 Assets 3.1.1 Primary assets The TOE serves to protect information and services on a customer’s network from malicious attempts to control or gain access to those assets; these assets can therefore be considered the primary assets of the TOE. These assets specifically comprise IP addresses, ports for offered services, information about network topology, the actual access to services in a customer’s network and the integrity of the network stack of the machines. 3.1.2 Secondary assets The secondary assets of the TOE comprise all the configuration data that is needed for the secure operation of the Security Functions of the TOE. This specifically comprises: - Authentication data (passwords or cryptographic data) - Other configuration data of Security Functions (Audit information, firewall rules, etc) 3.2 Threats 3.2.1 T.NETWORK_DISCLOSURE An attacker may attempt to “map” a subnet to determine the machines that reside on the network, and obtaining the IP addresses of machines, as well as the services (ports) those machines are offering. This information could be used to mount attacks to those machines via the services that are exported. 3.2.2 T.NETWORK_ACCESS With knowledge of the services that are exported by machines on a subnet, an attacker may attempt to exploit those services by mounting attacks against those services. 3.2.3 T.MALICIOUS_TRAFFIC An attacker may attempt to send malformed packets or sequences of network packets to a machine in hopes of causing the network stack or services listening on UDP/TCP ports of the target machine to crash, to gain use of unauthorized services on the target machine or to gain unauthorized access to user data on the target machine. 3.2.4 T.UNAUTHORIZED_ADMIN_ACCESS An attacker may attempt to gain administrator access to the SGM by nefarious means such as masquerading as an administrator to the SGM. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 32 This document may be freely reproduced and distributed whole and intact including this copyright notice. 3.2.5 T.UNDETECTED_ACTIVITY An attacker may attempt to access, change, and/or modify the security functionality of the SGM without Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. 3.3 Organizational security policies There are no organizational security policies imposed on the TOE by this Security Target. 3.4 Assumptions This section of the security problem definition shows the assumptions that are made on the operational environment in order to be able to provide security functionality. If the TOE is placed in an operational environment that does not meet these assumptions, the TOE may not be able to provide all of its security functionality anymore. Assumptions can be on physical, personnel and connectivity of the operational environment. Each assumption must be associated with one or more security objective for the TOE operational environment, as indicated. 3.4.1 A.PHYSICAL_PROTECTION The hardware components on which the TOE executes are assumed to be physically protected in its operational environment (e.g. server room, data center) and not subject to physical attacks that compromise the security and/or interfere with the TOE’s physical interconnections and correct operation. This also applies to the Maestro components if deployed as Scalable Platform. This protection is assumed to be sufficient to protect the TOE and the data it contains from physical compromise. As a result, this Security Target does not include any requirements on physical tamper protection or other physical attack mitigations. The Security Target does not expect the TOE to defend against physical access that allows unauthorized entities to extract data, bypass other controls, or otherwise manipulate it. 3.4.2 A.LIMITED_FUNCTIONALITY The TOE components are assumed to only provide services to support networking, filtering and IPS functionality as its core function, either directly by applying the policies, or indirectly by providing management functionality for those features or traffic load-balancing. The TOE components do not provide functionality that could be deemed as general-purpose computing services. 3.4.3 A.TRUSTED_ADMINSTRATOR The authorized administrator(s) for the TOE are assumed to be trusted and to act in the best interest of security for the organization. This includes being appropriately trained, following policy and adhering to guidance documentation. Administrators are trusted to ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 33 This document may be freely reproduced and distributed whole and intact including this copyright notice. ensure passwords/credentials have sufficient strength and entropy and to lack malicious intent when administering the TOE. The TOE is not expected to be capable of defending against a malicious administrator that actively works to bypass or compromise the security of the TOE. 3.4.4 A.CONNECTIONS It is assumed that the TOE components are connected to distinct networks in a manner that ensures that the TOE traffic filtering security policies will be enforced on all applicable network traffic flowing among the attached networks. 3.4.5 A.LOCAL_NETWORK_PROTECTION Where the components of the TOE are connected to other trusted IT entities on a dedicated management local area network (such as connection to Log servers), the connections are assumed to be physically secure and hence provide confidentiality of the communication between the TOE components located on the protected management network. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 34 This document may be freely reproduced and distributed whole and intact including this copyright notice. 4 Security Objectives The security objectives are a concise and abstract statement of the intended solution to the problem defined by the security problem definition. There are two types of security objectives, those objectives met by the TOE itself and those that are met by the operational environment. 4.1 Security objectives for the TOE The following subsections describe objectives for the TOE. 4.1.1 O.ADDRESS_FILTERING To address the issues associated with unauthorized disclosure of information, inappropriate access to services, misuse of services, disruption or denial of services, and network-based reconnaissance, the TOE will implement Packet Filtering capability. That capability will restrict the flow of network traffic between protected networks and other attached networks based on network addresses of the network nodes originating (source) and/or receiving (destination) applicable network traffic as well as on established connection information. SFR Rationale: • FFW_RUL_EXT.1 specifies requirements to prevent unauthorized access to protected devices and services restricting the flow of network traffic between protected networks based on address filtering. 4.1.2 O.PORT_FILTERING To further address the issues associated with unauthorized disclosure of information, etc., the TOE’s port filtering capability will restrict the flow of network traffic between protected networks and other attached networks based on the originating (source) and/or receiving (destination) port (or service) identified in the network traffic as well as on established connection information. SFR Rationale: • FFW_RUL_EXT.1 specifies requirements to prevent unauthorized access to protected devices and services restricting the flow of network traffic between protected networks based on port filtering. • FPT_STM.1 specified requirements to provide system time that can be used to filter traffic based on connection time information. 4.1.3 O.INTRUSION_PREVENTION To further address the issues associated with attempts to exploit services running on machines that reside on a subnet protected by the TOE, the TOE will provide the means to identify and act upon malformed network traffic and network traffic matching predefined attack signatures and other known malicious sequences of activities. SFR Rationale: ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 35 This document may be freely reproduced and distributed whole and intact including this copyright notice. • FFW_RUL_EXT.1 specifies requirements to prevent unauthorized access to protected devices and services restricting the flow of network traffic between protected networks based on malformed packets. • IPS_ANL_EXT.1 and IPS_RCT_EXT.1 specify requirements to detect and prevent the onward transmission of network traffic matching predefined attack sequences. 4.1.4 O.TOE_ADMINISTRATION In order to configure the security features and administer the device, the TOE will provide the functions necessary for an administrator to securely manage the TOE. The TOE will protect management data communicated between TOE components, and between the administrator and the TOE components. SFR Rationale: • FMT_SMR.1, FMT_SMF.1 specifies requirements to maintain administrator roles and assign users to that role, and to provide the relevant administration functionality. • FTP_TRP.1, FPT_ITT.2 specifies protection of the TSF data between administrator and TOE components and between TOE components themselves. • FCS_CKM.1, FCS_CKM.2, FCS_COP.1 (all iterations), FCS_RNG.1 provide the cryptographic services to implement the protocols protecting the transmission of data between administrator and TOE components and between TOE components. Along with FCS_CKM.1, FCS_CKM.4 has been introduced as a dependency to ensure secure deletion of the key. 4.1.5 O.AUTHENTICATION The TOE will provide a means to identify and authenticate the user to ensure they are communicating with an authorized administrator. Any remote session established with a authenticated user will terminate after a predefined period of inactivity or when termination is initiated by the user. SFR Rationale: • FIA_UID.1, FIA_UAU.1 specify requirements to identify and authenticate administrators attempting to establish a session to the TOE, masking credentials entered. • FIA_AFL.1 specifies requirements to limit the number of failed authentication attempts to prevent brute force password attacks. • FTA_SSL.3, FTA_SSL.4 specify requirements to terminate administrator sessions after a defined period of inactivity or when termination is initiated by the administrator. • FCS_COP.1/Hash provides the cryptographic services for verification of administrator credentials 4.1.6 O.SYSTEM_MONITORING The TOE must provide a means to generate and store an audit trail of security-related events. SFR Rationale: • FAU_GEN.1, FAU_GEN.2 specify requirements for the generation of audit events to record the occurrence of specified security relevant events. • FAU_EAS_EXT.1 specifies requirements for the storage of the audit events on the TOE and on an external log server. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 36 This document may be freely reproduced and distributed whole and intact including this copyright notice. • FPT_STM.1 specifies requirements for a time stamp to be provided by the TOE to record the time an event occurred in the audit record. 4.2 Security Objectives for the Operational Environment The following subsections describe objectives for the Operational Environment. 4.2.1 OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by the environment to TOE components. Addresses: A.PHYSICAL_PROTECTION 4.2.2 OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the hardware components on which the TOE executes, other than those services necessary for the operation, administration and support of the TOE. Addresses: A.LIMITED_FUNCTIONALITY 4.2.3 OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner. Addresses: A.TRUSTED_ADMINSTRATOR 4.2.4 OE.CONNECTIONS TOE administrators will ensure that the TOE is installed in a manner that will allow the TOE to effectively enforce its policies on network traffic of monitored networks. Addresses: A.CONNECTIONS 4.2.5 OE.LOCAL_NETWORK Log servers (and also NTP and syslog log servers in the case of single gateway deployment) are connected to the same dedicated management LAN as the Management Server appliance. Addresses: A.LOCAL_NETWORK_PROTECTION 4.3 Security objectives rationale The security objectives for the operational environment are mapped in Section 4.2 above. The rationale for the security objectives for the operational environment is trivial as each objective is the restatement of the single assumption to which it is mapped and all assumptions are mapped to exactly one security objective for the operational environment. Therefore, no further rationale of those objectives is necessary. Hence, this security objectives rationale addresses the security objectives for the TOE. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 37 This document may be freely reproduced and distributed whole and intact including this copyright notice. The rationale for the TOE security objectives contains two sections: • a tracing that shows which TOE security objectives address which threats and OSPs; • a set of justifications that shows that all threats and OSPs are effectively addressed by the TOE security objectives. There are no OSPs for the TOE so these are not considered in the rationale for the TOE security objectives. 4.3.1 Security objectives rationale tracing The mapping in the following table that shows which TOE security objectives address which threats. T.NETWORK_DISCLOSURE T.NETWORK_ACCESS T.MALICIOUS_TRAFFIC T.UNAUTHORIZED_ADMIN_ACCESS T.UNDETECTED_ACTIVITY O.ADDRESS_FILTERING X X O.PORT_FILTERING X X O.INTRUSION_PREVENTION X X O.TOE_ADMINISTRATION X X O.AUTHENTICATION X O.SYSTEM_MONITORING X Table 6 Threats and assumptions tracing As can be seen from the table above, the tracing is complete. Each threat maps to at least one objective for the TOE; each assumption maps to at least on objective for the operational environment and there are no spurious objectives, that is there are no objectives that do not map to a threat or assumption. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 38 This document may be freely reproduced and distributed whole and intact including this copyright notice. 4.3.2 Justification for the effectiveness of the security problem solution This section demonstrates that each threat is effectively met by one security objective or a combination of objectives working together. Threat Rationale T.NETWORK_DISCLOSURE An attacker may attempt to “map” a subnet to determine the machines that reside on the network, and obtaining the IP addresses of machines, as well as the services (ports) those machines are offering. This information could be used to mount attacks to those machines via the services that are exported. By meeting the security objectives O.ADDRESS_FILTERING and O.PORT_FILTERING, the TOE is able to prevent the mapping of a protected subnet by effectively filtering ports and addresses. T.NETWORK_ACCESS With knowledge of the services that are exported by machines on a subnet, an attacker may attempt to exploit those services by mounting attacks against those services. By meeting the security objectives O.ADDRESS_FILTERING and O.PORT_FILTERING, the TOE is able to control access to services on the protected network effectively filtering ports and addresses and enforcing stateful filtering of traffic flow. Furthermore, by meeting the security objective O.INTRUSION_PREVENTION, the TOE identifies and responds to signatures and sequences identifying malicious network activity. T.MALICIOUS_TRAFFIC An attacker may attempt to send malformed packets or sequences of network packets to a machine in hopes of causing the network stack or services listening on UDP/TCP ports of the target machine to crash, to gain use of unauthorized services on the target machine or to gain unauthorized access to user data on the target machine. By meeting the security objective O.INTRUSION_PREVENTION, the TOE identifies and responds to malformed network traffic and network traffic matching signatures and sequences identifying malicious network activity, thereby preventing loss of availability, access to services or data on the target machine. T.UNAUTHORIZED_ADMIN_ACCESS An attacker may attempt to gain administrator access to the SGM by nefarious means such as masquerading as an administrator to the SGM. By meeting the security objectives O.TOE_ADMINISTRATION and O.AUTHENTICATION the TOE is able to ensure that any administrator access is from genuine, authorized administrators with knowledge of the administrator authentication credentials. T.UNDETECTED_ACTIVITY An attacker may attempt to access, change, and/or modify the security functionality of the SGM without By meeting the security objective O.TOE_ADMINISTRATION the TOE ensures that only authorized administrators ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 39 This document may be freely reproduced and distributed whole and intact including this copyright notice. Threat Rationale Administrator awareness. This could result in the attacker finding an avenue (e.g., misconfiguration, flaw in the product) to compromise the device and the Administrator would have no knowledge that the device has been compromised. can manage the TOE. In addition by meeting the security objective O.SYSTEM_MONITORING the TOE generates and stores an audit trail of security-related events which includes administrative access and use of security functions, which facilitates reviews of the audit data from the TOE to look for signs of any unauthorized activity. Table 7 TOE threat prevention rationale ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 40 This document may be freely reproduced and distributed whole and intact including this copyright notice. 5 Extended Components Definition 5.1 Security Audit (FAU) A new family is defined for the existing Security Audit class. 5.1.1 External Audit Event Storage (FAU_EAS_EXT) Family Behaviour This family defines extends the requirements for audit storage on the TOE (as specified in the [CC] FAU_STG.1 family) by requiring the audit evidence also to be transmitted to an external server for storage. Component Levelling Management: The following actions could be considered for the management functions in FMT: a) None. Audit The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) No audit necessary. 5.1.1.1 External Audit Event Storage (FAU_EAS_EXT.1) Hierarchical to: No other components. Dependencies: FAU_GEN.1 Audit data generation FAU_EAS_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity. FAU_EAS_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. FAU_EAS_EXT.1.3 The TSF shall [selection: drop new audit data, overwrite previous audit records according to the following rule: [assignment: rule for overwriting previous audit records], [assignment: other action]] when the local storage space for audit data is full. 5.2 Intrusion Prevention System (IPS) The Intrusion Prevention System class is modelled on the analysis and anomaly detection aspects of the [CC] FAU: Security Audit class. The IPS Analyser analysis (IPS_ANL_EXT) family is modelled on a combination of FAU_SAA.1 Potential violation analysis and the first component of FAU_SAA.2 Profile based anomaly detection. The IPS Analyser React (IPS_RCT_EXT) family is modelled on FAU_ARP.1 Security alarms. FAU_EAS_EXT.1 Protected Audit Event Storage 1 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 41 This document may be freely reproduced and distributed whole and intact including this copyright notice. 5.2.1 IPS Analyser analysis (IPS_ANL_EXT) Family Behaviour This family defines requirements for automated means that analyse network traffic received by the TOE looking for possible or real security violations. This analysis may work in support of automatic response to a potential security violation. Component Levelling Management: The following actions could be considered for the management functions in FMT: a) The ability to configure the analyser reactions (addition, removal, or modification) of actions. Audit The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: Enabling and disabling of any of the analysis mechanisms; 5.2.1.1 IPS Analyser analysis (IPS_ANL_EXT.1) Hierarchical to: No other components Dependencies: None. IPS_ANL_EXT.1.1 The TSF shall be able to apply a set of rules in analysing all network traffic received and based upon these rules indicate a potential violation of the enforcement of the SFRs. Application Note: The set of rules shall be applied by a pattern matching engine. IPS_ANL_EXT.1.2 The TSF shall be able to apply database of attack signatures represent the patterns of network intrusion attempts. Application Note: A database of signatures is used by the pattern matching engine to identify network intrusions. IPS_ANL_EXT.1.3 The TSF shall record within each analytical result at least the following information: a) Date and time of the result, type of result, identification of data source; and b) [assignment: additional information to be recorded]. 5.2.2 IPS Analyser React (IPS_RCT_EXT) Family Behaviour This family defines the response to be taken in case of detected intrusions. IPS_ANL_EXT: ISP Analyser Analysis 1 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 42 This document may be freely reproduced and distributed whole and intact including this copyright notice. Component Levelling Management: The following actions could be considered for the management functions in FMT: a) The ability to configure the analyser reactions (addition, removal, or modification) of actions. Audit The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) None. 5.2.2.1 IPS_RCT_EXT.1 IPS Analyser React Hierarchical to: No other components Dependencies: IPS_ANL_EXT.1. IPS_RCT_EXT.1.1 The TSF shall take [assignment: list of actions] when an intrusion is detected. 5.3 Firewall (FFW) The Firewall class is taken from collaborative Protection Profile for Stateful Traffic Filter Firewalls, Version 2.0+ Errata 20180314, 14 March 2018. This class defines the requirements for filtering of network traffic to be performed by a network device (such as a firewall). 5.3.1 Stateful Traffic Filtering (FFW_RUL_EXT) Family Behaviour This requirement is used to specify the behaviour of a Stateful Traffic Filter Firewall. The network protocols that the TOE can filter, as well as the attributes that can be used by an administrator to construct a rule set are identified in this component. How the rule set is processed (i.e., ordering) is specified, as well as any expected default behaviour on the part of the TOE. Component Levelling Management: The following actions could be considered for the management functions in FMT: a) enable/disable a rule set on a network interface b) configure a rule set c) specifying rules that govern the use of resources. IPS_RCT_EXT: ISP Analyser React 1 FFW_RUL_EXT: Stateful Traffic Filtering 1 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 43 This document may be freely reproduced and distributed whole and intact including this copyright notice. Audit The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST: a) Minimal: • Result (i.e., drop, allow) of applying a rule in the rule set to a network packet; • Configuration of the rule set; • Indication of packets dropped due to too much network traffic. 5.3.1.1 Stateful Traffic Filtering (FFW_RUL_EXT.1) Hierarchical to: No other components Dependencies: None. FFW_RUL_EXT.1.1 The TSF shall perform Stateful Traffic Filtering on network packets processed by the TOE. FFW_RUL_EXT.1.2 The TSF shall allow the definition of Stateful Traffic Filtering rules using the following network protocol fields: [assignment: list of attributes supported by the rule set]. FFW_RUL_EXT.1.3 The TSF shall allow the following operations to be associated with Stateful Traffic Filtering rules: permit, deny, and log. FFW_RUL_EXT.1.4 The TSF shall allow the Stateful Traffic Filtering rules to be assigned to each distinct network interface. FFW_RUL_EXT.1.5 The TSF shall: a) accept a network packet without further processing of Stateful Traffic Filtering rules if it matches an allowed established session for the following protocols: [assignment: list of supported protocols for which state is maintained] based on the following network packet attributes [assignment: list of attributes associated with each of the protocols].: b) Remove existing traffic flows from the set of established traffic flows based on the following: [selection: session inactivity timeout, completion of the expected information flow]. FFW_RUL_EXT.1.6 The TSF shall enforce the following default Stateful Traffic Filtering rules on all network traffic: [assignment: list of default rules that are applied to network traffic flow]. FFW_RUL_EXT.1.7 The TSF shall be capable of dropping and logging according to the following rules: [assignment: list of specific rules that the TOE is capable of enforcing]. FFW_RUL_EXT.1.8 The TSF shall process the applicable Stateful Traffic Filtering rules in an administratively defined order. FFW_RUL_EXT.1.9 The TSF shall deny packet flow if a matching rule is not identified. FFW_RUL_EXT.1.10 The TSF shall be capable of limiting an administratively defined number of half-open TCP connections. In the event that the configured limit is reached, new connection attempts shall be dropped and the drop event shall be [assignment: rules governing the use of resources]. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 44 This document may be freely reproduced and distributed whole and intact including this copyright notice. 5.4 FCS_RNG Generation of random numbers Application Note: The following extended component FCS_RNG.1 and associated refinements for DRG.2 are taken from [RNG_Classes] (section 3.1 and section 4.7), Family Behaviour This family defines quality requirements for the generation of random numbers that are intended to be used for cryptographic purposes. Component levelling: FCS_RNG.1 Generation of random numbers, requires that the random number generator implements defined security capabilities and that the random numbers meet a defined quality metric. Management: FCS_RNG.1 There are no management activities foreseen. Audit: FCS_RNG.1 There are no actions defined to be auditable. 5.4.1 FCS_RNG.1 Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic] random number generator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric]. 5.4.1.1 Refinement of DRG.2 Class FCS_RNG.1 Random number generation (Class DRG.2) FCS_RNG.1.1 The TSF shall provide a deterministic random number generator that implements: • (DRG.2.1) If initialized with a random seed [selection: using a PTRNG of class PTG.2 as random source, using a PTRNG of class PTG.3 as random source, using an NPTRNG of class NTG.1 [assignment: other requirements for seeding], the internal state of the RNG shall [selection: have [assignment: amount of entropy]]2 . • (DRG.2.2) The RNG provides forward secrecy. 2 Refinements provided for DRG.2 class shows the completion of open operations to reflect the conformance to NIST [SP800-90B] ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 45 This document may be freely reproduced and distributed whole and intact including this copyright notice. • (DRG.2.3) The RNG provides backward secrecy. FCS_RNG.1.2 The TSF shall provide random numbers that meet: • (DRG.2.4) The RNG, initialized with a random seed [assignment: requirements for seeding], generates output for which [assignment: number of strings] strings of bit length 128 are mutually different with probability [assignment: probability]. • (DRG.2.5) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A [assignment: additional test suites]. 5.5 Extended Components Rationale The extended classes defined above were included to reflect the modelling of firewall filtering and intrusion prevention functionality, which are not readily captured by the existing CC Part 2 components. In addition, the extended family for the Security Audit class (FAU) has been defined to readily capture the storage of audit records on the TOE and also on an external IT entity (as also used in some collaborative Protection Profiles). ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 46 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6 Security Requirements This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort. This security Target is for an EAL4 evaluation augmented by AVA_VAN.4 – Advanced methodical vulnerability analysis and ALC_FLR.1 – Basic Flaw remediation and by reference this document contains all of the SARs that are relevant to the EAL4 package. 6.1 TOE Security Functional Requirements Requirement Class Requirement Component FAU: Security audit FAU_GEN.1 Audit Data Generation FAU_GEN.2 User Identity Association FAU_EAS_EXT.1 External Audit Event Storage FFW: Stateful Traffic Filtering Firewall FFW_RUL_EXT.1 Stateful Traffic Filtering IPS: Intrusion Prevention System IPS_ANL_EXT.1 IPS Analyser analysis IPS_RCT_EXT.1 Analyser React FIA: Identification and authentication FIA_UID.1 Timing of Identification FIA_UAU.1 Timing of authentication FIA_AFL.1 Authentication Failure Management FMT: Security management FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security Roles FTA: TOE access FTA_SSL.3 TSF-initiated Termination FTA_SSL.4 User-initiated Termination FPT: Protection of the TSF FPT_STM.1 Reliable time stamps FPT_ITT.2 TSF data transfer separation FTP: Trusted Path/Channels FTP_TRP.1 Trusted path FCS: Cryptographic Support FCS_CKM.1 Cryptographic key generation FCS_CKM.2 Cryptographic key distribution FCS_CKM.4 Cryptographic key destruction FCS_COP.1/AES Cryptographic operation FCS_COP.1/CHACHA20 FCS_COP.1/DSA FCS_COP.1/Hash FCS_COP.1/KeyedHash FCS_COP.1/MAC FCS_RNG.1 Random Number Generation Table 8 TOE Security Functional Requirements ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 47 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1.1 Security audit (FAU) 6.1.1.1 FAU_GEN.1 Audit data generation FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and shut-down of the audit functions; b) All auditable events for the [not specified] level of audit; and c) [All administrative actions comprising: • Administrative login and logout (name of user account shall be logged if individual user accounts are required for Security Management Server and Orchestrator administrators). • Changes to TSF data related to traffic filtering policy and Security Group configuration changes (in addition to the information that a change occurred it shall be logged what has been changed). • Resetting passwords (name of related user account shall be logged). • no other actions; d) Specifically defined auditable events listed in Table 9.] FAU_GEN.1.2 The TSF shall record within each audit record at least the following information: a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and b) For each audit event type, based on the auditable event definitions of the functional components included in the PP/ST, [information specified in column three of Table 9]. Requirement Auditable Events Additional Audit Record Contents TOE component generating audit record FAU_GEN.1 Start-up and shut- down of the audit functions None. SGM Management Server (Orchestrator when in SP deployment) FAU_GEN.2 None. None. n/a FAU_EAS_EXT.1 None. None. n/a FFW_RUL_EXT.1 Result: Application of rules configured with the ‘log’ operation Source and destination addresses Source and destination ports TOE Interface SGM IPS_ANL_EXT.1 Enabling and disabling of IPS blade None. Management Server IPS_RCT_EXT.1 None None. n/a ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 48 This document may be freely reproduced and distributed whole and intact including this copyright notice. Requirement Auditable Events Additional Audit Record Contents TOE component generating audit record FIA_UID.1 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). Management Server (Orchestrator when in SP deployment) FIA_UAU.1 All use of identification and authentication mechanism. Origin of the attempt (e.g., IP address). Management Server (Orchestrator when in SP deployment) FIA_AFL.1 Unsuccessful login attempt limit is met or exceeded. Origin of the attempt (e.g., IP address). Management Server (Orchestrator when in SP deployment) FMT_SMF.1 Administrator action performed. None. Management Server (Orchestrator when in SP deployment) FMT_SMR.1 None. None. n/a FTA_SSL.3 The termination of a remote session by the session locking mechanism. None. Management Server (Orchestrator when in SP deployment) FTA_SSL.4 The termination of an interactive session. None. Management Server (Orchestrator when in SP deployment) FPT_STM.1 None None n/a FPT_ITT.2 None None n/a Table 9 Security Functional Requirements and Auditable Events 6.1.1.2 FAU_GEN.2 User identity association FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event. 6.1.1.3 FAU_EAS_EXT.1 External Audit Event Storage FAU_EAS_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity. FAU_EAS_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself. FAU_EAS_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [audit is stored in a circular buffer and oldest records are overwritten first]] when the local storage space for audit data is full. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 49 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1.2 Stateful Traffic Filtering Firewall (FFW) 6.1.2.1 FFW_RUL_EXT.1 Stateful Traffic Filtering FFW_RUL_EXT.1.1 The TSF shall perform Stateful Traffic Filtering on network packets processed by the TOE. FFW_RUL_EXT.1.2 The TSF shall allow the definition of Stateful Traffic Filtering rules using the following network protocol fields: • [ICMPv4 o Type o Code • Ipv4 o Source address o Destination Address o Transport Layer Protocol • TCP o Source Port o Destination Port • UDP o Source Port o Destination Port] and distinct interface. FFW_RUL_EXT.1.3 The TSF shall allow the following operations to be associated with Stateful Traffic Filtering rules: permit, deny, and log. FFW_RUL_EXT.1.4 The TSF shall allow the Stateful Traffic Filtering rules to be assigned to each distinct network interface. FFW_RUL_EXT.1.5 The TSF shall: a) accept a network packet without further processing of Stateful Traffic Filtering rules if it matches an allowed established session for the following protocols: [TCP, UDP] based on the following network packet attributes: 1. [TCP: source and destination addresses, source and destination ports, sequence number, Flags; 2. UDP: source and destination addresses, source and destination ports]. b) Remove existing traffic flows from the set of established traffic flows based on the following: [session inactivity timeout]. FFW_RUL_EXT.1.6 The TSF shall enforce the following default Stateful Traffic Filtering rules on all network traffic: a) [The TSF shall drop and be capable of logging packets which are invalid fragments; b) The TSF shall drop and be capable of logging fragmented packets which cannot be re-assembled completely; c) The TSF shall drop and be capable of logging packets where the source address of the network packet is defined as being on a broadcast network; d) The TSF shall drop and be capable of logging packets where the source address of the network packet is defined as being on a multicast network; The TSF shall drop and be capable of logging ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 50 This document may be freely reproduced and distributed whole and intact including this copyright notice. network packets where the source address of the network packet is defined as being a loopback address; e) The TSF shall drop and be capable of logging network packets where the source or destination address of the network packet is defined as being unspecified (i.e. 0.0.0.0) or an address “reserved for future use” (i.e. 240.0.0.0/4) as specified in RFC 5735 for Ipv4; f) The TSF shall drop and be capable of logging network packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified]. FFW_RUL_EXT.1.7 The TSF shall be capable of dropping and logging according to the following rules: a) [The TSF shall drop and be capable of logging network packets where the source address of the network packet is equal to the address of the network interface where the network packet was received; b) The TSF shall drop and be capable of logging network packets where the source or destination address of the network packet is a link-local address; c) The TSF shall drop and be capable of logging network packets where the source address of the network packet does not belong to the networks associated with the network interface where the network packet was received]. FFW_RUL_EXT.1.8 The TSF shall process the applicable Stateful Traffic Filtering rules in an administratively defined order. FFW_RUL_EXT.1.9 The TSF shall deny packet flow if a matching rule is not identified. FFW_RUL_EXT.1.10 The TSF shall be capable of limiting an administratively defined number of half-open TCP connections. In the event that the configured limit is reached, new connection attempts shall be dropped and the drop event shall be [counted]. 6.1.3 Intrusion Prevention System (IPS) 6.1.3.1 IPS_ANL_EXT.1 IPS Analyser analysis IPS_ANL_EXT.1.1 The TSF shall be able to apply a set of rules in analysing all network traffic received and based upon these rules indicate a potential violation of the enforcement of the SFRs. IPS_ANL_EXT.1.2 The TSF shall be able to apply database of attack signatures represent the patterns of network intrusion attempts. Application Note: The TSF shall be able to maintain an internal representation of attack signature events and event sequences of known intrusion scenarios, encoded as IPS protections enabled by an Security Management Server administrator, and to compare the signature events and event sequences against the record of system activity discernible from an examination of the network traffic mediated by the TOE; IPS_ANL_EXT.1.3 The TSF shall record within each analytical result at least the following information: a) Date and time of the result, type of result, identification of data source; and b) [none]. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 51 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1.3.2 IPS_RCT_EXT.1 Analyser React IPS_RCT_EXT.1.1 The TSF shall take [actions as configured by a Security Management Server administrator which can be one of: a) Log the suspected traffic and allow it to pass; b) Silently drop the suspected traffic; c) Log and drop the suspected traffic; d) Reject the suspected traffic; e) Log and reject the suspected traffic] when an intrusion is detected. 6.1.4 Identification and authentication (FIA) 6.1.4.1 FIA_UID.1 Timing of Identification FIA_UID.1.1 The TSF shall allow [None] on behalf of the user to be performed before the user is identified. FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 6.1.4.2 FIA_UAU.1 Timing of Authentication FIA_UAU.1.1 The TSF shall allow [identification as stated in FIA_UID.1] on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 6.1.4.3 FIA_AFL.1 Authentication Failure Management FIA_AFL.1.1 The TSF shall detect when [3] unsuccessful authentication attempts occur related to [Administrators attempting to authenticate remotely]. FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [prevent the offending remote Administrator from successfully authenticating until 30 minutes have elapsed]. Application Note: This requirement applies to both Security Management Server administrator and Orchestrator administrator roles. 6.1.5 Security Management (FMT) 6.1.5.1 FMT_SMR.1 Security Roles FMT_SMR.1.1 The TSF shall maintain the roles [Security Management Server Administrator, and (when in SP deployment) Orchestrator Administrator]. FMT_SMR.1.2 The TSF shall be able to associate users with roles. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 52 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1.5.2 FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [On Security Management Server: • Ability to create, delete, modify Security Management Server administrator accounts; • Ability to configure the Management API session inactivity time before session termination; • Ability to manually update (import) Threat Protection signatures • Ability to configure firewall rules, including: o enable/disable a rule set on a network interface o configure a rule set o specifying rules that govern the use of resources • Ability to configure IPS rules, including: o configure the analyser reactions configure actions to be taken when signature matches are detected; o management (addition, removal, or modification) of actions • Ability to configure trusted path between Security Management Server administrator and Security Management Server (TLS between Security Management Server and Administrator PC); • Ability to configure secure channels between TOE components (SIC protection between Security Management Server and SGMs, and between SGMs); and (when in SP deployment) on Orchestrator appliances: • Ability configure objects and Security Groups; • Ability to create, delete, modify Orchestrator administrator accounts; • Ability to configure Orchestrator administrator session inactivity time before session termination; • Ability to configure trusted path between Orchestrator administrator and Orchestrator (TLS between Orchestrator and MHO Administrator PC)]. Application Note: The trusted channels between TOE components and the following trusted paths between administrators and TOE components can only be configured during the initial installation of the TOE: • Security Management Server Administrator and the Security Management Server, • Orchestrator Administrator and Orchestrator appliance. 6.1.6 TOE access (FTA) 6.1.6.1 FTA_SSL.3 TSF-initiated Termination FTA_SSL.3.1 The TSF shall terminate a remote interactive session after a [Security Management Server Administrator-configurable time interval of session inactivity, and (when in SP deployment) Orchestrator administrator-configuration time interval]. 6.1.6.2 FTA_SSL.4 User-initiated Termination FTA_SSL.4.1 The TSF shall allow Administrator-initiated termination of the Administrator’s own interactive session. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 53 This document may be freely reproduced and distributed whole and intact including this copyright notice. Application Note: This requirement applies to both Security Management Server administrator and Orchestrator administrator roles. 6.1.7 Protection of the TSF (FPT) and Trusted Path/Channels (FTP) 6.1.7.1 FPT_STM.1 Reliable time stamps FPT_STM.1.1 The TSF shall be able to provide reliable time stamps. 6.1.7.2 FPT_ITT.2 TSF data transfer separation FPT_ITT.2.1 The TSF shall protect TSF data from [disclosure, modification] when it is transmitted between separate parts of the TOE. FPT_ITT.2.2 The TSF shall separate user data from TSF data when such data is transmitted between separate parts of the TOE. 6.1.7.3 FTP_TRP.1 Trusted path FTP_TRP.1.1 The TSF shall provide a communication path between itself and [remote] users that is logically distinct from other communication paths and provides assured identification of its end points and protection of the communicated data from [modification, disclosure]. FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the trusted path. FTP_TRP.1.3 The TSF shall require the use of the trusted path for [initial user authentication, [transfer of TSF management data]]. 6.1.8 Cryptographic Support (FCS) 6.1.8.1 FCS_CKM.1 Cryptographic key generation FCS_CKM.1.1 The TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [RSA schemes] and specified cryptographic key sizes [2048 and 3072 bits] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3]. 6.1.8.2 FCS_CKM.2 Cryptographic key distribution FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [RSAES-PKCS1-v1_5] that meets the following: [RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1”]. 6.1.8.3 FCS_CKM.4 Cryptographic key destruction FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [for volatile memory, the destruction shall be ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 54 This document may be freely reproduced and distributed whole and intact including this copyright notice. executed by a single direct overwrite consisting of zeros. For non-volatile memory secret cryptographic keys are encrypted using a key encryption key (KEK) before storing them and this KEK is deleted if the secret key is no longer needed] that meets the following: [none]. 6.1.8.4 FCS_COP.1/AES Cryptographic operation FCS_COP.1.1 The TSF shall perform [encryption/decryption] in accordance with a specified cryptographic algorithm [AES in GCM mode, ] and cryptographic key sizes [128, 256 bits] that meet the following: [AES as specified in ISO 18033-3/FIPS 197, GCM mode as specified in ISO 19772/SP800-38D]. 6.1.8.5 FCS_COP.1/CHACHA20 Cryptographic operation FCS_COP.1.1 The TSF shall perform [encryption/decryption] in accordance with a specified cryptographic algorithm [CHACHA20] and cryptographic key sizes [256 bits] that meet the following: [RFC7905]. 6.1.8.6 FCS_COP.1/DSA Cryptographic operation FCS_COP.1.1 The TSF shall perform [cryptographic signature services (generation and verification)] in accordance with a specified cryptographic algorithm [RSA Digital Signature Algorithm] and cryptographic key sizes [(modulus) 2048 or 3072-bits for generation, 2048 bits for verification] that meet the following: [FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS]. 6.1.8.7 FCS_COP.1/Hash Cryptographic operation FCS_COP.1.1 The TSF shall perform [cryptographic hashing services] in accordance with a specified cryptographic algorithm [Secure Hashing Algorithm] and cryptographic key sizes [SHA-256, SHA-384, SHA-512 with message digest size 256, 384, 512 bits] that meet the following: [FIPS 180-4]. 6.1.8.8 FCS_COP.1/KeyedHash Cryptographic operation FCS_COP.1.1 The TSF shall perform [keyed-hash message authentication] in accordance with a specified cryptographic algorithm [Hash-based Message Authentication Code HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512] and cryptographic key sizes [256, 384, 512 bits with message digest sizes 256, 384, 512 bits] that meet the following: [FIPS 198-1]. 6.1.8.9 FCS_COP.1/MAC Cryptographic operation FCS_COP.1.1 The TSF shall perform [Message Authentication Code] in accordance with a specified cryptographic algorithm [Poly1305] and cryptographic key sizes [256 bits] that meet the following: [RFC 8439]. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 55 This document may be freely reproduced and distributed whole and intact including this copyright notice. 6.1.8.10 FCS_RNG.1 Random Number Generation Application Note: The following uses the refined FCS_RNG.1 extended component, for DRG.2 class, as defined in [RNG_Classes]. Refinements provided for DRG.2 class in section 5.4.1.1 above are not marked in the following, which only shows the completion of open operations to reflect the conformance to NIST [SP800-90A]. FCS_RNG.1.1/DRG2 The TSF shall provide a deterministic random number generator that implements: • (DRG.2.1) If initialized with a random seed [using a NPTRNG of NTG.1 class software-based noise source] the internal state of the RNG shall [have more than 128 bits of min-entropy]. • (DRG.2.2) The RNG provides forward secrecy. • (DRG.2.3) The RNG provides backward secrecy. FCS_RNG.1.2/ DRG2 The TSF shall provide random numbers that meet: • (DRG.2.4) The RNG, initialized with a random seed [that is equal in size as the generated random number, every time a random is obtained], generates output for which [226 ] strings of bit length 128 are mutually different with probability [[1- 2-12 ]. • (DRG.2.5) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. The random numbers must pass test procedure A [no additional test suites]. Application Note: The TOE uses the dedicated class of OpenSSL, called RAND_DRBG to implement deterministic random number generator. This DRNG is seeded from the NPTRNG of the underlying linux system. The seed has a length of 256 bit. Even under consideration of the fact that the NPTRNG does not provide pure entropy, the seed is assumed to have sufficient entropy to meet the requirement of 128 bit of entropy in DRG.2.1. 6.2 TOE Security Assurance Requirements The SARs for the TOE are the EAL 4 components as specified in Part 3 of the Common Criteria. The EAL4 assurance components have been augmented with AVA_VAN.4 and the addition of ALC_FLR.1. Assurance class Assurance components Class ADV: Development ADV_FSP.4 Complete functional specification ADV_ARC.1 Security architecture description ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Basic modular design Class AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures Class ALC: Life Cycle Support ALC_CMS.4 Problem tracking CM coverage ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 56 This document may be freely reproduced and distributed whole and intact including this copyright notice. Assurance class Assurance components ALC_FLR.1 Basic flaw remediation ALC_CMC.4 Production support, acceptance procedures and automation ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well-defined development tools Class ASE: Security Target Evaluation ASE_CCL.1 Conformance claims ASE_ECD.1 Extended components definition ASE_INT.1 ST introduction ASE_OBJ.2 Security objectives ASE_REQ.2 Derived security requirements ASE_SPD.1 Security problem definition ASE_TSS.1 TOE summary specification Class ATE: Tests ATE_COV.2 Analysis of coverage ATE_DPT.1 Testing: basic design ATE_FUN.1 Functional testing ATE_IND.2 Independent testing – sample Class AVA: Vulnerability Assessment AVA_VAN.4 Methodical vulnerability analysis Table 10 EAL 4 Assurance Components 6.2.1 Rationale for TOE Assurance Requirements Selection The TOE stresses assurance through vendor actions that are within the bounds of current best commercial practice. The TOE provides, via review of vendor-supplied evidence, independent confirmation that these actions have been competently performed. The general level of assurance for the TOE is: 1. Consistent with current best commercial practice for IT development and provides a product that is competitive against non-evaluated products with respect to functionality, performance, cost and time-to-market. 2. The TOE assurance also meets current constraints on widespread acceptance, by expressing its claims against EAL4 from part 3 of the Common Criteria. 3. Consistent with current best practice for tracking and fixing flaws as well as providing fixes to customers. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 57 This document may be freely reproduced and distributed whole and intact including this copyright notice. The augmentation of ALC_FLR.1 was chosen to give greater assurance of the developer’s on-going flaw remediation processes and the augmentation of AVA_VAN.4 was chose to reflect the critical role the TOE plays in defending an organization’s network against external attackers. 6.3 Security Requirements Rationale This section provides rationale for the Security Functional Requirements demonstrating that the SFRs are suitable to address the security objectives. 6.3.1 Security Functional Requirements for the TOE A mapping and rationale of the SFRs meeting each security objective for the TOE is provided in Section 4.1 above. 6.3.2 Security Functional Requirements Dependency Rationale The following table shows that all SFR dependencies are met by the TSF. Requirement Component Dependency Notes FAU_GEN.1 FPT_STM.1 FAU_GEN.2 FAU_GEN.1, FIA_UID.1 FAU_EAS_EXT.1 FAU_GEN.1 FFW_RUL_EXT.1 None IPS_ANL_EXT.1 None IPS_RCT_EXT.1 IPS_ANL_EXT.1 FIA_UID.1 None FIA_UAU.1 FIA_UID.1 FIA_AFL.1 FIA_UAU.1 FMT_SMR.1 FIA_UID.1 FMT_SMF.1 None FTA_SSL.3: None FTA_SSL.4: None FPT_STM.1 None FPT_ITT.2 None FTP_TRP.1 None FCS_CKM.1 [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] Met by FCS_CKM.2 & FCS_COP.1 ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 58 This document may be freely reproduced and distributed whole and intact including this copyright notice. Requirement Component Dependency Notes FCS_CKM.2 [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Met by FCS_CKM.1 FCS_CKM.4 [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Met by FCS_CKM.1 FCS_COP.1 [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] Met by FCS_CKM.1 FCS_RNG.1 None Table 11 SFR Dependencies ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 59 This document may be freely reproduced and distributed whole and intact including this copyright notice. 7 TOE Summary Specification This chapter describes the security functions provided by the TOE: • Security audit • Packet filtering and stateful traffic filtering firewall • Intrusion Prevention Systems • Identification and authentication • Security management • TOE access • Protection of the TSF 7.1 Security audit The SGM and Management Server generate audit logs of security events (see Table 9). GaiA generates OS-related security events on both the SGM and the Management Server. The SGM kernel is responsible for generating the traffic logs and a Security Management process is responsible for generating security management audit logs (these are the logs relating to all Security Management Server administrator activities on the Management Server). The SGM sends its traffic logs to the Management Server and sends its OS (GaiA) logs to the external syslog log server. In the event of failure, e.g. loss of power on the SGM, queued audit records that have not been successfully transmitted to the log server may be lost. The maximum number of records that may be lost is equal to the queue size: 4096 records. The Management Server sends to the external syslog log server the security management audit logs, its own OS (GAiA) logs and the traffic logs received from the SGM. The Management Server has a disk cleanup procedure where it removes old audit logs to allow space for new ones. This is configurable by the Security Management Server administrator. The Management Server also has the ability to prevent new connections if the Management Server runs out of space for new audit logs. When disk space on the Management Server falls below a predefined threshold, the server stops collecting audit records. As explained above, SGMs will queue the records, and eventually start logging them to the local disk, until connectivity is resumed. When in SP deployment, Orchestrator generates audit logs of security events (see Table 9). GAiA generates OS-related security events on Orchestrator, while the Orchestrator kernel is responsible for generating security management audit logs (these are the logs relating to the Orchestrator administrator activities on Orchestrator). Orchestrator sends to the external syslog log server the security management audit logs and the OS (GAiA) logs. Orchestrator has a disk cleanup procedure where it removes old audit logs to allow space for new ones. This is configurable by the Orchestrator ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 60 This document may be freely reproduced and distributed whole and intact including this copyright notice. administrator. Orchestrator also has the ability to prevent new connections if the Orchestrator runs out of space for new audit logs. When disk space on Orchestrator falls below a predefined threshold, Orchestrator stops collecting audit records. It should be noted that events indicating the start-up and shutdown of auditing are generated by GAiA for both the SGM and the Management Server, and when in SP deployment also for Orchestrator. The Security audit function is designed to satisfy the following security functional requirements: • FAU_GEN.1: The TOE is able to generate logs for the required range of events. Each event log is unique with the date/time of the event, type of event, subject identity (e.g. IP address), and the outcome of the event • FAU_GEN.2: The TOE is able to identify each auditable event with specific IP addresses and the TOE’s interfaces and SGMs • FAU_EAS_EXT.1: The TOE is able to send audit log data to an external log server. 7.2 Packet Filtering and Stateful Traffic Filtering Firewall If the TOE is configured as a Scalable Platform the Orchestrator appliance(s) will distribute the traffic to the appropriate SGM according to the distribution algorithm on the Orchestrator appliance. (This all happens within the TOE environment, before the traffic is forwarded to the TOE. No traffic inspection is performed by the Orchestrator appliance.) Every IPv4 packet received by the Check Point Security SGM is intercepted by the firewall kernel. Fragmented packets are first reassembled. IPv4 packets with unauthorized IP options (e.g. source route option) are dropped. When an IP packet is received on a network interface, its source address is compared to topology information configured by the Security Management Server administrator. If the source address does not correspond to the set of network addresses that match the given network interface, the packet is dropped as a spoofed packet. Note that broadcast and loopback addresses are never considered valid source addresses and are therefore rejected. The packet header attributes are used to match the packet against state tables that contain accepted ‘connections’. For all other packets, inspection is performed against the firewall rules. The rules have 4 possible outcomes: 1. Accept - the packet is allowed through; 2. Drop – the packet is dropped without notification to the sender; 3. Reject – the packet is dropped and the presumed sender is notified. 4. If no rule is matched, packets are dropped. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 61 This document may be freely reproduced and distributed whole and intact including this copyright notice. Firewall rules can be set to filter on protocol, source address, destination address, source port, destination port, ICMP type or ICMP code. All protocols including ICMPv4, IPv4, TCP, and UDP may be used in firewall rules. If any interface is overwhelmed with traffic, it will drop the packets and will increase the counter of any half open connections. The firewall will drop all of the following types of packet: 1. Packets which are invalid fragments, including a description of what constitutes an invalid fragment 2. Fragments that cannot be completely re-assembled 3. Packets where the source address is equal to the address of the network interface where the network packet was received 4. Packets where the source address does not belong to the networks associated with the network interface where the network packet was received, including a description of how the TOE determines whether a source address belongs to a network associated with a given network interface 5. Packets where the source address is defined as being on a broadcast network 6. Packets where the source address is defined as being on a multicast network 7. Packets where the source address is defined as being a loopback address 8. Packets where the source address is defined as being a reserved address as specified in RFC 1918 for IPv4 9. Packets where the source or destination address of the network packet is a link-local address 10. Packets where the source or destination address of the network packet is defined as being an address 'reserved for future use' as specified in RFC 5735 for IPv4 11. Packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified During the Check Point SGM boot process, there is a lag between the time when the network interface is operational, and the time that the Stateful Traffic Filtering functionality is fully functioning. During this time, Boot Security is enforced: • Traffic flow through the SGM is disabled; and • Traffic to and from the SGM is controlled by a Default Filter that drops all external traffic to the SGM The Stateful Traffic Filtering Firewall function is designed to satisfy the following security functional requirements: • FFW_RUL_EXT.1: The TOE supports all of the required protocols, which include ICMPv4 (RFC 792), IPv4 (RFC 791), TCP (RFC 793), and UDP (RFC 768). Conformance with the RFCs defining these protocols is asserted by the Check Point based upon the Check Point’s implementation and design The firewall rules implement the SPD rules (permit, deny, bypass). ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 62 This document may be freely reproduced and distributed whole and intact including this copyright notice. 7.3 Intrusion Prevention Systems Network traffic that passes through the firewall and IPS security policies is compared with signatures encoded as regular expressions, keywords, and INSPECT language code. The signatures database can be manually updated by the Security Management Server administrator. INSPECT is a Check Point script language that specifies packet handling by evaluating packet content and state. INSPECT scripts are compiled by a Security Management Server into low-level inspection code that is executed on SGMs using a stack-based virtual machine. An INSPECT script applies a conditioned sequence of pattern matching operations on packets flowing through the SGM. An INSPECT operator can be used to enforce an information flow control decision to permit or deny the flow and generate log records. The operator can read and modify state information encoded in transient registers and in persistent state tables. INSPECT operators can be configured to modify state tables in the incoming packets. Pattern matching on incoming packets is a function of state table information. So signature protections can be configured to detect both simple single-packet and complex multi-packet events that may indicate an attempt to violate the Security Requirements (SFRs). Compound Signature Identification (CSI) supports matching sequences of events. Encoded signature protections can be set to log the detected potential violation. Check Point SGM record within each analytical result (manifested as a match against an IPS protection) the following information required by IPS_ANL_EXT.1: • The date and time of the result. • The type of result. • Identification of the data source (IP address, port and protocol). Incoming network traffic is matched against a combined set of protocol enforcement and pattern matching logic that identifies suspicious traffic and assigns security attributes: • Confidence Level (that the traffic contains an attack) • Severity (the potential impact of the attack on protected resources) Based on these attributes and on Security Management Server administrator-specified security policy settings, the IPS engine may take action by generating applicable log records (Detect) and optionally blocking the traffic (Prevent). IPS engine logic consists of the following layers: • Passive Streaming Library (PSL) – an in-kernel TCP stack that assembles IP packets into information streams for protocol parsers. • Protocol Parsers – implement protocol-specific state machines that enforce protocol compliance and detect protocol anomalies that may be indicative of an intrusion attempt. The protocol parsers extract protocol ‘contexts’ from the information streams. A context is a well-defined part of the protocol on which further security analysis can be performed, e.g. a HTTP URL, HTTP headers, an HTTP response, etc. The HyperSPECT feature provides performance optimization for the processing of rules involving the body of HTTP packets. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 63 This document may be freely reproduced and distributed whole and intact including this copyright notice. • Context Management Interface – coordinates application of protections defined in the security policy on contexts established by protocol parsers. The contexts created by the parsers are sent to the relevant applications for inspection. • Pattern Matcher – a two-tier pattern matching engine that matches information streams against IPS protection signatures. The first tier applies simple matching criteria that separate clearly harmless traffic from the rest. Traffic not matched by the first tier is inspected by the second tier, which performs deeper inspection through the use of regular expression signatures or execution of INSPECTv2 signature matching programs for identifying suspicious activity. • Compound Signature Identification (CSI) – matches complex signatures that are triggered when a defined logical condition over multiple contexts is matched. The logical expression can use AND, OR, NOT and ORDERED-AND to construct its logic. An example of CSI use is a CAPICOM protection which looks for one of three signatures. IPS signatures updates may be imported manually into the TOE by a Security Management Server administrator. Updates are installed as regular expressions, keywords, and INSPECTv2 code fragments. The figure depicts an example IPS signature match for the FTP protocol. The left side of the figure depicts the IPS engine logic layers described above. The right side shows the incoming IP packets (on the bottom right of the figure) and the processing performed by the different logic layers, depicted from the bottom of the figure upwards. In the example, the attacker attempts to access an unauthorized file (‘bad.txt’) using a FTP ‘get’ command. The attacker attempts to obfuscate the attack by fragmenting the command over three IP packets, reordering them so that the ‘get’ command must be reconstructed from the first and third packets. The PSL layer (bottom left) converts the IP packets received by the SGM into protocol streams that are examined by the FTP protocol analyzer, extracting two contexts: command and file name. The Pattern Matcher matches a protection signature and signals a signature match to allow the SGM to take appropriate action (Allow, Drop, or Reject) and possibly capture packets for future investigation. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 64 This document may be freely reproduced and distributed whole and intact including this copyright notice. Encoded signature protections can be set to log the detected potential violation. The TOE records within each analytical result (manifested as a match against an IPS protection) the following information required: date and time of the result, type of result, and identification of the data source (IP address, port and protocol). The Intrusion Prevention Systems function is designed to satisfy the following security functional requirements: • IPS_ANL_EXT.1: The TOE supports signature-based detection and generates a record of detected anomalies. • IPS_RCT_EXT.1: The TOE can be configured to perform logging and or blocking (drop or reject) actions if an intrusion is detected. 7.4 Identification and authentication The TOE provides a password mechanism for authenticating users to the Management Server. Users are associated with a username, password, and one or more roles. Users may authenticate to the Management Server locally or via the web interface. Passwords can be composed of any alphabetic, numeric, and a wide range of special characters. Internally the TOE keeps track of failed login attempts. If a Security Management Server administrator fails 3 consecutive attempts, the administrator is locked out for 30 minutes. The TOE requires identification and authentication before allowing access to the Management Server. Only the banner may be presented before authentication is complete. When in SP deployment, the TOE provides a password mechanism for authenticating users to Orchestrator via the WebUI. Users are associated with a username and password. Passwords can be composed of any alphabetic, numeric, and a wide range of special characters. Internally the TOE keeps track of failed login attempts. If an Orchestrator administrator fails 3 consecutive attempts, the administrator is locked out for 30 minutes. The Identification and authentication function is designed to satisfy the following security functional requirements: • FIA_UID.1: The TOE’s identification and authentication mechanism employs a locally stored database of identification data. • FIA_UAU.1: The TOE’s identification and authentication mechanism employs a locally stored database of authentication data. • FCS_COP.1/Hash provides the cryptographic services for verification of the stored Security Management Server administrator and Orchestrator administrator credentials • FIA_AFL.1: The TOE supports the capability to lock an account for 30 minutes. 7.5 Security management User accounts on the Management Server are associated with the profile “read write all”. User accounts associated with this profile are called Security Management Server administrators. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 65 This document may be freely reproduced and distributed whole and intact including this copyright notice. Once authenticated, Security Management Server administrators have access to the following security functions on the Management Server: • Ability to create, delete, modify Security Management Server administrator accounts; • Ability to configure the Management API session inactivity time before session termination; • Ability to manually update (import) Threat Protection signatures; • Ability to configure firewall rules, including: o enable/disable a rule set on a network interface o configure a rule set o specifying rules that govern the use of resources • Ability to configure IPS rules, including: o configure the analyser reactions configure actions to be taken when signature matches are detected; o management (addition, removal, or modification) of actions • Ability to configure trusted path between Security Management Server administrator and Security Management Server (TLS between Security Management Server and Administrator PC)3 ; • Ability to configure secure channels between TOE components (SIC protection between Security Management Server and SGMs, and between SGMs)4 . The TOE offers two administrative interfaces to the Management Server: • CLI: The command line interface is a text based interface that is accessible via a directly connected console. These command line functions can be used to effectively perform most administrative activities, but it is most typically used during initial installation of the TOE. • Management API: The Management API is a REST interface that can be used to manage objects, policies, rules and administrative functionality. This API is defined at https://sc1.checkpoint.com/documents/latest/APIs/#web. Typically, most Security Management Server administrators use the API interface for management. When is Scalable Platform deployment the management of the Orchestrator appliances is performed through the Orchestrator WebUI. There is a single type of administrator account on Orchestrator, although multiple users can be defined to performed management activities on the Orchestrator appliance. Once authenticated, Orchestrator administrators have access to the following security functions on the Orchestrator appliance: • Ability configure objects and Security Groups; • Ability to create, delete, modify Orchestrator administrator accounts; • Ability to configure administrator session inactivity time before session termination; 3 The trusted path between authorized administrator and Security Management Server can only be configured during the initial installation of the TOE. 4 The trusted channels between TOE components can only be configured during the initial installation of the TOE. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 66 This document may be freely reproduced and distributed whole and intact including this copyright notice. • Ability to configure trusted path between an Orchestrator administrator and Orchestrator (TLS between Orchestrator and MHO Administration PC)5 The TOE offers two administrative interfaces to the Orchestrator appliance: • CLI: The command line interface is a text based interface that is accessible via SSH. These command line functions can be used to effectively perform most administrative activities, but it is most typically used during initial installation of the TOE. • WebUI: The WebUI is a browser based interface that can be used to manage objects, Security Groups and administrative functionality. This WebUI is defined at by the Maestro R82 Getting Started Guide and the Maestro R82 Administration Guide. The Security management function is designed to satisfy the following security functional requirements: • FMT_SMF.1: The TOE provides administrative interfaces to perform the functions identified above. • FMT_SMR.1: The TOE supports Security Management Server administrator and Orchestrator administrator roles. The single administrator profile “read write all” is supported in the evaluated configuration. A Security Management Server administrator can login to the TOE locally or remotely. A single Orchestrator administrator profile is supported on the Orchestrator appliance, and Orchestrator administrators can log in local or remotely to the Orchestrator appliance. 7.6 TOE access The TOE provides an inactivity timeout for Check Point REST API sessions to the Management Server and (when in SP deployment) to Orchestrator. The (Security Management Server and Orchestrator) administrator can set the inactivity timeout. When an inactivity period is exceeded, the session is terminated. The user will be required to login in after any session has been terminated due to inactivity or after voluntary termination. The TOE access function is designed to satisfy the following security functional requirements: • FTA_SSL.3: The TOE allows inactive sessions to disconnect after a set period of time configurable in the GUI. • FTA_SSL.4: The TOE allows session disconnect via a logout command. 7.7 Protection of the TSF Each TOE component (SGM, Security Management Server and (when in SP deployment) Orchestrator) provides a system clock. During installation the TOE is configured to synchronize its clock with a time server. The TOE uses the clock to support several security 5 The trusted path between authorized administrator and Orchestrator can only be configured during the initial installation of the TOE. ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 67 This document may be freely reproduced and distributed whole and intact including this copyright notice. functions including timestamps for audit records, triggering time-based firewall rules, recording when potential violations have been detected, and inactivity timeouts. All TSF data transmitted between the TOE components SGM and Security Management Server) is communicated using the proprietary SIC protocol to protect the integrity and confidentiality of the transmitted data. VLANs are used to separate the TSF data from user data transmitted over the same physical network connections when being transmitted between Orchestrator and the SGMs. The proprietary SIC protocol is a TLS compliant implementation with a shared secret used to restrict connectivity to trusted hosts. All TSF data transmitted between the administrators, both Security Management Server and Orchestrator in Scalable deployment, is protected using TLS v1.3. The administrators have to connect to the management ports of the Security Management Server and Orchestrator (respectively) from the internal network, and the browsers on the workstations must be configured to only support TLS v1.3. The TLS v1.3 supported ciphersuites are: • TLS_AES_256_GCM_SHA384 • TLS_CHACHA20_POLY1305_SHA256 • TLS_AES_128_GCM_SHA256 The TOE uses standard OpenSSL to generate deterministic random numbers (using RAND_DRBG class). The retrieving of random data is implemented via periodical call to rand_pool_acquire_entropy. This routine invokes series of calls to produce required entropy from various configured sources, including: "/dev/urandom", "/dev/random", "/dev/hwrng", "/dev/srandom". The cryptographic services provided by the TOE in support of the trusted path to the Security Management Server and Orchestrator administrators and the trusted channels between components are detailed in Table 12 below. Purpose Cryptographic mechanism Standard of implementation Key size Standard of application Authentication RSA key pair Signature generation (2048- bit/3072-bit with SHA-256, SHA-384 or SHA-512). Signature verification. (with SHA-256, SHA-384 or SHA- 512) FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3 and Section 5.5, using PKCS #1 v2.1 Signature Schemes RSASSA-PSS Generation 2048 or 3072-bits Verification 2048-bit RSA key pair used for TLS v1.3 (RFC 8446) authentication ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 68 This document may be freely reproduced and distributed whole and intact including this copyright notice. Purpose Cryptographic mechanism Standard of implementation Key size Standard of application SHA-256 hashing (validation of administrator credentials) Public key credentials are stored in the Security Management Server database as PKCS#12 formatted files (private keys in PKCS#1 format). FIPS 180-4 (SHA) PKCS#12 (RFC7292) PKCS#1 v2.1 - - Integrity AES in GCM mode encryption/decryption FIPS 197 (AES), ISO 19772/SP800-38D (GCM) 128 and 256 bits CHACHA20 encryption/decryption and POLY1305 authenticator RFC 7905 256 bits Key distribution RSAES-PKCS1-v1_5 RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 3447, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1” 2048, or 4096 bit TLS v1.3, RFC 8446 Crypto Primitives Random number generator: CTR DRBG based on AES 256 [SP800-90A] - - RSA encryption/decryption According to section 5.1.1 RSAEP and section 5.1.2 RSADP in PKCS v2.1 2048 or 3072 bits - AES encryption/decryption FIPS 197 (AES) 128 and 256 bits - Hashing: SHA-256, SHA-384 or SHA-512 FIPS 180-4 ≥256 bits - Message Authentication Code: HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA- 512. FIPS 198-1 ≥256 bits - Message Authentication Code: Poly1305 RFC8439 256 bits - ©2025 Check Point Software Technologies Ltd. All rights reserved | P. 69 This document may be freely reproduced and distributed whole and intact including this copyright notice. Table 12 TOE Cryptographic services The TOE will overwrite the secret keys relevant for the TSF that are held in volatile memory with zeroes as soon as they are no longer needed to avoid any misuse of this key material. Secret keys that are stored persistently are encrypted (using AES in GCM mode) by the use of a key encryption key (KEK) which is also stored permanently. The key encryption key is randomly created when needed for the first time. As soon as the persistently stored secret key is no longer needed, the secret key and the KEK will be deleted by overwriting so that access to the secret key is no longer possible. Note: as the KEK is also stored persistently, it does not provide complete protection against misuse of the stored key. However, in the context of the assumption A.PHYSICAL_PROTECTION this protection is deemed sufficient. The Protection of the TSF function is designed to satisfy the following security functional requirements: • FPT_STM.1: The TOE provides reliable time stamps using an internal clock maintained by the OS, which is synchronized with the NTP service provide on the Management LAN (as configured during installation). • FPT_ITT.2 FCS_CKM.1, FCS_CKM.2, FCS_COP.1 (all iterations), FCS_CKM.4, FCS_RNG.1: SIC is used to encrypt the management traffic between TOE components to protect it from modification and disclosure. When in SP deployment, the TSF data transmitted between TOE components (Gateways and Management Server, meditated by Orchestrator appliances) will be protected using VLANs to separate management traffic from user data. • FTP_TRP.1 FCS_CKM.1, FCS_CKM.2, FCS_COP.1(all iterations), FCS_RNG.1: The TSF data transmitted on internal networks between the Security Management Server administrator and Security Management Server (and when in SP deployment between the Orchestrator administrator and Orchestrator) will be protected from modification and disclosure using TLS v1.3.