Imperva Web Application Firewall (WAF) v14.7P20
Security Target
Version 1.8
11 September 2023
Prepared for:
One Curiosity Way, Suite 203
San Mateo, CA 94403
United States
Common Criteria Testing Laboratory
6841 Benjamin Franklin Drive
Columbia, Maryland 21046
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.8, 2023-02-
0811
1
Table of Contents
1 Security Target Introduction 1
1.1 Security Target, Target of Evaluation and Common Criteria Identification 1
1.2 Conformance Claims 1
1.3 Conventions 1
1.4 Keywords 2
1.5 TOE Overview 2
1.5.1 TOE Type 2
1.5.2 TOE Usage and Major Security Features 3
1.5.3 Non-TOE Hardware/Software/Firmware Required by the TOE 4
1.6 TOE Description 6
1.6.1 Introduction 6
1.6.2 Physical Boundary 7
1.6.3 Evaluated Configuration 7
1.6.4 Summary of TOE Security Functionality 7
1.6.5 Imperva WAF Deployment Scenarios 8
1.6.7 Web Application Firewall Functionality 12
1.7 TOE Documentation 13
2 Security Problem Definition 14
2.1 Introduction 14
2.2 Assumptions 14
2.2.1 Intended Usage Assumptions 14
2.2.2 Physical Assumptions 14
2.2.3 Personnel Assumptions 14
2.3 Threats 15
2.3.1 TOE Threats 15
2.3.2 IT System Threats 15
2.4 Organizational Security Policies 16
3 Security Objectives 17
3.1 Security Objectives for the TOE 17
3.2 Security Objectives for the Operational Environment 18
4 Extended Components Definition 19
4.1 Class FAU: Security audit 19
4.1.1 Security audit event storage (FAU_STG) 19
4.2 Class FCS: Cryptographic support 20
4.2.1 HTTPS (FCS_HTT) 20
4.2.2 Random Bit Generation (FCS_RBG) 21
4.2.3 TLS (FCS_TLS) 22
4.3 Class IDS: Intrusion Detection System 22
4.3.1 IDS data analysis (IDS_ANL) 23
4.3.2 IDS reaction (IDS_RCT) 24
4.3.3 IDS data review (IDS_RDR) 25
4.3.4 IDS data collection (IDS_SDC) 25
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
2
4.3.5 IDS data storage (IDS_STG) 26
5 Security Requirements 29
5.1 TOE Security Functional Requirements 29
5.1.1 Security Audit (FAU) 30
5.1.2 Cryptographic Support (FCS) 31
5.1.3 Identification and Authentication (FIA) 35
5.1.4 Security Management (FMT) 35
5.1.5 Protection of the TSF (FPT) 36
5.1.6 Trusted Path/Channels (FTP) 37
5.1.7 Intrusion Detection (IDS) 37
5.2 TOE Security Assurance Requirements 39
5.2.1 Development (ADV) 39
5.2.2 Guidance Documents (AGD) 41
5.2.3 Life-cycle Support (ALC) 42
5.2.4 Security Target Evaluation (ASE) 44
5.2.5 Tests (ATE) 47
5.2.6 Vulnerability Assessment (AVA) 48
6 TOE Summary Specification 49
6.1 FAU: Security audit 49
6.1.1 FAU_GEN.1 49
6.1.2 FAU_SAR.1 and FAU_SAR.2 50
6.1.3 FAU_SAR.3 50
6.1.4 FAU_STG.2, FAU_STG.4, FAU_STG.5 50
6.2 FCS: Cryptographic support 50
6.2.1 FCS_CKM.1, FCS_CKM.2, FCS_CKM.4, FCS_COP.1, FCS_HTT.1, FCS_RBG.1(1), FCS_RBG.1(2),
FCS_TLS.1(1), FCS_TLS.1(2), FCS_TLS.1(3), FCS_TLS.1(4) 50
6.3 FIA: Identification and authentication 53
6.3.1 FIA_ATD.1 53
6.3.2 FIA_UAU.2 and FIA_UID.2 53
6.4 FMT: Security management 54
6.4.1 FMT_MOF.1, FMT_MTD.1, FMT_SMR.1 54
6.4.2 FMT_SMF.1 54
6.5 FPT: Protection of the TSF 55
6.5.1 FPT_ITT.1 55
6.5.2 FPT_STM.1 56
6.6 FTP: Trusted path/channels 56
6.6.1 FTP_ITC.1 56
6.6.2 FTP_TRP.1 56
6.7 IDS: Intrusion Detection 56
6.7.1 IDS_ANL.1 56
6.7.2 IDS_RCT.1 57
6.7.3 IDS_RDR.1 57
6.7.4 IDS_SDC.1 58
6.7.5 IDS_STG.1, IDS_STG.2 58
7 TOE Rationale 59
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
3
7.1 Security Objectives Rationale 59
7.1.1 Threats 60
7.1.2 Organizational Security Policies 63
7.1.3 Assumptions 64
7.2 Security Functional Requirements Rationale 65
7.3 Security Assurance Requirements Rationale 70
7.4 SFR Component Hierarchies and Dependencies Rationale 71
8 Abbreviations and Acronyms 73
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
4
List of Figures and Tables
Figure 1: Multi-domain Environment Managed by SecureSphere Operation Manager (SOM) ...................4
Figure 2: Typical TOE Deployment................................................................................................................5
Figure 3: A Typical Imperva WAF Inline (Bridge) Deployment......................................................................9
Figure 4: A Typical Imperva WAF Non-Inline (Sniffing) Deployment.........................................................10
Figure 5: A Typical Reverse Proxy Deployment ..........................................................................................10
Figure 6: Reverse Proxy Deployed as a Cluster Behind a Load Balancer....................................................11
Table 1: Imperva WAF Gateway and MX Management Server Virtual Appliances......................................5
Table 2: : Imperva WAF Gateway and MX Management Server Physical Appliances..................................6
Table 3: TOE Security Functional Components...........................................................................................29
Table 4: Cryptographic Operations.............................................................................................................32
Table 5: System Data Collection Events and Details...................................................................................38
Table 6: Assurance Components.................................................................................................................39
Table 7: Cryptographic Operations.............................................................................................................52
Table 8: Key/CSP Zeroization Summary......................................................................................................53
Table 9: Management Functions ................................................................................................................54
Table 10: Security Problem Definition to Security Objective Correspondence..........................................59
Table 11: SFR to Security Objective Correspondence.................................................................................65
Table 12: TOE SFR Dependency Rationale..................................................................................................71
Table 13: Abbreviations and Acronyms......................................................................................................73
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.8, 2023-02-
0811
1
1 Security Target Introduction
This Security Target (ST) describes the objectives, requirements, and rationale for the Imperva Web
Application Firewall (WAF) software. The language used in this Security Target is consistent with the
Common Criteria for Information Technology Security Evaluation, Version 3.1, Revision 5. As such, the
spelling of terms is presented using the internationally accepted English.
1.1 Security Target, Target of Evaluation and Common Criteria Identification
ST Title: Imperva Web Application Firewall (WAF) v14.7P20 Security Target
ST Version: Version 1.8
ST Date: 2023-09-11
TOE Identification: Imperva Web Application Firewall (WAF) v14.7P20
1.2 Conformance Claims
This ST and the TOE it describes are conformant to the following CC specifications:
● 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.
This ST and the TOE it describes are conformant to the following package:
● EAL2 augmented (ALC_FLR.1 Basic flaw remediation)
1.3 Conventions
The following conventions are used in this document:
ï‚· Security Functional Requirements - Part 1 of the CC defines the approved set of operations that
may be applied to functional requirements: iteration; selection; assignment; and refinement.
o Iteration - allows a component to be used more than once with varying operations. In this
ST, iteration is identified with a number in parentheses following the base component
identifier. For example, iterations of FCS_COP.1 are identified in a manner similar to
FCS_COP.1(1) (for the component) and FCS_COP.1.1(1) (for the elements).
o Selection - allows the specification of one or more elements from a list. Selections are
indicated as underlined text and are enclosed by brackets (e.g., [selection]).
o Assignment - allows the specification of an identified parameter. Assignments are indicated
using italicized text and are enclosed by brackets (e.g., [assignment]). An assignment within
a selection is identified in underlined italics and with italicized embedded brackets (e.g.,
[[selected assignment]]).
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
2
o Refinement - allows the addition of details. Refinements are indicated using bold, for
additions, and strike-through, for deletions (e.g., “… all objects …” or “… some big things
…”).
ï‚· Other sections of the ST - other sections of the ST use bolding and/or different fonts (such as
Courier) to highlight text of special interest, such as captions, commands, or filenames specific
to the TOE.
1.4 Keywords
Web application firewall, threats, risk, collection, analysis.
1.5 TOE Overview
1.5.1 TOE Type
Imperva WAF v14.7P20 protects Web servers by analyzing network traffic flowing to and from protected
servers and applications, detecting requests that may be indicative of intrusion, and reacting by
reporting the events and/or blocking the suspected traffic.
A sampling of attacks WAF is capable of detecting is:
ï‚· Buffer Overflow,
ï‚· Denial of Service,
ï‚· SQL Injections,
ï‚· Cross-site Scripting,
ï‚· Parameter Tampering,
ï‚· Brute-force,
ï‚· Automated Bot attack,
ï‚· Scraping attack,
ï‚· Cookie Poisoning,
ï‚· Session Hijacking,
ï‚· Takeover of Server,
ï‚· Protocol Violation,
ï‚· Directory Traversal,
ï‚· Stealth Commanding,
ï‚· Site Probing.
In this Security Target, the Target of Evaluation is categorized as an IDS/IPS product. The WAF IDS
System collects the following information from the targeted IT System resource(s): service requests,
network traffic, detected known vulnerabilities. The IDS then performs various analysis functions on the
IDS data in order to make intrusion and vulnerability determinations, and provide a response capability.
The product underwent a re-branding in 2021/2 but some old references to “SecureSphere” are still
present in the vendor’s manuals and online documentation. Any references to “SecureSphere” in any
document or manual are the same as references to “WAF GW” or simply “WAF”. The TOE’s SOM
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
3
(SecureSphere Operation Manager) is referred to as Management Server Manager in some of the
manuals.
1.5.2 TOE Usage and Major Security Features
Imperva WAF v14.7P20 provides protection from attacks against Web and Web Services asset, both
within the organization (insider attacks) and from without. Imperva WAF protects Web servers by
analyzing network traffic flowing to and from protected servers and applications, detecting requests
that may be indicative of intrusion, and reacting by reporting the events and/or blocking the suspected
traffic. The product is deployed as one or more WAF appliances (physical, virtual, or cloud) and
controlled by a management system, MX Management Server (MX) appliance. In a multi-tier
management configuration, one or more MXs may be managed by a SecureSphere Operation Manager
(SOM) (Figure 1 below).
The TOE provides protection from attacks against Web and Web Services assets, both within the
organization (insider attacks) and from without. Installed on the network as a reverse HTTP proxy, a
transparent inline bridge or as an offline network monitor (sniffer), an Imperva WAF appliance monitors
application-level protocols for attacks and reacts by blocking the attacks and/or reporting them to a
centralized management server, MX Management Server.
The product is deployed as one or more WAF instances (physical, virtual, or cloud), controlled by an
Imperva Management Server (MX) appliance. In multi-tier management configurations, one or more
MXs may in turn be managed by an Imperva SecureSphere Operation Manager (SOM). Administrators
connect to the MX using a standard Web browser (Figure 1 below) or using OpenAPI. They are required
to authenticate their identity before being allowed any further action.
The different appliance models all run the same WAF v14.7P20 software and provide all claimed security
functionality but may differ in throughput and storage capacity. Imperva WAF software (including both
management and/or WAF components) may alternatively be installed on a Virtual Machine (VM) hosted
by a VMware ESX/ESXi Hypervisor. The Virtual Machine emulates the WAF v14.7P20 appliance
hardware. The VMware Hypervisor and underlying hardware is considered to be outside of the
boundaries of the Target of Evaluation.
The security functionality includes protection of communications between TOE components and trusted
IT entities, identification and authentication of administrators, auditing of security-relevant events, and
the ability to verify the source and integrity of updates to the TOE and provides FIPS-approved
cryptographic libraries.
Imperva's Dynamic Profiling technology automatically builds a model of legitimate application behavior
that is used by the product to identify illegitimate traffic. In addition, attack signatures are
preconfigured into the product and can be periodically updated from an external Application Defense
Center (ADC). The ADC also provides ADC Insights – these are pre-packaged security policy rules and
reports for commonly used applications. Imperva also provides a ThreatRadar service that provides
categorized reputation-based IP blocking lists in near real-time.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
4
Figure 1: Multi-domain Environment Managed by SecureSphere Operation Manager (SOM)
1.5.3 Non-TOE Hardware/Software/Firmware Required by the TOE
The figure below depicts the TOE protecting Web servers. The Imperva WAF v14.7P20 software (TOE) is
installed on Imperva appliances in front of the protected resources. They are connected to the MX
Management Server using dedicated out of band (OOB) management network interfaces, so that the
communication between the gateways and the MX Management Server is not exposed to any internal
or external users.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
5
Figure 2: Typical TOE Deployment
1.5.3.1.1 Web Browser for Imperva GUI Management Interface
Administrators manage and monitor the TOE by connecting to the TOE’s GUI or via OpenAPI which is
resident on the MX Management Server. Imperva WAF accepts the following Web browsers:
● Microsoft Internet Explorer: 10 - 11
● Mozilla Firefox: Most recent stable version.
● Google Chrome: Most recent stable version.
● Microsoft Edge: Most recent stable version.
● Safari : Most recent stable version.
● Opera: Most recent stable version.
1.5.3.1.2 Network Time Protocol (NTP) Server
The TOE requires a reliable time source. This is accomplished by requiring the environment to provide a
NTP implementation. The MX Management Server is configured to communicate to the server and in
turn supplies the time to the WAF GWs.
1.5.3.1.3 Models
The TOE is a software application which runs on the following Imperva physical and virtual appliances.
Table 1: Imperva WAF Gateway and MX Management Server Virtual Appliances
WAF Gateway Appliances Management
Appliance
Model V6500 V4500 V2500 V1000 VM150
CPU 8 8 4 2 4
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
6
Memory 32 GB 16 GB 8 GB 8 GB 8 GB
Minimum Disk 250 GB 160 GB 160 GB 160 GB 160 Gb
Virtual appliances are supported on the following hypervisors:
● VMware ESX/ESXi (5.5 and later)
● KVM (Linux)
● Microsoft Azure
● Microsoft Hyper-V
● Amazon AWS
Table 2: : Imperva WAF Gateway and MX Management Server Physical Appliances
Product
Generation
Model Throughput Form Factor Fault Tolerant
Management
Server
5G
X1010 100 Mbps 1U No
M110
X2010 500 Mbps 1U No
X2510 500 Mbps 2U Yes
M160
X4510 1 Gbps 2U Yes
X6510 2 Gbps 2U Yes
X8510 5 Gbps 2U Yes
X10K 10 Gbps 2U Yes
6G
X1020 100 Mbps 1U No
M120
X2020 500 Mbps 1U No
X2520 500 Mbps 2U Yes
M170
X4520 1 Gbps 2U Yes
X6520 2 Gbps 2U Yes
X8520 5 Gbps 2U Yes
X10k2 10 Gbps 2U Yes
1.6 TOE Description
1.6.1 Introduction
Imperva WAF v14.7P20 provides 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
must be established in accordance with the evaluated configuration guidance.
This part of the ST describes the physical and logical scope and boundaries of the Target of Evaluation
(TOE). This description effectively partitions product functionality into three classes:
● Claimed security functionality that is evaluated in the context of this ST.
● Excluded functionality that is not available in the TOE's evaluated configuration.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
7
● Other functionality that is in the TOE but is not evaluated in the context of this ST except for the
determination that it cannot compromise any claimed security functionality.
1.6.2 Physical Boundary
The TOE is distributed as a software distribution, Imperva WAF v14.7P20, that includes the software,
operating system, crypto-libraries, and additional libraries to operate the WAF Gateways, MX
Management Server, and the SecureSphere Operation Manager (SOM). The bundle includes:
● the Imperva WAF v14.7P20 software,
● the MX Management Server v14.7P20 software (includes OpenAPI 3.0),
● the SecureSphere Operation Manager (SOM) v14.7P20 software,
● CentOS 7.5, the operating system for appliances,
● Security-Enhanced Linux (SELinux) - a kernel module that provides a mechanism for supporting
access control security policies,
● the Bouncy Castle v1.71 crypto library used with the MX Management Server software, and
● the OpenSSL v1.1.1n crypto library used with the WAF Gateway software.
The specific evaluated Imperva software version is 14.7.0.20_0.44105. The TOE is delivered to
customers in the form of pre-installed hardware appliances via courier delivery and Virtual Appliance
images (.ovf) via web site download. The TOE includes the guidance documentation identified in Section
1.7. The guidance documentation can be obtained and downloaded from the Imperva FTP site.
Installation procedures prompt the installer which product to install. The complete Imperva WAF
v14.7P20 distribution is included in the TOE boundary with one exception. The TOE appliances support
local console access and remote access to appliance operating system-level installation and
configuration CLI over the SSH protocol. The CLI is used solely for initial configuration, once an appliance
is correctly configured and operational, the SSH channel used for this configuration is disabled and all
management should be performed via Imperva GUI or the OpenAPI interface. Therefore, the evaluated
configuration excludes the CLI.
1.6.3 Evaluated Configuration
The evaluated configuration is the TOE (software) installed on one WAF Gateway appliance and one MX
Management Server physical appliance, and a virtual SOM installed on VMware ESXi 6.7.
1.6.4 Summary of TOE Security Functionality
1.6.4.1 IDS Component
Imperva WAF is an IDS/IPS that monitors web traffic between clients and servers in real-time, analyses
that traffic for suspected intrusions, and provides a reaction capability. Reaction options include
recording and monitoring suspected traffic and ID events, blocking traffic, and generating alarms
containing event notifications. Available configurable alarms are sending a syslog message to a syslog
server or creating an SNMP trap and sending the trap to an SNMP destination.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
8
1.6.4.2 Security Management, Identification and Authentication and Trusted Path
Administrators manage system configuration settings using the Imperva GUI, a web-based interface
provided by the MX Management Server or OpenAPI. Administrators log in to the MX Management
Server and are authenticated using a password. The server provides a trusted path for the management
session using the TLS protocol. A role-based scheme is used to define administrator authorizations. Only
designated authorized System administrators may modify the behavior of IDS System data collection,
analysis and reaction capabilities. Other authorized administrators may only query System and audit
data and modify other TOE data.
1.6.4.3 Security Audit
The TOE records TOE events related to ADC content updates, administrator logins, changes to
configuration, activation of settings, building profiles, automatic profile updates, server start/stop, etc.
in an audit trail. Administrators are provided with reporting tools to review audit trail and System data.
The TOE provides protection against modification and unauthorized deletion of audit records and
System data, as well as storage exhaustion.
1.6.4.4 Protection of the TSF
The TOE protects itself and its data from tampering. Transfer of information between the gateways and
the Management Server is physically separated from other information flows by the use of the
dedicated OOB management network interface. Audit data that is stored on an archive outside of the
TOE is cryptographically protected from disclosure or tampering. ADC content updates are provided
over a secure channel using TLS, ensuring that the updates will not introduce malicious or other
unexpected changes in the TOE. WAF also protects particularly sensitive data such as stored passwords
and cryptographic keys so that they are not accessible even by an administrator. The TOE includes its
own time clock to ensure that reliable time information is available (e.g., for log accountability) but
requires an NTP Server in the operational environment in order to synchronize its clock with that of the
external time server. The TOE uses HTTPS to protect communications between distributed TOE
components and with the users.
1.6.4.5 Cryptographic Support
The TOE provides a FIPS mode of operation, which must be enabled in the evaluated configuration. The
TOE includes FIPS-approved algorithms providing supporting cryptographic functions. The TOE uses the
Bouncy Castle v1.71 and OpenSSL v1.1.1n for all of the cryptographic functionality. The modules
provide key management, random bit generation, encryption/decryption, digital signature and
cryptographic hashing and keyed-hash message authentication features in support of higher level
cryptographic protocols, including TLS and HTTP over TLS.
1.6.5 Imperva WAF Deployment Scenarios
Imperva Web Application Firewall (WAF) v14.7P20 appliances support both non-inline (sniffing), inline
(bridge), and reverse proxy gateways. An inline gateway is more invasive but provides better blocking
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
9
capabilities. A sniffing gateway is totally noninvasive but provides less effective blocking capabilities. A
reverse proxy gateway terminates the connections and therefore is the most invasive mode, as a result,
it provides more capabilities and features than an inline gateway.
In all modes, system administrators shall ensure that the connection between WAF GW and MX is over
an OOB network and that there is IP connectivity between the WAF GWs, the MX, and the optional
SOM.
1.6.5.1 Inline (Bridge)
Figure 3: A Typical Imperva WAF Inline (Bridge) Deployment
In the inline scenario, the WAF gateway acts as a bridging device between the external network and the
protected network segment. The gateway will block malicious traffic inline (i.e., drop packets). A single
inline gateway protects one or two network segments. It has six network interface cards. Two of the
cards are used for management: one to connect to the management server and the other is optional.
The other four cards are part of two bridges that are used for inline inspection of up to two different
protected network segments. Each bridge includes one card for the external network and one for the
protected network. The figure above depicts a sample inline deployment.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
10
1.6.5.2 Non-Inline (Sniffing Mode)
Figure 4: A Typical Imperva WAF Non-Inline (Sniffing) Deployment
A sniffing gateway is a passive sniffing device. It connects to corporate hubs and switches and taps the
traffic sent to and from protected servers, using a SPAN (mirror) port on the switch, or a dedicated TAP
device. Traffic is copied to it instead of passing directly through it. TCP resets are transmitted over a
“blocking” NIC. The above figure depicts a sample sniffing deployment.
1.6.6 Reverse Proxy
In a Reverse Proxy deployment, the client begins the session by sending packets to the WAF Gateway’s
inbound IP address. The WAF Gateway inspects the packets and based on the rules, opens a second
connection to the server, changing the packet’s source IP address to the WAF Gateway’s outbound IP
address and the destination IP address to the real IP address of the server. The following figure depicts a
Reverse Proxy Deployment.
Figure 5: A Typical Reverse Proxy Deployment
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
11
A Reverse Proxy configured WAF Gateway can be deployed as a cluster of gateways behind a load
balancer. The following figure depicts an example of a cluster gateway configuration. In this case, from
the client’s point of view, the server is the load balancer’s inbound IP address. The server sends the
return packets to the WAF Gateway, which inspect the packets and forwards them to the client,
changing the source IP address to the Gateway’s inbound IP addresses, and the destination IP address to
that of the client. From the client’s point of view, the server is the Gateway’s inbound IP address. From
the server’s point-of-view, the client is the Gateway’s outbound IP address.
A reverse proxy gateway can be deployed as a cluster of gateways behind a load balancer. In this case,
from the client’s point of view, the server is the load balancer’s inbound IP address.
Figure 6: Reverse Proxy Deployed as a Cluster Behind a Load Balancer
1.6.6.1 Management Network
TOE guidance instructs the administrator to ensure that the Imperva WAF gateways connect to the MX
Management Server through an OOB management network. In this configuration, all WAF Gateway-to-
Management Server communication is carried over a dedicated and secure network that is completely
separated from production traffic.
Separation between the production traffic and the OOB management network is achieved by allocating
a separate (onboard) NIC for this purpose on WAF GWs. The WAF GWs operating system does not
bridge or route packets between production NICs and Management NICs.
Note that the connection to the MX or SOM using the Imperva GUI or via OpenAPI may be performed
through a potentially unsecure LAN network or using the OOB management network. Both possibilities
are allowed. In the first scenario the cryptographic functionality will protect the channel, while in the
second one another extra layer of security will be added through the use of the out of band network.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
12
1.6.7 Web Application Firewall Functionality
1.6.7.1 Network Traffic Data Collection Modes
WAF v14.7P20 collects and records network traffic using either the sniffing, inline, or reverse proxy
topologies described above. The traffic is analyzed using the TOE’s IDS functionality. This section
describes these different configurations.
1.6.7.1.1 Non-Inline (Sniffing)
When configured in sniffing topology, Imperva WAF is configured with one or more NICs in sniffing
mode. Sniffing mode allows the appliance to read all frames transmitted on the monitored network
segment. Frames picked up from the network are then passed to the appliance’s analysis and reaction
logic.
1.6.7.1.2 Inline (Bridge)
When configured in inline topology, WAF v14.7P20 appliances can be configured to bridge pairs of NICs.
When bridging, frames are picked up from one network segment, and if the destination MAC address
belongs to the paired segment, and the frame is not blocked by the analysis and reaction logic, the
frame is transmitted it on the paired segment. This mode is known as “Transparent Bridge”.
This traffic data collection mode has an optional feature that utilizes the reverse proxy mechanism and
is called Transparent Reverse Proxy (TRP) and can be found in the Administrative Guide under Reverse
Proxy (even though it is actually a bridge).
1.6.7.1.3 Transparent Reverse Proxy
When configured in inline topology, Imperva WAF appliances can be configured in Transparent Reverse
Proxy mode. Transparent Reverse Proxy Mode is similar to bridging; however, instead of processing
each individual frame, TCP segments are accumulated and the proxy processes complete HTTP
messages.
This data collection mode can be used in bridge mode. In this case it is known as “Transparent Reverse
Proxy in bridge mode.”
1.6.7.1.4 Reverse Proxy (NGRP)
In non-Transparent mode, the gateway is assigned an IP address, and HTTP clients proxy traffic through
the gateway. Reverse Proxy configurations are used to provide support for HTTP translation rules (e.g.,
URL rewriting). This mode is written completely in user space and uses OpenSSL v1.1.1n for
cryptography purposes.
1.6.7.1.5 Fail-Safe Modes
WAF 14.7P20 Gateway appliances in inline topology can be configured to either block all traffic in the
event of a software, hardware, or power failure, or to allow all traffic to pass transparently through the
gateway. By default, the TOE uses safe mode.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
13
1.6.7.2 Analysis and Reaction
Imperva WAF applies different layers of intrusion detection logic to analyzed network traffic. Some of
these layers are applicable to all network traffic; some are relevant only for Web traffic. In addition,
Imperva’s Correlated Attack Validation (CAV) technology examines sequences of events and identifies
suspicious traffic based on a correlation of multiple analysis layers. Identified malicious traffic is blocked.
Imperva WAF supports the following blocking methods:
● TCP Reset (sniffing topology): Imperva WAF can signal protected servers to disconnect malicious
users using TCP reset, a special TCP packet that signals TCP peers to close the TCP session.
Imperva WAF spoofs a TCP reset packet and sends it to the protected server. It is assumed that a
standards-conformant server would immediately drop the attacker’s session on receipt of the
TCP reset packet. Note: TCP reset is considered inferior to inline blocking (see below) because
it does not actively block the malicious traffic from reaching the server; blocking depends on the
server’s correct and timely session termination behavior.
● Inline Blocking: the WAF appliance drops the packet, so that it doesn’t reach its intended
destination, and sends a TCP reset to the server. Note: When Imperva WAF blocks a web
connection, it can be configured to display an error page to the blocked user.
● Reverse Proxy Blocking: the WAF drops the packet and closes the connection with the server. To
the blocked client, the WAF will send a pre-defined HTML error page and then close the
connection.
1.7 TOE Documentation
The physical boundary includes the following guidance documentation.
ï‚· Imperva 14.7 WAF Administration Guide, version 1, May 2023
ï‚· Imperva 14.7 WAF Management Server Manager User Guide, version 1, May 2023
ï‚· Imperva 14.7 WAF API Reference Guide, version 1, May 2023
ï‚· Imperva Application Firewall User Guide, version 1, May 2023
ï‚· Imperva WAF GW 14.7 Evaluated Configuration Guidance v1.2, 2023-07-17
ï‚· Imperva v14.7 WAF System Events Reference Guide, Version 1, May 2023
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
14
2 Security Problem Definition
2.1 Introduction
This section describes the security aspects of the operational environment and its expected use in said
environment. It includes the declaration of the TOE operational environment that identifies and
describes:
A. The TOE usage assumptions in the suggested operational environment.
B. The alleged known threats that will be countered by the TOE
C. The organizational security policies that the TOE must adhere to
2.2 Assumptions
This section contains assumptions regarding the security environment and the intended usage of the
TOE.
2.2.1 Intended Usage Assumptions
A.ACCESS The TOE has access to all the IT System data it needs to perform its functions.
A.ASCOPE The TOE is appropriately scalable to the IT System the TOE monitors.
A.DYNMIC The TOE will be managed in a manner that allows it to appropriately address changes in
the IT System the TOE monitors.
A.TIME The NTP server configured in the TOE for synchronization must be accurate and reliable
so when the TOE acts as a server itself, it will provide good timestamps.
2.2.2 Physical Assumptions
A.LOCATE The processing resources of the TOE will be located within controlled access facilities,
which will prevent unauthorized physical access.
A.PROTCT The TOE hardware and software critical to security policy enforcement will be protected
from unauthorized physical modification.
2.2.3 Personnel Assumptions
A.NOEVIL The authorized administrators are not careless, willfully negligent, or hostile, and will
follow and abide by the instructions provided by the TOE documentation.
A.NOTRST The TOE can only be accessed by authorized users.
A.MANAGE There will be one or more competent individuals assigned to manage the TOE and the
security of the information it contains.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
15
2.3 Threats
This section identifies and describes the threats to be countered by the TOE and its operational
environment. Threats are identified for the TOE and the IT System the TOE monitors. The TOE itself has
threats and the TOE is also responsible for addressing threats to the environment in which it resides.
2.3.1 TOE Threats
T.COMDIS An unauthorized user may attempt to disclose the data collected and produced by the
TOE by bypassing a security mechanism.
T.COMINT An unauthorized user may attempt to compromise the integrity of the data collected
and produced by the TOE by bypassing a security mechanism.
T.FACCNT An unauthorized user’s attempts to access TOE data or security functions goes
undetected.
T.IMPCON An unauthorized user may inappropriately change the configuration of the TOE causing
potential intrusions of the monitored IT System to go undetected.
T.INFLUX An unauthorized user may cause malfunction of the TOE by creating an influx of data
that the TOE cannot handle.
T.LOSSOF An unauthorized user may attempt to remove or destroy data collected and produced
by the TOE.
T.NOHALT An unauthorized user may attempt to compromise the continuity of the TOE’s collection
and analysis functions by halting execution of the TOE.
T.PRIVIL An unauthorized user may gain access to the TOE and exploit system privileges to gain
access to TOE security functions and data
2.3.2 IT System Threats
The following identifies threats to the IT System that may be indicative of vulnerabilities in or misuse of
IT resources.
T.FALACT The TOE may fail to react to identified or suspected vulnerabilities or inappropriate
activity, allowing unauthorized or malicious users to exploit vulnerabilities in the
monitored IT System or gain unauthorized access to protected data.
T.FALASC The TOE may fail to identify vulnerabilities or inappropriate activity based on association
of IDS data received from all data sources, allowing unauthorized or malicious users to
exploit vulnerabilities in the monitored IT System or gain unauthorized access to
protected data.
T.FALREC The TOE may fail to recognize vulnerabilities or inappropriate activity based on IDS data
received from each data source, allowing unauthorized or malicious users to exploit
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
16
vulnerabilities in the monitored IT System or gain unauthorized access to protected
data.
T.INADVE Inadvertent activity and access may occur on an IT System the TOE monitors, allowing
careless or unauthorized users to access or adversely manipulate protected data
undetected.
T.MISUSE Undetected authorized accesses and activity indicative of misuse may occur on an IT
System the TOE monitors, allowing unauthorized or malicious users to exploit
weaknesses in the system or gain unauthorized access to protected data.
T.SCNVUL Vulnerabilities may exist in the IT System the TOE monitors, allowing unauthorized or
malicious users to exploit weaknesses in the system or gain unauthorized access to
protected data.
2.4 Organizational Security Policies
The organizational security policies are defined as follows.
P.ACCACT Users of the TOE shall be accountable for their actions within the IDS.
P.ACCESS All data collected and produced by the TOE shall only be used for authorized purposes.
P.ANALYZ Analytical processes and information to derive conclusions about intrusions (past,
present, or future) must be applied to IDS data and appropriate response actions taken.
P.INTGTY Data collected and produced by the TOE shall be protected from modification.
P.MANAGE The TOE shall only be managed by authorized users.
P. PROTCT The TOE shall be protected from unauthorized accesses and disruptions of TOE data
and functions.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
17
3 Security Objectives
This section identifies the security objectives for the TOE and its operational environment. The security
objectives identify the responsibilities of the TOE and its environment in addressing the security
problem defined in Section 2.
3.1 Security Objectives for the TOE
The TOE must satisfy the following objectives.
O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and
data.
O.AUDITS The TOE must record audit records for data accesses and use of the System
functions.
O.AUDIT_PROT The TOE must provide the capability to protect audit information
O.AUDIT_SORT The TOE must provide the capability to sort the audit information
O.EADMIN The TOE must include a set of functions that allow effective management of its
functions and data.
O.IDANLZ The TOE must collect system data and then apply analytical processes and
information to derive conclusions about intrusions (past, present, or future).
O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to
TOE functions and data.
O.IDSCAN The TOE must collect and store system data information that might be indicative of
the potential for a future intrusion or the occurrence of a past intrusion of an IT
System.
O.SDC The TOE must collect and store information about all events that are indicative of
inappropriate activity that may have resulted from misuse, access, or malicious
activity of IT System assets and the IDS.
O.INTEGR The TOE must ensure the integrity of all audit and System data.
O.OFLOWS The TOE must appropriately handle potential audit and System data storage
overflows.
O.PROTCT The TOE must protect itself from unauthorized modifications and access to its
functions and data.
O.RESPON The TOE must respond appropriately to analytical conclusions.
O.TIME The TOE must provide a reliable time source.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
18
3.2 Security Objectives for the Operational Environment
The following are the security objectives for the operational environment of the TOE:
OE.CREDEN Those responsible for the TOE must ensure that all access credentials are protected
by the users in a manner which is consistent with IT security.
OE.INSTAL Those responsible for the TOE must ensure that the TOE is delivered, installed,
managed, and operated in a manner which is consistent with IT security.
OE.INTROP The TOE is interoperable with the IT System it monitors.
OE.PERSON Personnel working as authorized administrators shall be carefully selected with
competency and trustworthiness in mind and trained for proper operation of the
System.
OE.PHYCAL Those responsible for the TOE must ensure that the software of the TOE and the
hardware where it runs is protected from any physical attack, including
administrator workstations and OOB network.
OE.TIME The IT Environment (external NTP server and hardware clock sources) will provide
reliable timestamps to the TOE.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
19
4 Extended Components Definition
This ST defines the following extended components for use within this ST.
4.1 Class FAU: Security audit
Security auditing involves recognizing, recording, storing, and analyzing information related to security
relevant activities (i.e. activities controlled by the TSF). The resulting audit records can be examined to
determine which security relevant activities took place and whom (which user) is responsible for them.
4.1.1 Security audit event storage (FAU_STG)
Family behaviour
This family defines the requirements for the TSF to be able to create and maintain a secure audit trail.
Stored audit records refers to those records within the audit trail, and not the audit records that have
been retrieved (to temporary storage) through selection.
Component levelling
This requirement allows defining mechanisms that allow exporting or purging of audit data in manual or
scheduled ways.
Management: FAU_STG.5
There are no management activities foreseen.
Audit: FAU_STG.5
There are no auditable events foreseen.
FAU_STG.5 Audit export and purge
Hierarchical to:
No other components.
Dependencies:
FAU_GEN.1
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
20
FAU_STG.5.1 The TSF shall enable [selection: manual, scheduled] [selection: archiving, purging] of
audit data.
4.2 Class FCS: Cryptographic support
The TSF may employ cryptographic functionality to help satisfy several high-level security objectives.
These include (but are not limited to): identification and authentication, non-repudiation, trusted path,
trusted channel and data separation. This class is used when the TOE implements cryptographic
functions, the implementation of which could be in hardware, firmware and/or software.
The FCS class is composed of two families: FCS_CKM and FCS_COP. The FCS_CKM family addresses the
management aspects of cryptographic keys, while the FCS_COP family is concerned with the operational
use of those cryptographic keys.
This class is extended to satisfy security objectives that pertain to secure handling, transport and
disposal of sensitive IDS target systems data. These include protection of data related to the systems
that the IDS protects or audits and ensuring that the data is available to the appropriate personnel.
4.2.1 HTTPS (FCS_HTT)
Family behaviour
The requirements of this family ensure that the TSF will implement the HTTPS protocol in accordance
with an approved cryptographic standard.
Component leveling
This SFR requires the TOE to implement HTTPS in accordance with a defined standard.
Management: FCS_HTT.1
There are no management activities foreseen.
Audit: FCS_HTT.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
a) Basic: Failure to establish a session.
b) Basic: Establishment/termination of a session.
FCS_HTT.1: HTTPS
Hierarchical to:
No other components.
Dependencies:
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
21
FCS_TLS.1
FCS_HTT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTT.1.2 The TSF shall implement HTTPS using TLS as specified in FCS_TLS.1.
4.2.2 Random Bit Generation (FCS_RBG)
Family behaviour
The requirements of this family ensure that the TSF will generate random numbers in accordance with
an approved cryptographic standard.
Component leveling
This SFR requires the TOE to perform random bit generation in accordance with a defined standard.
Management: FCS_RBG.1
There are no management activities foreseen.
Audit: FCS_RBG.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
a) Basic: Failure of the randomization process.
FCS_RBG Random Bit Generation
Hierarchical to:
No other components.
Dependencies:
No dependencies.
FCS_RBG.1.1 The TSF shall perform all random bit generation (RBG) services in accordance with
[selection, choose one of: NIST Special Publication 800-90 using Hash_DRBG (any),
NIST Special Publication 800-90 using HMAC_DRBG (any), NIST Special Publication
800-90 using CTR_DRBG (AES), FIPS Pub 140-2 Annex C: X9.31 Appendix 2.4 using AES]
seeded by an entropy source that accumulates entropy from [selection, choose one of:
a software-based noise source, a TSF-hardware-based noise source].
FCS_RBG.1.2 The deterministic RBG shall be seeded with a minimum of [selection, choose one of:
128 bits, 256 bits] of entropy at least equal to the greatest bit length of the keys and
authorization factors that it will generate.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
22
4.2.3 TLS (FCS_TLS)
Family behaviour
The requirements of this family ensure that the TSF will implement the TLS protocol in accordance with
an approved cryptographic standard.
Component leveling
This SFR requires the TOE to implement TLS in accordance with a defined standard.
Management: FCS_TLS.1
There are no management activities foreseen.
Audit: FCS_TLS.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
a) Basic: Failure to establish a session.
b) Basic: Establishment/termination of a session.
FCS_TLS.1 TLS
Hierarchical to:
No other components.
Dependencies:
FCS_COP.1
FCS_TLS.1.1 The TSF shall implement one or more of the following protocols [selection: TLS 1.0 (RFC
2246), TLS 1.1 (RFC 4346), TLS 1.2 (RFC 5246), TLS1.3 (RFC 8446)] supporting the
following ciphersuites: [assignment (ciphersuite supported)].
4.3 Class IDS: Intrusion Detection System
Introduction
This class is used to satisfy security objectives that pertain to intrusion detection and prevention
(IDS/IPS) systems. These include data collection and analysis, automatic reaction capabilities, review,
and IDS data analysis (IDS_ANL).
Informative notes
A class of IDS requirements was created to specifically address the data collected and analyzed by an
IDS. The audit class of the CC (FAU) was used as a model for creating these requirements. The purpose
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
23
of this class of requirements is to address the unique nature of IDS data and provide for requirements
about collecting, reviewing, and managing the data.
4.3.1 IDS data analysis (IDS_ANL)
Family behaviour
This family defines requirements for automated means that analyze IDS System data looking for possible
or real security violations. The actions to be taken based on the detection can be specified using the IDS
reaction (IDS_RCT) family as desired.
Component leveling
In IDS_ANL.1 Analyser analysis, statistical, signature, or integrity-based analysis is required.
Management: IDS_ANL.1
The following actions could be considered for the management functions in FMT:
a) maintenance (deletion, modification, addition) of the parameters of the analytical functions.
Audit: IDS_ANL.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
b) Minimal: Enabling and disabling of any of the analysis mechanisms.
IDS_ANL.1 IDS data analysis
Hierarchical to:
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
24
No other components.
Dependencies:
IDS_SDC.1
IDS_ANL.1.1: The System shall perform the following analysis function(s) on all IDS data received:
a) [selection: statistical, signature, integrity] ; and
b) [assignment: any other analytical functions].
IDS_ANL.1.2: The System 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: any other security relevant information about the result].
4.3.2 IDS reaction (IDS_RCT)
Family behaviour
This family defines the response to be taken in case when an intrusion is detected.
Component leveling
At IDS_RCT.1 IDS reaction, the TSF shall send an alarm and take action when an intrusion is detected.
Management: IDS_RCT.1
The following actions could be considered for the management functions in FMT:
a) the management (addition, removal, or modification) of actions.
Audit: IDS_RCT.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
a) Minimal: Actions taken due to detected intrusions.
IDS_RCT.1 IDS reaction
Hierarchical to:
No other components.
Dependencies:
IDS_ANL.1
IDS_RCT.1.1 The System shall send an alarm to [assignment: alarm destination] and take
[assignment: appropriate actions] when an intrusion is detected.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
25
4.3.3 IDS data review (IDS_RDR)
Family behaviour
This family defines the requirements for tools that should be available to authorised users to assist in
the review of IDS System data.
Component leveling
IDS data review, provides the capability to read information from the System data and requires that
there are no other users except those that have been identified as authorised users that can read the
information.
Management: IDS_RDR.1
The following actions could be considered for the management functions in FMT:
a) maintenance (deletion, modification, addition) of the group of users with read access right
to the System data.
Audit: IDS_RDR.1
The following actions should be auditable if FAU_GEN is included in the PP/ST:
a) Basic: Reading of information from the System data.
b) Basic: Unsuccessful attempts to read information from the System data.
IDS_RDR.1 IDS data review
Hierarchical to:
No other components.
Dependencies:
IDS_SDC.1
IDS_RDR.1.1 The System shall provide [assignment: authorised users] with the capability to read
[assignment: list of System data] from the System data.
IDS_RDR.1.2 The System shall provide the System data in a manner suitable for the user to interpret
the information.
IDS_RDR.1.3 The System shall prohibit all users read access to the System data, except those users
that have been granted explicit read access.
4.3.4 IDS data collection (IDS_SDC)
Family behaviour
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
26
This family defines requirements for recording information from the targeted IT System resource(s).
Component leveling
IDS data collection defines the information to be collected from the targeted IT System resource(s), and
specifies the data that shall be recorded in each record.
Management: IDS_SDC.1
There are no management activities foreseen.
Audit: IDS_SDC.1
There are no auditable events foreseen.
IDS_SDC.1 IDS data collection
Hierarchical to:
No other components.
Dependencies:
FPT_STM.1
IDS_SDC.1.1 The System shall be able to collect the following information from the targeted IT
System resource(s):
a) [selection: Start-up and shutdown, identification and authentication events, data
accesses, service requests, network traffic, security configuration changes, data
introduction, detected malicious code, access control configuration, service
configuration, authentication configuration, accountability, policy configuration,
detected known vulnerabilities]; and
b) [assignment: other specifically defined events].
IDS_SDC.1.2 At a minimum, the System shall collect and record 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) [assignment: other additional information].
4.3.5 IDS data storage (IDS_STG)
Family behaviour
This family defines requirements for protecting IDS System data after it is recorded and stored by the
TOE.
Component leveling
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
27
Guarantees of System data availability, specifies the guarantees that the TSF maintains over the system
data given the occurrence of an undesired condition.
Prevention of System data loss specifies actions in case of exceeded storage capacity.
Management: IDS_STG.1
The following actions could be considered for the management functions in FMT:
a) maintenance of the parameters that control the System data storage capability.
Management: IDS_STG.2
The following actions could be considered for the management functions in FMT:
a) maintenance (deletion, modification, addition) of the actions to be taken in case of storage
failure.
Audit: IDS_STG.1, IDS_STG.2
There are no auditable events foreseen.
IDS_STG.1 Guarantees of System data availability
Hierarchical to:
No other components.
Dependencies:
IDS_SDC.1
IDS_STG.1.1 The System shall protect the stored System data from unauthorized deletion.
IDS_STG.1.2 The System shall protect the stored System data from modification.
IDS_STG.1.3 The System shall ensure that [assignment: metric for saving System data] System data
will be maintained when the following conditions occur: [selection: System data
storage exhaustion, failure, attack].
IDS_STG.2 Prevention of System data loss
Hierarchical to:
No other components.
Dependencies:
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
28
IDS_STG.1
IDS_STG.2.1: The System shall [selection: ‘ignore System data’, ‘prevent System data, except those
taken by the authorised user with special rights’, ‘overwrite the oldest stored System
data’] and [assignment: other actions to be taken in case of storage failure] if the
storage capacity has been reached.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
29
5 Security Requirements
This section specifies the security functional requirements (SFRs) for the TOE. SFRs were drawn from
Part 2 of the Common Criteria v3.1 Revision 5, and from the extended components defined in Section
4.3 above.
5.1 TOE Security Functional Requirements
Table 3: TOE Security Functional Components
Requirement Class Requirement Component
FAU: Security audit FAU_GEN.1 Audit data generation
FAU_SAR.1 Audit review
FAU_SAR.2 Restricted audit review
FAU_SAR.3 Selectable audit review
FAU_STG.2 Guarantees of audit data availability
FAU_STG.4 Prevention of audit data loss
FAU_STG.5 Audit export and purge
FCS: Cryptographic support FCS_CKM.1 Cryptographic key generation
FCS_CKM.2 Cryptographic key distribution
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FCS_HTT.1 HTTPS
FCS_RBG.1(1) Random Bit Generation (WAF Gateway)
FCS_RBG.1(2) Random Bit Generation (Management Server)
FCS_TLS.1(1) TLS (Traffic Connections)
FCS_TLS.1(2) TLS (HTTP GUI)
FCS_TLS.1(3) TLS (ADC Content)
FCS_TLS.1(4) TLS (Inter-TOE)
FIA: Identification and
authentication
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
FMT: Security management FMT_MOF.1 Management of security functions behaviour
FMT_MTD.1 Management of TSF data
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
30
Requirement Class Requirement Component
FPT: Protection of the TSF FPT_ITT.1 Basic internal TSF data transfer protection
FPT_STM.1 Reliable time stamps
FTP: Trusted path/channels FTP_ITC.1 Inter-TSF trusted channel
FTP_TRP.1 Trusted path
IDS: Intrusion Detection IDS_ANL.1 IDS Analyser analysis
IDS_RCT.1 IDS Analyser react
IDS_RDR.1 IDS Restricted data review
IDS_SDC.1 IDS System data collection
IDS_STG.1 Guarantees of System data availability
IDS_STG.2 Prevention of System data loss
5.1.1 Security Audit (FAU)
5.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 shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit; and
c) [
ï‚· All configuration changes. This includes all actions (CUD = Create, Update,
Delete) on all entities (policies, users, roles, authentication schema,
authorization schema, permissions, access or communication keys, certificates,
lists of signatures, lists of IP addresses).
ï‚· Export of information from WAF.
ï‚· Purge of information.
 All actions related to patch and version changes – availability of a new version,
installation on a machine, failure to install.
ï‚· WAF deployment changes.
ï‚· Failover events, MXs registration and removal from SOM, adding or removing
gateways, gateway move within group/cluster or out of it.
 All actions related to users and permissions – including the above (CUD) – and
also accessing these screens.
ï‚· Access to the audit screens.
].
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
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
31
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, [none].
5.1.1.2 FAU_SAR.1 Audit review
FAU_SAR.1.1 The TSF shall provide [Administrators with appropriate permissions] with the capability
to read [all audit information] from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to interpret the
information.
5.1.1.3 FAU_SAR.2 Restricted audit review
FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that
have been granted explicit read-access.
5.1.1.4 FAU_SAR.3 Selectable audit review
FAU_SAR.3.1 The TSF shall provide the ability to apply [sorting] of audit data based on [date and time,
subject identity, type of event, and success or failure of related event].
5.1.1.5 FAU_STG.2 Guarantees of audit data availability
FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from unauthorised
deletion.
FAU_STG.2.2 The TSF shall be able to [prevent] unauthorised modifications to the stored audit
records in the audit trail.
FAU_STG.2.3 The TSF shall ensure that [an administrator-configurable number of] stored audit
records will be maintained when the following conditions occur: [audit storage
exhaustion].
5.1.1.6 FAU_STG.4 Prevention of audit data loss
FAU_STG.4.1 The TSF shall [“overwrite the oldest stored audit records”] and [send an alarm] if the
audit trail is full.
5.1.1.7 FAU_STG.5 Audit export and purge
FAU_STG.5.1 The TSF shall enable [manual, scheduled] [archiving, purging] of audit data.
5.1.2 Cryptographic Support (FCS)
5.1.2.1 FCS_CKM.1 Cryptographic key generation
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm [IFC Key Pair Generation, ECC Key Pair Generation] and
specified cryptographic key sizes [2048 or more bits for IFC Key Pairs; 256, 384 or 521
bits for ECC Key Pairs] that meet the following: [FIPS PUB 186-4, “Digital Signature
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
32
Standard (DSS)” Appendix B.3; FIPS PUB 186-4, “Digital Signature Standard (DSS)
Appendix B.4].
5.1.2.2 FCS_CKM.2 Cryptographic key distribution
FCS_CKM.2.1 The TSF shall establish distribute cryptographic keys in accordance with a specified
cryptographic key establishment distribution method [FFC Schemes using “safe-prime”
groups, elliptic curve schemes] that meets the following: [NIST Special Publication 800-
56A Revision 3, “Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography”; NIST Special Publication 800-56A Revision 3,
“Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography, and groups listed in RFC 3526].
5.1.2.3 FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method [overwriting with zeroes] that meets the following: [FIPS 140-2
level 1].
5.1.2.4 FCS_COP.1 Cryptographic operation (symmetric cryptography)
FCS_COP.1.1 The TSF shall perform [the cryptographic operations listed in the table below] in
accordance with a specified cryptographic algorithm [listed in the table below] and
cryptographic key sizes [listed in the table below] that meet the following: [FIPS 140-2
level 1 and the standards identified in the table below].
Table 4: Cryptographic Operations
Operation Algorithm Key Size Standard
encryption and decryption AES-CBC, AES-GCM 128 and 256 bits AES as specified in ISO
18033-3, CBC as specified in
ISO 10116, CTR as specified
in ISO 10116, GCM as
specified in ISO 19772
AES-CTR 128, 192 and 256
bits
cryptographic signature
services
RSA Digital Signature
Algorithm (rDSA)
2048 bits or
greater
FIPS Pub 186-4, “Digital
Signature Standard (DSS)”,
Section 5.5, using PKCS #1
v2.1 Signature Schemes
RSASSA-PSS and/or RSASSA-
PKCS1v1_5
Elliptic Curve Digital
Signature Algorithm
(ECDSA)
256, 384 and 521
bits
FIPS PUB 186-4, “Digital
Signature Standard (DSS)”,
Section 6 and Appendix D;
ISO/IEC 14888-3, Section 6.4
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
33
Operation Algorithm Key Size Standard
cryptographic hashing
services
SHA-1, SHA-256, SHA-
384, SHA-512
160, 256, 384 and
512 bits
FIPS Pub 180-4, ‘Secure Hash
Standard.’
keyed-hash message
authentication
HMAC-SHA-1, HMAC-
SHA-256, HMAC-SHA-
384, HMAC-SHA-512
160, 256, 384 and
512 bits
FIPS Pub 198-1, ‘The Keyed-
Hash Message
Authentication Code’, and
FIPS Pub 180-4, ‘Secure Hash
Standard.’
5.1.2.5 FCS_HTT.1 HTTPS
FCS_HTT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTT.1.2 The TSF shall implement HTTPS using TLS as specified in FCS_TLS.1.
5.1.2.6 FCS_RBG.1(1): Random Bit Generation (WAF Gateway)
FCS_RBG.1.1(1) The TSF shall perform all random bit generation (RBG) services in accordance with
[NIST Special Publication 800-90 using CTR_DRBG (AES)] seeded by an entropy source
that accumulates entropy from [a software-based noise source].
FCS_RBG.1.2(1) The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at
least equal to the greatest bit length of the keys and authorization factors that it will
generate.
Application note: Iteration (1) applies to the WAF Gateway.
5.1.2.7 FCS_RBG.1(2): Random Bit Generation (Management Server)
FCS_RBG.1.1(2) The TSF shall perform all random bit generation (RBG) services in accordance with
[NIST Special Publication 800-90 using HMAC DRBG (any)] seeded by an entropy source
that accumulates entropy from [a TSF-hardware-based noise source].
FCS_RBG.1.2(2) The deterministic RBG shall be seeded with a minimum of [256 bits] of entropy at
least equal to the greatest bit length of the keys and authorization factors that it will
generate.
Application note: Iteration (2) applies to the Management Server.
5.1.2.8 FCS_TLS.1(1): TLS (Traffic Connections)
FCS_TLS.1.1(1) The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246),
TLS.1.3 (RFC 8446)] supporting the following ciphersuites: [
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA,
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA256,
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
34
ï‚· TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
ï‚· TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
ï‚· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
ï‚· TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384].
Application note: Iteration (1) applies to the traffic connections in reverse proxy mode.
5.1.2.9 FCS_TLS.1(2): TLS (HTTP GUI)
FCS_TLS.1.1(2) The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246)]
supporting the following ciphersuites: [
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA,
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA].
Application note: Iteration (2) applies to the HTTPS GUI connection.
5.1.2.10 FCS_TLS.1(3): TLS (ADC Content)
FCS_TLS.1.1(3) The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246)]
supporting the following ciphersuites: [
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA,
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA256,
ï‚· TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
ï‚· TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
ï‚· TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
ï‚· TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
ï‚· TLS_DHE_DSS_WITH_AES_256_CBC_SHA].
Application note: Iteration (3) applies to the ADC Content update connection.
5.1.2.11 FCS_TLS.1(4): TLS (Inter-TOE)
FCS_TLS.1.1(4) The TSF shall implement one or more of the following protocols [TLS 1.2 (RFC 5246)]
supporting the following ciphersuites: [
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA
ï‚· TLS_RSA_WITH_AES_128_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA256,
ï‚· TLS_RSA_WITH_AES_256_CBC_SHA,
ï‚· TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
ï‚· TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384].
Application note: Iteration (4) applies to the inter-TOE communications.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
35
5.1.3 Identification and Authentication (FIA)
5.1.3.1 FIA_ATD.1 User Attribute Definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual
users: [user identity, authentication data, and authorisations].
5.1.3.2 FIA_UAU.2 User authentication before any action
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
5.1.3.3 FIA_UID.2 User identification before any action
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other
TSF-mediated actions on behalf of that user.
5.1.4 Security Management (FMT)
5.1.4.1 FMT_MOF.1 Management of security functions behaviour
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions [System data
collection, analysis and reaction] to [authorised System administrators].
5.1.4.2 FMT_MTD.1 Management of TSF Data
FMT_MTD.1.1 The TSF shall restrict the ability to [query, modify, [add]] the [System data, audit data
and other TOE data] to [users with the authorisations as specified in FMT_SMF.1].
5.1.4.3 FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [specified
in the following table].
Table 5: Specification of Management Functions
SFR Management Function Required Authorisations Management Functionality
FMT_MOF.1 Modify the behaviour of the
functions of System data
collection, analysis and
reaction
Authorised System
administrator
Authorised System administrators
use the Imperva GUI or via OpenAPI
interface to modify Server Group
definitions, define Action Interfaces
and Action Policies, configure
Security Rules for each Server
Group, enable collection, analysis
and reaction capabilities, and
manage Profiles and Signatures.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
36
SFR Management Function Required Authorisations Management Functionality
FMT_MTD.1 Query audit data Authorized administrator
with appropriate
permissions
Audit records are stored as System
Events and may be reviewed using
the Imperva GUI or via OpenAPI.
Format or as System Events
reports.
Query and add System data Authorised administrator
with View permission on
applicable objects
Authorised administrators can use
the WAF GUI or via OpenAPI
interface to review System data for
which they have View permission,
to update Profiles and Signatures
and to invoke assessments.
Query (export) and modify
(create, delete, import)
audit archive protection
keys
Authorised administrator
with Settings permission
Authorised administrators with
Settings permission can use the
OpenAPI or Imperva GUI interface
to create, delete, import and export
and to set the default RSA keys
used for signing and encrypting
archived audit data.
Query and modify all other
(non-System and audit) TOE
data
Authorised administrator Authorised administrators can use
the OpenAPI or WAF GUI interface
for reviewing and modifying all
other TOE data (e.g., jobs or tasks).
FMT_SMR.1 Modify the group of users
that are part of a Imperva
WAF role
Authorised System
administrator
Imperva GUI or via OpenAPI
allows authorised administrators
belonging to the Administrators
group with access to the Users and
Roles screen, providing the ability
to add, edit, and delete user
accounts, and reset their
passwords.
5.1.4.4 FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles [authorised System administrators (main System
administrator user assigned when first logging to the web), and authorised
administrators with one or more of the authorisations identified in FMT_SMF.1].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.1.5 Protection of the TSF (FPT)
5.1.5.1 FPT_ITT.1 Basic internal TSF data transfer protection
FPT_ITT.1.1 The TSF shall protect TSF data from [disclosure, modification] when it is transmitted
between separate parts of the TOE.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
37
5.1.5.2 FPT_STM.1 Reliable time stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Application note: This SFR is implemented by the TOE using an NTP server used by the MX Management Server
which provides reliable timestamps to its WAF GWs.
5.1.6 Trusted Path/Channels (FTP)
5.1.6.1 FTP_ITC.1 Inter-TSF Trusted Channel
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted IT
product that is logically distinct from other communication channels and provides
assured identification of its end points and protection of the channel data from
modification or disclosure.
FTP_ITC.1.2 The TSF shall permit [the TSF] to initiate communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [ADC Content].
5.1.6.2 FTP_TRP.1 Trusted path
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [remote] users that is
logically distinct from other communication paths and provides assured identification of
its end points and protection of the communicated data from [modification, disclosure].
FTP_TRP.1.2 The TSF shall permit [remote users] to initiate communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [initial user authentication, [all
subsequent user interactions]].
5.1.7 Intrusion Detection (IDS)
5.1.7.1 IDS_ANL.1 IDS data analysis
IDS_ANL.1.1 The System shall perform the following analysis function(s) on all IDS data received: a)
[signature, integrity] ; and b) [Matching traffic with ThreatRadar Block Lists, Protocol
violations, Profile violations, Correlated Attack Validation].
IDS_ANL.1.2 The System 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)
[destination server Group and username].
5.1.7.2 IDS_RCT.1 IDS reaction
IDS_RCT.1.1 The System shall send an alarm to [MX Server, syslog server, SNMP trap] and take
[action to block and/or monitor application network traffic] when an intrusion is
detected.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
38
5.1.7.3 IDS_RDR.1 IDS data review
IDS_RDR.1.1 The System shall provide [authorized Administrators] with the capability to read [Alerts,
audit records, collected application profiles, System configuration and Gateway Status]
from the System data.
IDS_RDR.1.2 The System shall provide the System data in a manner suitable for the user to interpret
the information.
IDS_RDR.1.3 The System shall prohibit all users read access to the System data, except those users
that have been granted explicit read access.
5.1.7.4 IDS_SDC.1 IDS data collection
IDS_SDC.1.1 The System shall be able to collect the following information from the targeted IT
System resource(s): [service requests, network traffic, detected known vulnerabilities] ;
and b) [none].
IDS_SDC.1.2 At a minimum, the System shall collect and record 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) [The additional information specified in the following table].
Table 5: System Data Collection Events and Details
Event Details
Service requests Specific service, source address, destination address
Network traffic Protocol, source address, destination address
Detected known vulnerabilities Identification of the known vulnerability
5.1.7.5 IDS_STG.1 Guarantees of System data availability
IDS_STG.1.1 The System shall protect the stored System data from unauthorised deletion.
IDS_ STG.1.2 The System shall protect the stored System data from modification.
IDS_ STG.1.3 The System shall ensure that [250,000 Alert records] System data will be maintained
when the following conditions occur: [System data storage exhaustion].
5.1.7.6 IDS_STG.2 Prevention of System data loss
IDS_STG.2.1 The System shall [‘overwrite the oldest stored System data’] and [send an alarm,
backup and purge the older 250000 records] if the storage capacity has been reached.
Application Note: The TOE keeps two tables of 250000 records each, so when it exhausts – it has 500000 records it
backs up the older 250000 and purge them.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
39
5.2 TOE Security Assurance Requirements
The security assurance requirements for the TOE are the EAL2 augmented with ALC_FLR.1 Basic flaw
remediation components as specified in Part 3 of the Common Criteria. No operations are applied to the
assurance components. The assurance requirements are identified in the following table. These
requirements reference Part 3 of the Common Criteria for Information Technology Security Evaluation.
The TOE meets the assurance requirements for EAL2 augmented by ALC_FLR.2.
Table 6: Assurance Components
Requirement Class Requirement Component
ADV: Development ADV_ARC.1: Security architecture description
ADV_FSP.2: Security-enforcing functional specification
ADV_TDS.1: Basic design
AGD: Guidance documents AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-cycle support ALC_CMC.2: Use of a CM system
ALC_CMS.2: Parts of the TOE CM coverage
ALC_DEL.1: Delivery procedures
ALC_FLR.1: Basic flaw remediation
ASE: Security Target evaluation ASE_CCL.1: Conformance claims
ASE_ECD.1: Extended components definition
ASE_INT.1: ST introduction
ASE_OBJ.2: Security objectives
ASE_REQ.2: Derived security requirements
ASE_SPD.1: Security problem definition
ASE_TSS.1: TOE summary specification
ATE: Tests ATE_COV.1: Evidence of coverage
ATE_FUN.1: Functional testing
ATE_IND.2: Independent testing – sample
AVA: Vulnerability assessment AVA_VAN.2: Vulnerability analysis
5.2.1 Development (ADV)
5.2.1.1 ADV_ARC.1 Security architecture description
ADV_ARC.1.1D The developer shall design and implement the TOE so that the security features of the
TSF cannot be bypassed.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
40
ADV_ARC.1.2D The developer shall design and implement the TSF so that it is able to protect itself
from tampering by untrusted active entities.
ADV_ARC.1.3D The developer shall provide a security architecture description of the TSF.
ADV_ARC.1.1C The security architecture description shall be at a level of detail commensurate with
the description of the SFR-enforcing abstractions described in the TOE design
document.
ADV_ARC.1.2C The security architecture description shall describe the security domains maintained
by the TSF consistently with the SFRs.
ADV_ARC.1.3C The security architecture description shall describe how the TSF initialisation process is
secure.
ADV_ARC.1.4C The security architecture description shall demonstrate that the TSF protects itself
from tampering.
ADV_ARC.1.5C The security architecture description shall demonstrate that the TSF prevents bypass
of the SFR-enforcing functionality.
ADV_ARC.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.1.2 ADV_FSP.2 Security-enforcing functional specification
ADV_FSP.2.1D The developer shall provide a functional specification.
ADV_FSP.2.2D The developer shall provide a tracing from the functional specification to the SFRs.
ADV_FSP.2.1C The functional specification shall completely represent the TSF.
ADV_FSP.2.2C The functional specification shall describe the purpose and method of use for all TSFI.
ADV_FSP.2.3C The functional specification shall identify and describe all parameters associated with
each TSFI.
ADV_FSP.2.4C For each SFR-enforcing TSFI, the functional specification shall describe the SFR-
enforcing actions associated with the TSFI.
ADV_FSP.2.5C For each SFR-enforcing TSFI, the functional specification shall describe direct error
messages resulting from processing associated with the SFR-enforcing actions.
ADV_FSP.2.6C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
specification.
ADV_FSP.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ADV_FSP.2.2E The evaluator shall determine that the functional specification is an accurate and
complete instantiation of the SFRs.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
41
5.2.1.3 ADV_TDS.1 Basic design
ADV_TDS.1.1D The developer shall provide the design of the TOE.
ADV_TDS.1.2D The developer shall provide a mapping from the TSFI of the functional specification to
the lowest level of decomposition available in the TOE design.
ADV_TDS.1.1C The design shall describe the structure of the TOE in terms of subsystems.
ADV_TDS.1.2C The design shall identify all subsystems of the TSF.
ADV_TDS.1.3C The design shall describe the behavior of each SFR-supporting or SFR non-interfering
TSF subsystem in sufficient detail to determine that it is not SFR-enforcing.
ADV_TDS.1.4C The design shall summarise the SFR-enforcing behavior of the SFR-enforcing
subsystems.
ADV_TDS.1.5C The design shall provide a description of the interactions among SFR-enforcing
subsystems of the TSF, and between the SFR-enforcing subsystems of the TSF and
other subsystems of the TSF.
ADV_TDS.1.6C The mapping shall demonstrate that all TSFIs trace to the behavior described in the
TOE design that they invoke.
ADV_TDS.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ADV_TDS.1.2E The evaluator shall determine that the design is an accurate and complete
instantiation of all security functional requirements.
5.2.2 Guidance Documents (AGD)
5.2.2.1 AGD_OPE.1 Operational user guidance
AGD_OPE.1.1D The developer shall provide operational user guidance.
AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user-accessible
functions and privileges that should be controlled in a secure processing environment,
including appropriate warnings.
AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the
available interfaces provided by the TOE in a secure manner.
AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available
functions and interfaces, in particular all security parameters under the control of the
user, indicating secure values as appropriate.
AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of
security-relevant event relative to the user-accessible functions that need to be
performed, including changing the security characteristics of entities under the control
of the TSF.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
42
AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE
(including operation following failure or operational error), their consequences and
implications for maintaining secure operation.
AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures
to be followed in order to fulfil the security objectives for the operational environment
as described in the ST.
AGD_OPE.1.7C The operational user guidance shall be clear and reasonable.
AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.2.2 AGD_PRE.1 Preparative procedures
AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.
AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure
acceptance of the delivered TOE in accordance with the developer’s delivery
procedures.
AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure
installation of the TOE and for the secure preparation of the operational environment
in accordance with the security objectives for the operational environment as
described in the ST.
AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be
prepared securely for operation.
5.2.3 Life-cycle Support (ALC)
5.2.3.1 ALC_CMC.2 Use of a CM system
ALC_CMC.2.1D The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.2.2D The developer shall provide the CM documentation.
ALC_CMC.2.3D The developer shall use a CM system.
ALC_CMC.2.1C The TOE shall be labelled with its unique reference.
ALC_CMC.2.2C The CM documentation shall describe the method used to uniquely identify the
configuration items.
ALC_CMC.2.3C The CM system shall uniquely identify all configuration items.
ALC_CMC.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
43
5.2.3.2 ALC_CMS.2 – Parts of the TOE CM coverage
ALC_CMS.2.1D The developer shall provide a configuration list for the TOE.
ALC_CMS.2.1C The configuration list shall include the following: the TOE itself; the evaluation
evidence required by the SARs; and the parts that comprise the TOE.
ALC_CMS.2.2C The configuration list shall uniquely identify the configuration items.
ALC_CMS.2.3C For each TSF relevant configuration item, the configuration list shall indicate the
developer of the item.
ALC_CMS.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.3.3 ALC_DEL.1 Delivery procedures
ALC_DEL.1.1D The developer shall document and provide procedures for delivery of the TOE or parts
of it to the consumer.
ALC_DEL.1.2D The developer shall use the delivery procedures.
ALC_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to
maintain security when distributing versions of the TOE to the consumer.
ALC_DEL.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.3.4 ALC_FLR.1 Basic flaw remediation
ALC_FLR.1.1D The developer shall document and provide flaw remediation procedures addressed to
TOE developers.
ALC_FLR.1.1C The flaw remediation procedures documentation shall describe the procedures
used to track all reported security flaws in each release of the TOE.
ALC_FLR.1.2C The flaw remediation procedures shall require that a description of the nature and
effect of each security flaw be provided, as well as the status of finding a
correction to that flaw.
ALC_FLR.1.3C The flaw remediation procedures shall require that corrective actions be identified
for each of the security flaws.
ALC_FLR.1.4C The flaw remediation procedures documentation shall describe the methods used
to provide flaw information, corrections and guidance on corrective actions to TOE
users.
ALC_FLR.1.1E The evaluator shall confirm that the information provided meets all requirements
for content and presentation of evidence.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
44
5.2.4 Security Target Evaluation (ASE)
5.2.4.1 ASE_CCL.1 Conformance claims
ASE_CCL.1.1D The developer shall provide a conformance claim.
ASE_CCL.1.2D The developer shall provide a conformance claim rationale.
ASE_CCL.1.1C The conformance claim shall contain a CC conformance claim that identifies the
version of the CC to which the ST and the TOE claim conformance.
ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 2 as
either CC Part 2 conformant or CC Part 2 extended.
ASE_CCL.1.3C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as
either CC Part 3 conformant or CC Part 3 extended.
ASE_CCL.1.4C The CC conformance claim shall be consistent with the extended components
definition.
ASE_CCL.1.5C The conformance claim shall identify all PPs and security requirement packages to
which the ST claims conformance.
ASE_CCL.1.6C The conformance claim shall describe any conformance of the ST to a package as
either package-conformant or package-augmented.
ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the TOE type is consistent
with the TOE type in the PPs for which conformance is being claimed.
ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of the security
problem definition is consistent with the statement of the security problem definition
in the PPs for which conformance is being claimed.
ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security
objectives is consistent with the statement of security objectives in the PPs for which
conformance is being claimed.
ASE_CCL.1.10C The conformance claim rationale shall demonstrate that the statement of security
requirements is consistent with the statement of security requirements in the PPs for
which conformance is being claimed.
ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.4.2 ASE_ECD.1 Extended components definition
ASE_ECD.1.1D The developer shall provide a statement of security requirements.
ASE_ECD.1.2D The developer shall provide an extended components definition.
ASE_ECD.1.1C The statement of security requirements shall identify all extended security
requirements.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
45
ASE_ECD.1.2C The extended components definition shall define an extended component for each
extended security requirement.
ASE_ECD.1.3C The extended components definition shall describe how each extended component is
related to the existing CC components, families, and classes.
ASE_ECD.1.4C The extended components definition shall use the existing CC components, families,
classes, and methodology as a model for presentation.
ASE_ECD.1.5C The extended components shall consist of measurable and objective elements such
that conformance or nonconformance to these elements can be demonstrated.
ASE_ECD.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ASE_ECD.1.2E The evaluator shall confirm that no extended component can be clearly expressed
using existing components.
5.2.4.3 ASE_INT.1 ST introduction
ASE_INT.1.1D The developer shall provide an ST introduction.
ASE_INT.1.1C The ST introduction shall contain an ST reference, a TOE reference, a TOE overview
and a TOE description.
ASE_INT.1.2C The ST reference shall uniquely identify the ST.
ASE_INT.1.3C The TOE reference shall uniquely identify the TOE.
ASE_INT.1.4C The TOE overview shall summarise the usage and major security features of the TOE.
ASE_INT.1.5C The TOE overview shall identify the TOE type.
ASE_INT.1.6C The TOE overview shall identify any non-TOE hardware/software/firmware required by
the TOE.
ASE_INT.1.7C The TOE description shall describe the physical scope of the TOE.
ASE_INT.1.8C The TOE description shall describe the logical scope of the TOE.
ASE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ASE_INT.1.2E The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE
description are consistent with each other.
5.2.4.4 ASE_OBJ.2 Security objectives
ASE_OBJ.2.1D The developer shall provide a statement of security objectives.
ASE_OBJ.2.2D The developer shall provide a security objectives rationale.
ASE_OBJ.2.1C The statement of security objectives shall describe the security objectives for the TOE
and the security objectives for the operational environment.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
46
ASE_OBJ.2.2C The security objectives rationale shall trace each security objective for the TOE back to
threats countered by that security objective and OSPs enforced by that security
objective.
ASE_OBJ.2.3C The security objectives rationale shall trace each security objective for the operational
environment back to threats countered by that security objective, OSPs enforced by
that security objective, and assumptions upheld by that security objective.
ASE_OBJ.2.4C The security objectives rationale shall demonstrate that the security objectives
counter all threats.
ASE_OBJ.2.5C The security objectives rationale shall demonstrate that the security objectives enforce
all OSPs.
ASE_OBJ.2.6C The security objectives rationale shall demonstrate that the security objectives for the
operational environment uphold all assumptions.
ASE_OBJ.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.4.5 ASE_REQ.2 Derived security requirements
ASE_REQ.2.1D The developer shall provide a statement of security requirements.
ASE_REQ.2.2D The developer shall provide a security requirements rationale.
ASE_REQ.2.1C The statement of security requirements shall describe the SFRs and the SARs.
ASE_REQ.2.2C All subjects, objects, operations, security attributes, external entities and other terms
that are used in the SFRs and the SARs shall be defined.
ASE_REQ.2.3C The statement of security requirements shall identify all operations on the security
requirements.
ASE_REQ.2.4C All operations shall be performed correctly.
ASE_REQ.2.5C Each dependency of the security requirements shall either be satisfied, or the security
requirements rationale shall justify the dependency not being satisfied.
ASE_REQ.2.6C The security requirements rationale shall trace each SFR back to the security objectives
for the TOE.
ASE_REQ.2.7C The security requirements rationale shall demonstrate that the SFRs meet all security
objectives for the TOE.
ASE_REQ.2.8C The security requirements rationale shall explain why the SARs were chosen.
ASE_REQ.2.9C The statement of security requirements shall be internally consistent.
ASE_REQ.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
47
5.2.4.6 ASE_SPD.1 Security problem definition
ASE_SPD.1.1D The developer shall provide a security problem definition.
ASE_SPD.1.1C The security problem definition shall describe the threats.
ASE_SPD.1.2C All threats shall be described in terms of a threat agent, an asset, and an adverse
action.
ASE_SPD.1.3C The security problem definition shall describe the OSPs.
ASE_SPD.1.4C The security problem definition shall describe the assumptions about the operational
environment of the TOE.
ASE_SPD.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.4.7 ASE_TSS.1 TOE summary specification
ASE_TSS.1.1D The developer shall provide a TOE summary specification.
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR.
ASE_TSS.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is consistent with the
TOE overview and the TOE description.
5.2.5 Tests (ATE)
5.2.5.1 ATE_COV.1 Evidence of coverage
ATE_COV.1.1D The developer shall provide evidence of the test coverage.
ATE_COV.1.1C The evidence of the test coverage shall show the correspondence between the tests in
the test documentation and the TSFIs in the functional specification.
ATE_COV.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.5.2 ATE_FUN.1 Functional testing
ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2D The developer shall provide test documentation.
ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and actual test
results.
ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the scenarios for
performing each test. These scenarios shall include any ordering dependencies on the
results of other tests.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
48
ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a successful
execution of the tests.
ATE_FUN.1.4C The actual test results shall be consistent with the expected test results.
ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
5.2.5.3 ATE_IND.2 Independent testing – sample
ATE_IND.2.1D The developer shall provide the TOE for testing.
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in
the developer’s functional testing of the TSF.
ATE_IND.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
ATE_IND.2.2E The evaluator shall execute a sample of tests in the test documentation to verify the
developer test results.
ATE_IND.2.3E The evaluator shall test a subset of the TSF to confirm that the TSF operates as
specified.
5.2.6 Vulnerability Assessment (AVA)
5.2.6.1 AVA_VAN.2 Vulnerability analysis
AVA_VAN.2.1D The developer shall provide the TOE for testing.
AVA_VAN.2.1C The TOE shall be suitable for testing.
AVA_VAN.2.1E The evaluator shall confirm that the information provided meets all requirements for
content and presentation of evidence.
AVA_VAN.2.2E The evaluator shall perform a search of public domain sources to identify potential
vulnerabilities in the TOE.
AVA_VAN.2.3E The evaluator shall perform an independent vulnerability analysis of the TOE using the
guidance documentation, functional specification, TOE design and security
architecture description to identify potential vulnerabilities in the TOE.
AVA_VAN.2.4E The evaluator shall conduct penetration testing, based on the identified potential
vulnerabilities, to determine that the TOE is resistant to attacks performed by an
attacker possessing Basic attack potential.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
49
6 TOE Summary Specification
This section describes the following security functions implemented by the TOE to satisfy the SFRs
claimed in Section 5.
6.1 FAU: Security audit
6.1.1 FAU_GEN.1
The MX Management Server hosts a database that is used for storing audit records (System Events), IDS
System data (Alerts), application Profiles, user attributes and configuration information.
The System Events Log includes activities related to
● changes to configuration,
● ADC content updates,
● activation of settings,
● building profiles,
● automatic profile updates,
● server start/stop,
● OpenAPI and GUI logins/logouts, and
● user administration operations.
For each event, the following attributes are recorded in the MX database on the MX Management
Server:
● Event Time: Date and time of the event.
● Sub System: The subsystem that generated the log entry, e.g., User, platform, ADC, security etc.
● Severity: One of: high, medium, low, info.
● Message: A description of the event. For administrator login events, this includes the user’s IP
address.
● User: The username that generated this event. If the event was generated by the WAF system,
the username is ‘System’.
Each system log record includes the following information: date and time of the event, type of event,
subject identity, Severity, and object IDs (primary URI) where applicable. Location is identified by the
administrator’s IP address. The outcome (success or failure) of the related event is implied from the
event Type.
The SOM administrator can pre-select System Event types that will be automatically forwarded from the
MX server to the SOM for storage and audit review by the SOM administrator. System Events are also
generated by the SOM (e.g., for SOM administrator logins and SOM user account management) and are
stored locally on the SOM server.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
50
6.1.2 FAU_SAR.1 and FAU_SAR.2
The Imperva GUI and the OpenAPI interface allows users to read audit information from the audit
records using a Web-based interface. Users without access authorisations to OpenAPI or Imperva GUI
cannot view audit records.
6.1.3 FAU_SAR.3
Imperva GUI and the OpenAPI interface allow authorised administrators to perform sorting of audit data
based on date and time, subject identity (username), and event type. The success or failure of the
related event is implied from the event type.
6.1.4 FAU_STG.2, FAU_STG.4, FAU_STG.5
System Events log records are stored in a MX Management Server database table and may also be
forwarded for storage on a corresponding SOM database. The TOE does not provide any interface for
modifying audit records. Audit records can only be archived and purged by an authorized System
administrator via the Imperva GUI management interface.
By default, the MX Management Server retains up to 100,000 System Event records and purges the
oldest records when this configurable threshold is exceeded. An authorized System administrator with
appropriate permissions can modify this threshold or specify a time period for which System Event
records must be retained. System Event records can also be archived to external storage before being
purged on a defined schedule. An alarm can be configured to be sent to an Action Interface if the audit
trail is full.
The authorised administrator may schedule automatically generated recurring reports that are sent
from the MX Management Server in CSV or PDF format to an administrator-specified email address,
containing all or a subset of the stored audit records.
6.2 FCS: Cryptographic support
6.2.1 FCS_CKM.1, FCS_CKM.2, FCS_CKM.4, FCS_COP.1, FCS_HTT.1, FCS_RBG.1(1),
FCS_RBG.1(2), FCS_TLS.1(1), FCS_TLS.1(2), FCS_TLS.1(3), FCS_TLS.1(4)
Passwords
Administrator passwords for locally defined users are stored using BcryptPasswordEncoder version $2a
hashes in a database located on the MX Management Server.
Random Number Generation (FCS_RBG.1(1), FCS_RBG.1(2))
The WAF Gateways implement a software-based deterministic random bit generator that complies with
NIST SP 800-90, using CTR_DRBG (AES) seeded with 256 bits of entropy. On the X10K2, X8520, X6520,
X4520, X2520, X10K, X8510, X6510 and X2510 appliances, the entropy source is the RDRAND
instruction provided by Intel Ivy Bridge-based processors, which is assumed to provide 0.5 bits of
entropy per bit sample. The same entropy source is also used on virtual gateway appliances, which
require an Ivy Bridge-based processor on the hosting hardware. On X4510 appliances, the entropy
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
51
source is an Infineon SLB96xx Trusted Platform Module (TPM) processor, which is assumed to provide 1
bit of entropy per bit sample (i.e., full entropy).
The MX Management Server appliances (including the virtual Management Server appliance) implement
a software-based deterministic random bit generator that complies with NIST SP 800-90, using
HMAC_DRBG seeded with 256 bits of entropy. On M160 appliances, the entropy source is an Infineon
SLB96xx Trusted Platform Module (TPM) processor, which is assumed to provide 1 bit of entropy per bit
sample (i.e., full entropy).
HTTP/TLS (FCS_HTT.1, FCS_TLS.1(2))
Imperva GUI is a browser-based interface to the MX that allows authorised administrators to access TOE
management functions. It is implemented by a Web server component on the MX. The TOE’s HTTPS
protocol complies with RFC 2818 and is implemented using TLS 1.2 (RFC 5246) supporting the following
ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256, and TLS_RSA_WITH_AES_256_CBC_SHA.
Key agreement supports DH with FFC schemes using “safe-prime” groups and elliptic curve schemes.
For FFC, key sizes of 2048 bits and greater are supported. For elliptic curve, P-256 and P-384 are
supported.
HTTP over TLSv1.2 as well as the same ciphersuites are also used for the internal TOE component
communications.
TLS WAF GW Traffic in Reverse Proxy mode (FCS_HTT.1, FCS_TLS.1(1))
The TOE’s TLS protocol complies with RFC 2818 and is implemented using TLS v1.2 (RFC5246) and
TLSv1.3 (RFC 8446 ) supporting the following ciphersuites: TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.
Key agreement supports DH with FFC schemes using “safe-prime” groups and elliptic curve schemes.
For FFC, key sizes of 2048 bits and greater are supported. For elliptic curve, P-256, P-384 and P-521 are
supported.
ADC content updates (FCS_TLS.1(3))
The TOE retrieves ADC content updates from the trusted Imperva Server using a secure TLS v1.2
(RFC5246) channel supporting the following ciphersuites: TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA .
Inter-TOE communication (FCS_TLS.1(4))
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
52
The TOE uses TLS v1.2 to secure communications between the separate TOE components and supports
the following ciphersuite: TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Key agreement supports RSA with key sizes of 2048 bits and greater and elliptic curve with P-256, P-384,
and P-521.
Sending audit (FCS_COP.1)
An authorised administrator can configure the TOE to automatically archive and/or purge the audit files
on a defined schedule. Archiving sends the audit files in CSV format to an external audit server. To
protect the archived audit data from unauthorised read access or modification, the TOE encrypts and
signs the files.
The TOE uses the following cryptographic operations in support of higher level protocols such as HTTPS
and TLS as well as for protecting the archived audit data.
Table 7: Cryptographic Operations
Function Algorithm Options
Random Number Generation.
Symmetric key generation
[SP 800--90] DRBG
Prediction
resistance
HMAC DRBG, no reseed CTR DRBG (AES), no
derivation function
Encryption/Decryption [FIPS 197] AES 128/256 CBC and GCM
128/192/256 CTR
Hash [FIPS 180-4] SHA-1, SHA-2 (256, 384, 512)
Keyed Hash [FIPS 198-1] HMAC SHA-1, SHA-2 (256, 384, 512)
Digital Signature [FIPS 186-4] RSA SigGen PKCS1.5/PSS, SigVer PKCS1.5/PSS
[FIPS 186-4] ECDSA SigGen/SigVer P-256, P-384,P-521
Asymmetric Key Generation [FIPS 186-4] RSA KeyGen Mode B.3, 2048
[FIPS 186-4] ECDSA KeyGen P-256,P-384, P-521
The TOE is designed to cryptographically destroy (zeroization) secret and private keys when they are no
longer required by the TOE. The TOE performs all zeroization automatically by calling Bouncy Castle APIs
that perform an “Overwrite with a fixed string of zeroes; then delete”. The zeroization applied to keys
stored on RAM disk refers to the fixed data structures in the file system where the keys permanently
reside, until they are no longer needed and subsequently deleted. The TOE’s zeroization method
ensures Keys and CSPs zeroized from the storage locations as identified in the table below are
unrecoverable.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
53
Table 8: Key/CSP Zeroization Summary
# Key/ CSP
Name
Generation/
Algorithm
Description Storage
CSP1 RSA private
keys
RSA(2048 bits) Identity
certificates for
the security
appliance itself
and also used in
TLS negotiations
Key Store on
Disk
RAM (plain text)
CSP2 CA Certificates RSA(2048 bits) Trusted CAs Trust Store on
Disk
RAM (plain text)
CSP3 Proxy
Credentials
Secret (plain
text)
Usernames and
passwords for
protected
machines
Transit (TLS
with secrets
generated by
RSA-2048
private keys)
CSP4 SIEM
Credentials
Secret Used for
sending syslog
messages
See CSP3
CSP5 External
Machines
Certificates
Various, can be
shared secrets
of any kind
Public Keys of
machines for
integration
authentication
See CSP3
CSP6 Machine Secret admin login Stored
encrypted as a
Linux Hash
saved on disk
6.3 FIA: Identification and authentication
6.3.1 FIA_ATD.1
The Imperva application on the MX Management Server maintains the following required security
attributes in the MX database (described above for FAU_GEN.1) for each authorised administrator user,
as follows:
● User identity – Username
● Authentication data –Hashed Password
● Authorisations – Role assignments, user-specific permissions
6.3.2 FIA_UAU.2 and FIA_UID.2
The Web Server component on the MX Management Server requires identification and authentication
for all Imperva GUI and OpenAPI requests. The Web Server requires HTTP Basic Authentication from the
user and sends the user’s password to the Imperva application on the MX Management Server for
validation against the authentication data stored in the database.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
54
6.4 FMT: Security management
6.4.1 FMT_MOF.1, FMT_MTD.1, FMT_SMR.1
As explained above for FIA_ATD.1, each authorised administrator may be associated with role(s) and
user-specific permissions in the OpenAPI and Imperva GUI.
Roles are associated with permissions. Users associated with the role inherit these permissions in
addition to any user-specific permissions they have been allocated. Permissions are evaluated for each
user when the user logs in. They are associated with the user’s session, and affect which objects are
displayed and which operations may be performed.
The predefined Administrator role is granted all permissions and is the only out-of-the-box role that is
allowed to access the Imperva GUI Admin workspace in order to manage MX server users, roles, and
authorisations.
Permissions are defined on managed objects (Applications, Policies, Gateways, Sites, Servers, and Global
Objects), as View, Edit, or Create. Edit permission implies View permission. Create permission implies
Edit permission. An authorised administrator is defined in this ST (see FMT_SMR.1) to be an authorised
System administrator for a subset of System data if assigned Edit permissions to the corresponding
System objects. In particular, the predefined Web Security Admin role provide authorized System
administrator permissions to the corresponding functional subsets of System data.
Special permissions allow users to activate settings and navigate to certain pages, e.g., the Alerts
permissions allow access to the Alerts viewer or for viewing Alerts reports. In this example, users
assigned with this special permission will only see report data regarding alerts generated on Server
Groups for which they have View permission. In particular, the Settings permission is required for access
to database audit archiving configuration and key management interfaces.
6.4.2 FMT_SMF.1
The Imperva GUI and OpenAPI interface is used by authorised administrators to manage all IDS/IPS
System and audit capabilities as described in the following table.
Table 9: Management Functions
Requirement Class Requirement Component
FMT_MOF.1 Modify the behaviour of the functions
of System data collection, analysis, and
reaction
Authorised System administrators use the OpenAPI or
Imperva GUI interface to modify Server Group
definitions, define Action Interfaces and Action
Policies, configure Security Rules for each Server
Group, enable collection, analysis and reaction
capabilities, and manage Profiles and Signatures.
FMT_MTD.1 Query audit data Audit records are stored as System Events and may be
reviewed using the Imperva GUI in an online tabular
format or as System Events reports.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
55
Requirement Class Requirement Component
Query and add System data Authorised administrators can use the Imperva GUI
interface to review System data for which they have
View permission, to update Profiles and Signatures and
to invoke assessments.
Query (export) and modify (create,
delete, import) audit archive protection
keys
Authorised administrators with Settings permission can
use the OpenAPI or Imperva GUI interface to create,
delete, import and export and to set the default RSA
keys used for signing and encrypting archived database
audit data.
Query and modify all other (non-
System and audit) TOE data
Authorised administrators can use the OpenSSL or
Imperva GUI interface for reviewing and modifying all
other TOE data (e.g., Tasks).
FMT_SMR.1 Modify the group of users that are part
of a role
Imperva GUI allows authorised administrators
belonging to the Administrators group with access to
the Users and Roles screen, providing the ability to
add, edit, and delete user accounts, and reset their
passwords.
6.5 FPT: Protection of the TSF
6.5.1 FPT_ITT.1
The internal TOE transfer of TSF data is protected by the allocation of a physically separate NIC on both
MX Management Server and WAF gateways for Gateway-Management Server communication, as
explained in the ST introduction.
Neither the MX Management Server nor the WAF gateways route or bridge network traffic between the
Management NIC and the production NICs. This separation provides a separate network domain for the
Out of Band (OOB) management network, protecting all Gateway-MX Management Server
communication from any access by authorised or unauthorised users.
ST introduction describes supported Imperva WAF deployment configurations. In both sniffing and
bridging configurations (except for non-transparent reverse proxy configurations), Imperva Gateways do
not have an assigned IP address on all sniffing/bridging network interface cards (NICs), so that the
gateways cannot be directly attacked over the network.
FPT_ITT.1 requires protection of TSF data when it is transmitted between separate parts of the TOE, i.e.,
while it is in transit outside of the TOE. For protection between the TOE components, TLS v1.2 is used. In
the case of audit archiving, the MX Management Server is sending the TSF data outside the TOE through
untrusted media (the audit archive server) for later retrieval by same MX Management Server. The audit
archive server does not have to be trusted to protect the data while it is outside the TOE – it is
prevented from disclosing or modifying the data by the cryptographic protection applied to the data by
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
56
the TOE, as described for FCS_COP.1. The FPT_ITT term “separate parts of the TOE” is interpreted in this
context to mean that there is a gap (of potential insecurity) that is traversed by the data.
6.5.2 FPT_STM.1
The MX Management Server and WAF gateways use the system real time clock that provides reliable
timestamps for recorded System data. The MX Management Server synchronizes the gateways’ clocks
with its own using the NTP protocol over the OOB management network. The MX Management Server’s
clock can be synchronized with an external NTP server. An external NTP server providing a reliable time
source is required.
6.6 FTP: Trusted path/channels
6.6.1 FTP_ITC.1
The TOE provides a trusted channel for the TOE to retrieve ADC content updates from the trusted
Imperva Server. The channel is secured using TLS v1.2.
6.6.2 FTP_TRP.1
The TOE provides a trusted path for authorised administrator sessions to the OpenAPI and Imperva GUI.
The MX Management Server allows remote users to initiate communication via the trusted path by
establishing TLSv1.2 sessions, using RSA for Management Server authentication and a password for
authenticating the administrator. This is required for all administrator sessions.
6.7 IDS: Intrusion Detection
6.7.1 IDS_ANL.1
Events that are matched by any of the ID analysis engines are recorded as an Alert. Security Rules
applied when an Alert is generated are defined per Server Group. There are six categories of Security
Rules, defined by the type of ID analysis layer that generated the Alert:
● Network Firewall Rules,
● Signature Rules,
● Protocol Violation Rules,
● Web Worm Defender Rules,
● Profile Violation Rules, and
● Correlation Rules.
Alert attributes include the following relevant fields:
● Alert Severity: Informative or Low, Medium, or High Severity.
● Time: date and time when the Alert was generated.
● Type:
o Firewall,
o Signature,
o HTTP Worm,
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
57
o Protocol Violation,
o Profile Violation,
o Correlation.
● Aggregated: Alert record is an aggregation of multiple network-level events.
● Source IP: the source IP address that generated the alert.
● Server Group: the name of the destination Server Group.
● Description: Alert identification
● Immediate Action: Blocked if the corresponding connection was blocked.
● User identity: The identity of the user associated with the event (if available).
In addition, Alert Type-specific information is recorded. Among other attributes, this may include source
and destination ports, protocol (TCP/UDP/ICMP), service name (if recognized), and packet contents.
6.7.2 IDS_RCT.1
For each Security Rule, the Action Policy defined by the authorised System administrator can invoke two
types of actions:
● Immediate Actions: actions taken as an immediate response to an attack. Imperva WAF can be
configured to immediately react to a specific identified intrusion type by blocking the network
packet that generated the security event (by dropping it when in inline topology), by closing the
HTTP connection in reverse proxy topology, or by sending a TCP reset to the attacked server
(when in sniffing topology) to cause it to disconnect the corresponding session.
● Followed Actions: follow-up actions taken by the System. An Action Set defines a set of actions
and operations that are executed by Imperva WAF v14.7P20 as a result of an ID analysis.
Configurable actions include:
o Blocking Attacking IP: Blocking subsequent IP packets with a presumed source address equal
to that recorded for the event, for a specified period of time.
o Blocking Attacking Session: Blocking subsequent HTTP requests with the same session
identifier as was recorded for the event, for a specified period of time.
o Block User: Block subsequent requests associated with the same user as was identified for
the event, for a specified period of time.
o Dispatch Alert: Send alarm to specified Action Interfaces including relevant Alert details.
o Start Monitoring-Record all requests/responses from the IP or session recorded for the
event, for a specified period of time.
The available configurable alarms are: sending a syslog message to a syslog server or creating and
sending an SNMP trap to an SNMP destination.
6.7.3 IDS_RDR.1
The Imperva GUI capability provides authorised administrators with the capability to read System data
using a Web-based interface. Authorised administrator permissions are described for FMT_SMR.1.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
58
Audit data archived outside the TOE is cryptographically protected as described for FCS_COP.1,
preventing unauthorized access to the data
6.7.4 IDS_SDC.1
In both sniffing and bridging topologies, Imperva WAF collects all IP network traffic flowing between
external and internal networks. Collected IP packets are recognized as UDP datagrams, TCP sessions, or
other IP protocols, and forwarded to the TOE’s analysis and reaction logic. As described above for
IDS_ANL.1. Alerts may be generated by the analysis logic; these may be an indication of suspicious
activity, or a result of an administrator request to monitor specified events.
In addition to collecting network traffic, the TOE provides application-level monitoring for service
requests for Web resources (over HTTP and HTTPS protocols).
The TOE can identify HTML form-based Web identification and authentication events and associate the
user’s identity with the session. Because Web access often involves multiple HTTP sessions to the Web
server for a single user session, the TOE can track Web session identifiers passed as HTTP parameters or
in HTTP cookies, allowing it to trace users’ activity more accurately across HTTP sessions.
6.7.5 IDS_STG.1, IDS_STG.2
Alerts and system data are sent by the Gateway that generates the Alert to the MX Management Server
and stored in the Imperva database in a table that can hold up to 250,000 Alert records. When the table
fills up, the MX Management Server switches to a second table of the same capacity, erasing its previous
contents and overwriting them with new Alert records. The MX Management Server switches back to
the first table when the second table fills up. This process guarantees that at the least the most recent
250,000 Alert records will be retained at any given point in time. An Alarm can be configured to be sent
to a syslog server in the IT environment after a table switch is performed.
Recorded System data is reviewed by authorized Administrators via the Imperva GUI. Authorized
Administrators can selectively delete System data but have no interface for modifying stored data. The
TOE does not provide any interface for unauthorized users to access System data. The TOE extends
protection to archived audit files by signing the files, allowing the TOE to detect any unauthorized
modification of these files while outside the TOE. The TOE cannot prevent unauthorized deletion of data
stored outside the TOE.
System data storage capacity is described for IDS_SDC.1. An authorized administrator may schedule
automatically generated recurring reports that are sent from the MX Management Server in CSV or PDF
format to an administrator-specified email address, containing all or a subset of the stored Alerts
records. Audit files can be archived outside the TOE, either manually by the administrator or on an
administrator-defined schedule.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
59
7 TOE Rationale
7.1 Security Objectives Rationale
This section shows that all secure usage assumptions, threats and policies are completely covered by
security objectives for the TOE or operational environment. In addition, each objective counters or
addresses at least one assumption or threat.
Table 10: Security Problem Definition to Security Objective Correspondence
Objectives
Threats
O.ACCESS
O.AUDITS
O.AUDIT_PROT
O.AUDIT_SORT
O.EADMIN
O.IDANLZ
O.IDAUTH
O.IDSCAN
O.SDC
O.INTEGR
O.OFLOWS
O.PROTCT
O.RESPON
O.TIME
OE.CREDEN
OE.INSTAL
OE.INTROP
OE.PERSON
OE.PHYCAL
OE.TIME
T.COMDIS ✓ ✓ ✓
T.COMINT ✓ ✓ ✓ ✓
T.FACCNT ✓
T.IMPCON ✓ ✓ ✓ ✓ ✓ ✓ ✓
T.INFLUX ✓
T.LOSSOF ✓ ✓ ✓ ✓
T.NOHALT ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
T.PRIVIL ✓ ✓ ✓ ✓ ✓ ✓ ✓
T.FALACT ✓
T.FALASC ✓
T.FALREC ✓
T.INADVE ✓ ✓
T.MISUSE ✓ ✓
T.SCNVUL ✓
P.ACCACT ✓ ✓ ✓ ✓ ✓
P.ACCESS ✓ ✓ ✓ ✓
P.ANALYZ ✓
P.INTGTY ✓
P.MANAGE ✓ ✓ ✓ ✓ ✓ ✓ ✓
P.PROTCT ✓ ✓
A.ACCESS ✓
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
60
Objectives
Threats
O.ACCESS
O.AUDITS
O.AUDIT_PROT
O.AUDIT_SORT
O.EADMIN
O.IDANLZ
O.IDAUTH
O.IDSCAN
O.SDC
O.INTEGR
O.OFLOWS
O.PROTCT
O.RESPON
O.TIME
OE.CREDEN
OE.INSTAL
OE.INTROP
OE.PERSON
OE.PHYCAL
OE.TIME
A.ASCOPE ✓
A.DYNMIC ✓ ✓
A.TIME ✓ ✓
A.LOCATE ✓
A.PROTCT ✓
A.NOEVIL ✓ ✓
A.NOTRST ✓ ✓
A.MANAGE ✓
7.1.1 Threats
This section shows that all threats are completely countered by the security objectives for the TOE or
operational environment.
7.1.1.1 TOE Threats
T.COMDIS
An unauthorized user may attempt to disclose the data collected and produced by the TOE by
bypassing a security mechanism.
● The O.IDAUTH objective provides for authentication of users prior to any TOE data access.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users
to access TOE data.
● The O.PROTCT objective addresses this threat by providing TOE self-protection from
unauthorized modifications and access to its functions and data.
T.COMINT
An unauthorized user may attempt to compromise the integrity of the data collected and produced
by the TOE by bypassing a security mechanism.
● The O.IDAUTH objective provides for authentication of users prior to any TOE data access.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users
to access TOE data.
● The O.INTEGR objective ensures no TOE data will be modified.
● The O.PROTCT objective addresses this threat by providing TOE self-protection.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
61
T.FACCNT
An unauthorized user’s attempts to access TOE data or security functions goes undetected.
● The O.AUDITS objective counters this threat by requiring the TOE to audit attempts for data
accesses and use of TOE functions.
T.IMPCON
An unauthorized user may inappropriately change the configuration of the TOE causing potential
intrusions of the monitored IT System to go undetected.
● The OE.PERSON, OE.CREDEN, OE.PHYCAL and OE.INSTAL security objectives for the operational
environment together provides mitigation to this threat with responsible administrators and
forbidden physical access to the TOE.
● The O.EADMIN objective ensures the TOE has all the necessary administrator functions to
manage the product.
● The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized
users to access TOE functions.
T.INFLUX
An unauthorized user may cause malfunction of the TOE by creating an influx of data that the TOE
cannot handle.
● The O.OFLOWS objective counters this threat by requiring the TOE handle data storage
overflows.
T.LOSSOF
An unauthorized user may attempt to remove or destroy data collected and produced by the TOE.
● The O.IDAUTH objective provides for authentication of users prior to any TOE data access.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users
to access TOE data.
● The O.INTEGR objective ensures no TOE data will be deleted.
● The O.PROTCT objective addresses this threat by providing TOE self-protection.
T.NOHALT
An unauthorized user may attempt to compromise the continuity of the TOE’s collection and analysis
functions by halting execution of the TOE.
● OE.PERSON, OE.CREDEN, OE.PHYCAL and OE.INSTAL security objectives for the operational
environment together provides mitigation to this threat with responsible, trusted administrators
and forbidden physical access to the TOE.
● The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users
to access TOE functions.
● The O.IDSCAN, O.SDC, and O.IDANLZ objectives address this threat by requiring the TOE to
collect and analyze System data, which includes attempts to halt the TOE.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
62
T.PRIVIL
An unauthorized user may gain access to the TOE and exploit system privileges to gain access to TOE
security functions and data.
● The OE.PERSON, OE.CREDEN, OE.PHYCAL and OE.INSTAL security objectives for the operational
environment together provides mitigation to this threat with responsible administrators and
forbidden physical access to the TOE.
● The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized users
to access TOE functions.
● The O.PROTCT objective addresses this threat by providing TOE self-protection.
7.1.1.2 IT System Threats
T.FALACT
The TOE may fail to react to identified or suspected vulnerabilities or inappropriate activity, allowing
unauthorized or malicious users to exploit vulnerabilities in the monitored IT System or gain
unauthorized access to protected data.
● The O.RESPON objective ensures the TOE reacts to analytical conclusions about suspected
vulnerabilities or inappropriate activity.
T.FALASC
The TOE may fail to identify vulnerabilities or inappropriate activity based on association of IDS data
received from all data sources, allowing unauthorized or malicious users to exploit vulnerabilities in
the monitored IT System or gain unauthorized access to protected data.
● The O.IDANLZ objective provides the function that the TOE will recognize vulnerabilities or
inappropriate activity from multiple data sources.
T.FALREC
The TOE may fail to recognize vulnerabilities or inappropriate activity based on IDS data received
from each data source, allowing unauthorized or malicious users to exploit vulnerabilities in the
monitored IT System or gain unauthorized access to protected data.
● The O.IDANLZ objective provides the function that the TOE will recognize vulnerabilities or
inappropriate activity from a data source.
T.INADVE
Inadvertent activity and access may occur on an IT System the TOE monitors, allowing careless or
unauthorized users to access or adversely manipulate protected data undetected.
● The O.AUDITS and O.SDC objectives address this threat by requiring a TOE to collect audit and
system data.
T.MISUSE
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
63
Undetected authorized accesses and activity indicative of misuse may occur on an IT System the TOE
monitors, allowing unauthorized or malicious users to exploit weaknesses in the system or gain
unauthorized access to protected data.
● The O.AUDITS and O.SDC objectives address this threat by requiring a TOE to collect system and
audit data.
T.SCNVUL
Vulnerabilities may exist in the IT System the TOE monitors, allowing unauthorized or malicious users
to exploit weaknesses in the system or gain unauthorized access to protected data.
● The O.IDSCAN objective counters this threat by requiring a TOE to collect and store system
information that might be indicative of a vulnerability.
7.1.2 Organizational Security Policies
This section shows that all security policies are completely countered by the security objectives for the
TOE or operational environment.
P.ACCACT
Users of the TOE shall be accountable for their actions within the IDS.
● The O.AUDITS objective implements this policy by requiring auditing of all data accesses and use
of TOE functions.
● The O.IDAUTH objective supports this objective by ensuring each user is uniquely identified and
authenticated.
● O.AUDIT_SORT supports this objective by allowing the administrator to sort audit data
providing for user accountability
● OE.TIME and O.TIME together supports this OSP providing an accurate time and date.
P.ACCESS
All data collected and produced by the TOE shall only be used for authorized purposes.
● The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized
users to access TOE functions.
● The O.PROTCT objective addresses this policy by providing TOE self-protection.
● O.AUDIT_PROT supports this objective by providing protection for audit data.
P.ANALYZ
Analytical processes and information to derive conclusions about intrusions (past, present, or future)
must be applied to IDS data and appropriate response actions taken.
● The O.IDANLZ objective requires analytical processes be applied to collected system data.
P.INTGTY
Data collected and produced by the TOE shall be protected from modification.
● The O.INTEGR objective ensures the protection of data from modification.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
64
P.MANAGE
The TOE shall only be managed by authorized users.
● The OE.PERSON objective ensures competent administrators will manage the TOE and the
O.EADMIN objective ensures there is a set of functions for administrators to use.
● The OE.INSTAL objective supports the OE.PERSON objective by ensuring administrator follow all
provided documentation and maintain the security policy.
● The O.IDAUTH objective provides for authentication of users prior to any TOE function accesses.
● The O.ACCESS objective builds upon the O.IDAUTH objective by only permitting authorized
users to access TOE functions.
● The OE.CREDEN objective requires administrators to protect all authentication data.
● The O.PROTCT objective addresses this policy by providing TOE self-protection.
P. PROTCT
The TOE shall be protected from unauthorized accesses and disruptions of TOE data and functions.
● The O.OFLOWS objective counters this policy by requiring the TOE handle disruptions.
● The OE.PHYCAL objective protects the TOE from unauthorized physical modifications.
7.1.3 Assumptions
This section shows that all secure usage assumptions are completely covered by security objectives for
the TOE or operational environment.
7.1.3.1 Intended Usage Assumptions
A.ACCESS
The TOE has access to all the IT System data it needs to perform its functions.
● The OE.INTROP objective ensures the TOE has the needed access.
A.ASCOPE
The TOE is appropriately scalable to the IT System the TOE monitors.
● The OE.INTROP objective ensures the TOE has the necessary interactions with the IT System it
monitors.
A.DYNMIC
The TOE will be managed in a manner that allows it to appropriately address changes in the IT
System the TOE monitors.
● The OE.INTROP objective ensures the TOE has the proper access to the IT System.
● The OE.PERSON objective ensures that the TOE will be managed appropriately.
A.TIME
The NTP server configured in the TOE for synchronization must be accurate and reliable so when the
TOE acts as a server itself, it will provide good timestamps.
● The OE.PERSON and OE.TIME ensures time is correctly configured for the TOE.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
65
7.1.3.2 Physical Assumptions
A.LOCATE
The processing resources of the TOE will be located within controlled access facilities, which will
prevent unauthorized physical access.
● The OE.PHYCAL provides for the physical protection of the TOE.
A.PROTCT
The TOE hardware and software critical to security policy enforcement will be protected from
unauthorized physical modification.
● The OE.PHYCAL provides for the physical protection of the TOE software and the hardware
where it runs, including administration workstations and OOB network.
7.1.3.3 Personnel Assumptions
A.NOEVIL
The authorized administrators are not careless, willfully negligent, or hostile, and will follow and
abide by the instructions provided by the TOE documentation.
● The OE.PERSONobjective ensures that the TOE administrators are carefully selected with
competency and trustworthiness in mind and trained for proper operation of the System.
● The OE.INSTAL objective provides administrators with the instructions they are expected to
abide by.
A.NOTRST
The TOE can only be accessed by authorized users.
● The OE.PHYCAL objective provides for physical protection of the TOE to protect against
unauthorized access.
● The OE.CREDEN objective supports this assumption by requiring protection of all authentication
data.
A.MANAGE
There will be one or more competent individuals assigned to manage the TOE and the security of the
information it contains.
● The OE.PERSON objective ensures all authorized administrators are qualified and trained to
manage the TOE
7.2 Security Functional Requirements Rationale
All security functional requirements identified in this ST are fully addressed in this section and each is
mapped to the objective it is intended to satisfy. The following table summarizes the correspondence of
functional requirements to TOE security objectives.
Table 11: SFR to Security Objective Correspondence
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
66
Objectives
SFRs
O.ACCESS
O.AUDITS
O.AUDIT_PROT
O.AUDIT_SORT
O.EADMIN
O.IDANLZ
O.IDAUTH
O.IDSCAN
O.SDC
O.INTEGR
O.OFLOWS
O.PROTCT
O.RESPON
O.TIME
FAU_GEN.1 ✓
FAU_SAR.1 ✓
FAU_SAR.2 ✓ ✓
FAU_SAR.3 ✓
FAU_STG.2 ✓ ✓ ✓ ✓ ✓ ✓
FAU_STG.4 ✓ ✓
FAU_STG.5 ✓ ✓
FCS_CKM.1 ✓ ✓ ✓
FCS_CKM.2 ✓ ✓ ✓
FCS_CKM.4 ✓ ✓ ✓
FCS_COP.1 ✓ ✓ ✓
FCS_HTT.1 ✓ ✓
FCS_RBG.1(1) ✓
FCS_RBG.1(2) ✓ ✓ ✓
FCS_TLS.1(1) ✓ ✓
FCS_TLS.1(2) ✓ ✓
FCS_TLS.1(3) ✓
FCS_TLS.1(4) ✓
FIA_ATD.1 ✓
FIA_UAU.2 ✓ ✓
FIA_UID.2 ✓ ✓
FMT_MOF.1 ✓ ✓ ✓
FMT_MTD.1 ✓ ✓ ✓ ✓
FMT_SMF.1 ✓ ✓ ✓ ✓
FMT_SMR.1 ✓
FPT_ITT.1 ✓ ✓
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
67
Objectives
SFRs
O.ACCESS
O.AUDITS
O.AUDIT_PROT
O.AUDIT_SORT
O.EADMIN
O.IDANLZ
O.IDAUTH
O.IDSCAN
O.SDC
O.INTEGR
O.OFLOWS
O.PROTCT
O.RESPON
O.TIME
FPT_STM.1 ✓
FTP_ITC.1 ✓
FTP_TRP.1 ✓
IDS_ANL.1 ✓
IDS_RCT.1 ✓
IDS_RDR.1 ✓ ✓ ✓
IDS_SDC.1 ✓ ✓
IDS_STG.1 ✓ ✓ ✓ ✓ ✓
IDS_STG.2 ✓
O.ACCESS
The TOE must allow authorized users to access only appropriate TOE functions and data.
● FIA_UID.2, FIA_UAU.2: Users authorized to access the TOE are defined using an identification
and authentication process.
● FMT_MOF.1, FMT_SMF.1: The TOE is required to provide the ability to restrict managing the
behaviour of functions of the TOE to authorized users of the TOE.
● FMT_MTD.1: Only authorized administrators of the System may query and add System and
audit data, and authorized administrators may query and modify all other data.
● FCS_HTT.1, FCS_TLS.1(2), FCS_CKM.1, FCS_CKM.2, FCS_CKM.4, FCS_RBG.1(2): The connection
to the user interface cannot be modified or intercepted because secure access mechanisms are
implemented.
● FAU_SAR.2: The TOE is required to restrict the review of audit data to those granted with
explicit read-access.
● IDS_RDR.1, FCS_CKM.1, FCS_COP.1: The System is required to restrict the review of System
data to those granted with explicit read access.
● FCS_CKM.1, FCS_COP.1: System archived audit data is encrypted.
● FAU_STG.2: The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure, or attack.
● IDS_STG.1: The System is required to protect the System data from any modification and
unauthorized deletion.
O.AUDITS
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
68
The TOE must record audit records for data accesses and use of the System functions.
● FAU_GEN.1: Security-relevant events must be defined and auditable for the TOE.
● FAU_STG.4, FAU_STG.5: The TOE must prevent the loss of collected data in the event its audit
trail is full.
O.AUDIT_PROT
The TOE must provide the capability to protect audit information.
● FAU_STG.2: The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure, or attack.
O.AUDIT_SORT
The TOE must provide the capability to sort the audit information.
● FAU_SAR.3: The TOE must provide the ability to review and manage the audit trail of the System
to include sorting the audit data.
O.EADMIN
The TOE must include a set of functions that allow effective management of its functions and data.
● FAU_SAR.1: The TOE must provide the ability to review and manage the audit trail of the
System.
● IDS_RDR.1: The System must provide the ability for authorized administrators to view all System
data collected and produced.
● FMT_SMF.1: The TOE includes a set of functions that allow effective management of TOE
functions and data.
O.IDANLZ
The TOE must collect system data and then apply analytical processes and information to derive
conclusions about intrusions (past, present, or future).
● IDS_ANL.1: The TOE is required to perform intrusion analysis and generate conclusions.
O.IDAUTH
The TOE must be able to identify and authenticate users prior to allowing access to TOE functions
and data.
● FAU_SAR.2: The TOE is required to restrict the review of audit data to those granted with
explicit read access.
● IDS_RDR.1: The System is required to restrict the review of System data to those granted with
explicit read access.
● FAU_STG.2: The TOE is required to protect the stored audit records from unauthorized deletion.
● IDS_STG.1: The System is required to protect the System data from any modification and
unauthorized deletion, as well as guarantee the availability of the data in the event of storage
exhaustion, failure or attack.
● FIA_ATD.1: Security attributes of subjects use to enforce the authentication policy of the TOE
must be defined.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
69
● FIA_UID.2, FIA_UAU.2: Users authorized to access the TOE are defined using an identification
and authentication process.
● FMT_MOF.1, FMT_SMF.1: The TOE is required to provide the ability to restrict managing the
behaviour of functions of the TOE to authorized users of the TOE.
● FMT_MTD.1: Only authorized administrators of the System may query and add System and
audit data, and authorized administrators of the TOE may query and modify all other TOE data.
● FMT_SMR.1: The TOE must be able to recognize the different administrative and user roles that
exist for the TOE.
O.IDSCAN
The TOE must collect and store system data information that might be indicative of the potential for
a future intrusion or the occurrence of a past intrusion of an IT System.
● IDS_SDC.1: The TOE is required to collect and store system data information.
O.SDC
The TOE must collect and store information about all events that are indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity of IT System assets and the
IDS.
● IDS_SDC.1: The TOE is required to collect events indicative of inappropriate activity that may
have resulted from misuse, access, or malicious activity of IT System assets of an IT System.
O.INTEGR
The TOE must ensure the integrity of all audit and System data.
● FAU_STG.2: The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure or attack.
● IDS_STG.1 The System is required to protect the System data from any modification and
unauthorized deletion.
● FMT_MTD.1: Only authorized administrators of the System may query or add audit and System
data.
● FPT_ITT.1, FCS_COP.1, FCS_TLS.1(1), FCS_TLS.1(2), FCS_CKM.4, FCS_CKM.1 (MX), FCS_CKM.2
(MX): The System must protect the collected data from modification and ensure its integrity
when the data is transmitted internally and to remote IT systems.
● FCS_COP.1, FCS_TLS.1(1), FCS_HTT.1, FCS_RBG.1(2) (accessed by users): The System must
protect the collected data from modification and ensure its integrity when the data is
transmitted internally and to remote IT systems.
O.OFLOWS
The TOE must appropriately handle potential audit and System data storage overflows.
● FAU_STG.2: The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure or attack.
● FAU_STG.4, FAU_STG.5: The TOE must prevent the loss of audit data in the event its audit trail
is full.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
70
● IDS_STG.1: The System is required to protect the System data from any modification and
unauthorized deletion, as well as guarantee the availability of the data in the event of storage
exhaustion, failure or attack.
● IDS_STG.2: The System must prevent the loss of audit data in the event its audit trail is full.
O.PROTCT
The TOE must protect itself from unauthorized modifications and access to its functions and data.
● FAU_STG.2: The TOE is required to protect the audit data from deletion as well as guarantee the
availability of the audit data in the event of storage exhaustion, failure, or attack.
● IDS_STG.1: The System is required to protect the System data from any modification and
unauthorized deletion, as well as guarantee the availability of the data in the event of storage
exhaustion, failure or attack.
● FMT_MOF.1, FMT_SMF.1: The TOE is required to provide the ability to restrict managing the
behaviour of functions of the TOE to authorized users of the TOE.
● FMT_MTD.1: Only authorized administrators of the System may query and add System and
audit data, and authorized administrators of the TOE may query and modify all other TOE data.
● FTP_ITC.1: The TOE provides a trusted channel to obtain ADC content updates from the trusted
Imperva Server using TLS v1.2.
● FTP_TRP.1: The TOE provides a trusted path for remote users initiating communication for
administrator sessions, protecting OpenAPI and Imperva GUI data and functions from
unauthorized access over the network.
● FPT_ITT.1: It also prevents unauthorized modifications and access for TSF data transmitted
between the separate parts of the TOE.
● FCS_CKM.1, FCS_CKM.2, , FCS_TLS.1(1), FCS_TLS.1(2), FCS_TLS.1(3), FCS_TLS.1(4), FCS_CKM.4,
FCS_COP.1, FCS_RBG.1(1), FCS_RBG.1(2): This requires some cryptographic capabilities.
O.RESPON
The TOE must respond appropriately to analytical conclusions.
● IDS_RCT.1: The TOE is required to respond accordingly in the event an intrusion is detected.
O.TIME
The TOE must provide a reliable time source.
● FPT_STM.1: The NTP server in the management server provides a reliable time source
7.3 Security Assurance Requirements Rationale
EAL2 was selected as the assurance level because the TOE is a commercial product whose users require
a low to moderate level of independently assured security. The TOE is intended for use in an
environment with good physical access security where it is assumed that attackers will have Basic attack
potential. The target assurance level of EAL2 is appropriate for such an environment. Augmentation was
chosen to provide the added assurance that is gained by defining flaw remediation procedures.
Therefore, the target assurance level of EAL2 augmented with ALC_FLR.1 is appropriate for such an
environment.
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
71
7.4 SFR Component Hierarchies and Dependencies Rationale
This section of the ST demonstrates that the identified SFRs include the appropriate hierarchy and
dependencies. The following table lists the TOE SFRs and the SFRs each are hierarchical to, dependent
upon and any necessary rationale.
Table 12: TOE SFR Dependency Rationale
SFR Hierarchical To Dependency Rationale
FAU_GEN.1 No other components. FPT_STM.1 Satisfied
FAU_SAR.1 No other components. FAU_GEN.1 Satisfied
FAU_SAR.2 No other components. FAU_SAR.1 Satisfied
FAU_SAR.3 No other components. FAU_SAR.1 Satisfied
FAU_STG.2 FAU_STG.1 FAU_GEN.1 Satisfied
FAU_STG.4
FAU_STG.3 FAU_STG.1 Satisfied because FAU_STG.2 is hierarchical to
FAU_STG.1
FAU_STG.5 No other components. FAU_GEN.1 Satisfied
FCS_CKM.1
No other components. FCS_CKM.2 or
FCS_COP.1,
FCS_CKM.4
FCS_COP.1 Satisfied
FCS_CKM.4 Satisfied
FCS_CKM.2
No other components. FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1,
FCS_CKM.4
FCS_CKM.1 Satisfied
FCS_CKM.4 Satisfied
FCS_CKM.4
No other components. FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1
FCS_CKM.1 Satisfied
FCS_COP.1
No other components. FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1,
FCS_CKM.4,
FCS_CKM.1 Satisfied
FCS_CKM.4 Satisfied
FCS_HTT.1 No other components. FCS_TLS.1 Satisfied
FCS_RBG.1 No other components. None n/a
FCS_TLS.1 No other components. FCS_COP.1 Satisfied
FIA_ATD.1 No other components. None n/a
FIA_UAU.2
FIA_UAU.1 FIA_UID.1 FIA_UID.1 is satisfied because FIA_UID.2 is
hierarchical to FIA_UID.1
FIA_UID.2 FIA_UID.1 None n/a
FMT_MOF.1
No other components. FMT_SMR.1,
FMT_SMF.1
Satisfied,
Satisfied
FMT_MTD.1
No other components. FMT_SMR.1,
FMT_SMF.1
Satisfied,
Satisfied
FMT_SMF.1 No other components. None n/a
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
72
SFR Hierarchical To Dependency Rationale
FMT_SMR.1
No other components. FIA_UID.1 FIA_UID.1 is satisfied because FIA_UID.2 is
hierarchical to FIA_UID.1
FPT_ITT.1 No other components. None n/a
FPT_STM.1 No other components. None n/a
FTP_ITC.1 No other components. None. n/a
FTP_TRP.1 No other components. None n/a
IDS_ANL.1 No other components. IDS_SDC.1 Satisfied
IDS_RCT.1 No other components. IDS_ANL.1 Satisfied
IDS_RDR.1 No other components. IDS_SDC.1 Satisfied
IDS_SDC.1 No other components. FPT_STM.1 Satisfied
IDS_STG.1 No other components. IDS_SDC.1 Satisfied
IDS_STG.2 No other components. IDS_STG.1 Satisfied
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
73
8 Abbreviations and Acronyms
Table 13: Abbreviations and Acronyms
Abbreviation
and Acronyms
Definition
ADC Application Defense Center
AES Advanced Encryption Standard—a symmetric encryption algorithm
API Application Programming Interface
CAV Correlated Attack Validation
CC Common Criteria
CLI Command Line Interface
CM Configuration Management
CSV Comma Separated Values
EAL Evaluation Assurance Level
GCM Galois/Counter Mode—a mode of operation for AES
GUI Graphical User Interface
GW Gateway
HMAC Keyed-Hash Message Authentication Code
HTTPS Hypertext Transfer Protocol Secure
ID Intrusion Detection
IDS Intrusion Detection System
IT Information Technology
NGRP Next Generation Reverse Proxy
NIC Network Interface Card
NTP Network Time Protocol
OOB Out of Band
OSP Organizational Security Policy
PDF Portable Document Format
RSA Rivest-Shamir-Adleman—an asymmetric cryptographic algorithm
SAR Security Assurance Requirement
SFP Security Function Policy
SFR Security Function
SHA Secure Hash Algorithm
SIEM Security Information and Event Management
Imperva Web Application Firewall (WAF) v14.7P20 Security Target Version 1.48, 2023-02-
0811
74
Abbreviation
and Acronyms
Definition
SNMP Simple Network Management Protocol
SPAN Switched Port Analyzer
SSH Secure Shell
SSL Secure Sockets Layer
ST Security Target
TAP Terminal Access Point
TCP Transmission Control Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functionality
TSS TOE Summary Specification
UDP User Datagram Protocol