Korean National
Korean National
Protection Profile for
Protection Profile for
Web Application Firewall
Web Application Firewall
V3.0
V3.0
2023. 4. 27.
The certified Protection Profile is written in Korean. This document is a translation of the original
from Korean into English.
Foreword
This Protection Profile has been developed with the support of National Security Research
Institute (NSR) under the agreement between National Intelligence Service (NIS) and Ministry of
Science and ICT (MSIT). The Protection Profile author converted Part 2, Common Security
Requirements of ‘Security Requirements for Government V3.0 for the Information Security Systems
and Network Devices‘ and Part 3, Product Security Requirements of Security Requirements for Web
Application Firewall in conformity with the Common Criteria. The accurate interpretation of the
requirements ws made through advice of the National Cyber Security Center of the National
Intelligence Service. The Protection Profile includes Application notes which give the additional
interpretation and guidance for the evaluation and certification based on the Common Criteria, and
the separated guidance supporting document (Korean only) for the Protection Profile is provided.
Revision History
버 전 일 자 개정 내용
3.0 2023. 4. 27.
o Korean National Protection Profile for Web Application Firewall
V3.0 First Issue
Table of Contents
1. PP introduction 1
1.1. PP reference 1
1.2. TOE overview 1
1.2.1. Web Application Firewall overview 1
1.2.2. TOE type and scope 1
1.2.3. TOE usage and major security features 1
1.2.4. Non-TOE and TOE operational environment 2
1.3. Conventions 5
1.4. Terms and definitions 6
1.5. PP organization 10
2. Conformance claim 12
2.1. CC conformance claim 12
2.2. PP conformance claim 12
2.3. Package conformance claim 12
2.4. Conformance claim rationale 12
2.5. PP conformance statement 12
3. Security objectives 13
3.1. Security objectives for the operational environment 13
4. Extended components definition 15
4.1. Cryptographic support 15
4.1.1. Random Bit Generation 15
4.2. User data protection 15
4.2.1. External-stored data integrity 15
4.3. Security Management 16
4.3.1. ID and password 17
4.4. Protection of the TSF 18
4.4.1. Linkable external entities 18
4.4.2. Protection of stored TSF data 19
4.4.3. TSF update 20
5. Security requirements 22
5.1. Security functional requirements (Mandatory SFR) 23
5.1.1. Security audit (FAU) 24
5.1.2. Cryptographic support (FCS) 29
5.1.3. User data protection (FDP) 32
5.1.4. Identification and authentication (FIA) 35
5.1.5. Security management (FMT) 40
5.1.6. Protection of TSF (FPT) 49
5.1.7. TOE access (FTA) 56
5.2. Security functional requirements (Conditional mandatory SFR) 58
5.2.1. Security audit (FAU) 59
5.2.2. Identification and authentication (FIA) 60
5.2.3. Protection of the TSF (FPT) 61
5.2.4. TOE access (FTA) 63
5.2.5. Trusted path/channels (FTP) 64
5.3. Security function requirements (optional SFRs) 66
5.3.1. Cryptographic support (FCS) 67
5.3.2. Protection of the TSF (FPT) 67
5.4. Security assurance requirements 68
5.4.1. Security Target evaluation 68
5.4.2. Development 72
5.4.3. Guidance documents 73
5.4.4. Life-cycle support 74
5.4.5. Tests 75
5.4.6. Vulnerability assessment 76
5.5. Security requirements rationale 77
5.5.1. Dependency rationale of security functional requirements 77
5.5.2. Dependency rationale of security assurance requirements 79
References 80
Abbreviated terms 81
Korean National Protection Profile for Web Application Firewall
1
1. PP introduction
1.1. PP reference
1.2. TOE overview
1.2.1. Web Application Firewall overview
Web Application Firewall or WAF (hereafter ‘TOE’) is used to protect web server and web
applications by detects and prevents an attack by identifying the normality of L7 layer HTTP and
HTTPS user request.
The main function of TOE is to detect and block the inflow of malicious web traffic into web server
and web applications according to security policies.
1.2.2. TOE type and scope
The definition of TOE in this Protection Profile is Web Application Firewall that detects and blocks
an attack by identifying the normality of L7 layer HTTP and HTTPS user request, provided in the
form of appliance or software. Management console can be included in TOE component optionally,
in this case, should be identified as TOE component on the statement of security objectives by the
ST author of the statement. This Protection Profile defines the common minimum security
requirements that should be provided by TOE.
1.2.3. TOE usage and major security features
The TOE is used for the purpose of detects and prevents web traffic inflow into web server and
web applications that violates the security policies set by the authorized administrator. The TOE
Title Korean National Protection Profile Web Application Firewall
Version 3.0
Evaluation Assurance
Level
EAL1+(ATE_FUN.1)
Developer National Security Research Institute
Evaluation Criteria Common Criteria for Information Technology Security Evaluation
Common Criteria version CC V3.1 r5
Certification Number KECS-PP-1234-2023
Keywords
Web Application Firewall, Web Traffic Detection, Web Application
Security
CC V3.1 R5
2
provides malicious traffic detection and prevents functions by comparing web traffic and packet
contents inflow according to each URL.
The TOE provides the security audit function that records major events as audit data when security
functions and management functions are operated; the identification and authentication function
such as verifying the identity of the administrator and handling authentication failure; and the TSF
protection function including protection of the data stored in the storage controlled by the TSF, TSF
self-tests and integrity verification. In addition, it includes the cryptographic support function such
as cryptographic key management and cryptographic operations to support IPSec, TLS, SSH, HTTPS
and other encrypted communication for management access communication by the administrator;
the security management function for the management of security functions and security attributes
and the definition of the administrator role; and the TOE access function to manage the access
session of the authorized administrator.
1.2.4. Non-TOE and TOE operational environment
The operational environment of TOE defined in this Protection Profile consists of ‘In Line’ or
‘Reverse Proxy’ type, which is a network type where the TOE becomes the single point of
connection.
[Figure 1] is an example of general operational environment of In Line type. The TOE is located
right in front of the web server and web applications to detect and block inflow of malicious web
traffic into the web server and web applications.
[Figure 1] Operational environment of TOE(example: In Line type)
[Figure 2] is an example of general operational environment of Reverse Proxy type, one of diverse
operational environments applied to cases where it is difficult to install physical In Line type. The
TOE, which is located right in front of the web zone to function as the single point of connection
of the web server and web applications to be protected, sets the IP address of the web server
Korean National Protection Profile for Web Application Firewall
3
registered in DNS as the IP address of the TOE, or configures the web request traffic transmitted
from the web client through the L4 switch to be delivered to the TOE.
[Figure 2] Operational environment of TOE(example: Reverse Proxy type)
The TOE is installed and operated inside the organization protected by an Firewall, etc. The TOE is
located in a physically secured environment, which shall be accessible only to the administrator.
The authorized administrator shall access to the TOE through a web browser, serial communication,
and management program, etc. and shall perform the security management through secure
communication such as IPSec, TLS, SSH and HTTPS.
In the operational environment for the TOE, there may exist external IT entities such as NTP server
for time synchronization, Log server to store and manage the audit data, Mail server for the
authorized administrator notification in the case of audit data loss, etc. The ST author of the TOE
complying with this PP shall identify all external IT entities that interact with the TOE in the ST.
The others such as the NTP server except for the TOE are the TOE operational environment. In
addition, those parts (e.g. functions that have nothing to do with Web Application Firewall security
features) which are not related to the security functional requirements (hereinafter called the “SFR”)
can be excluded from the scope of the TOE or classified into the non-TSF of the TOE with
consideration for the physical scope of the TOE, etc..
This PP has been developed considering various types of the TOE implementation. The ST author
complying with this PP, shall describe any non-TOE hardware, software or firmware required by the
TOE to operate.
The ST author must have the conditional mandatory security functional requirement defined in
this PP, if the following conditions are met.
CC V3.1 R5
4
- If the TOE provides additional identification and authentication mechanisms (e.g., certificate-based
authentication method, OTP method, etc.) in addition to ID/PW-based identification and
authentication, FIA_UAU.5 shall be included.
- When providing additional identification and authentication functions, the TOE can provide those
functions by receiving the authentication results of external IT entities that interact with the TOE
(e.g., 2FA support device that complies with the FIDO standards), and accordingly
FPT_LEE.1(Extended) shall be included instead of FIA_UAU.5. In this case, the authentication
information used by external IT entities to perform additional identification and authentication
methods is safely managed by external IT entities, so the security objectives for the operating
environment shall be added accordingly.
- In case of users(authorized administrators) directly access the management server through web
browsers or terminal access programs, FTP_TRP.1 shall be included. Assuming that the web server
is the TOE operating environment, and if a secure communication path is provided through
communication between the user’s web browser and web server, the ST author shall add the
security objectives for the operational environment instead of including FTP_TRP.1. And if the
user’s web browser access the TOE server via the web server, such as when the web server and
the TOE server are physically separated to perform communication, FTP_TRP.1 is included to
provide a secure path between the TOE server and the user, and FTP_ITC.1 shall be included to
provide a secure channel between the web server and the TOE server. FPT_ITT.1 shall be included
when transmitting TSF data between the TOE components which are physically separated.(eg, If
communication between the TOE management console and the management server is directly
implemented, FPT_ITT.1 shall be included)
- When the TOE interacts with external IT entities(e.g., mail server, log server, etc.), FTP_ITC.1 shall
be included.
The ST author shall include FAU_STG.1, a conditional mandatory security functional requirement, in
the ST when the protected audit trail storage function is implemented in the TOE. If the function is
not implemented in the TOE, the function must be provided in the operating environment (for
example: using a DBMS, etc.), and accordingly, the security objectives for the operational
environment must be added.
The ST author shall include FPT_STM.1, an optional security functional requirement, in the ST if the
TOE implements a function that provides reliable time stamps. If the function is not implemented in
the TOE, the function must be provided by the operating environment (for example: provided by
the operating system, etc.), and accordingly, the security objectives for the operational environment
must be added.
Optional security functional requirements can be optionally implemented in the TOE. However, when
the TOE additionally provides related capabilities, the ST author must include the corresponding
SFRs. The ST author shall pay attention not to omit the security functional requirements for the
security features provided by the TOE by referring to the application notes when applying each
optional security functional requirement with regard to the applicability of the optional security
functional requirements.
Korean National Protection Profile for Web Application Firewall
5
1.3. Conventions
The notation, formatting and conventions used in this PP are consistent with the Common Criteria
for Information Technology Security Evaluation.
The CC allows several operations to be performed for functional requirements: iteration, assignment,
selection and refinement. Each operation is used in this PP.
Iteration
Iteration is used when a component is repeated with varying operations. The result of iteration is
marked with an iteration number in parenthesis following the component identifier, i.e., denoted as
(iteration No.).
Assignment
This is used to assign specific values to unspecified parameters (e.g., password length). The result of
assignment is indicated in square brackets like [ assignment_value ].
Selection
This is used to select one or more options provided by the CC in stating a requirement. The result
of selection is shown as underlined and italicized.
Refinement
This is used to add details and thus further restrict a requirement. The result of refinement is shown in
bold text.
Security Target (ST) Author
This is used to represent the final decision of attributes being made by the ST author. The ST
author's operation is denoted in braces, as in { decided by the ST author }. In addition, operations
of SFR not completed in the Protection Profile must be completed by the ST author.
“Application notes” is provided to clarify the intent of requirements, provide the information for the
optional items in implementation, and define "Pass/Fail" criteria for a requirement. The application
notes is provided with corresponding requirements if necessary.
CC V3.1 R5
6
1.4. Terms and definitions
Terms used in this PP, which are the same as in the CC, must follow those in the CC.
Assets
Entities that the owner of the TOE presumably places value upon
Assignment
The specification of an identified parameter in a component (of the CC) or requirement
Attack potential
Measure of the effort to be expended in attacking a TOE expressed as an attacker's expertise,
resources and motivation
Augmentation
Addition of one or more requirement(s) to a package
Authentication Data
Information used to verify a user's claimed identity
Automated recovery
Recovery without the user’s intervention
Authorized Administrator
Authorized user to securely operate and manage the TOE
Can/could
The ‘can’ or ‘could’ presented in Application notes indicates optional requirements applied to
the TOE by ST author’s choice
Class
Set of CC families that share a common focus
Component
Smallest selectable set of elements on which requirements may be based
DBMS (Database Management System)
A software system composed to configure and apply the database.
Decryption
The act that restoring the ciphertext into the plaintext using the decryption key
Dependency
Korean National Protection Profile for Web Application Firewall
7
Relationship between components such that if a requirement based on the depending
component is included in a PP, ST or package, a requirement based on the component that is
depended upon must normally also be included in the PP, ST or package
Element
Indivisible statement of a security need
Encryption
The act that converting the plaintext into the ciphertext using the encryption key
Evaluation Assurance Level(EAL)
Set of assurance requirements drawn from CC Part 3, representing a point on the CC
predefined assurance scale, that form an assurance package
External Entity
Human or IT entity possibly interacting with the TOE from outside of the TOE boundary
Family
Set of components that share a similar goal but differ in emphasis or rigour
Identity
Representation uniquely identifying entities (e.g. user, process or disk) within the context of the
TOE
Iteration
Use of the same component to express two or more distinct requirements
Local access
The access to the TOE by using the console port to manage the TOE by administrator, directly
Management access
The access to the TOE by using the HTTPS, SSH, TLS etc. to manage the TOE by administrator,
remotely
Management console
Application program that provides GUI, CLI, etc. to the administrator and provides system
management and configuration
Manual recovery
Recovery through an update server, etc. by user execution or user intervention
Object
Passive entity in the TOE containing or receiving information and on which subjects perform
operations
CC V3.1 R5
8
Operation (on a component of the CC)
Modification or repetition of a component. Allowed operations on components are assignment,
iteration, refinement and selection
Operation (on an object)
Specific type of action performed by a subject on an object
Organizational Security Policies
Set of security rules, procedures, or guidelines for an organization wherein the set is currently
given by actual or virtual organizations, or is going to be given
Private Key
A cryptographic key which is used in an asymmetric cryptographic algorithm and is uniquely
aTOEciated with an entity(the subject using the private key), not to be disclosed
Protection Profile(PP)
implementation-independent statement of security needs for a TOE type
Public Key(asymmetric) cryptographic algorithm
A cryptographic algorithm that uses a pair of public and private keys
RADIUS(Remote Authentication Dial-In User Services)
Implementation of identification and authentication of users by sending information such as user
ID, password, IP address to the authentication server, when a remote user requests access
Random bit generator (RBG)
A device or algorithm that outputs a binary sequence that is statistically independent and is not
biased. The RBG used for cryptographic application generally generates 0 and 1 bit string, and
the sequence can be combined into a random bit block. The RBG is classified into the
deterministic and non-deterministic type. The deterministic type RBG is composed of an
algorithm that generates bit strings from the initial value called a “seed key,” and the
non-deterministic type RBG produces output that depends on the unpredictable physical source.
Recommend/be recommended
The ‘recommend’ or ‘be recommended’ presented in Application notes is not mandatorily
recommended, but required to be applied for secure operations of the TOE
Refinement
Addition of details to a component
Role
Predefined set of rules on permissible interactions between a user and the TOE
Secret Key
Korean National Protection Profile for Web Application Firewall
9
A cryptographic key which is used in an symmetric cryptographic algorithm and is uniquely
aTOEciated with one or several entity, not to be disclosed
Security Function Policy(SFP)
set of rules describing specific security behaviour enforced by the TSF and expressible as a set
of SFRs
Security Target(ST)
Implementation-dependent statement of security needs for a specific identified TOE
Selection
Specification of one or more items from a list in a component
Self-test
Pre-operational or conditional test executed by the cryptographic module
Shall/must
The ‘shall’ or ‘must’ presented in Application notes indicates mandatory requirements applied to
the TOE
SSL(Secure Sockets Layer)
Security protocol developed by Netscape, is proposed to provide the security such as
confidentiality and integrity on computer network and is standardized to Transport Layer
Security (TLS).
Subject
Addition of one or more requirement(s) to a package
Symmetric cryptographic technique
Encryption scheme that uses the same secret key in mode of encryption and decryption, also
known as secret key cryptographic technique
Target of Evaluation(TOE)
Set of software, firmware and/or hardware possibly accompanied by guidance
Threat Agent
Entity that can adversely act on assets
TLS(Transport Layer Security)
This is a secure communication protocol between a server and a client based on SSL and is
described in RFC 2246.
TOE Security Functionality (TSF)
CC V3.1 R5
10
1.5. PP organization
Chapter 1 introduces to the Protection Profile, providing Protection Profile references and the TOE
overview.
Chapter 2 provides the conformance claims to the CC, PP and package; and describes the claim’s
conformance rationale and PP conformance statement.
Chapter 3 describes the security objectives for the operational environment.
Chapter 4 defines the extended components for Web Application Firewall.
Chapter 5 describes the security functional and assurance requirements. If required, Application
Combined functionality of all hardware, software, and firmware of a TOE that must be relied
upon for the correct enforcement of the SFRs
TSF Data
Data for the operation of the TOE upon which the enforcement of the SFR relies
User
See “external entity”, a user in the wireless LAN authentication server shall be an authorized
administrator, while a user in the wireless LAN authentication client shall be an authorized end
user
User Data
data for the user, that does not affect the operation of the TSF
Web Application
Applications accessed through network such as internet or intranet. Applications are usually
operated in web browsers or environments that can be controlled by web browsers, and are
formed by integrating markup languages such as HTML by using programming languages that
can be run on web browsers including JavaScript, Java Applet, etc..
Web Content
Digital documents and multimedia contents delivered through web. Digital documents include
web document files, image files, etc., and multimedia contents include animation and video files,
etc..
Web Server
Web server software receives the client (web browser)’s requested information through HTTP
protocol and transfers the result back to the client. It receives the client’s requested resource in
the form of URL (Uniform Resource Locator) and processes it by mapping it with internal file
system, or when receiving the URL and input value (e.g. ID, password, etc. at the login screen)
together, processes it as previously agreed, and send the result to the client. Apache, nginx,
and Microsoft IIS (Internet Information Services) are some of the most representative web
servers.
Korean National Protection Profile for Web Application Firewall
11
notes are provided to clarify the meaning of requirements and provide an explanation of detailed
guidelines to the ST author for correct operations.
Reference describes the references for users who need more information about the background and
related information than those described in this PP.
Abbreviated terms are listed to define frequently used terms in the PP.
CC V3.1 R5
12
2. Conformance claim
2.1. CC conformance claim
CC
Common Criteria for Information Technology Security Evaluation,
Version 3.1, Revision 5
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 1: Introduction and General Model, Version
3.1, Revision 5 (CCMB-2017-04-001, April, 2017)
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 2: Security Functional Components, Version
3.1, Revision 5 (CCMB-2017-04-002, April, 2017)
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 3: Security Assurance Components, Version
3.1, Revision 5 (CCMB-2017-04-003, April, 2017)
Conformance
claim
Part 2 Security
functional
components
Extended: FDP_EDI.1, FMT_PWD.1, FPT_LEE.1, FPT_PST.1,
FPT_TUD.1
Part 3 Security
assurance
components
Conformant
Package Augmented : EAL1 augmented (ATE_FUN.1)
2.2. PP conformance claim
This Protection Profile does not claim conformance to other PPs.
2.3. Package conformance claim
This Protection Profile claims conformance to assurance package EAL1 augmented with ATE_FUN.1.
2.4. Conformance claim rationale
Since this Protection Profile does not claim conformance to other Protection Profiles, it is not
necessary to describe the conformance claim rationale.
2.5. PP conformance statement
This Protection Profile requires “strict PP conformance” of any ST or PP, which claims conformance to
this PP.
Korean National Protection Profile for Web Application Firewall
13
3. Security objectives
The followings are the security objectives handled by technical and procedural method supported
from operational environment in order to provide the TOE security functionality accurately.
3.1. Security objectives for the operational environment
OE.LOG_BACKUP
The authorized administrator periodically checks a spare space of audit data storage in case of
the audit data loss, and carries out the audit data backup (external log server or separate storage
device, etc.) to prevent audit data loss.
OE.PHYSICAL_CONTROL
The TOE shall be located in physically secure environment to which only the authorized
administrator is allowed to access and the protective facilities are provided.
OE.SECURITY_MAINTENANCE
When the internal network environment changes due to the change in network configuration,
increase/decrease of Web Server and increase/decrease of Web Application, etc., the changed
environment and security policies must be immediately reflected to the TOE operational policies
in order to maintain the same level of security as before.
OE.TRUSTED_ADMIN
The authorized administrator of the TOE shall be non-malicious users, have appropriately trained
for the TOE management functions and accurately fulfill the duties in accordance with
administrator guidances.
OE.OPERATION_SYSTEM_REINFORCEMENT
The authorized administrator of the TOE shall ensure the reliability and security of the operating
system by performing the reinforcement on the latest vulnerabilities of the operating system in
which the TOE is installed and operated.
Application notes
Since TOE component might not use single OS independently according to TOE realization
method (when management console is included in the TOE component), the authorized
administrator should be precautious that the OS setting of external IT entity operating in a same
OS does not affect safe operation of the TOE.
OE.SINGLE_POINT_OF_CONNECTION
Connection with web server or web applications should be accessed only through TOE.
Application notes
In case of Reverse Proxy type, the TOE is installed by connecting to the switch, and to work as
CC V3.1 R5
14
the single point of connection to the web application, should be established to ensure that user’s
web access request passes the TOE by transforming the IP address of the DNS registered web
server and web applications.
Korean National Protection Profile for Web Application Firewall
15
4. Extended components definition
4.1. Cryptographic support
4.1.1. Random Bit Generation
4.1.1.1. FCS_RBG.1 Random bit generation
4.2. User data protection
4.2.1. External-stored data integrity
Family Behaviour
This family defines requirements for the TSF to provide the capability that generates random bits
required for TOE cryptographic operation.
Component leveling
FCS_RBG.1 random bit generation, requires TSF to provide the capability that generates random
bits required for TOE cryptographic operation.
FCS_RBG Random bit generation 1
Management: FCS_RBG.1
There are no management activities foreseen.
Audit: FCS_RBG.1
There are no auditable events foreseen.
Hierarchical to No other components.
Dependencies No dependencies.
FCS_RBG.1.1 The TSF shall generate random bit using the specified random bit generator
that meets the following [assignment: list of standards].
CC V3.1 R5
16
4.2.1.1. FDP_EDI.1 External-stored data integrity verification and response action
4.3. Security Management
Family Behaviour
This family defines requirements dealing with user data integrity stored in containers that is not
controlled by the TSF.
Component levelling
FDP_EDI.1 External-stored data integrity verification and response action requires external-stored
data verification of the TSF on identified integrity error and requires response action that should
be taken as a result of error detection.
FDP_EDI : External-stored data integrity 1
Management : FDP_EDI.1
The following actions could be considered for the management functions in FMT:
a) Designate external-stored integrity user data for protection.
b) Response action that should be taken in case of integrity error detection can be organized.
Audit : FDP_EDI.1
a) Minimal : Integrity verification result (success, failure) and response action
Hierarchical to: No other components.
Dependencies: No other components.
FDP_EDI.1.1 TSF shall verify the integrity of following [assignment : an administrator
configurable list of external-stored user data].
FDP_EDI.1.2 Upon detection of a external-stored user data integrity error, the TSF shall
[assignment: action to be taken].
Application notes
o In FDP_EDI.1.1, [assignment : an administrator configurable list of external-stored user data]
refers to external-stored user data object for integrity verification.
o In FDP_EDI.1.2, alarms, sending an email, etc. to the authorized administrator can be stated
in [assignment : action to be taken].
Korean National Protection Profile for Web Application Firewall
17
4.3.1. ID and password
4.3.1.1. FMT_PWD.1 Management of ID and password
Family Behaviour
This family defines the capability that is required to control ID and password management used
in the TOE, and set or modify ID and/or password by authorized users.
Component leveling
FMT_PWD.1 ID and password management, requires that the TSF provides the management
function of ID and password.
FMT_PWD ID and password 1
Management: FMT_PWD.1
The following actions could be considered for the management functions in FMT:
a) Management of ID and password configuration rules.
Audit: FMT_PWD.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Minimal: All changes of the password.
Hierarchical to No other components.
Dependencies FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_PWD.1.1 The TSF shall restrict the ability to manage the password of [assignment:
list of functions] to [assignment: the authorized identified roles].
1. [assignment: password combination rules and/or length]
2. [assignment: other management such as management of special characters
unusable for password, etc.]
FMT_PWD.1.2 The TSF shall restrict the ability to manage the ID of [assignment: list of
functions] to [assignment: the authorized identified roles].
1. [assignment: ID combination rules and/or length]
2. [assignment: other management such as management of special
characters unusable for ID, etc.]
CC V3.1 R5
18
4.4. Protection of the TSF
4.4.1. Linkable external entities
FMT_PWD.1.3 The TSF shall provide the capability for [selection, choose one of: setting ID
and password when installing, setting password when installing, changing
the ID and password when the authorized administrator accesses for the
first time, changing the password when the authorized administrator
accesses for the first time].
Application notes
o If the TOE does not provide the capability for managing the ID and password combination
rules by authorized roles, etc., ‘None.’ may be specified in assignment operations of
FMT_PWD.1.1, FMT_PWD.1.2.
o The ID and password combination rules that can be set by authorized roles may include
minimum and maximum length setting, mixing rule setting involving English upper
case/lower case/number/special characters, etc..
Family Behaviour
This family (FPT_LEE, Linkable External Entities) defines the requirement for the TSF to perform
security functions with the support of external entities. In this family, external entities refer to
software or hardware, but users are not counted as external entities.
Component leveling
FPT_LEE.1, linkable external entities, requires the TSF to provide the security functions by linking
with external entities.
FMT_LEE Linkable external entities 1
Management: FMT_LEE.1
There are no management activities foreseen.
Audit: FPT_LEE.1
It is recommended to record the following actions for audit if FAU_GEN Security audit data
generation family is included in the PP/ST:
Korean National Protection Profile for Web Application Firewall
19
4.4.1.1. FPT_LEE.1 Linkable external entities
4.4.2. Protection of stored TSF data
4.4.2.1. FPT_PST.1 Basic protection of stored TSF data
Family Behaviour
This family defines rules to protect TSF data stored within containers controlled by the TSF from
the unauthorized modification or disclosure.
Component leveling
FPT_PST.1 Basic protection of stored TSF data, requires the protection of TSF data stored in
containers controlled by the TSF.
FPT_PST Protection of stored TSF data 1
Management: FPT_PST.1
There are no management activities foreseen.
Audit: FPT_PST.1
There are no auditable events foreseen.
Hierarchical to No other components.
Dependencies No dependencies.
a) Minimal: Result of the execution of the security function provided by linking with external
entities
Hierarchical to No other components.
Dependencies No dependencies.
FPT_LEE.1.1 The TSF shall perform [assignment: list of actions) and provide [assignment:
list of functions] in connection with external entities.
Application notes
o In FPT_LEE.1.1, [assignment: List of actions] means the way the TSF is linked with external
entities, such as API function call.
o In FPT_LEE.1.1, [assignment: List of functions] shall specify the security functions (e.g.
verification of secrets, protection of authentication feedback, etc.) provided by the TSF in
linkage with external entities
CC V3.1 R5
20
4.4.3. TSF update
4.4.3.1. FPT_TUD.1 TSF security patch update
FPT_PST.1.1 The TSF shall protect [assignment: TSF data] stored in containers controlled
by the TSF from the unauthorized [selection: disclosure, modification].
Application notes
o Containers controlled by the TSF mean storage in the TOE or external entities (DBMS,
etc.)that interact with the TOE.
o Examples of TSF data to be protected as follows:
- User password, cryptographic key (pre-shared key, symmetric key, private key, etc), TOE
configuration values (security policy, configuration parameters), audit data, etc.
o The TSF data can be encrypted and stored to be protected from the unauthorized
disclosure or modification.
Family Behaviour
This family defines TOE firmware/software update requirements.
Component leveling
FPT_TUD.1 TSF security patch update, requires trusted update of the TOE firmware/software
including the capability to verify the validity on the update file before installing updates.
FPT_TUD: TSF update 1
Management: FPT_TUD.1
The following actions could be considered for the management functions in FMT:
a) Management of update file verification mechanism
Audit: FPT_TUD.1
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Minimal: Update file verification result (success, failure)
Hierarchical to: No other components.
Dependencies: No dependencies.
Korean National Protection Profile for Web Application Firewall
21
FPT_TUD.1.1 The TSF shall provide the capability to view the TOE versions to
[assignment: the authorized identified roles].
FPT_TUD.1.2 The TSF shall verify validity of the update files using [selection: hash value
comparison, digital signature verification] before installing updates.
Application notes
o The TSF shall provide the capability to check the current version of TOE that most recently
installed and executed by authorized roles.
o The latest updates and security patches are essential to remove security vulnerabilities. The
validity verification on the update files is required since the installation of update files
without any verification can result in system malfunction, or service failures, etc.
CC V3.1 R5
22
5. Security requirements
The security requirements specify security functional requirements and assurance requirements that
must be satisfied by the TOE that claims conformance to this PP.
The security functional requirements included in this PP are derived from CC Part 2 and Chapter 4
Extended Components Definition.
In addition, the security functional requirements are classified into mandatory SFRs, conditional
mandatory SFRs and optional SFRs, as follows.
Ÿ Mandatory SFRs: are required to be mandatorily implemented in the ‘Web Apllication
Firewall’
Ÿ Conditional mandatory SFRs: are required to be mandatorily implemented, if the stated
conditions are met.
Ÿ Optional SFRs: are not required to be mandatorily implemented in ‘Web Apllication Firewall’.
However, when the TOE additionally provides related capabilities, the ST
author must include the corresponding SFRs.
The following table summarizes the security functional requirements used in the PP.
Security
functional
class
Security functional component Remarks
FAU
FAU_ARP.1 Security alarms Mandatory SFR
FAU_GEN.1 Audit data generation Mandatory SFR
FAU_SAA.1 Potential violation analysis Mandatory SFR
FAU_SAR.1 Audit review Mandatory SFR
FAU_SAR.3 Selectable audit review Mandatory SFR
FAU_STG.1 Protected audit trail storage
Conditional
mandatory SFR
FAU_STG.3 Action in case of possible audit data loss
Conditional
mandatory SFR
FAU_STG.4 Prevention of audit data loss
Conditional
mandatory SFR
FCS
FCS_CKM.1 Cryptographic key generation Mandatory SFR
FCS_CKM.2 Cryptographic key distribution Optional SFR
FCS_CKM.4 Cryptographic key destruction Mandatory SFR
FCS_COP.1 Cryptographic operation Mandatory SFR
FCS_RBG.1(Extended) Random bit generation Mandatory SFR
FDP
FDP_IFC.1 Subset information flow control Mandatory SFR
FDP_IFF.1 Simples security attributes Mandatory SFR
FDP_EDI.1(Extended) External-stored data integrity verification
and response action
Mandatory SFR
Korean National Protection Profile for Web Application Firewall
23
5.1. Security functional requirements (Mandatory SFR)
A WAF that claims conformance to this PP must meet the following ‘Mandatory SFRs’.
Security
functional
class
Security functional component Remarks
FIA
FIA_AFL.1 Authentication failure handling Mandatory SFR
FIA_SOS.1 Verification of secrets Mandatory SFR
FIA_UAU.1 Timing of authentication Mandatory SFR
FIA_UAU.4 Single-use authentication mechanisms Mandatory SFR
FIA_UAU.5 Multiple authentication mechanisms
Conditional
mandatory SFR
FIA_UAU.7 Protected authentication feedback Mandatory SFR
FIA_UID.1 Timing of identification Mandatory SFR
FMT
FMT_MOF.1 Management of security functions behaviour Mandatory SFR
FMT_MSA.1 Management of security attributes Mandatory SFR
FMT_MSA.3 Static attribute initialisation Mandatory SFR
FMT_MTD.1 Management of TSF data Mandatory SFR
FMT_PWD.1(Extended) Management of ID and password Mandatory SFR
FMT_SMF.1 Specification of management functions Mandatory SFR
FMT_SMR.1 Security roles Mandatory SFR
FPT
FPT_ITT.1 Basic internal TSF data transfer protection
Conditional
mandatory SFR
FPT_LEE.1(Extended) Linkable external entities – authentication
Conditional
mandatory SFR
FPT_PST.1(Extended) Basic protection of stored TSF data Mandatory SFR
FPT_RCV.2 Automated recovery Mandatory SFR
FPT_STM.1 Reliable time stamps Optional SFR
FPT_TST.1 TSF testing Mandatory SFR
FPT_TUD.1(Extended) TSF security patch update Mandatory SFR
FTA
FTA_MCS.2
Per user attribute limitation on multiple
concurrent sessions Mandatory SFR
FTA_SSL.1 TSF-initiated session locking
Conditional
mandatory SFR
FTA_SSL.3 TSF-initiated termination
Conditional
mandatory SFR
FTA_TSE.1(1) TOE session establishment Mandatory SFR
FTA_TSE.1(2) TOE session establishment
Conditional
mandatory SFR
FTP
FTP_ITC.1 Inter-TSF trusted channel
Conditional
mandatory SFR
FTP_TRP.1 Trusted path
Conditional
mandatory SFR
[Table 1] Security functional requirements
CC V3.1 R5
24
5.1.1. Security audit (FAU)
5.1.1.1. FAU_ARP.1 Security alarms
Security
functional
class
Security functional component
FAU
FAU_ARP.1 Security alarms
FAU_GEN.1 Audit data generation
FAU_SAA.1 Potential violation analysis
FAU_SAR.1 Audit review
FAU_SAR.3 Selectable audit review
FCS
FCS_CKM.1 Cryptographic key generation
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1 Cryptographic operation
FCS_RBG.1(Extended) Random bit generation
FDP
FDP_IFC.1 Subset information flow control
FDP_IFF.1 Simples security attributes
FDP_EDI.1(Extended)
External-stored data integrity verification and response
action
FIA
FIA_AFL.1 Authentication failure handling
FIA_SOS.1 Verification of secrets
FIA_UAU.1 Timing of authentication
FIA_UAU.4 Single-use authentication mechanisms
FIA_UAU.7 Protected authentication feedback
FIA_UID.1 Timing of identification
FMT
FMT_MOF.1 Management of security functions behaviour
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
FMT_MTD.1 Management of TSF data
FMT_PWD.1(Extended) Management of ID and password
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FPT
FPT_PST.1(Extended) Basic protection of stored TSF data
FPT_RCV.2 Automated recovery
FPT_TST.1 TSF testing
FPT_TUD.1(Extended) TSF security patch update
FTA
FTA_MCS.2
Per user attribute Limitation on multiple concurrent
sessions
FTA_TSE.1(1) TOE session establishment
[Table 2] Mandatory security functional requirements
Korean National Protection Profile for Web Application Firewall
25
Hierarchical to No other components.
Dependencies FAU_SAA.1 Potential violation analysis.
FAU_ARP.1.1 The TSF shall take [assignment: list of actions] upon detection of a potential
security violation.
Application notes
o If the TOE self-test result is a failure, response functions shall be performed.
- Examples of response functions to be performed when the self-test result is a failure are
as follows:
• Program execution interruption, warning message screen display, process restart, etc.
o If the TOE integrity verification result is a failure, response functions shall be performed.
- Examples of response functions to be performed when the integrity verification result is a
failure are as follows:
• Program execution interruption, warning message screen display, etc.
5.1.1.2. FAU_GEN.1 Audit data generation
Hierarchical to No other components.
Dependencies FPT_STM.1 Reliable time stamps
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) [assignment: other specifically defined auditable events]
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if applicable),
and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of
the functional components included in the PP/ST, [assignment: other
audit relevant information].
Application notes
o The TOE shall generate audit records for major audit events.
- [Table 3] below shows the audit events for which audit records must be generated.
CC V3.1 R5
26
- [Table 4] below shows the audit events for which audit records may be generated when
providing a function.
Sub-category Audit events
Additional
audit
information
Identification and
authentication
User login and logout
User registration, change and deletion
The reaching of the threshold for the unsuccessful user
authentication attempts and the actions taken
All changes of the password
Security
management
Registration, deletion and change IP address of the
management terminals.
Execution of security management function and all changes
and deletions of security attribute values.
** However, among the security management functions,
‘Audit record inquiry’ and ‘TOE version information inquiry’
functions are excluded.
Changed
security
attribute data
Default account(ID)/Password change
Management terminal access IP blocking
Trusted
session
management
User’s session locking or termination
Response actions when duplicate login attempts of the same
account are detected
Denial of new sessions based on the limit on the number of
concurrent sessions
Cryptographic
key
generation
Cryptographic key generation failure
Cryptographic
operation
Cryptographic operation failure (including cryptographic
operation type)
Audit record
Start-up and shutdown of the TOE audit functions in the
form of H/W appliance
[Table 3] Major audit events to be recorded mandatorily.
Sub-category Audit events
Additional
audit
information
Self-protection
Execution of self-test
security
function with
failed self-test
Execution of integrity verification of the TOE itself
Components
with failed
integrity
Korean National Protection Profile for Web Application Firewall
27
o If the TOE detects an attempt to reuse authentication information that is prohibited for
reuse, authentication shall fail and an audit record of the authentication failure event shall
be generated.
o Audit records shall be generated for self-test results.
o Integrity verification contents and results shall be confirmed through screen display, audit
records.
o Audit records shall be generated for integrity verification results.
o Update file validation results(success•failure) shall be recorded in audit records.
o Audit records shall be generated for the update installation results and the reason for
failure.
o Audit records shall be generated when the session locking or termination function is
activated.
o Audit records shall be generated when blocking duplicate access.
o Audit records shall not contain more information than necessary.
- Items that shall be included at least in audit records are as follows.
• The date and time of the event, the type of event, the identity of the subject that
caused the event (e.g., account, process, IP, etc.), and the outcome of the event (success•
failure)
- Information such as authentication information (e.g., password, etc.) and encryption key
shall not be stored in the audit records.
o Sensitive data (e.g., password, resident registration number, etc.) shall not be recorded, or
shall be generated by processing with masking if record is inevitable.
o Each component of the TOE shall generate audit records using trusted time information.
- Trusted time information should use the time information provided by the NTP server or
the operating system.
o If the WAS(Tomcat, Jesus, etc.) is included in the TOE package, the TOE shall be
implemented so that important information is not included in the WAS log.
- It can be implemented so that the log may be left only in the TOE’s audit record
verification
Updated files validity verification by the administrator
Update
protection
Update
protection
Execution of update files validity verification
Audit records Start-up and shutdown of the TOE audit function in the
form of software
Audit records
Security
management
[Table 4] Audit events that must be recorded when providing a function
CC V3.1 R5
28
5.1.1.3. FAU_SAA.1 Potential violation analysis
5.1.1.4. FAU_SAR.1 Audit review
storage without leaving the WAS log.
- Important information such as passwords and encryption keys shall not be left in plain
text in the WAS log.
o The TOE shall generate audit records for major audit events.
- The TOE shall generate audit records for web traffic allowed and blocked by the TOE.
• The result of allowing and blocking web traffic according to FDP_IFF.1 shall be
included.
- It shall be possible to inquire the events that occurred during a specific period and the
total amount of blocked traffic.
- Audit records shall be generated for security management actions related to web traffic
detection and blocking rules performed by the administrator in the FMT class.
- Audit records shall include at least the date and time of the event, the type of event,
the identity of the subject that caused the event, and the outcome of the event.
Hierarchical to No other components.
Dependencies FAU_GEN.1 Audit data generation
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited
events and based upon these rules indicate a potential violation of the
enforcement of the SFRs.
FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited events:
a) Accumulation or combination of [assignment: subset of defined auditable
events] known to indicate a potential security violation
b) [assignment: any other rules]
Application notes
o If the result of the TOE’s self-test is failure, the response function shall be performed.
o The TOE shall perform the response function if the integrity verification fails.
Hierarchical to No other components.
Dependencies FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide [authorized administrator] with the capability to read
[all the audit data] from the audit records.
Korean National Protection Profile for Web Application Firewall
29
5.1.1.5. FAU_SAR.3 Selectable audit review
5.1.2. Cryptographic support (FCS)
5.1.2.1. FCS_CKM.1 Cryptographic key generation
Hierarchical to No other components.
Dependencies FAU_SAR.1 Audit review
FAU_SAR.3.1 The TSF shall provide the capability to apply [assignment: methods of
selection and/or ordering] of audit data based on [assignment: criteria with
logical relations].
Application notes
o The TOE shall provide a function for the administrator to select a logical condition when
inquiring audit records, and to search or sort the records according to various conditions.
o It shall be possible to inquire the events that occurred during a specific period and the
total amount of blocked traffic.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the
authorized administrator to interpret the information.
Application notes
o The TOE shall provide a function for the authorized administrator to inquire the audit record.
- The audit record shall be inquired only through the security function provided by the TOE.
- The TOE shall provide audit records for the authorized administrator to properly interpret
the information.
Hierarchical to No other components.
Dependencies [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Application notes
CC V3.1 R5
30
5.1.2.2. FCS_CKM.4 Cryptographic key destruction
o The TOE shall generate cryptographic keys in a secure method.
- Examples of secure cryptographic key generation methods are as follows:
• Password-based key derivation(PKCS#5 v2.1(RFC 8018), NIST SP 800-132, etc.)
• Key derivation with pre-shared keys(TTAK.KO-12.0272)
• Key generation using random bit generator(CTR_DRBG, HASH DRBG, HMAC_DRBG, etc.)
- The random bit generator shall be implemented in compliance with domestic and foreign
standards.
- It is possible to generate asymmetric key pairs (public keys/private keys) or symmetric
keys using random bits generated by the random bit generator.
- The password-based key derivation function shall only be used to generate a Key
Encryption Key(KEK).
• The initial key encryption key shall be generated differently for each TOE.
• Initial data required to generate a key encryption key can be directly entered or
injected from stored values in storage media such as smart cards, security USBs,
security tokens(HSM: Hardware Security Module).
• It is recommended to use products that have obtained security function test report or
domestic/foreign CC certificates for the storage media.
• For details, refer to the Encryption Key Generation of the ‘Encryption Key Management
Guide’ (Ministry of Science and ICT, 2014).
• If a password is used as the initial data for generating a key encryption key(KEK), the
value entered at the time of the initial installation of the product can be stored and
used, and the stored data shall be protected from unauthorized exposure attempts.
Hierarchical to No other components.
Dependencies [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destruct cryptographic keys in accordance with a specified
cryptographic key destruction method [assignment: cryptographic key
destruction method] that meets the following: [assignment: list of standards].
Application notes
o The TOE shall securely destroy the cryptographic keys generated or used in the TOE.
- △When terminating execution of the TOE, △When calling cryptographic key deletion function,
△When terminating cryptographic communication, etc., all cryptographic keys and information
related to cryptographic key that have expired shall be destroyed.
Korean National Protection Profile for Web Application Firewall
31
5.1.2.3. FCS_COP.1 Cryptographic operation
- When destroying cryptographic keys, a method of overwriting at least 3 times with values
of 0 or 1 can be used.
- For details, refer to the cryptographic key destruction method of the ‘Encryption Key
Management Guide’ (Ministry of Science and ICT, 2014).
Hierarchical to No other components.
Dependencies [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic operations] in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Application notes
o The TOE shall use the recommended cryptographic algorithm when transmitting and storing
important information.
o The recommended cryptographic algorithm is a standard algorithm with a security strength
of 112 bits or more. Refer to the [Attachment] to the auxiliary document. Examples are as
follows:
- Hash Algorithm: SHA-224 or higher
- Symmetric key Algorithm: Key length 128 bits or higher
- Public key Algorithm: RSA 2048 or higher, DSA(2018, 224) or higher
- Digital signature Algorithm: RSA-PSS 2048 or higher, KCDSA(2048, 224) or higher, ECDSA/EC-KCDSA
(B-233, B-283, K-223, K-283, P-224, P-256)
o However, the use of TDES( including 2 keys and 3 keys) is not permitted.
o When using block cipher, ECB mode shall not be used if the plain text size is larger than
the encryption block size.
o When using block cipher, fixed IV shall not be used in CFB or OFB mode.
o Domestic/foreign standard cryptographic algorithms shall be used, and the use of the national
cryptographic algorithm is recommended.
o For details of cryptographic algorithm with a security strength of 112 bits or higher, refer
to ‘Guide to Cryptographic Algorithm and Key Length’ (Ministry of Science and ICT, 2018),
‘Software Cryptographic Module Validation Standard’ and ‘NIST SP 800-131Ar2’.
CC V3.1 R5
32
5.1.2.4. FCS_RBG.1 Random bit generation (Extended)
5.1.3. User data protection (FDP)
5.1.3.1. FDP_IFC.1 Subset information flow control
Hierarchical to No other components.
Dependencies No dependencies.
FCS_RBG.1.1 The TSF shall generate random bit using the specified random bit generator
that meets the following [assignment: list of standards].
Application notes
o Examples of secure cryptographic key generation methods are as follows:
• Password-based key derivation(PKCS#5 v2.1(RFC 8018), NIST SP 800-132, etc.)
• Key derivation with pre-shared keys(TTAK.KO-12.0272)
• Key generation using random bit generator(CTR_DRBG, HASH DRBG, HMAC_DRBG, etc.)
o The random bit generator shall be implemented in compliance with domestic and foreign
standards.
o It is possible to generate asymmetric key pairs (public keys/private keys) or symmetric keys
using random bits generated by the random bit generator.
o User password used by the TOE for user identification and authentication shall be stored
using a one-way encryption(Hash) to prevent decryption.
- When performing a one-way encryption, it is necessary to add and apply a randomly
generated value called salt to the password.
- The salt value does not need to be confidential. It shall be generated using random bit
generator and the size must be at least 48 bits.
- The iteration count shall be applied as large as possible. (at least 1000 times)
Hierarchial to No other components
Dependencies FDP_IFF.1 Simples security attributes
FDP_IFC.1.1 The TSF shall enforce the [Web Firewall information flow control policy] on
[operation list that induces information flow to/from controlled subject
handled by the following subject and information list, and SFP].
a) Subject: Web client
b) Information: Web traffic transferred by the subject
c) Operation: HTTP, HTTPS request to web server and web applications
Korean National Protection Profile for Web Application Firewall
33
5.1.3.2. FDP_IFF.1 Simples security attributes
Hierarchial to No other components
Dependencies FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1 The TSF shall enforce the [Web Firewall information flow control policy]
based on the following types of subject and information security attributes:
[following subject and information list, subject and information security
attributes controlled by the Web Firewall information flow control policy].
a) Subject and subject security attributes
b) Information and information security attributes
Subject Subject security attributes
Web client
{Decided by the ST author of statement
of security objectives}
Information Information security objectives
Web traffic transferred by
the subject
{Decided by the ST author of statement
of security objectives}
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[assignment: for each operation, the security attribute-based relationship that
must hold between subject and information security attributes].
FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow control
SFP rules].
FDP_IFF.1.4 The TSF shall explicitly authorise an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly authorise
information flows].
FDP_IFF.1.5 The TSF shall explicitly deny an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly deny
information flows].
Application notes
ㅇ The TOE shall be able to detect and block abnormal traffic by determining whether the web
traffic generated and transmitted by a malicious user is normal.
- The TOE shall detect and block various attack patterns, such as the latest list of vulnerabilities
Application notes
ㅇ The TOE shall be able to detect and block abnormal traffic by determining whether the web
traffic generated and transmitted by a malicious user is normal.
o The TOE must be able to allow or block web traffic (HTTP and HTTPS) flowing into the
protected target web server according to the rules set by the authorized administrator.
CC V3.1 R5
34
5.1.3.3. FDP_EDI.1 External-stored data integrity verification and response action
published by OWASP and vulnerabilities determined by the evaluation facilities and
certification body to require mandatory measures.
• Detection signatures for known web attacks and web vulnerabilities shall be provided by
the TOE.
- The TOE shall detect and block HTTP and HTTPS service denial attacks of the following L7
layer.
• HTTP GET Flooding, CC(Cache-Control) Attack, Slow HTTP Header DoS, Slow HTTP Post
DOS, Slow HTTP Read DoS, etc.
- The TOE shall respond to web-based attacks to bypass its own security functions as follows.
• IIS Short File/Floder Name Disclosure (IIS web server information disclosure) vulnerabilities,
Big-HTTP Request attack, attack using modified SQL comments, Method Confusion attack
technique using confusion between Get and Post method, etc.
- The TOE shall provide the ability to update to the latest signature.
o The TOE shall be able to allow or block web traffic (HTTP and HTTPS) flowing into the
protected target web server according to the rules set by the authorized administrator.
- Detection rules can be set by the administrator, which shall support pattern matching using
regular expressions.
• Content analysis and detection rules for HTTP 1.0/1.1, HTTP 2.0, and web services (SOAP,
WSDL, UDDI, etc.) shall be applicable.
- Detection rules shall be able to set and control based on the types of security attributes for
subjects and information.
• Examples of subject security attributes: IP address, MAC address, web browser name, web
browser version, OS name, OS version, etc.
• Examples of information security attributes: Method, URL, HTTP version, request header
information (Cookie, Content-Type, etc.), request body information (Message-Body, etc.)
- The white list method is recommended for information flow control of web application
services (specific directory, IP address (transmission and reception)) and the black list
method is recommended for blocking abnormal web traffic based on signatures.
o The TOE shall generate audit records audit for major audit events.
- Audit records on web traffic allowed and blocked by the TOE shall be generated.
• The results of allowing and blocking web traffic by FDP_IFF.1 shall be included.
Hierarchial to No other components
Dependencies No other components
FDP_EDI.1.1
TSF shall verify the integrity of following [assignment : an administrator
Korean National Protection Profile for Web Application Firewall
35
5.1.4. Identification and authentication (FIA)
5.1.4.1. FIA_AFL.1 Authentication failure handling
configurable list of external-stored user data].
FDP_EDI.1.2 Upon detection of a external-stored user data integrity error, the TSF shall
[assignment: action to be taken].
Application notes
o The TOE shall verify the integrity of web contents, and when an integrity error is detected, it
shall perform response actions (alarm, mail, recovery, etc.) set by the authorized administrator.
- The administrator shall be able to designate web contents subject to integrity protection
(homepage, picture, file, etc.).
Hierarchical to No other components.
Dependencies FIA_UAU.1 Timing of authentication
FIA_AFL.1.1 The TSF shall detect when [selection: [assignment: positive integer number],
an administrator configurable positive integer within [assignment: range of
acceptable values]] unsuccessful authentication attempts occur related to
[assignment: list of authentication events].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been
met, the TSF shall [assignment: list of actions].
Application notes
o If user authentication fails consecutively as many times as the set number in the TOE, the
identification and authentication functions shall be deactivated.
- Examples of how to activate after deactivating the identification and authentication
functions are as follows:
• Activation in a specified period of time after account lock-out
• Provision of other identification and authentication means for activation after account
lock-out
- Additional identification and authentication means specified in FIA_UAU.1 may be provided.
In case of authentication failure with additional identification and authentication means, it
shall be included in the number of user authentication failures.
- The number of consecutive authentication failures in which identification and authentication
are deactivated shall be fixed or settable at a value of 5 or less.
- When implementing to deactivate the authentication function for a certain period of time,
the time required for re-activation shall be fixed or settable at a value of 5 minutes or
more.
CC V3.1 R5
36
5.1.4.2. FIA_SOS.1 Verification of secrets
o If administrator authentication fails consecutively as many times as the set number, the
TOE shall notify the administrator through means that can be immediately checked.
- Notification shall be made through at least one of alarm, text messaging, e-mail, etc.
Hierarchical to No other components.
Dependencies No dependencies.
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [assignment:
a defined quality metric].
Application notes
o If ID/password is the only means of user identification and authentication, the TOE shall
meet the security criteria of Password Security Criteria Type(1) when registering and
changing passwords.
<Password Security Criteria Type(1)>
o If ID/password input and additional identification and authentication functions are performed
concurrently, the TOE shall meet the security standards of Password Security Standard
Type(2) when registering and changing passwords.
<Password Security Criteria Type(2)>
Description Contents Remarks
Compliance
Secure the length of more than 9 digits Mandatory
Contains at least one number, uppercase
letter(english), lowercase letter(english), and
special character
Mandatory
Prohibition
Do not set the same password as the user
account (ID)
Mandatory
Prohibition of consecutive repeated input of
the same letter/number
Mandatory
Prohibit sequential input of consecutive letters
or numbers on the keyboard
Mandatory
Prohibition of reuse of the password used
immediately before Implement either one of the
two
Prohibition of reuse of the password used
within the past 3 months
Description Contents Remarks
Compliance
Secure the length of more than 6 digits. Mandatory
Contains at least one number, uppercase
letter(english), lowercase letter(english), and
special character.
Optional
Prohibition Do not set the same password as the user Mandatory
Korean National Protection Profile for Web Application Firewall
37
5.1.4.3. FIA_UAU.1 Timing of authentication
account (ID)
Prohibition of consecutive repeated input of
the same letter/number
Optional
Prohibit sequential input of consecutive letters
or numbers on the keyboard
Optional
Prohibition of reuse of the password used
immediately before
Optional
Prohibition of reuse of the password used
within the past 3 months
Optional
Hierarchical to No other components.
Dependencies FIA_UID.1 Timing of identification
FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF mediated actions] on behalf of
the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user, except for
the actions specified in FIA_UAU.1.1.
Application notes
o The TOE shall provide user account/password-based identification and authentication
functions to verify the identity of the user.
- Identification and authentication must be performed to confirm that the user is a
legitimate user of the TOE.
- If it is required to identify and authenticate users who exist in the agents or clients
constituting the TOE, the identification value shall be a unique value that is not
registered in duplicate.
• When authenticating the user, the additional attributes of the registered agents or
clients shall also be authenticated.
• Additional attributes: IP address is mandatory, and at least one of the MAC address,
Serial Number, and information that can uniquely identify the agent itself shall be
additionally used.
o In case of the TOE supports additional identification and authentication methods, for user
identification and authentication, the TOE must provide additional identification and
authentication functions on its own or by interacting with external IT entities in parallel
with user account and password-based identification and authentication.
- In order to provide additional identification and authentication functions, △2FA support
device complying with FIDO standards, △certificates, △one-time password generator(OTP),
etc. can be used.
CC V3.1 R5
38
5.1.4.4. FIA_UAU.4 Single-use authentication mechanisms
5.1.4.5. FIA_UAU.7 Protected authentication feedback
• If it is supported in the TOE operating environment, ‘2FA support device complying
with FIDO standards’ is recommended.
- If additional identification and authentication functions are provided by the TOE, the
functions can be provided by receiving the authentication results from the inside of the
TOE or from interaction with the external IT entities.
• If the TOE provides a certificate utilization method, certificate validation shall be
performed.
• The authentication information used by external IT entities to perform additional
identification and authentication methods shall be securely managed by the external IT
entities. If the TOE stores authentication information use to perform additional
identification and authentication methods, the requirements of FPT_PST.1 shall be
applied.
o If the TOE authenticates external IT entities, the TOE shall authenticate the interacted
external IT entities.
Hierarchical to No other components.
Dependencies No dependencies.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [assignment:
identified authentication mechanism(s)].
Application notes
o The TOE shall prevent reuse of user’s authentication information(using timestamp, encrypting
session ID, etc.)
- It is mandatory to apply to authentication information to be used for user account/password-based
identification and authentication specified in FIA_UAU.1.
- If the TOE receives authentication information from the user to provide additional identification
and authentication methods specified in FIA_UAU.1, it is mandatory to apply to the
corresponding authentication information.
- It can be prevented by encrypting the session ID or guaranteeing the uniqueness of the
session ID(including timestamp and random bit values, setting session expiration time,
etc.)
- If the TOE detects an attempt to reuse authentication information that is prohibited from
being reused, authentication shall fail and an audit record shall be generated for the
authentication failure event.
Hierarchical to No other components.
Dependencies FIA_UAU.1 Timing of authentication
Korean National Protection Profile for Web Application Firewall
39
5.1.4.6. FIA_UID.1 Timing of identification
Hierarchical to No other components.
Dependencies No dependencies.
FIA_UID.1.1 The TSF shall allow [assignment: list of TSF-mediated actions] on behalf of
the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user, except for the
actions specified in FIA_UAU.1.1.
Application notes
o The TOE shall provide user account/password-based identification and authentication
functions to verify the identity of the user.
- Identification and authentication must be performed to confirm that the user is a
legitimate user of the TOE.
o When supporting additional identification and authentication methods, the TOE shall
provide additional identification and authentication functions on its own or in conjunction
with external IT entities, in parallel with user account/password-based identification and
authentication.
o If the TOE authenticates external IT entities, the TOE shall authenticate the interacted
external IT entities.
FIA_UAU.7.1 The TSF shall provide only [assignment: list of feedback] to the user while
the authentication is in progress.
Application notes
o The TOE shall not display the contents when displaying the information used for
authentication on the output device.
- It shall be applied when the authentication information specified in FIA_UAU.1 is displayed
on the output device.
- The information used for authentication shall be output in the form of no-display of
input contents, display of “*” instead of input characters, etcs.
- When users log in, the authentication information shall not be exposed with plain text
in the memory area.
o In case of identification and authentication failures, the TOE shall not provide the feedback
for the cause of failure (e.g. non-existent account(ID), password error, etcs.).
CC V3.1 R5
40
5.1.5. Security management (FMT)
5.1.5.1. FMT_MOF.1 Management of security functions behaviour
Hierarchical to No other components.
Dependencies FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_MOF.1.1 The TSF shall restrict the ability to conduct management actions of the
functions [assignment: list of functions] to [the authorized administrator].
Application notes
o The TOE shall provide the authorized administrator with the security management functions
to set and manage security functions, security policies, important data, etc.
- The security management functions include the followings:
• A function to add, delete or change conditions or rules that can determine the
operation of the security function.
• A function to add, remove or change the actions to be performed by the TOE in
accordance with the conditions or rules.
• A function to select or change TOE settings
- The security management functions to be implemented by the TOE are shown in [Table 5]
below.
Sub-category Security management Remarks
Identification
a n d
authentication
User registration, deletion and change, grant
privileges
Not applicable, if the
user registered in the
TOE is the only one.
Setting user’s password combination/length policy
Mandatory when
providing the function
Setting the allowed number of user’s
authentication failures
Mandatory when
providing the function
Setting the response methods to user’s
authentication failures
Mandatory when
providing the function
Setting the time from deactivation of user’s
authentication function to re-activation
Mandatory when
providing the function
Setting the authentication information of external
IT entities that is authenticated by the TOE.
Mandatory when
providing the function
IP registration, deletion and change of the
management terminals
S e c u r i t y
management
Backup of important data, configuration
information, audit records, etc.
Mandatory when
providing the function
Recovery of of important data, configuration
information, audit records, etc.
Mandatory when
providing the function
Korean National Protection Profile for Web Application Firewall
41
o The TOE shall provide enable/disable functions for all management access.
o If the agent itself has a security management function, the server shall be able to enable/disable
the agent setting function.
o The communication service that does not support encrypted communication channels shall be
able to be disabled.
o During TOE operation, it shall support the self-test execution periodically or by administrator’s
request.
o To ensure correct operation, the TOE shall perform the response function implemented on
its own or the response function set by the administrator when the self-test fails.
o The TOE shall provide the administrator with the function to perform integrity verification.
Enabling and disabling management access service
Mandatory when
providing the function
S e c u r i t y
management
Agent inquiry - status, version, and applied
security policy
Mandatory when
including agents
Agent security policy management – policy
settings, policy transmission
Mandatory when
including agents
Setting the authentication information for access
to external IT entities
Mandatory when
providing the function
Performing self-test for TOE’s security function by
administrator’s request
Mandatory when
providing the function
Self-protection
Setting response actions when self-test fails
Mandatory when
providing the function
Performing an integrity verification of the TOE
setting values and the TOE itself by the
administrator's request
Setting response actions when integrity verification
fails
Mandatory when
providing the function
Manual validation of update files by
administrator
Mandatory when
providing the function
U p d a t e
protection
Manual recovery of failed installation of update
files by administrator
Mandatory when
providing the function
Inquiry of TOE version information
User session locking time, user session timeout
time setting
Mandatory when
providing the function
Safe session
management
(In case session locking) Administrator or
individual user authentication when unlocking
sessions
Setting the number of concurrent user access
sessions
Mandatory when
providing the function
Inquiry of audit records
Audit records
Response-related settings for loss of audit records
Mandatory when
providing the function
[Table 5] Security management functions to be implemented by TOE
CC V3.1 R5
42
5.1.5.2. FMT_MSA.1 Management of security attributes
o The TOE shall perform the response function implemented on its own or the response
function set by the administrator when the integrity verification fails.
o If the TOE provides online update or manual update function, only the update files that
have succeeded in validation shall be installed or applied.
o If the TOE does not provide the function of automatically maintaining the existing version
when the update installation fails, manual recovery by the administrator shall be supported.
o Locked sessions shall be unlocked by the administrator or through the user authentication
function for each session, after the locking time has elapsed.
o Additionally, the TOE may provide a function to send audit records to external log servers
by administrator.
- If syslog is supported, it shall support encrypted transmission through syslog over TLS(RFC
5424), or syslog over DTLS(RFC 6012).
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall meet the requirements of ‘Protection when storing cryptographic key’ of FCS
class and FPT_PST.1.
o The TOE shall restrictively allow only authorized administrators to perform security management
functions that can set and manage web traffic detection and blocking rules.
- The security management functions are as follows.
• Ability to add, delete, or change operating conditions or rules for security functions that
detect or block web traffic
• Signature (detection patterns) update
• Generation of new signatures (detection patterns)
• Change of the thresholds at which the blocking function of the TOE operates
• Change of execution period of traffic blocking action
• Change of white list and black list IP address or range
• Function to add, remove, change actions to be performed by the TOE according to
conditions or rules
- The verification function for administrator input values ​​(restrictions on unacceptable characters,
length, etc.) shall be provided.
Hierarchical to No other components.
Dependencies [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_MSA.1.1 The TSF shall enforce the [assignment: access control SFP, information flow
Korean National Protection Profile for Web Application Firewall
43
control SFP] to restrict the ability to [selection: change_default, query,
modify, delete, [assignment: other operations]] the security attributes
[assignment: list of security attributes] to [the authorized Administrator].
Application notes
o The ST author shall define FMT_MSA.1.1 assignment operation with reference to '[Table]
Security attribute management type fo each component' if the TOE supports security
attribute management functions.
o The ST author can define additional security attribute management actions in addition to
management function that are presented in '[Table] Security attribute management type fo
each component'. Management actions of security attributes for additional or extended
requirements other than the security function requirements defined in this document can
be presented.
<Table. Security attribute management type fo each component>
o The TOE shall be able to allow or block web traffic (HTTP and HTTPS) flowing into the
protected target web server according to the rules set by the authorized administrator.
- Detection rules can be set by the administrator, which shall support pattern matching using
regular expressions.
• Content analysis and detection rules for HTTP 1.0/1.1, HTTP 2.0, and web services (SOAP,
WSDL, UDDI, etc.) shall be applicable.
- Detection rules shall be able to set and control based on the types of security attributes for
subjects and information.
• Examples of subject security attributes: IP address, MAC address, web browser name, web
browser version, OS name, OS version, etc.
• Examples of information security attributes: Method, URL, HTTP version, requested header
information (Cookie, Content-Type, etc.), requested body information (Message-Body, etc.)
- The white list method is recommended for information flow control of web application
services (specific directory, IP address (transmission and reception)) and the black list method
Security
function
components
Management functions Management types
FDP_IFF.1
Managing the attributes used to make explicit
access based decision
Management of security attributes
FDP_EDI.1
Management of the data attributes used for
external-stored user data for integrity protection
Management of security attributes
FMT_MSA.1
Management of rules by which security attributes
security attributes inherit specified values
Management of security attributes
FMT_MSA.3
Management of permissive or restriictive setting
of default values for a given access control SFP
Management of rules by which security attributes
inherit specified values
Management of security attributes
CC V3.1 R5
44
5.1.5.3. FMT_MSA.3 Static attribute initialisation
5.1.5.4. FMT_MTD.1 Management of TSF data
is recommended for blocking abnormal web traffic based on signatures.
Hierarchical to No other components.
Dependencies FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the [Web application firewall information flow control
policy] to provide [selection, choose one of: restrictive, permissive,
[assignment: other property]] default values for security attributes that are
used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [ the authorized administrator ] to specify
alternative initial values to override the default values when an object or
information is created.
Application notes
o The TOE shall be able to allow or block web traffic (HTTP and HTTPS) flowing into the
protected target web server according to the rules set by the authorized administrator.
- Detection rules can be set by the administrator, which shall support pattern matching using
regular expressions.
• Content analysis and detection rules for HTTP 1.0/1.1, HTTP 2.0, and web services (SOAP,
WSDL, UDDI, etc.) shall be applicable.
- Detection rules shall be able to set and control based on the types of security attributes for
subjects and information.
• Examples of subject security attributes: IP address, MAC address, web browser name, web
browser version, OS name, OS version, etc.
• Examples of information security attributes: Method, URL, HTTP version, requested header
information (Cookie, Content-Type, etc.), requested body information (Message-Body, etc.)
- The white list method is recommended for information flow control of web application
services (specific directory, IP address (transmission and reception)) and the black list method
is recommended for blocking abnormal web traffic based on signatures.
Hierarchical to No other components.
Dependencies FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_MTD.1.1 The TSF shall restrict the ability to manage [assignment: list of TSF data] to
[assignment: the authorized roles].
Korean National Protection Profile for Web Application Firewall
45
Application notes
o The TOE shall provide the authorized administrator with the security management functions
to set and manage security functions, security policies, important data, etc.
- The security management functions include the followings:
• A function to add, delete or change conditions or rules that can determine the
operation of the security function.
• A function to add, remove or change the actions to be performed by the TOE in
accordance with the conditions or rules.
• A function to select or change TOE settings
- The security management functions to be implemented by the TOE are shown in [Table
5].
o The administrator shall be able to grant privileges each user or each group.
o The user account(ID) is a unique value and shall not be registered in duplicate.
o The number of consecutive authentication failures in which identification and authentication
are deactivated shall be fixed or settable at a value of 5 or less.
o When implementing to deactivate the authentication function for a certain period of time,
the time required for re-activation shall be fixed or settable at a value of 5 minutes or
more.
o If ID/password is the only means of user identification and authentication, the TOE shall
meet the security criteria, <Password Security Criteria Type(1)> of FIA_SOS.1 when
registering and changing passwords.
o If ID/password input and additional identification and authentication functions are
performed concurrently, the TOE shall meet the security criteria, <Password Security
Criteria Type(2)> of FIA_SOS.1 when registering and changing passwords.
o If ID/password input and additional identification and authentication functions are
performed concurrently, the TOE shall meet the security standards, <Password Security
Standard Type(2)> of FIA_SOS.1 when registering and changing passwords.
o If authentication information necessary for external IT entity authentication is required to
be set, the TOE shall provide the function to set the information necessary for external IT
entity authentication.
- The application target may be a pre-shared key for the authentication server connection,
an SNMP authentication/encryption password, etc.
- When passwords are used for external IT entity authentication, the security criteria,
<Password Security Criteria Type(1)> or <Password Security Criteria Type(2)>of FIA_SOS.1
shall be complied with.
o The TOE shall provide a function to limit the IP of the accessible management terminals.
- The IP address of the management terminals shall be able to be registered, deleted or
CC V3.1 R5
46
changed.
- Management terminals that can be accessed by administrators who have only read
permission instead of for management purpose (e.g., monitoring administrators, etc.) can
be additionally registered and operated.
- Only one single host IP address can be added per time for accessible management
terminals.
- A method of specifying an IP address range, such as 192.168.10.2~253, or registration
using 0.0.0.0, 192.168.10.*, any, etc. which means the the entire network range is not
allowed.
o When providing a function that requires a password to access internal components of
the TOE or external IT entities, the TOE shall provide the default password change
function used to access internal components or external IT entities.
- Examples of default passwords include DBMS passwords and web server/WAS server
passwords.
- If the TOE stores the default password to access the DBMS, the TOE shall provide a
function to change the default password.
- Examples of authentication information include the password used to authenticate the
TOE in the SMTP server.
- Depending on whether additional identification and authentication functions are
concurrently used when generating a password, the security criteria, <Password Security
Criteria Type(1)> or <Password Security Criteria Type(2)> of FIA_SOS.1 shall be complied
with.
- If a default account(ID) exists in the TOE to access DBMS/Web Server/WAS Server, a
function to change it may be provided.
o If an external IT entity interacted with the TOE requests authentication information for
TOE authentication, the TOE shall provide a function to set the authentication
information required to be authenticated by the external IT entity.
- Examples of authentication information include the password used to authenticate the
TOE in the SMTP server.
- It is recommended that passwords should comply with the security criteria, <Password
Security Criteria Type (2)> of FIA_SOS.1.
• However, even the characters included in the password security criteria may not include
characters that are not permitted to be entered by the interacted external IT entity.
o The TOE shall provide an interface that allows only authorized administrators to access
the TOE settings, and other persons than authorized administrators shall not be able to
access the TOE settings.
- Access means operations such as read, change, and delete, etc.
o When providing the function to backup the TOE settings in the form of external file, an
Korean National Protection Profile for Web Application Firewall
47
encryption function shall be provided.
ㅇ For encryption, the encryption algorithm used, encryption key security, and encryption key
storage method shall satisfy the 'protection when storing encryption key' requirements of
FCS class and FPT_PST.1.
o The TOE shall provide a function for the administrator to check the contents and results
of integrity verification.
- The contents and results of integrity verification shall be confirmed through screen
display, audit records.
o The TOE shall provide a function for users to check ‘the unique identification information
of the TOE’.
- The TOE identification information must be unique, can be checked by the user through
the interface, and cannot be modified or changed. It shall include the following:
• TOE name, TOE version, TOE release or build number
- If the TOE includes multiple components that are physically separated, the identification
information of each component shall be unique, can be checked, and cannot be
modified or changed by users. It shall include the following:
• The name and version of the TOE including the component, the component name, the
component version, and the component release or build number
- A version management system shall be applied to check the patch of the TOE/components
and whether functions are improved.
(e.g., In case of patch and function improvement, a system for changing the major version,
minor version, release number, and build number for each case is established to track
the reason for the change of TOE/components with version information)
- In case of hardware appliance, users shall be able to view the unique identification
information of the firmware in addition to TOE identification information through TOE
interface.
ㅇ A certain amount of time, which is the cumulative amount of time after connection that
triggers user session locking or session time-out, the administrator can fix the
accumulated amount of time from a value of 10 minutes or less, or set it in proportion
to the number of authentication failures.
o Audit records shall be inquired only through the security function provided by the TOE.
o The relevant user interface(UI) and CLI commands shall not be provided so that even an
authorized administrator cannot delete or change audit records.
o Examples of conditions to notify administrators related to audit record loss response are
as follows.
- 90% or more of the setup disk capacity, 100 MB or more, etc.
o The TOE shall restrictively allow only authorized administrators to perform security management
functions that can set and manage web traffic detection and blocking rules.
CC V3.1 R5
48
5.1.5.5. FMT_PWD.1 Management of ID and password (Extended)
- The security management functions are as follows.
• Ability to add, delete, or change operating conditions or rules for security functions that
detect or block web traffic
• Signature (detection patterns) update
• Generation of new signatures (detection patterns)
• Change of the thresholds at which the blocking function of the TOE operates
• Change of execution period of traffic blocking action
• Change of white list and black list IP address or range
• Function to add, remove, change actions to be performed by the TOE according to
conditions or rules
- The verification function for administrator input values ​​(restrictions on unacceptable characters,
length, etc.) shall be provided.
Hierarchical to No other components.
Dependencies FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_PWD.1.1 The TSF shall restrict the ability to manage the password of [assignment:
list of functions] to [the authorized administrator].
1. [assignment: password combination rules and/or length]
2. [assignment: other management such as management of special
characters unusable for password, etc.]
FMT_PWD.1.2 The TSF shall restrict the ability to manage the ID of [assignment: list of
functions] to [the authorized administrator].
1. [assignment: ID combination rules and/or length]
2. [assignment: other management such as management of special
characters unusable for ID, etc.]
FMT_PWD.1.3 The TSF shall provide the capability for [selection: setting ID and password
when installing, setting password when installing, changing the ID and
password when the authorized administrator accesses for the first time,
changing the password when the authorized administrator accesses for the
first time].
Application notes
o The user account(ID) is a unique value and shall not be registered in duplicate.
o The TOE shall provide a function to forcibly change/generate the administrator default
password during the initial access (management access, local access) to the TOE.
Korean National Protection Profile for Web Application Firewall
49
5.1.5.6. FMT_SMF.1 Specification of Management Functions
5.1.5.7. FMT_SMR.1 Security roles
5.1.6. Protection of TSF (FPT)
5.1.6.1. FPT_PST.1 Basic protection of stored TSF data (Extended)
- If there is a default password, the function to change the default password shall be
provided during the initial access to the TOE, and then management and local access to
the TOE shall be possible.
- If there is no default password, a new password shall be created, and then management
and local access to the TOE shall be possible.
• Passwords shall comply with the security criteria, <Password Security Criteria Type (1)> or
<Password Security Criteria Type (2)> of FIA_SOS.1.
- If there is no default account(ID), a new account(ID) shall be created, and then management
and local access to the TOE shall be possible.
Hierarchical to No other components.
Dependencies FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [assignment: the authorized identified
roles].
FMT_SMR.1.2 TSF shall be able to associate users and their roles defined in FMT_SMR.1.1.
Hierarchical to No other components
Dependencies No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [assignment: list of management functions to be provided by the
TSF].
Hierarchical to No other components.
Dependencies No dependencies.
FPT_PST.1.1 The TSF shall protect [assignment: TSF data] stored in containers controlled
by the TSF from the unauthorized disclosure, modification.
Application notes
1. Protection when storing TSF data (important information)
o The TOE shall store important information in a secure way when storing it inside the TOE.
CC V3.1 R5
50
- At least when the TOE stores the following important information, it shall be encrypted and
stored.
• Password used by the TOE for user identification and authentication
• Authentication information used by the TOE for additional identification and authentication
• Data Encryption Key(DEK)
- The data encryption key(DEK) shall be encrypted and stored using the key encryption
key(KEK).
- Requirements related to generation and storage of key encryption key(KEK) shall satisfy the
'protection when storing encryption key' requirements of FCS_CKM.1(1), FCS_CKM.1(2) and
FPT_PST.1.
- When the TOE stores the following information, it must be stored using encryption, access
control, etc.
• Information used for mutual authentication when the TOE and external IT entities are
interacted
• DBMS/web server/WAS server's administrator password required for the TOE to access
DBMS/web server/WAS server that exist inside or outside the TOE.
• Encryption key (pre-shared key, symmetric key, private key)
- The user password used by the TOE for user identification and authentication shall be stored
using one-way encryption(hash) to prevent decryption.
• When performing one-way encryption, it is necessary to add and apply a randomly
generated value called salt to the password.
• The salt value does not need to be confidential. It shall be generated using a random bit
generator and the size must be at least 48 bits.
• The iteration count shall be applied as large as possible (at least 1000 times).
- DBMS/Web server/WAS server's administrator password, etc. required for TOE operation can
be stored after being encrypted by applying the public key/symmetric key encryption
algorithm.
- Encryption key means pre-shared key, symmetric key, private key, etc., and covers all keys
used for TOE management access/local access, and interaction settings among TOE
components.
- Passwords and encryption keys included in the minimum important information that shall be
encrypted shall not be stored in the TOE by hard-coding.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy the requirements of 'protection when storing cryptographic key' of FCS
class and FPT_PST.1.
Korean National Protection Profile for Web Application Firewall
51
2. Protection when storing TSF data (settings, audit records)
ㅇ The TOE shall provide a function to protect the stored TOE setting values (security policies, environment
setting parameters, etc.) so that only authorized administrators can access.
- For hardware appliance-type TOE, the TOE settings stored inside shall be protected, and for
software-type TOE, the TOE settings stored in the store controlled by the TOE after
installation.
- The TOE shall provide an interface that allows only authorized administrators to access TOE
settings, and other persons than authorized administrators shall not be able to access TOE
settings
• Access means operations such as read, change, delete, etc.
- When providing the function to backup the TOE settings in the form of external files, an
encryption function shall be provided.
- During encryption, the encryption algorithm used, encryption key security, and encryption key
storage method shall satisfy the 'protection when storing encryption key' requirements of
FCS class and FPT_PST.1.
o If WAS(Tomcat, Jesus, etc.) is included in the TOE package, the TOE shall implement not to
include important information in the WAS log.
- Important information such as passwords and encryption keys shall not be left in plain text
in the WAS log.
o The TOE may safely encrypt and store audit records when they are stored inside the TOE.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy the requirements of 'protection when storing cryptographic key' of FCS
class and FPT_PST.1.
3. Protection when storing cryptographic key
o The TOE shall store the cryptographic key in a secure way.
- Data encryption key(DEK) can be stored by using key encryption key(KEK).
- Key Encryption Key(KEK) can be generated through multiple stages of key chain, among
which the final key encryption key(KEK) can be encrypted and stored using the key
encryption key(KEK) of the previous stage.
- The key encryption key(KEK) except the final key encryption key(KEK) in the key chain cannot
be stored.
- When the cryptographic key is stored outside the TOE, it is recommended to use storage
media that have been verified for safety such as smart cards, security USBs, and security
tokens(HSM).
• It is recommended to use a product that has obtained a security function test report or a
domestic/foreign CC certificate for the storage media.
CC V3.1 R5
52
5.1.6.2. FPT_RCV.2 Automated recovery
- Hard-coding and storing the encryption key in the TOE are not permitted.
- As shown in the [Table 6] below, the applicant shall identify all cryptographic keys used for
storage and transmission in the TOE, and prove security by submitting a list and explanatory
materials for key storage and destruction methods.
- When the TOE stores cryptographic keys (pre-shared key, symmetric key, private key, etc.)
used for local/administrative access for TOE management and for interacted setting with
separate equipment, it shall be protected and stored in a way such as encryption, access
control, etc.
Cryptographic key type How to store and destroy keys
TLS private key
- Type: RSA Private Key
- Generator: Generated by TOE
- Storage/Protection: Store in the TOE/Block unauthorized
access to TOE storage area
- Destruction: Overwrite 3 times with 0 and 1 when
executing key destruction command
TLS session encryption
key
- Type: ARIA Key
- Generator: Generated by TOE
- Storage/Protection: Store only in memory(RAM)
- Destruction: Overwrite 3 times with 0 and 1 when at the
end of the session
TLS session integrity
verification key
- Type: HMAC Key
- Generator: Generated by TOE
- Storage/Protection: Store only in memory(RAM)
- Destruction: Overwrite 3 times with 0 and 1 when at the
end of the session
[Table 6] How to store and destroy cryptographic keys
Hierarchical to FRP_RCV.1 Manual recovery
Dependencies AGD_OPE.1 Operational user guidance
FPT_RCV.2.1 When automated recovery from [assignment: list of failures/service
discontinuities] is not possible, the TSF shall enter a maintenance mode
where the ability to return to a secure state is provided.
FPT_RCV.2.2
For [assignment: list of failures/service discontinuities], the TSF shall ensure
the return of the TOE to a secure state using automated procedures.
Application notes
Korean National Protection Profile for Web Application Firewall
53
5.1.6.3. FPT_TST.1 TSF testing
o The TOE shall provide the function to update to the latest signature.
o If the update function is provided, the TOE shall provide a function to automatically maintain
the existing version when the update installation fails.
- If it is not supported by the TOE, manual recovery by the administrator shall be supported.
- The sponsor shall describe the manual recovery procedure by the administrator in detail in
the deliverables.
Hierarchical to No other components.
Dependencies No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self tests [selection: at the initial start-up,
periodically during normal operation, upon the request of authorized user,
at the conditions [assignment: conditions under which self-test should occur]
to demonstrate the correct operation of [selection: [assignment: parts of
TSF], the TSF].
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify the
integrity of [selection: [assignment: parts of TSF data], TSF data].
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF].
Application notes
1. TOE server self-test, response function, and audit record generation
o The TOE shall perform self-test during initial start-up(or execution)/operation periodically or at
the request of the administrator.
- When initial start-up(or execution) the TOE, it is mandatory to perform self-test, and during
operation, it shall support the perform self-test periodically or at the request of the
administrator.
- The self-test target means the main process of the TOE, and shall check whether the
process is running normally.
- The subject of self-test can be selected by the applicant, but if the entity’s abnormal
state(e.g., error, stop, etc.) affects the security function of the TOE, the corresponding entity
shall be included as the subject of self-test.
- The history of self-testing shall be confirmed through screen output, audit records.
- The hardware appliance-type TOE shall satisfy the following requirements.
• A self-test shall be performed to detect errors in hardware(e.g., memory, flash, NIC, etc.)
CC V3.1 R5
54
and software(e.g., process, etc.) included in the scope of the TOE at the start-up and
during operation of the TOE.
- If physically separated TOE components exist, self-test shall be performed by selecting the
subjects to include all components.
- The sponsors shall describe the self-test function in detail in the submission document.
o If the TOE self-test result is a failure, it shall perform the response function.
- The TOE shall perform the implemented response function or the response function set by
the administrator to ensure correct operation.
- Audit records shall be generated for self-test results.
- Examples of response functions performed when the self-test result is a failure are as
follows.
• Termination of program, warning message screen display, restart process, etc.
- A security management function may be provided for the administrator to set the response
function.
2. TOE server integrity verification, response function, and audit record
generation
o The TOE shall provide a function to verify the integrity of itself and its setting values.
- Integrity verification covers the TOE setting values(configuration files, etc.) and the TOE
itself(processes, libraries, executable files, etc.).
- Integrity verification shall be performed when the TOE is initial executed(or start-up), and
periodic integrity verification can be performed additionally.
- The subject of integrity verification can be selected by the sponsor, but if the entity’s
abnormal state(e.g., error, stop, etc.) affects the security function of the TOE, the
corresponding entity shall be included as the subject of integrity verification.
- If physically separated TOE components exist, integrity verification shall be performed by
selecting the subjects to include all components.
- A function for the administrator to perform integrity verification shall be provided.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy ‘protection when storing cryptographic key’ requirements of FCS class
and FPT_PST.1.
o If the operating system kernel or kernel level module is included in the scope of the TOE, the
TOE shall provide a function to verify the integrity of the operating system kernel or kernel
level module.
- When verifying integrity by hash value comparison method, the cryptographic algorithm
used, cryptographic key security, and cryptographic key storage method shall satisfy
‘protection when storing cryptographic key’ requirements of FCS class and FPT_PST.1.
Korean National Protection Profile for Web Application Firewall
55
5.1.6.4. FPT_TUD.1 TSF security patch update (Extended)
o The TOE shall provide a function for the administrator to check the contents and results of
the integrity verification.
- The contents and results of the integrity verification shall be checked through screen display
and audit records.
o The TOE shall perform response function if integrity verification fails.
- The TOE shall perform its own implemented response function or the response function set
by the administrator.
- Audit records shall be generated for integrity verification results.
- Examples of response functions performed when the integrity verification result is a failure
are as follows.
• Interrupt program execution, warning message screen display, etc.
- A security management function may be provided for the administrator to set the response
function.
Hierarchical to No other components.
Dependencies No dependencies.
FPT_TUD.1.1 The TSF shall provide [assignment: authorized role] with a function to
inquire unique identification information of the TOE.
FPT_TUD.1.2
The TSF shall verify validity of the update files using [selection: hash value
comparison, digital signature verification, [assignment: other secure validation
mechanism] ] before installing updates.
Application notes
ㅇ The TOE shall provide a function for users to check the ‘unique identification information of
the TOE’.
- The TOE identification information shall be unique, can be checked by users through the
interface, and cannot be modified or changed. It shall include the following.
• TOE name, TOE version, TOE release or build number
- If the TOE includes multiple components that are physically separated, the identification
information of each component shall be unique, can be checked, and cannot be modified
or changed by users. It shall include the following:
• The name and version of the TOE including the component, The component name, The
component version, The component release or build number.
- A version management system that can check whether the TOE and TOE components are
patched and functionally improved should be applied.
(e.g., In case of patch and function improvement, a system for changing the major version,
CC V3.1 R5
56
5.1.7. TOE access (FTA)
5.1.7.1. FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions
minor version, release number, and build number for each case is established to track the
reason for the change of TOE/TOE components with version information)
- In case of hardware appliances, users shall be able to view the unique identification
information of the firmware in addition to TOE identification information through TOE interface.
o The TOE shall provide the function to update to the latest signature.
o In case of providing the update function, the TOE shall verify the validity of the TOE update
files before installing or applying the update files.
- If the TOE provides online update or manual update function, only the update files that
have succeeded in verification of the validity shall be installed or applied.
- Integrity verification is mandatory when verify the validity of the update files, and shall be
implemented using digital signature verification, public hash value verification, etc.
- When verifying the digital signature, verification of the validity of the certificate (within 1
year of validity) shall be performed.
- Cryptographic algorithm and cryptographic key security shall satisfy FCS class requirements.
- Update file validation results (successㆍfailure) shall be audited and recorded.
o If the update function is provided, the TOE shall provide a function to automatically maintain
the existing version when the update installation fails.
- An audit record shall be generated for the update installation result and the reason for
failure.
- If it is not supported by the TOE, manual recovery by the administrator shall be supported.
- The developer shall describe the manual recovery procedure by the administrator in detail in
the deliverables.
Hierarchical to FTA_MCS.1 Basic limitation on multiple concurrent sessions
Dependencies FIA_UID.1 Timing of identification
FTA_MCS.2.1 The TSF shall restrict the maximum number of concurrent sessions
belonging to the same user according to the rules [limiting the maximum
number of concurrent sessions to 1 for users who have the same privilege
and the same user, rules on the maximum number of concurrent sessions
{determined by the ST author}].
FTA_MCS.2.2 The TSF shall enforce a limit of [1] session per user by default.
Application notes
Korean National Protection Profile for Web Application Firewall
57
5.1.7.2. FTA_TSE.1(1) TOE session establishment
o The TOE shall not allow duplicate access to the TOE with the same user account or the same
privilege.
- If a user logs in with the same account on another terminal after logging in, it is required
to block a new access or terminate the previous access.
- Duplicate logins with the same privilege shall not be allowed.
- An audit record should be generated when duplicate access is blocked.
Hierarchical to No other components.
Dependencies No dependencies.
FTA_TSE.1.1 The TSF shall be able to deny the administrator’s management access
session establishment based on [access IP, [selection: [assignment: important
management function attributes], none]].
Application notes
o The TOE shall provide a function to restrict the IP of the accessible management terminals.
- It shall be possible to register, delete, and change the IP address of the management
terminals.
- Management terminals accessible to administrators who only have read access instead of for
management purposes(e.g., monitoring administrators) can be additionally registered for
operation.
- The IP of accessible management terminals can be added one by one at a time as a host
IP.
- It is not allowed to register by designating an IP address range such as 192.168.10.2~253,
or by using 0.0.0.0, 192.168.10.*, any, which means the entire network range.
CC V3.1 R5
58
5.2. Security functional requirements (Conditional mandatory SFR)
‘Conditional mandatory SFRs’ in this PP are as follows. ‘Conditional mandatory SFRs’ mandatorily require
to be included in the ST, if they meet ‘the additional conditions for the ST’ in the table below.
Security
functional
class
Security functional component SFR additional conditions Remark
FAU
FAU_STG.1
Protected audit
trail storage
In case of the TOE server stores
audit records in local storage
FAU_STG.3
Action in case of
possible audit
data loss
In case of the TOE server stores
audit records in local storage
FAU_STG.4
Prevention of
audit data loss
In case of the TOE server stores
audit records in local storage
FIA FIA_UAU.5
Multi-authenticatio
n mechanism
In case of the TOE server supports
additional identification and
authentication functions by itself in
addition to the ID/password-based
authentication method
FPT
FPT_ITT.1
Basic internal TSF
data transfer
protection
In case of the TOE is physically
separated (eg server, management
console, etc.)
FPT_LEE.1
Linkable external
entities (Extended)
- authentication
In case of the TOE server supports
additional identification and
authentication functions by
interacting with external IT entities
in addition to the
ID/password-based authentication
method
FTA
FTA_SSL.1
TSF-initiated
session locking
In case of the TOE provides
session locking function
O
ne of the
tw
om
ust be
im
plem
ented
FTA_SSL.3
TSF-initiated
termination
In case of the TOE provides
session termination function
FTA_TSE.1(2)
TOE session
establishment
In case of it is necessary to
identify and authenticate users
existing in the agent, management
console, or client constituting the
TOE
FTP
FTP_ITC.1
Inter-TSF trusted
channel
In case of interacting with external
IT entities is supported
In case of audit records are
transmitted and stored to external
IT entities in real time
In case of providing the online
update function through the
developer update server.
FTP_TRP.1 Trusted path
In case of authorized administrators
and general users directly access
the management server through
web browsers or terminal access
programs, etc.
[Table 7] Conditional mandatory SFRs
Korean National Protection Profile for Web Application Firewall
59
5.2.1. Security audit (FAU)
5.2.1.1. FAU_STG.1 Protected audit trail storage
5.2.1.2. FAU_STG.3 Action in case of audit data loss
Hierarchical to No other components
Dependencies FAU_GEN.1 Audit data generation
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from
unauthorized deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorized modifications to the stored
audit records in the audit trail.
Application notes
o The TOE shall protect the audit records from being deleted or changed.
- A function shall be implemented to store audit records in a local storage or to transmit and
store audit records to an external IT entity in real time.
- Relevant user interface(UI) and CLI commands shall not be provided so that even authorized
administrators cannot delete or change audit records.
- Unauthorized person's access shall be controlled to protect the stored audit records.
- If the TOE security function cannot be fully implemented, the TOE operational environment
can support the protected audit trail storage.
• Example: When audit records are stored in the DBMS installed on the same operating
system as the TOE, the DBMS’ identification and authentication functions can be used to
protect deletion or modification by unauthorized users.
- If audit records are stored in the log server outside the TOE, encrypted communication shall
be performed.
• If syslog is supported, encrypted transmission shall be supported through syslog over
DTLS(RFC 5424), syslog over DTLS(RFC 6012), etc.
Hierarchical to No other components
Dependencies FAU_STG.1 Protected audit trail storage
FAU_STG.3.1 The TSF shall [Notification to the authorized administrator, [assignment:
actions to be taken in case of possible audit storage failure] if the audit
trail exceeds [assignment: pre-defined limit].
Application notes
o In case of the size of the audit record reaches the predefined capacity, the TOE shall take
response actions such as notifying the administrator.
- A function shall be implemented to store audit records in the local storage or to transmit
CC V3.1 R5
60
5.2.1.3. FAU_STG.4 Prevention of audit data loss
5.2.2. Identification and authentication (FIA)
5.2.2.1. FIA_UAU.5 Multiple authentication mechanisms
and store audit records to an external IT entity in real time.
- A function to notify the administrator shall be provided. Examples of the function are as
follows.
• Screen alarm, sending email to the administrator, etc.
- Examples of conditions for notifying the administrator in response to audit record loss are
as follows.
• 90% or more of the setup disk capacity, 100MB or more, etc.
- In addition, a function for the administrator to send audit records to an external log server
may be provided.
• If syslog is supported, encrypted transmission shall be supported through syslog over
DTLS(RFC 5424), syslog over DTLS(RFC 6012), etc.
• The cryptographic algorithm used, cryptographic key security, and cryptographic key
storage method shall satisfy the 'protection when storing cryptographic key' requirements
of FCS class and FPT_PST.1.
Hierarchical to FAU_STG.3 Action in case of possible audit data loss
Dependencies FAU_STG.1 Protected audit trail storage
FAU_STG.4.1 The TSF shall [selection, choose one of: “ignore audited events”, “prevent
audited events, except those taken by the authorised user with special
rights”, “overwrite the oldest stored audit records”] and [assignment: other
actions to be taken in case of audit storage failure] if the audit trail is full.
Application notes
ㅇ In case of the audit record storage capacity is full, the TOE shall respond to failure to save
in an appropriate way.
- A function shall be implemented to store audit records in a local storage or to transmit and
store audit records to an external IT entity in real time.
- Examples of response functions in case of failure to save are as follows.
• Overwriting the oldest audit records, save audit records compression, etc.
Hierarchical to No other components.
Dependencies No dependencies.
Korean National Protection Profile for Web Application Firewall
61
5.2.3. Protection of the TSF (FPT)
5.2.3.1. FPT_ITT.1 Basic internal TSF data transfer protection
FIA_UAU.5.1 The TSF shall provide [password authentication mechanism, [assignment: list
of additional authentication mechanism]] to support user authentication.
FIA_UAU.5.2
The TSF shall authenticate any user's claimed identity according to the
[assignment: rules describing how the multiple authentication mechanisms
provide authentication].
Application notes
o In case of the TOE supports additional identification and authentication methods, the TOE
shall provide additional identification and authentication functions on its own or by interacting
with external IT entities, in parallel with user account/password-based identification and
authentication.
- In order to provide additional identification and authentication functions, △2FA support
device complying with FIDO standards, △certificates, △one-time password generator(OTP),
etc. can be used.
• If it is supported in the TOE operational environment, ‘2FA support device complying with
FIDO standards’ is recommended.
- If additional identification and authentication functions are provided in the TOE, the
functions can be provided by receiving the authentication results from the inside of the
TOE or from the interacted external IT entities.
• If the TOE provides a certification utilization method, certificate validation shall be
performed.
• The authentication information used by external IT entities to perform additional
identification and authentication methods shall be securely managed by the external IT
entities. If the TOE stores authentication information use to perform additional
identification and authentication methods, the requirements of FPT_PST.1 shall be applied.
Hierarchical to Hierarchical to
Dependencies No dependencies.
FPT_ITT.1.1 The TSF shall protect the TSF data from disclosure and modification when
the TSF data is transmitted among TOE’s separated parts.
Application notes
ㅇ The TOE shall transmit using an encrypted channel to protect data transmitted among TOE
components (e.g., security policies, control commands, audit records, etc.)
- For secure encrypted communication, confidentiality and integrity shall be provided using
CC V3.1 R5
62
5.2.3.2. FPT_LEE.1 Linkable external entities (Extended) - authentication
Hierarchical to No other components.
Dependencies No dependencies.
FPT_LEE.1.1 The TSF shall perform [assignment: list of actions] and provide [assignment:
list of functions] by linking with external entities.
Application notes
o In case of the TOE supports additional identification and authentication methods, the TOE
shall provide additional identification and authentication functions on its own or by interacting
with external IT entities, in parallel with user account/password-based identification and
authentication.
- In order to provide additional identification and authentication functions, △2FA support
device complying with FIDO standards, △certificates, △one-time password generator(OTP),
etc. can be used.
• If it is supported in the TOE operational environment, ‘2FA support device complying with
FIDO standards’ is recommended.
- If additional identification and authentication functions are provided in the TOE, the
functions can be provided by receiving the authentication results from the inside of the
TOE or from the interacted external IT entities.
• If the TOE provides a certification utilization method, certificate validation shall be
performed.
• The authentication information used by external IT entities to perform additional
identification and authentication methods shall be securely managed by the external IT
entities. If the TOE stores authentication information use to perform additional
identification and authentication methods, the requirements of FPT_PST.1 shall be applied.
standard protocols.
• Secure cryptographic communication protocols include HTTPS (implemented using TLS), TLS
(TLS 1.2-RFC5246 or higher), SSH (SSH V2-RFC 4251, 4254), etc.
- Use of its own protocol is not allowed.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy the requirements of 'protection when storing cryptographic key' of FCS
class and FPT_PST.1.
Korean National Protection Profile for Web Application Firewall
63
5.2.4. TOE access (FTA)
5.2.4.1. FTA_SSL.1 TSF-initiated Session locking
5.2.4.2. FTA_SSL.3 TSF-initiated termination
Hierarchical to No other components.
Dependencies FIA_UAU.1 Timing of authentication
FTA_SSL.1.1 The TSF shall lock the interactive session after [assignment: time interval of
user inactivity] by:
a) clearing or overwriting display devices, making the current contents
unreadable;
b) disabling any activity of the user's data access/display devices other than
unlocking the session.
FTA_SSL.1.2 The TSF shall require the following events to occur prior to unlocking the
session: [ [selection: unlocking session by the administrator, user re-authentication
before unlocking session] ].
Application notes
o The TOE shall provide a function to lock or terminate the session if it is not used for a
certain period of time after the user session is connected.
- The time information used shall be applied based on the server time.
- A certain period of time refers to the amount of time accumulated after a connection that
triggers session locking or termination.
• A certain period of time can be fixed by the administrator among 10 minutes or less or
set in proportion to the number of authentication failures.
- After the lock time has elapsed, a locked session shall be unlocked by the administrator or
through the user authentication function for each session.
- An audit record shall be generated when the session lock or termination function is
activated.
- It shall be applied to all management and local access included in the TOE.
Hierarchical to No other components.
Dependencies No dependencies.
FTA_SSL.3.1 The TSF shall terminate an interactive session after a [assignment: time
interval of user inactivity].
Application notes
o The TOE shall provide a function to lock or terminate the session if it is not used for a
CC V3.1 R5
64
5.2.4.3. FTA_TSE.1(2) TOE session establishment
5.2.5. Trusted path/channels (FTP)
5.2.5.1. FTP_ITC.1 Inter-TSF trusted channel
certain period of time after the user session is connected.
- The time information used shall be applied based on the server time.
- A certain period of time refers to the amount of time accumulated after a connection that
triggers session locking or termination.
• A certain period of time can be fixed by the administrator among 10 minutes or less or
set in proportion to the number of authentication failures.
- After the lock time has elapsed, a locked session shall be unlocked by the administrator or
through the user authentication function for each session.
- An audit record shall be generated when the session lock or termination function is
activated.
- It shall be applied to all management and local access included in the TOE.
Hierarchical to No other components.
Dependencies No dependencies.
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
Hierarchical to No other components.
Dependencies No dependencies.
FTA_TSE.1.1 The TSF shall be able to deny session establishment based on [assignment:
list of additional attributes of agent or client.]
Application notes
o In case of it is necessary to identify and authenticate a user existing in the agent or client
constituting the TOE, the identification value shall be a unique value that is not registered in
duplicate.
- During user authentication, additional attributes of the registered agent or client shall also
be authenticated.
- Additional attributes: IP address is mandatory, and at least one of MAC address, serial
number, and information that can uniquely identify the agent itself shall be additionally used.
Korean National Protection Profile for Web Application Firewall
65
5.2.5.2. FTP_TRP.1 Trusted path
protection of the channel data from modification or disclosure.
FTP_ITC.1.2 The TSF shall permit [selection: the TSF, another trusted IT product] to
initiate communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for
[assignment: list of functions for which a trusted channel is required].
Application notes
ㅇ In case of interacting with external IT entities is supported, the TOE shall transmit data using
an encrypted communication channel to protect the transmitted data when interacting with
external IT entities.
- For secure cryptographic communication, confidentiality and integrity shall be provided using
standard protocols.
• Secure cryptographic communication protocols include HTTPS (implemented using TLS), TLS
(TLS 1.2-RFC5246 or higher), SSH (SSH V2-RFC 4251, 4254), etc.
- Use of its own protocol is not allowed.
- The cryptographic communication channel can be implemented directly in the TOE or to be
provided by the TOE using the operating environment.
- This requirement shall be applied when the TOE provides a function that interacting with
external IT entities to provide a security function.
- If transmission data is not protected using an cryptographic communication channel when
interacting with external IT entities, the needlessness to protect the confidentiality and
integrity of transmitted data shall be proven.
- Communication services that do not support cryptographic communication channels shall be
able to be disabled.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy the requirements of 'protection when storing cryptographic key' of FCS
class and FPT_PST.1.
o In case of audit records are stored in a log server outside the TOE, cryptographic
communication shall be performed.
- If syslog is supported, encrypted transmission shall be supported through syslog over
DTLS(RFC 5424), syslog over DTLS(RFC 6012), etc.
Hierarchical to No other components.
Dependencies No dependencies.
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection:
remote, local] users that is logically distinct from other communication paths
and provides assured identification of its end points and protection of the
CC V3.1 R5
66
5.3. Security function requirements (optional SFRs)
The ‘optional SFRs’ in this PP are as follows. The ‘optional SFRs’ are not required to be
implemented mandatorily, but if the TOE provides relevant functions additionally, the ST author shall
include the corresponding SFRs in the ST.
Security
function class
Security functional component
Cryptographic
support
(FCS)
FCS_CKM.2 Cryptographic key distribution
Protection of the
TSF
(FPT)
FPT_STM.1 Reliable timestamp
[Table 8] Optional SFRs
communicated data from modification, disclosure, [assignment: other types
of integrity or confidentiality violation].
FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to initiate
communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: the
authentication of management access administrator, [assignment: other
services for which trusted path is required] ].
Application notes
ㅇ During management access, the TOE shall transmit data using an cryptographic communication
channel to protect the transmitted data.
- For secure cryptographic communication, confidentiality and integrity shall be provided using
standard protocols.
• Secure cryptographic communication protocols include HTTPS (implemented using TLS), TLS
(TLS 1.2-RFC5246 or higher), SSH (SSH V2-RFC 4251, 4254), etc.
- Use of its own protocol is not allowed.
- The cryptographic communication channel can be implemented directly in the TOE or to be
provided by the TOE using the operational environment.
- The cryptographic algorithm used, cryptographic key security, and cryptographic key storage
method shall satisfy the requirements of 'protection when storing cryptographic key' of FCS
class and FPT_PST.1.
Korean National Protection Profile for Web Application Firewall
67
5.3.1. Cryptographic support (FCS)
5.3.1.1. FCS-CKM.2 Cryptographic key distribution
5.3.2. Protection of the TSF (FPT)
5.3.2.1. FPT_STM.1 Reliable time stamps
Hierarchical to No other components.
Dependencies [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified
cryptographic key distribution method [assignment: cryptographic key
distribution method] that meets the following: [assignment: list of
standards].
Application notes
o FCS_CKM.2 cryptographic key distribution is a selectively implementable functional requirement(‘optional
SFRs’), and if the TOE additionally provides the above function, the ST author shall include this
requirement in the SFR.
o If the ST author includes this SFR, security problem definition and security objectives shall be
derived additionally, if necessary.
o The key used in the cryptographic key establishment method defined in FCS_CKM.2.1 shall be
related to the key generated in FCS_CKM.1.1 of FCS_CKM.1.
Hierarchical to No other components.
Dependencies No dependencies.
FTP_STM.1.1 The TSF shall be able to provide the reliable timestamp.
Application notes
o Each component of the TOE shall generate audit records using trusted time information.
- Trusted time information shall use the time information provided by the NTP server or operating system..
CC V3.1 R5
68
5.4. Security assurance requirements
Assurance requirements of this Protection Profile are comprised of assurance components in CC
part 3, and the evaluation assurance level is EAL1+. The following table summarizes assurance
components.
5.4.1. Security Target evaluation
5.4.1.1. ASE_INT.1 ST introduction
Security
assurance class
Security assurance component
Security Target
evaluation
ASE_INT.1 ST introduction
ASE_CCL.1 Conformance claims
ASE_OBJ.1 Security objectives for the operational environment
ASE_ECD.1 Extended components definition
ASE_REQ.1 Stated security requirements
ASE_TSS.1 TOE summary specification
Development ADV_FSP.1 Basic functional specification
Guidance
documents
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Life-cycle support
ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM coverage
Tests
ATE_FUN.1 Functional testing
ATE_IND.1 Independent testing - conformance
Vulnerability
assessment
AVA_VAN.1 Vulnerability survey
[Table 9] Security assurance requirements
Dependencies No dependencies.
Developer action
elements
ASE_INT.1.1D The developer shall provide an ST introduction.
Content and
presentation
elements
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.
Korean National Protection Profile for Web Application Firewall
69
5.4.1.2. ASE_CCL.1 Conformance claims
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.
Evaluator action
elements
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.
Dependencies ASE_INT.1 ST introduction
ASE_ECD.1 Extended components definition
ASE_REQ.1 Stated security requirements
Developer action
elements
ASE_CCL.1.1D The developer shall provide a conformance claim.
ASE_CCL.1.2D The developer shall provide a conformance claim rationale.
Content and
presentation
elements
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
CC V3.1 R5
70
5.4.1.3. ASE_OBJ.1 Security objectives for the operational environment
5.4.1.4. ASE_ECD.1 Extended components definition
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.
Evaluator action
elements
ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Dependencies No dependencies.
Developer action
elements
ASE_OBJ.1.1D The developer shall provide a statement of security objectives.
Content and
presentation
elements
ASE_OBJ.1.1C The statement of security objectives shall describe the security objectives for
the operational environment.
Evaluator action
elements
ASE_OBJ.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Dependencies No dependencies.
Developer action
elements
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.
Content and
presentation
elements
Korean National Protection Profile for Web Application Firewall
71
5.4.1.5. ASE_REQ.1 Stated security requirements
ASE_ECD.1.1C The statement of security requirements shall identify all extended security
requirements.
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.
Evaluator action
elements
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.
Dependencies ASE_ECD.1 Extended components definition
Developer action
elements
ASE_REQ.1.1D The developer shall provide a statement of security requirements.
ASE_REQ.1.2D The developer shall provide a security requirements rationale.
Content and
presentation
elements
ASE_REQ.1.1C The statement of security requirements shall describe the SFRs and the
SARs.
ASE_REQ.1.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.1.3C The statement of security requirements shall identify all operations on the
security requirements.
ASE_REQ.1.4C All operations shall be performed correctly.
ASE_REQ.1.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.1.6C The statement of security requirements shall be internally consistent.
Evaluator action
CC V3.1 R5
72
5.4.1.6. ASE_TSS.1 TOE summary specification
5.4.2. Development
5.4.2.1. ADV_FSP.1 Basic functional specification
elements
ASE_REQ.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Dependencies ASE_INT.1 ST introduction
ASE_REQ.1 Stated security requirements
ADV_FSP.1 Basic functional specification
Developer action
elements
ASE_TSS.1.1D The developer shall provide a TOE summary specification
Evaluator action
elements
ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR.
Evaluator action
elements
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.
Dependencies No dependencies.
Developer action
elements
ADV_FSP.1.1D The developer shall provide a functional specification.
ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to
the SFRs.
Content and
presentation
elements
ADV_FSP.1.1C The functional specification shall describe the purpose and method of use
for each SFR-enforcing and SFR-supporting TSFI.
ADV_FSP.1.2C The functional specification shall identify all parameters associated with each
SFR-enforcing and SFR-supporting TSFI.
ADV_FSP.1.3C The functional specification shall provide rationale for the implicit
categorization of interfaces as SFR-non-interfering.
ADV_FSP.1.4C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional
specification.
Korean National Protection Profile for Web Application Firewall
73
5.4.3. Guidance documents
5.4.3.1. AGD_OPE.1 Operational user guidance
Evaluator action
elements
ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
ADV_FSP.1.2E The evaluator shall determine that the functional specification is an accurate
and complete instantiation of the SFRs.
Dependencies ADV_FSP.1 Basic functional specification
Developer action
elements
AGD_OPE.1.1D The developer shall provide operational user guidance.
Content and
presentation
elements
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.
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.
Evaluator action
elements
AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
CC V3.1 R5
74
5.4.3.2. AGD_PRE.1 Preparative procedures
5.4.4. Life-cycle support
5.4.4.1. ALC_CMC.1 Labelling of the TOE
5.4.4.2. ALC_CMS.1 TOE CM coverage
Dependencies No dependencies.
Developer action
elements
AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures.
Content and
presentation
elements
AGD_PRE1.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_PRE1.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.
Evaluator action
elements
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.
Dependencies ALC_CMS.1 TOE CM coverage
Developer action
elements
ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE.
Content and
presentation
elements
ALC_CMC.1.1C The TOE shall be labelled with its unique reference.
Evaluator action
elements
ALC_CMC.1.1E The evaluator shall confirm that the information provided meet requirements
for content and presentation of evidence.
Korean National Protection Profile for Web Application Firewall
75
5.4.5. Tests
5.4.5.1. ATE_FUN.1 Functional testing
5.4.5.2. ATE_IND.1 Independent testing - conformance
Dependencies No dependencies.
Developer action
elements
ALC_CMS.1.1D The developer shall provide a configuration list for the TOE.
Content and
presentation
elements
ALC_CMS.1.1C The configuration list shall include the following: the TOE itself; and the
evaluation evidence required by the SARs.
ALC_CMS.1.2C The configuration list shall uniquely identify the configuration items.
Evaluator action
elements
ALC_CMS.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
Dependencies ATE_COV.1 Evidence of coverage
Developer action
elements
ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2D The developer shall provide test documentation.
Content and
presentation
elements
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.
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.
Evaluator action
elements
ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
CC V3.1 R5
76
5.4.6. Vulnerability assessment
5.4.6.1. AVA_VAN.1 Vulnerability survey
Dependencies ADV_FSP.1 Basic functional specification
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Developer action
elements
ATE_IND.1.1D The developer shall provide the TOE for testing.
Content and
presentation
elements
ATE_IND.1.1C The TOE shall be suitable for testing.
Evaluator action
elements
ATE_IND.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
ATE_IND.1.2E The evaluator shall test a subset of the TSF to confirm that the TSF
operates as specified.
Dependencies ADV_FSP.1 Basic functional specification
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Developer action
elements
AVA_VAN.1.1D The developer shall provide the TOE for testing
Content and
presentation
elements
AVA_VAN.1.1C The TOE shall be suitable for testing.
Evaluator action
elements
AVA_VAN.1.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
AVA_VAN.1.2E The evaluator shall perform a search of public domain sources to identify
potential vulnerabilities in the TOE.
AVA_VAN.1.3E 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.
Korean National Protection Profile for Web Application Firewall
77
5.5. Security requirements rationale
5.5.1. Dependency rationale of security functional requirements
The following table shows dependency of security functional requirements.
No.
Security
functional
requirements
Dependency Reference
No.
SFR type
1 FAU_ARP.1 FAU_SAA.1 3
2 FAU_GEN.1 FPT.STM.1 Rationale(1) Mandatory
3 FAU_SAA.1 FAU_GEN.1 2 Mandatory
4 FAU_SAR.1 FAU_GEN.1 2 Mandatory
5 FAU_SAR.3 FAU_SAR.1 4 Mandatory
6 FAU_STG.1 FAU_GEN.1 2
Conditional
mandatory
7 FAU_STG.3 FAU_STG.1 Rationale(2)
Conditional
mandatory
8 FAU_STG.4 FAU_STG.1 Rationale(2)
Conditional
mandatory
9 FCS_CKM.1
[FCS_CKM.2 or FCS_COP.1] 10, 12
Mandatory
FCS_CKM.4 11
10 FCS_CKM.2
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] 9
Optional
FCS_CKM.4 11
11 FCS_CKM.4 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] 9 Mandatory
12 FCS_COP.1
[FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1] 9
Mandatory
FCS_CKM.4 11
13 FCS_RBG.1 - - Mandatory
14 FDP_IFC.1 FDP_IFF.1 15 Mandatory
15 FDP_IFF.1
FDP_IFC.1 14
Mandatory
FMT_MSA.3 26
16 FDP_EDI.1 - - Mandatory
17 FIA_AFL.1 FIA_UAU.1 19 Mandatory
18 FIA_SOS.1 - - Mandatory
19 FIA_UAU.1 FIA_UID.1 23 Mandatory
20 FIA_UAU.4 - - Mandatory
21 FIA_UAU.5 - -
Conditional
mandatory
CC V3.1 R5
78
No.
Security
functional
requirements
Dependency
Reference
No. SFR type
22 FIA_UAU.7 FIA_UAU.1 19 Mandatory
23 FIA_UID.1 - - Mandatory
24 FMT_MOF.1
FMT_SMF.1 29
Mandatory
FMT_SMR.1 30
25 FMT_MSA.1
[FDP_ACC.1 or FDP_IFC.1] 14
Mandatory
FMT_SMF.1 29
FMT_SMR.1 30
26 FMT_MSA.3
FMT_MSA.1 25
Mandatory
FMT_SMF.1 30
27 FMT_MTD.1
FMT_SMF.1 29
Mandatory
FMT_SMR.1 30
28 FMT_PWD.1
FMT_SMF.1 29
Mandatory
FMT_SMR.1 30
29 FMT_SMF.1 - - Mandatory
30 FMT_SMR.1 FIA_UID.1 23 Mandatory
31 FPT_ITT.1 - -
Conditional
Mandatory
32 FPT_LEE.1 - -
Conditional
mandatory
33 FPT_PST.1 - - Mandatory
34 FPT_RCV.2 AGD_OPE.1 - Mandatory
35 FPT_STM.1 - - Optional
36 FPT_TST.1 - - Mandatory
37 FPT_TUD.1 - -
Conditional
mandatory
38 FTA_MCS.2 FIA_UID.1 23 Mandatory
39 FTA_SSL.1 FIA_UAU.1 19
Conditional
mandatory
40 FTA_SSL.3 - -
Conditional
mandatory
41 FTA_TSE.1(1) - - Mandatory
42 FTA_TSE.1(2) - -
Conditional
mandatory
43 FTP_ITC.1 - - Conditional
Korean National Protection Profile for Web Application Firewall
79
The ST author refers to the table above and prepares a dependency relationship rationale table for
the SFRs included in the ST.
Rationale(1) : FAU_GEN.1 has the dependency on FAU_STG.1. However, if the pertinent function is
implemented by the TOE, the ST author needs to identify the optional SFR (FAU_STM.1) as the SFR
of the ST and describe the pertinent reference number. In addition, if FAU_STM.1 is supported by
the operational environment, the author shall add the security objectives for the operational
environment and provide justification that a subordinate relationship is satisfied.
Rationale(2) : FAU_STG.3 and FAU_STG.4 have the dependency on FAU_STG.1. However, if the
pertinent function is implemented by the TOE, the ST author needs to identify the optional SFR
(FAU_STG.1) as the SFR of the ST and describe the pertinent reference number. In addition, if
FAU_STG.1 is supported by the operational environment (e.g., DBMS), the author shall add the
security objectives for the operational environment and provide justification that a subordinate
relationship is satisfied.
5.5.2. Dependency rationale of security assurance requirements
The dependency of EAL1 assurance package provided in the CC is already satisfied, the rationale is
omitted.
The augmented ATE_FUN.1 has dependency on ATE_COV.1. but, ATE_FUN.1 is augmented to
require developer testing in order to check if the developer correctly performed and documented
the tests in the test documentation, ATE_COV.1 is not included in this PP since it is not necessarily
required to show the correspondence between the tests and the TSFIs.
No.
Security
functional
requirements
Dependency
Reference
No. SFR type
mandatory
44 FTA_TRP.1 - -
Conditional
mandatory
[Table 10] Rationale for the dependency of the security functional requirements
CC V3.1 R5
80
References
Title Author Remark
Common Criteria for Information Technology Security Evaluation,
Version 3.1, Revision 5
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 1: Introduction and General Model,
Version 3.1, Revision 5 (CCMB-2017-04-001)
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 2: Security Functional Components,
Version 3.1, Revision 5 (CCMB-2017-04-002)
Ÿ Common Criteria for Information Technology Security
Evaluation. Part 3: Security Assurance Components,
Version 3.1, Revision 5 (CCMB-2017-04-003)
CCMB 2017. 4
Security Requirements for Government V3.0 for the Information
Security Systems and Network Devices
- Part 2, Common security requirements
- Part 3, Product security requirements, Security requirements for
Web Application Firewalls
National
Cybersecurity
Center,
IT Security
Certification Center
2021. 4
2021. 9
Korean National Protection Profile for Web Application Firewall
81
Abbreviated terms
CC Common Criteria
CCMB Common Criteria Maintenance Board
CLI Command Line Interface
CPU Central Processing Unit
DBMS Data Base Management System
DoS Denial of Service
EAL Evaluation Assurance Level
HTTPS Hypertext Transfer Protocol over Secure Socket Layer
IP Internet Protocol
IPSec Internet Protocol Security
IT Information Technology
NTP Network Time Protocol
OTP One Time Password
PP Protection Profile
RFC Request for Comments
SFP Security Function Policy
SFR Security Function Requirement
SMS Short Message Service
SSH Secure Shell
SSL Secure Socket Layer
ST Security Target
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functionality
UI User Interface