Check Point Gateway appliances provide a broad range of services, features and capabilities. This 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. The evaluated configuration is a subset of the possible configurations of the product, established according to the evaluated configuration guidance.
","evaluation_configuration":"The TOE is Check Point software Security Gateway Appliances running software version R81.20. The TOE includes the following components:
All products are running Checkpoint version R81.20 software. All platforms are x86 based hardware. These platforms can be installed as a Security Gateway and all are running the R81.20 software.
The following Check Point “Smart-1” Security Management Servers are included in the evaluated configuration, running the same R81.20 software. The below platform and virtualized platform run the same software but provide Security Management Server functionality and do not operate as a Security Gateway.
The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) requirements and guidance. The evaluation demonstrated that the TOE meets the security requirements contained in the Security Target. The criteria against which the TOE was judged are described in the Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5, April 2017. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 5, April 2017. The product, when delivered and configured as identified in the Check Point Software Technologies LTD. Quantum Force R81.20 Common Criteria Supplement, Version 1.0, April 23, 2025 and Check Point Software Technologies LTD. Quantum Force R81.20 NIAP Installation Guide, Version 1.0, March 21, 2025 documents, satisfies all of the security functional requirements stated in the Check Point Software Technologies LTD. Quantum Force R81.20 Security Target, version 0.4, April 23, 2025. The project underwent CCEVS Validator review. The evaluation was completed in April 2025. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report (report number CCEVS-VR-VID11509-2025) prepared by CCEVS
\r\n","environmental_strengths":"
The logical boundaries of the Quantum Force R81.20 are realized in the security functions that it implements. Each of these security functions is summarized below.
\r\n\r\n
Security audit:
\r\nThe TOE generates audit logs and has the capability to store them internally or to send them to an external audit server. The connection between the TOE and the remote audit server is protected with IPsec. The TOE has a disk cleanup procedure where it removes old audit logs to allow space for new ones. When disk space falls below a predefined threshold (the cleanup procedure cannot keep up with the audit collection), the TOE stops collecting audit records.
\r\nCommunication:
\r\nThe TOE is a distributed solution consisting of Quantum Force as well as a Security Management Server. The Security Management Server can manage one or more Quantum Force Appliances.
\r\nCryptographic support:
\r\nThe TOE uses the Check Point Cryptographic Library version 1.1 that has received Cryptographic Algorithm Validation Program (CAVP) certificates for all cryptographic functions claimed in this ST. Cryptographic services include key management, random bit generation, encryption/decryption, digital signature and secure hashing.
\r\nUser data protection:
\r\nThe TOE ensures that residual information is protected from potential reuse in accessible objects such as network packets.
\r\nFirewall:
\r\nThe TOE supports many protocols for packet filtering including icmpv4, icmpv6, ipv4, ipv6, 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. The TOE supports FTP for stateful filtering.
\r\nRouted 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.
\r\nIP packets are processed by the Check Point R81.20 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.
\r\nThe TOE mediates the information flows according to an administrator-defined policy. Some of the traffic may be either silently dropped or rejected (with notification to the presumed source).
\r\nThe TOE's firewall and VPN 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.
\r\nIdentification and authentication:
\r\nThe TOE implements a password-based authentication mechanism for authenticating users and requires identification and authentication before allowing access. Only the banner may be presented before authentication is complete. The TOE supports passwords of varying length and allows an administrator to specify a minimum password length between 8 and 100 characters long. The password composition can contain all special characters as required by FIA_PMG_EXT.1.1.
\r\nInternally, the TOE keeps track of failed login attempts and if the configured number of attempts is met, the administrator is either locked out for a period of time or until the primary administrator unlocks the account. The local CLI remains available when the remote account is locked out.
\r\nThe TOE’s IPsec implementation supports X.509 certificates (both RSA and ECDSA) for IKE authentication.
\r\nSecurity management:
\r\nThe TOE allows both local and remote administration for management of the TOE’s security functions. The TOE creates and maintains roles for configured administrators. An administrator can log in locally to the TOE using a serial connection. The local login operates in a Command Line Interface (CLI). There is one remote administration interface that can be used once the TOE is in its evaluated configuration. The remote administration interface is executed through a Graphical User Interface program named SmartConsole using a connection protected by IPsec.
\r\nPacket filtering:
\r\nPlease see the prior Firewall section for a description of the TOE’s packet filtering mechanism.
\r\nProtection of the TSF:
\r\nThe TOE includes capabilities to protect itself from unwanted modification as well as protecting its persistent data.
\r\nThe TOE does not store passwords in plaintext; they are obfuscated. The TOE does not support any command line capability to view any cryptographic keys generated or used by the TOE.
\r\nThe TOE only allows updates after their signature is successfully verified. The TOE update mechanism uses ECDSA with SHA-512 and P-521 to verify the signature of the update package.
\r\nThe TOE’s FIPS executables are signed using ECDSA with SHA-512 and P-521. For all other executables a hash is computed during system installation and configuration and during updates.
\r\nDuring power-up the integrity of all executables is verified. If an integrity test fails in the cryptographic module, the system will enter a kernel panic and will fail to boot up. If an integrity test fails due to a non-matching hash, a log is written. Also during power-up, algorithms are tested in the kernel and user-space. If any of these test fail, the TOE is not operational for users.
\r\nThe TOE protects all communications among its distributed components with IPsec.
\r\nThe TOE provides a timestamp for use with audit records, timing elements of cryptographic functions, and inactivity timeouts.
\r\nTOE access:
\r\nThe TOE is able to terminate interactive sessions if the session is inactive for an administrator configured period of time. The TOE also allows a session to be disconnected via a logout command. An administrator can configure a login banner to be displayed before authentication is completed.
\r\nTrusted path/channels:
\r\nThe TOE protects all communications with outside entities using IPsec communications only. The TOE employs IPsec when it sends audit data to an audit server, and when allowing remote administration connections. Any protocol that is part of the distributed TOE must be protected in an IPsec connection.
","features":[{"id":2657,"feature_name":"Asymmetric Key Generation"},{"id":2660,"feature_name":"Auditing"},{"id":2652,"feature_name":"Certificate Authentication"},{"id":2654,"feature_name":"Certificate Validation"},{"id":2672,"feature_name":"Cryptographic Hashing"},{"id":2670,"feature_name":"Cryptographic Key Establishment"},{"id":2671,"feature_name":"Cryptographic Signature Verification"},{"id":2669,"feature_name":"DRBG"},{"id":2668,"feature_name":"Firewall"},{"id":2651,"feature_name":"IPsec"},{"id":2662,"feature_name":"Key Destruction"},{"id":2673,"feature_name":"Keyed-hash message authentication"},{"id":2649,"feature_name":"VPN Gateway"}]}