Common Criteria EAL4+ALC_FLR.1
Check Point Software
Technologies Ltd. R80.30
Firmware for Security Gateway
Appliances with Firewall, IPS
Blade Pattern Matcher, and
Security Management Server
Security Target
Security Target Introduction
2
© 2019 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.
Security Target Introduction
3
Document History
Date Description
10 December 2019 First release of this document
Security Target Introduction
4
Contents
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 ...........................................................................................................9
1.4.1 TOE Architecture....................................................................................................10
1.4.2 Required non-TOE Hardware/Software/Firmware..................................................11
1.4.3 Physical Boundaries...............................................................................................11
1.4.4 Logical Boundaries.................................................................................................14
2 Conformance Claims..........................................................................................................17
2.1 Common Criteria Conformance Claims......................................................................17
2.2 Protection Profile Conformance Claims......................................................................17
2.3 Packages Conformance Claims .................................................................................17
2.4 Conformance Rationale..............................................................................................17
3 Security Problem Definition................................................................................................18
3.1 Threats .......................................................................................................................18
3.1.1 T.NETWORK_DISCLOSURE.................................................................................18
3.1.2 T.NETWORK_ACCESS .........................................................................................18
3.1.3 T.MALICIOUS_TRAFFIC .......................................................................................18
3.1.4 T.UNAUTHORIZED_ADMIN_ACCESS .................................................................18
3.1.5 T.UNDETECTED_ACTIVITY..................................................................................18
3.2 Organisational security policies..................................................................................18
3.3 Assumptions...............................................................................................................18
3.3.1 A.PHYSICAL_PROTECTION.................................................................................18
3.3.2 A.LIMITED_FUNCTIONALITY ...............................................................................19
3.3.3 A.LOCAL_NETWORK_PROTECTION ..................................................................19
3.3.4 A.TRUSTED_ADMINSTRATOR ............................................................................19
3.3.5 A.CONNECTIONS..................................................................................................19
4 Security Objectives.............................................................................................................20
4.1 Security objectives for the TOE..................................................................................20
4.1.1 O.ADDRESS_FILTERING......................................................................................20
4.1.2 O.PORT_FILTERING.............................................................................................20
4.1.3 O.INTRUSION_PREVENTION...............................................................................20
4.1.4 O.TOE_ADMINISTRATION....................................................................................21
Security Target Introduction
5
4.1.5 O.AUTHENTICATION ............................................................................................21
4.1.6 O.SYSTEM_MONITORING....................................................................................21
4.2 Security Objectives for the Operational Environment.................................................21
4.2.1 OE.PHYSICAL........................................................................................................21
4.2.2 OE.NO_GENERAL_PURPOSE .............................................................................21
4.2.3 OE.LOCAL_NETWORK .........................................................................................22
4.2.4 OE.TRUSTED_ADMIN...........................................................................................22
4.2.5 OE.CONNECTIONS...............................................................................................22
4.3 Security objectives rationale.......................................................................................22
4.3.1 Security objectives rationale tracing.......................................................................22
4.3.2 Justification for the effectiveness of the security problem solution.........................23
5 Extended Components Definition.......................................................................................25
5.1 Security Audit (FAU)...................................................................................................25
5.1.1 Protected Audit Event Storage (FAU_STG_EXT) ..................................................25
5.2 Intrusion Prevention System (IPS) .............................................................................25
5.2.1 IPS Analyser analysis (IPS_ANL_EXT)..................................................................25
5.2.2 IPS Analyser React (IPS_RCT_EXT).....................................................................26
5.3 Firewall (FFW)............................................................................................................27
5.3.1 Stateful Traffic Filtering (FFW_RUL_EXT) .............................................................27
5.4 Extended Components Rationale...............................................................................28
6 Security Requirements.......................................................................................................29
6.1 TOE Security Functional Requirements .....................................................................29
6.1.1 Security audit (FAU) ...............................................................................................29
6.1.2 Stateful Traffic Filtering Firewall (FFW) ..................................................................31
6.1.3 Intrusion Prevention System (IPS) .........................................................................32
6.1.4 Identification and authentication (FIA) ....................................................................33
6.1.5 Security Management (FMT)..................................................................................33
6.1.6 TOE access (FTA)..................................................................................................34
6.1.7 Protection of the TSF (FPT) ...................................................................................34
6.2 TOE Security Assurance Requirements.....................................................................34
6.2.1 Rationale for TOE Assurance Requirements Selection..........................................35
6.3 Security Requirements Rationale...............................................................................35
6.3.1 Security Functional Requirements for the TOE ......................................................35
6.3.2 Security Functional Requirements Dependency Rationale ....................................35
7 TOE Summary Specification ..............................................................................................37
7.1 Security audit..............................................................................................................37
7.2 Packet Filtering and Stateful Traffic Filtering Firewall ................................................38
Security Target Introduction
6
7.3 Intrusion Prevention Systems.....................................................................................39
7.4 Identification and authentication.................................................................................41
7.5 Security management.................................................................................................42
7.6 TOE access................................................................................................................42
7.7 Protection of the TSF..................................................................................................43
Security Target Introduction
7
Tables and Figures
Table 1 TOE firmware packages................................................................................................12
Table 2 TOE Component versions.............................................................................................14
Table 3 Threats and assumptions tracing ..................................................................................23
Table 4 TOE threat prevention rationale ....................................................................................24
Table 5 TOE Security Functional Requirements........................................................................29
Table 6 Security Functional Requirements and Auditable Events .............................................30
Table 7 EAL 4 Assurance Components .....................................................................................35
Table 8 SFR Dependencies.......................................................................................................36
Security Target Introduction
8
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 R80.30
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 4)
• Extended Components Definition (Section 5)
• Security Requirements (Section 6)
• TOE Summary Specification (Section 7)
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 Software Technologies Ltd. R80.30 Firmware for
Security Gateway Appliances with Firewall, IPS Blade Pattern
Matcher, and Security Management Server EAL4+ALC_FLR.1
Security Target
ST Publication Date 10 December 2019
1.2 TOE Reference
TOE Identification Check Point Software Technologies Ltd. R80.30 Firmware for
Security Gateway Appliances with Firewall, IPS Blade Pattern
Matcher, and Security Management Server
TOE Developer Check Point Software Technologies Ltd.
Security Target Introduction
9
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 Software Technologies Ltd. R80.30 Firmware
for Security Gateway Appliances with Firewall, IPS Blade Pattern Matcher, and Security
Management Server.
The TOE 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 Management Server and management workstation are co-located on a logically protected
LAN behind the firewall.
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.
1.4 TOE Description
Check Point Security Gateway Appliances R80.30 firmware provides a broad range of services,
features and capabilities to be delivered by the underlying appliance. 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).
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 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.
• Logical Boundaries – describes the claimed logical security features offered by the
TOE.
• TOE Guidance – identifies the guidance documentation that is considered to be part of
the TOE.
Security Target Introduction
10
1.4.1 TOE Architecture
The TOE is the Security Gateway Appliances R80.30 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
• Security Management – Security Management Server software.
Figure 1 TOE deployment
Check Point Security Gateway R80.30 Security Gateway firmware is installed on a hardware
platform (appliance). 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.
Check Point Security Gateway Appliances mediate information flows between clients and
servers located on internal and external networks governed by the firewall. 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 an authorized administrator has the
authority to change the security policy rules.
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.
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 TOE administrators. The audit records
Security Target Introduction
11
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 administrator (remotely) communicates with the Security Management server via the
Check Point REST API or (locally) via a directly connected console to the CLI. Local
administration is, and is typically only used during initial installation or troubleshooting. Use of
the Check Point SmartConsole, via the SIC (Secure Internal Communication) interface is not
supported in the evaluated configuration. The workstation from which the TOE is managed
must also be connected to the dedicated management LAN. The configuration of the dedicated
management LAN is detailed in CC Installation Configuration and Administration Guide.
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 and Security Management Appliances, which execute firmware installed
from the applicable R80.30 firmware image. 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:
• Security Gateway appliances running R80.30 GA 2.6 firmware:
o Check Point 3100, 3200
o Check Point 5100, 5200, 5400, 5600, 5800, 5900
o Check Point 6500, 6800
o Check Point 15400, 15600
o Check Point 23500, 23800, 23900
o TE100X, TE250X, TE1000X, TE2000X
o CloudGuard for ESXi running on a Dell R720
• Security Gateway appliances running R80.30 GA 3.10 firmware:
o Check Point 16000, 26000
• Security Management Server appliances running the R80.30 GA 3.10 firmware
o Smart-1 405
o Smart-1 410
o Smart-1 525
o Smart-1 625
o Smart-1 5050
o Smart-1 5150
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:
• Admin PC – This PC is the machine used by the administrator to issue the management
commands to the TOE over REST API.
• NTP Server – This server provides NTP time services to the TOE.
• Syslog 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 R80.30 firmware and
Security Management Server firmware (i.e. it is a software only TOE boundary).
Security Target Introduction
12
There are three variants of the R80.30 firmware .iso package depending on which GAiA
operating system is supported by the appliance1
:
Firmware
Package
Download file SHA-256 hash value
R80.30 GA 2.6
Gateway
Check_Point_R80.30_T200_
Security_Gateway.iso
e59d52b87418df4751b0ba24d57229d8b
2999589960fc3d1bd954a763b35948a
R80.30 GA 3.10
Gateway
Check_Point_R80.30_Gaia_
3.10_T273.iso
2ebe838e3cb9f339b917d3a529e0d06d65
9aa8addd4471fdb60bb8986b5a3070
R80.30 GA
Security
Management
Server
Check_Point_R80.30_T200_
Security_Management.iso
25e443cb7e2632553e890fb0ae0fa436b1
29282c25c71ae4a518fcffa28fe0e3
Table 1 TOE firmware packages
The following hotfix must be applied to the R80.30 GA 2.6 Security Gateway Server:
• Download file: Check_Point_R80.30_T200_Hotfix_133_T6_sk162814_FULL.tgz
• SHA256:
e6cc8914320e37d667192a1370c8637f0911795e68bcd21bb1f7d4a94ed66768
The following hotfix must be applied to the R80.30 GA 3.10 Security Gateway Server:
• Download file:
Check_Point_R80.30_T300_GAIA_3.10_Hotfix_020_T6_sk162814_FULL.tgz
• SHA256: cf10003e7e0e7cc8014c8f6e0b017ffb449b585970a2f63a3952115e10beb98f
The following hotfix must be applied to the R80.30 GA Security Management Server:
• Download file: Check_Point_R80.30_T200_Hotfix_T6_sk162814_FULL.tgz
• SHA256:
4069a1d7ddc92c1d72e534649abd18106e55e41a85e9d50a9ed99e3fde44c5c1
The unique version of the TOE is determined by the execution of two commands on the
console during installation:
show version all
Smart-1 6500 Security Gateway
appliance (2.6.18 GW)
16K/26K Security Gateway
appliance (3.10 GW)
Product version Check Point
Gaia R80.30
Product version Check Point
Gaia R80.30
Product version Check Point
Gaia R80.30
OS build 200 OS build 200 OS build 273
OS kernel version 3.10.0-
693cpx86_64
OS kernel version 2.6.18-
92cpx86_64
OS kernel version 3.10.0-
693cpx86_64
OS edition 64-bit OS edition 64-bit OS edition 64-bit
cpinfo -y all
Smart-1 6500 Security Gateway
appliance (2.6.18 GW)
16K/26K Security Gateway
appliance (3.10 GW)
This is Check Point CPinfo Build
914000196 for GAIA
This is Check Point CPinfo
Build 914000196 for GAIA
This is Check Point CPinfo Build
914000196 for GAIA
Local host is not a Gateway
1
Unless followed by “GA” or “3.10” qualifiers, all references to R80.30 in this document are equally
relevant to both R80.30 GA 2.6 and R80.30 GA 3.10 variants of the firmware.
Security Target Introduction
13
[IDA] [IDA] [IDA]
No hotfixes.. No hotfixes.. No hotfixes..
[CPFC] [MGMT] [MGMT]
No hotfixes.. No hotfixes.. No hotfixes..
[MGMT] [CPFC] [CPFC]
HOTFIX_HEAT_201_ Take: 6 No hotfixes.. No hotfixes..
No hotfixes..
[FW1] [FW1] [FW1]
HOTFIX_HEAT_201_ Take: 6
HOTFIX_R80_30_T200_133_
MAIN Take: 6
HOTFIX_R80_30_GOGO_T300_
020_MAIN Take: 6
FW1 build number: FW1 build number: FW1 build number:
This is Check Point Security
Management Server R80.30 - Build
159
This is Check Point's software
version R80.30 - Build 484
This is Check Point's software
version R80.30 - Build 116
This is Check Point's software
version R80.30 - Build 484
kernel: R80.30 - Build 003 kernel: R80.30 - Build 002
[SecurePlatform] [SecurePlatform] [SecurePlatform]
HOTFIX_GOGO_LT_HEAT_200_
HOTFIX_HEAT_201 Take: 6
HOTFIX_R80_30_T200_133_
MAIN Take: 6
HOTFIX_GOGO_HEAT_188_CE
RTIFICATION_MAIN Take: 6
[CPinfo] [PPACK] [PPACK]
No hotfixes.. No hotfixes.. No hotfixes..
[DIAG] [CPinfo] [CPinfo]
No hotfixes.. No hotfixes.. No hotfixes..
[Reporting Module] [DIAG] [DIAG]
No hotfixes.. No hotfixes.. No hotfixes..
[CPuepm] [CVPN] [CVPN]
No hotfixes.. No hotfixes.. No hotfixes..
[VSEC] [CPUpdates] [CPUpdates]
No hotfixes..
BUNDLE_R80_30_T200_133_
MAIN Take: 6
BUNDLE_R80_30_GOGO_T300_
020_MAIN Take: 6
[SmartLog]
No hotfixes..
[R7520CMP]
No hotfixes..
[R7540CMP]
No hotfixes..
[R76CMP]
No hotfixes..
[SFWR77CMP]
No hotfixes..
[R77CMP]
No hotfixes..
[R75CMP]
No hotfixes..
[NGXCMP]
Security Target Introduction
14
No hotfixes..
[EdgeCmp]
No hotfixes..
[SFWCMP]
No hotfixes..
[FLICMP]
No hotfixes..
[SFWR75CMP]
No hotfixes..
[MGMTAPI]
No hotfixes..
[CPUpdates]
BUNDLE_HEAT_201_HOTFIX_IN
TERCEPTOR_MAIN Take: 6
Table 2 TOE Component versions
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 Software Technologies Ltd. R80.30 Firmware for Security Gateway
Appliances with Firewall, IPS Blade Pattern Matcher, and Security Management Server,
R80.30, CC Installation Configuration and Administration Guide, 10 December 2019.
This guidance documentation (available in PDF format) is available for download from the
Check Point User Center (http://downloads.checkpoint.com/dc/download.htm?ID=100649).
1.4.4 Logical Boundaries
This section summarizes the security functions provided by R80.30:
• Security audit
• Stateful Traffic Filtering Firewall
• Packet Filtering
• Intrusion Prevention Systems
• Identification and authentication
• Security management
• TOE access
• Protection of TSF
Security Target Introduction
15
The following table shows which TOE component is responsible for the implementation of each
of the SFRs:
Requirement Class Security Gateway Appliance Management Server
Firewall
blade
IPS
blade
GAiA Management
Server
application
GAiA
FAU: Security audit X X X X
FFW: Stateful Traffic Filtering
Firewall
X X
IPS: Intrusion Prevention Systems X
FIA: Identification and
authentication
X X X
FMT: Security management X
FTA: TOE access X
FPT: Protection of the TSF X X
Figure 2 Security Functionality provided TOE components
1.4.4.1 Security audit
The Gateway Appliances generates audit records of the application of rules configured with the
‘log’ operation. The Gateway Appliances 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 Gateway Appliance will store locally until the connection is restored. The
Management Server generates audit records for specified events, recording at least date and
time of the event, type of event, subject identity, and the outcome. The TOE can be configured
to send audit logs to a log server (hosted in the dedicated management LAN) as well. Finally,
note that the Gateway Appliances 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.
1.4.4.2 Packet Filtering and Stateful Traffic Filtering Firewall and
The TOE supports 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 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 an 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.
Security Target Introduction
16
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 TOE provides 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 administrator-specified 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 TOE implements a password-based authentication mechanism that identifies operators via
usernames. Three sequential failed authentication attempts made by a user will result in a
lockout of the administrator account for 30 minutes.
1.4.4.5 Security management
The TOE allows both local and remote administration for management of the TOE’s security
functions. The single administrator profile “read write all” is supported in the evaluated
configuration. An administrator can log in locally to the TOE using a serial connection. The
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 is available via the Check Point REST API (as defined at
https://sc1.checkpoint.com/documents/latest/APIs/#web). Again, the administrator has to
authenticate before being able to successfully initiate any management functionality. This
management functionality includes configuration of network objects (hosts, NAT, etc), firewall
policies, IPS policies, administrator accounts, auditing functionality.
In the evaluated configuration the management workstation must be connected to the same
dedicated management LAN as the Management Server.
1.4.4.6 TOE Access
Remote 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.
1.4.4.7 Protection of the TSF
Each TOE component (Security Gateway and Security Management Server) provides a system
clock that is synchronised with a time server (provided in the IT environment).
Conformance Claims
17
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
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.
Security Problem Definition
18
3 Security Problem Definition
3.1 Threats
3.1.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.1.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.1.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 unauthorised services on the target machine or to gain
unauthorised access to user data on the target machine.
3.1.4 T.UNAUTHORIZED_ADMIN_ACCESS
Threat agents may attempt to gain administrator access to the firewall by nefarious means such
as masquerading as an administrator to the firewall.
3.1.5 T.UNDETECTED_ACTIVITY
Threat agents may attempt to access, change, and/or modify the security functionality of the
firewall 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.2 Organisational security policies
There are no organisational security policies imposed on the TOE by this Security Target.
3.3 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.3.1 A.PHYSICAL_PROTECTION
The hardware components on which the TOE executed are assumed to be physically protected
in its operational environment (e.g. server room, data centre) and not subject to physical
attacks that compromise the security and/or interfere with the TOE’s physical interconnections
and correct operation. This protection is assumed to be sufficient to protect the TOE and the
data it contains. As a result, this Security Target does not include any requirements on physical
Security Problem Definition
19
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.3.2 A.LIMITED_FUNCTIONALITY
The Security Gateway platform is assumed to only provide services to support networking,
filtering and IPS functionality as its core function and not provide functionality that could be
deemed as general-purpose computing services.
3.3.3 A.LOCAL_NETWORK_PROTECTION
Where the components of the TOE are connected together or connected to other trusted IT
entities on a dedicated management local area network, the connections are assumed to be
physically secure and not to require any additional cryptographic protection to ensure the
confidentiality of the communication between the TOE components.
3.3.4 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 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.3.5 A.CONNECTIONS
It is assumed that the Security Gateway is connected to distinct networks in a manner that
ensures that the TOE security policies will be enforced on all applicable network traffic flowing
among the attached networks.
Security Objectives
20
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 unauthorised 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 unauthorised 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:
• FFW_RUL_EXT.1 specifies requirements to prevent unauthorised 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.
Security Objectives
21
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.
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.
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.
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_STG_EXT.1 specifies requirements for the storage of the audit events on the TOE
and on an external log server.
• 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.
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 TOE, other than those services necessary for the operation, administration and
support of the TOE.
Addresses: A.LIMITED_FUNCTIONALITY
Security Objectives
22
4.2.3 OE.LOCAL_NETWORK
All components related to the management of the TOE are connected to a dedicated
management LAN. The following components are connected to the dedicated management
LAN: Management Server appliance, management workstation, external log server and NTP
server.
Addresses: A.LOCAL_NETWORK_PROTECTION
4.2.4 OE.TRUSTED_ADMIN
TOE Administrators are trusted to follow and apply all guidance documentation in a trusted
manner.
Addresses: A.TRUSTED_ADMINSTRATOR
4.2.5 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.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.
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.
Security Objectives
23
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 3 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 or operational environment; 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.
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
Security Objectives
24
Threat Rationale
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 unauthorised
services on the target machine or to gain
unauthorised 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
Threat agents may attempt to gain administrator
access to the firewall by nefarious means such as
masquerading as an administrator to the firewall.
By meeting the security objectives
O.TOE_ADMINISTRATION and
O.AUTHENTICATION the TOE is able to
ensure that any administrator access is
from genuine, authorised administrators
with knowledge of the administrator
authentication credentials.
T.UNDETECTED_ACTIVITY
Threat agents may attempt to access, change,
and/or modify the security functionality of the
firewall 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.
By meeting the security objective
O.TOE_ADMINISTRATION the TOE
ensures that only authorised
administrators 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 unauthorised activity.
Table 4 TOE threat prevention rationale
Extended Components Definition
25
5 Extended Components Definition
5.1 Security Audit (FAU)
A new family is defined for the existing Security Audit class.
5.1.1 Protected Audit Event Storage (FAU_STG_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 Protected Audit Event Storage (FAU_STG_EXT.1)
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external
IT entity.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
FAU_STG_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.
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.
FAU_STG_EXT.1 Protected Audit Event Storage 1
Extended Components Definition
26
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.
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.
IPS_ANL_EXT: ISP Analyser Analysis 1
IPS_RCT_EXT: ISP Analyser React 1
Extended Components Definition
27
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: None.
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.
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: Stateful Traffic Filtering 1
Extended Components Definition
28
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].
5.4 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).
Security Requirements
29
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 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_STG_EXT.1 Protected 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
Table 5 TOE Security Functional Requirements
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 administrators).
• Changes to TSF data related to 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 6.]
Security Requirements
30
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, 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 6].
Requirement Auditable Events Additional Audit Record
Contents
FAU_GEN.1 Start-up and shut-down of the
audit functions
None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FFW_RUL_EXT.1 Result: Application of rules
configured with the ‘log’
operation
Source and destination
addresses
Source and destination ports
TOE Interface
IPS_ANL_EXT.1 Enabling and disabling of IPS
blade
None.
IPS_RCT_EXT.1 None None.
FIA_UID.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_UAU.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
FIA_AFL.1 Unsuccessful login attempt
limit is met or exceeded.
Origin of the attempt (e.g., IP
address).
FMT_SMF.1 Administrator action
performed.
None.
FMT_SMR.1 None. None.
FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
None.
FTA_SSL.4 The termination of an
interactive session.
None.
FPT_STM.1 None None
Table 6 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_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external
IT entity.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
Security Requirements
31
FAU_STG_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.
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 network packets where the source address of the network packet is
defined as being a loopback address;
Security Requirements
32
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 authorized 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].
6.1.3.2 IPS_RCT_EXT.1 Analyser React
IPS_RCT_EXT.1.1 The TSF shall take [actions as configured by an authorized 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;
Security Requirements
33
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].
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 [Authorised Administrator].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
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:
• [Ability to create, delete, modify 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].
Security Requirements
34
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 [Authorised
Administrator-configurable time interval of session inactivity].
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.
6.1.7 Protection of the TSF (FPT)
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.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 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
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
Security Requirements
35
Assurance class Assurance components
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.3 Focused vulnerability analysis
Table 7 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.
The augmentation of ALC_FLR.1 was chosen to give greater assurance of the developer’s on-
going flaw remediation processes.
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_STG_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
Security Requirements
36
Requirement Component Dependency Notes
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
Table 8 SFR Dependencies
TOE Summary Specification
37
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 Security Gateway and Management Server generate audit logs of security events (see
Table 6).
GAiA generates OS-related security events on both the Security Gateway and the Management
Server. The Security Gateway 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 administrator activities on the Management Server).
The Security Gateway sends its traffic logs to the Management Server and sends its OS (GAiA)
logs to the external syslog server. In the event of failure, e.g. loss of power on the Gateway,
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 server the security management audit
logs, its own OS (GAiA) logs and the traffic logs received from the Security Gateway.
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 authorized administrator. The TOE 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, gateways will queue the records, and
eventually start logging them to the local disk, until connectivity is resumed.
It should be noted that events indicating the start-up and shutdown of auditing are generated by
GAiA for both the Security Gateway and the Management Server.
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 gateways
• FAU_STG_EXT.1: The TOE is able to send audit log data to an external log server.
• FPT_STM.1: The TOE provides timestamps for use in audit records.
TOE Summary Specification
38
7.2 Packet Filtering and Stateful Traffic Filtering
Firewall
Every IPv4 packet received by the Check Point Security Gateway Appliances gateway 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 authorized 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.
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
TOE Summary Specification
39
During the Check Point Security Gateway Appliances gateway 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 appliance is disabled; and
• Traffic to and from the appliance is controlled by a Default Filter that drops all external
traffic to the appliance
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).
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 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 Security Gateways using a stack-based virtual
machine.
An INSPECT script applies a conditioned sequence of pattern matching operations on packets
flowing through the gateway. 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
Security Gateway Appliances 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 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:
TOE Summary Specification
40
• 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.
• 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 an 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
Security Gateway 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 Security Gateway to take appropriate
action (Allow, Drop, or Reject) and possibly capture packets for future investigation.
TOE Summary Specification
41
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.
• FPT_STM.1: The TOE provides a clock for use in traffic analysis rules that relate to
date/time.
7.4 Identification and authentication
The TOE provides a password mechanism for authenticating users. Users are associated with
a username, password, and one or more roles. Users may authenticate 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 an administrator
fails 3 consecutive attempts, the administrator is locked out for 30 minutes.
The TOE requires identification and authentication before allowing access. Only the banner
may be presented before authentication is complete.
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.
• FIA_AFL.1: The TOE supports the capability to lock an account for 30 minutes .
TOE Summary Specification
42
7.5 Security management
User accounts are associated with the profile “read write all”. User accounts associated with
this profile are called authorized administrators.
Once authenticated, authorized administrators have access to the following security functions:
• Ability to create, delete, modify 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
The TOE offers two administrative interfaces:
• 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 authorized
administrators use the API interface for management.
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 administrator roles. The single administrator profile
“read write all” is supported in the evaluated configuration. An administrator can login to
the TOE locally or remotely.
7.6 TOE access
The TOE provides an inactivity timeout for Check Point REST API sessions. The authorized
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.
TOE Summary Specification
43
7.7 Protection of the TSF
Each TOE component (Security Gateway and Secuirty Management Server) 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 functions including timestamps for audit
records, triggering time-based firewall rules, recording when potential violations have been
detected, and inactivity timeouts.
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).