IBM QRadar Security Intelligence
Platform (NDcPP21) Security Target
Version 0.7
January 15, 2020
Prepared for:
IBM, Corporation
1 New Orchard Road
Armonk, New York 10504
Prepared By:
www.gossamersec.com
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 2 of 32
1. SECURITY TARGET INTRODUCTION........................................................................................................3
1.1 SECURITY TARGET REFERENCE......................................................................................................................3
1.2 TOE REFERENCE............................................................................................................................................3
1.3 TOE OVERVIEW .............................................................................................................................................4
1.4 TOE DESCRIPTION .........................................................................................................................................4
1.4.1 TOE Architecture...................................................................................................................................4
1.4.2 TOE Documentation ..............................................................................................................................6
2. CONFORMANCE CLAIMS..............................................................................................................................7
2.1 CONFORMANCE RATIONALE...........................................................................................................................7
3. SECURITY OBJECTIVES ................................................................................................................................8
3.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .....................................................................8
4. EXTENDED COMPONENTS DEFINITION ..................................................................................................9
5. SECURITY REQUIREMENTS.......................................................................................................................10
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS .............................................................................................10
5.1.1 Security audit (FAU)............................................................................................................................11
5.1.2 Cryptographic support (FCS)..............................................................................................................13
5.1.3 Identification and authentication (FIA) ...............................................................................................16
5.1.4 Security management (FMT) ...............................................................................................................18
5.1.5 Protection of the TSF (FPT) ................................................................................................................18
5.1.6 TOE access (FTA)................................................................................................................................19
5.1.7 Trusted path/channels (FTP) ...............................................................................................................20
5.2 TOE SECURITY ASSURANCE REQUIREMENTS...............................................................................................20
5.2.1 Development (ADV).............................................................................................................................20
5.2.2 Guidance documents (AGD)................................................................................................................21
5.2.3 Life-cycle support (ALC) .....................................................................................................................22
5.2.4 Tests (ATE) ..........................................................................................................................................22
5.2.5 Vulnerability assessment (AVA)...........................................................................................................23
6. TOE SUMMARY SPECIFICATION..............................................................................................................24
6.1 SECURITY AUDIT ..........................................................................................................................................24
6.2 CRYPTOGRAPHIC SUPPORT ...........................................................................................................................24
6.3 IDENTIFICATION AND AUTHENTICATION.......................................................................................................29
6.4 SECURITY MANAGEMENT .............................................................................................................................30
6.5 PROTECTION OF THE TSF .............................................................................................................................30
6.6 TOE ACCESS.................................................................................................................................................31
6.7 TRUSTED PATH/CHANNELS ...........................................................................................................................32
LIST OF TABLES
Table 5-1 TOE Security Functional Components........................................................................................................11
Table 5-2 Auditable Events .........................................................................................................................................13
Table 5-3 Assurance Components ...............................................................................................................................20
Table 6-1 CAVP Certificates for OpenSSL library ................................................................................................25
Table 6-2 CAVP Certificates for IBMFIPSJCE library...............................................................................................25
Table 6-3 CAVP Certificates for libgcrypt library ......................................................................................................26
Table 6-4 Cryptographic Keys .................................................................................................................................27
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 3 of 32
1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization. The TOE is IBM Security QRadar SIEM provided by IBM,
Corporation. The TOE is being evaluated as a network device.
The Security Target contains the following additional sections:
 Conformance Claims (Section 2)
 Security Objectives (Section 3)
 Extended Components Definition (Section 4)
 Security Requirements (Section 5)
 TOE Summary Specification (Section 6)
Conventions
The following conventions have been applied in this document:
 Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST,
iteration is indicated by a parenthetical number placed at the end of the component. For example
FDP_ACC.1(1) and FDP_ACC.1(2) indicate that the ST includes two iterations of the FDP_ACC.1
requirement.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by brackets (e.g., [assignment]). Note that an assignment within a selection
would be identified in italics and with embedded bold brackets (e.g., [[selected-assignment]]).
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by brackets (e.g., [selection]).
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions, and
strike-through, for deletions (e.g., “… all objects …” or “… some big things …”).
 Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.1 Security Target Reference
ST Title – IBM QRadar Security Intelligence Platform (NDcPP21) Security Target
ST Version – Version 0.7
ST Date – January 15, 2020
1.2 TOE Reference
TOE Identification – IBM, Corporation IBM QRadar Security Intelligence Platform version 7.3.2
TOE Developer – IBM, Corporation
Evaluation Sponsor – IBM, Corporation
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 4 of 32
1.3 TOE Overview
The Target of Evaluation (TOE) is QRadar Security Intelligence Platform version 7.3.2.
IBM Security QRadar Security Intelligence Platform is also known as the IBM QRadar Security Information and
Event Management (SIEM). The QRadar SIEM is a network device intended to detect potential threats through the
review of audit and event data collected from network sources. The TOE is the QRadar SIEM. The TOE is
administered either locally or remotely. The QRadar product consolidates log source event data from thousands of
devices endpoints and applications distributed throughout a network.
1.4 TOE Description
IBM QRadar SIEM consolidates log source event data from device endpoints and applications that are distributed
throughout a network. QRadar performs intermediate normalization and correlation activities on this raw data and
can forward data to another network server when so configured. Communication with network peers for outbound
log/event data is accomplished using TLS protected communication channels. QRadar is capable of providing an
X.509v3 certificate to authenticate itself as part of an outbound TLS connection.
The QRadar SIEM utilizes multiple cryptographic security kernel libraries internally, IBMFIPSJCE, OpenSSL and
GPG. The related CAVP algorithm certs are shown in C1207, C1208, and C1209
Table 6-1 CAVP Certificates for OpenSSL library.
QRadar provides its cryptographic features through a Java implementation (IBMFIPSJCE) which is developed by
IBM independently from QRadar. The OpenSSL library included in the TOE is OpenSSL 1.0.2k-fips as provided by
RedHat Enterprise Linux. Thus, all cryptographic functions except those associated with a TOE update validation are
provided by IBMFIPSJCE or OpenSSL.
The TOE includes support for GNU Privacy Guard (GPG), which is a public key software package. GPG is used to
verify signatures on product updates.
1.4.1 TOE Architecture
The evaluated product is a single All-in-one device running QRadar SIEM w/ QFlow enabled. A QRadar QFlow
collectors collect network traffic passively through network taps and span ports. A QFlow collector can detect and
collect information from networked applications. The All-in-One device is a self-contained appliance running the
QRadar SIEM in a Red Hat RHEL 7.5 environment. The appliance makes only those interfaces offered by QRadar
available.
The IBM All-In-One: Dell 3128C, model utilizes an x86 64-bit CPU architecture, with 4 network interface cards, and
varying amounts of memory.
The All-In-One device can connect to an external audit server allowing QRadar to transmit audit and event data to an
external server. All outbound audit data is transferred using TLS protected communication channels.
An IBM QRadar All-In-One device provides a trusted path to remote administrators using an HTTPS protected web
GUI or SSH protected Command Line Interface (CLI). The QRadar system offers a CLI at the local console and
remotely via SSH as an administrative interface. QRadar also offers a web interface for additional administrative
functionality. A single device will have four (4) network connections which can be used either for remote
management, receipt of event/syslog data, transmission of audit data, or other network support traffic (e.g.,DNS). A
REST API interface is offered by QRadar and can be protected by HTTPS/TLS.
1.4.1.1 Physical Boundaries
The TOE is composed of one physical component that is accessed and managed by administrators from computers in
the environment.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 5 of 32
The TOE can be configured to forward its audit records to an external syslog server in the environment. All audit
records sent to the external syslog server are protected using a TLS channel.
1.4.1.2 Logical Boundaries
This section summarizes the security functions provided by QRadar:
 Security audit
 Cryptographic support
 Identification and authentication
 Security management
 Protection of the TSF
 TOE access
 Trusted path/channels
1.4.1.2.1 Security audit
The TOE generates logs for a wide range of security relevant events. The TOE can be configured to store the logs
locally so they can be accessed by an administrator and also to send the logs to a designated network peer using TLS
to protect data while in transit. The TOE is also capable of acting as a log storage device and receiving TLS protected
communication from network peers sending audit/event data.
1.4.1.2.2 Cryptographic support
The TOE utilizes NIST validated cryptographic algorithms to support key management, random bit generation,
encryption/decryption, digital signature and secure hashing and key-hashing features in support of higher level
cryptographic protocols including SSH and TLS.
1.4.1.2.3 Identification and authentication
The TOE requires users to be identified and authenticated before they can use functions mediated by the TOE, with
the exception of reading the login banner. The TOE authenticates administrative users. In order for an administrative
user to access the TOE, a user account including a user name and password must be created for the user.
1.4.1.2.4 Security management
The TOE provides Command Line Interface (CLI) commands and an HTTP over TLS (HTTPS) Graphical User
Interface (GUI) to access the wide range of security management functions to manage its security policies. The TOE
also offers HTTP over TLS protection for RESTAPI interfaces that can be used for administration. All administrative
activity and functions including security management commands are limited to authorized users (i.e., administrators)
only after they have provided acceptable user identification and authentication data to the TOE. The security
management functions are controlled through the use of privileges associated with roles that can be assigned to TOE
users.
1.4.1.2.5 Protection of the TSF
The TOE implements a number of features designed to protect itself to ensure the reliability and integrity of its security
features.
It protects particularly sensitive data such as stored passwords and cryptographic keys so that they are not accessible
even by an administrator. It also provides its own timing mechanism to ensure that reliable time information is
available (e.g., for log accountability).
Note that the TOE is a single appliance, and as such, no intra-TOE communication is subject to any risks that may
require special protection (e.g., cryptographic mechanisms).
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 6 of 32
The TOE includes functions to perform self-tests so that it might detect when it is failing. It also includes support for
GNU Privacy Guard (GPG) is a public key software package. GPG is used to verify signatures on product updates.
The GPG signature of an update is verified against a published GPG key for IBM which is installed in the TOE.
1.4.1.2.6 TOE access
The TOE can be configured to display a logon banner before a user session is established. The TOE also enforces
inactivity timeouts for local and remote sessions.
1.4.1.2.7 Trusted path/channels
The TOE protects communication channels between itself and remote administrators using HTTPS/TLS and SSH.
The SSH protocol is used to protect administrative connections utilizing the TOE’s command line interface (CLI).
Additionally, web-based GUI and RESTAIP interfaces are available for remote administration which are protected
using HTTP over TLS (HTTPS/TLS).
The TOE also protects communication with network peers using TLS. Protected communication includes the TOE’s
outbound connection to an external audit server.
1.4.2 TOE Documentation
The TOE offers a series of documents that describe the installation process for the TOE as well as guidance for
subsequent use and administration of the applicable security features. The following is a list of such documents.
 IBM QRadar Common Criteria for NIAP, Version 7.3.2
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 7 of 32
2. Conformance Claims
This TOE is conformant to the following CC specifications:
 Common Criteria for Information Technology Security Evaluation Part 2: Security functional components,
Version 3.1, Revision 5, April 2017.
 Part 2 Extended
 Common Criteria for Information Technology Security Evaluation Part 3: Security assurance components,
Version 3.1, Revision 5, April 2017.
 Part 3 Conformant
 Package Claims:
 collaborative Protection Profile for Network Devices, Version 2.1, 11 March 2019 (NDcPP21)
with the following technical decisions:
TD0395
TD0396
TD0397
TD0398
TD0399
TD0400
TD0401
TD0402
TD0407
TD0408
TD0409
TD0410
TD0411
TD0412
TD0423
TD0424
TD0425
2.1 Conformance Rationale
The ST conforms to the NDcPP21. As explained previously, the security problem definition, security objectives, and
security requirements have been drawn from the PP.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 8 of 32
3. Security Objectives
The Security Problem Definition may be found in the NDcPP21 and this section reproduces only the corresponding
Security Objectives for operational environment for reader convenience. The NDcPP21 offers additional information
about the identified security objectives, but that has not been reproduced here and the NDcPP21 should be consulted
if there is interest in that material.
In general, the NDcPP21 has defined Security Objectives appropriate for a network device and as such are applicable
to the IBM Security QRadar SIEM TOE.
3.1 Security Objectives for the Operational Environment
OE.ADMIN_CREDENTIALS_SECURE The administrator's credentials (private key) used to access the TOE must
be protected on any other platform on which they reside.
OE.NO_GENERAL_PURPOSE There are no general-purpose computing capabilities (e.g., compilers or user
applications) available on the TOE, other than those services necessary for the operation, administration and support
of the TOE.
OE.NO_THRU_TRAFFIC_PROTECTION The TOE does not provide any protection of traffic that traverses it. It
is assumed that protection of this traffic will be covered by other security and assurance measures in the operational
environment.
OE.PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains, is provided by
the environment.
OE.RESIDUAL_INFORMATION The Security Administrator ensures that there is no unauthorized access possible
for sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords etc.) on networking
equipment when the equipment is discarded or removed from its operational environment.
OE.TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all guidance documentation in a trusted
manner.
OE.UPDATES The TOE firmware and software is updated by an administrator on a regular basis in response to the
release of product updates due to known vulnerabilities.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 9 of 32
4. Extended Components Definition
All of the extended requirements in this ST have been drawn from the NDcPP21. The NDcPP21 defines the following
extended requirements and since they are not redefined in this ST the NDcPP21 should be consulted for more
information in regard to those CC extensions.
Extended SFRs:
 NDcPP21:FAU_STG_EXT.1: Protected Audit Event Storage
 NDcPP21:FCS_HTTPS_EXT.1: HTTPS Protocol
 NDcPP21:FCS_RBG_EXT.1: Random Bit Generation
 NDcPP21:FCS_SSHS_EXT.1: SSH Server Protocol
 NDcPP21:FCS_TLSC_EXT.2: TLS Client Protocol with authentication
 NDcPP21:FCS_TLSS_EXT.1: TLS Server Protocol
 NDcPP21:FIA_PMG_EXT.1: Password Management
 NDcPP21:FIA_UAU_EXT.2: Password-based Authentication Mechanism
 NDcPP21:FIA_UIA_EXT.1: User Identification and Authentication
 NDcPP21:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
 NDcPP21:FIA_X509_EXT.2: X.509 Certificate Authentication
 NDcPP21:FIA_X509_EXT.3: X.509 Certificate Requests
 NDcPP21:FPT_APW_EXT.1: Protection of Administrator Passwords
 NDcPP21:FPT_SKP_EXT.1: Protection of TSF Data (for reading of all pre-shared, symmetric and private
keys)
 NDcPP21:FPT_STM_EXT.1: Reliable Time Stamps
 NDcPP21:FPT_TST_EXT.1: TSF testing
 NDcPP21:FPT_TUD_EXT.1: Trusted update
 NDcPP21:FTA_SSL_EXT.1: TSF-initiated Session Locking
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 10 of 32
5. Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) that
serve to represent the security functional claims for the Target of Evaluation (TOE) and to scope the evaluation effort.
The SFRs have all been drawn from the NDcPP21. The refinements and operations already performed in the NDcPP21
are not identified (e.g., highlighted) here, rather the requirements have been copied from the NDcPP21 and any
residual operations have been completed herein. Of particular note, the NDcPP21 made a number of refinements and
completed some of the SFR operations defined in the Common Criteria (CC) and that PP should be consulted to
identify those changes if necessary.
The SARs are also drawn from the NDcPP21 which includes all the SARs for EAL 1. However, the SARs are
effectively refined since requirement-specific 'Assurance Activities' are defined in the NDcPP21 that serve to ensure
corresponding evaluations will yield more practical and consistent assurance than the EAL 1 assurance requirements
alone. The NDcPP21 should be consulted for the assurance activity definitions.
5.1 TOE Security Functional Requirements
The following table identifies the SFRs that are satisfied by IBM Security QRadar SIEM TOE.
Requirement Class Requirement Component
FAU: Security audit NDcPP21:FAU_GEN.1: Audit Data Generation
NDcPP21:FAU_GEN.2: User identity association
NDcPP21:FAU_STG_EXT.1: Protected Audit Event Storage
FCS: Cryptographic support NDcPP21:FCS_CKM.1: Cryptographic Key Generation
NDcPP21:FCS_CKM.2: Cryptographic Key Establishment
NDcPP21:FCS_CKM.4: Cryptographic Key Destruction
NDcPP21:FCS_COP.1/DataEncryption: Cryptographic Operation
(AES Data Encryption/Decryption)
NDcPP21:FCS_COP.1/Hash: Cryptographic Operation (Hash
Algorithm)
NDcPP21:FCS_COP.1/KeyedHash: Cryptographic Operation (Keyed
Hash Algorithm)
NDcPP21:FCS_COP.1/SigGen: Cryptographic Operation (Signature
Generation and Verification)
NDcPP21:FCS_HTTPS_EXT.1: HTTPS Protocol
NDcPP21:FCS_RBG_EXT.1: Random Bit Generation
NDcPP21:FCS_SSHS_EXT.1: SSH Server Protocol
NDcPP21:FCS_TLSC_EXT.2: TLS Client Protocol with
authentication
NDcPP21:FCS_TLSS_EXT.1: TLS Server Protocol
FIA: Identification and
authentication
NDcPP21:FIA_AFL.1: Authentication Failure Management
NDcPP21:FIA_PMG_EXT.1: Password Management
NDcPP21:FIA_UAU.7: Protected Authentication Feedback
NDcPP21:FIA_UAU_EXT.2: Password-based Authentication
Mechanism
NDcPP21:FIA_UIA_EXT.1: User Identification and Authentication
NDcPP21:FIA_X509_EXT.1/Rev: X.509 Certificate Validation
NDcPP21:FIA_X509_EXT.2: X.509 Certificate Authentication
NDcPP21:FIA_X509_EXT.3: X.509 Certificate Requests
FMT: Security management NDcPP21:FMT_MOF.1/ManualUpdate: Management of security
functions behavior
NDcPP21:FMT_MTD.1/CoreData: Management of TSF Data
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 11 of 32
NDcPP21:FMT_SMF.1: Specification of Management Functions
NDcPP21:FMT_SMR.2: Restrictions on Security Roles
FPT: Protection of the TSF NDcPP21:FPT_APW_EXT.1: Protection of Administrator Passwords
NDcPP21:FPT_SKP_EXT.1: Protection of TSF Data (for reading of
all pre-shared, symmetric and private keys)
NDcPP21:FPT_STM_EXT.1: Reliable Time Stamps
NDcPP21:FPT_TST_EXT.1: TSF testing
NDcPP21:FPT_TUD_EXT.1: Trusted update
FTA: TOE access NDcPP21:FTA_SSL.3: TSF-initiated Termination
NDcPP21:FTA_SSL.4: User-initiated Termination
NDcPP21:FTA_SSL_EXT.1: TSF-initiated Session Locking
NDcPP21:FTA_TAB.1: Default TOE Access Banners
FTP: Trusted path/channels NDcPP21:FTP_ITC.1: Inter-TSF trusted channel
NDcPP21:FTP_TRP.1/Admin: Trusted Path
Table 5-1 TOE Security Functional Components
5.1.1 Security audit (FAU)
5.1.1.1 Audit Data Generation (NDcPP21:FAU_GEN.1)
NDcPP21:FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
1. Administrative login and logout (name of user account shall be logged if
individual user accounts are required for administrators).
2. Changes to TSF data related to configuration changes (in addition to the
information that a change occurred it shall be logged what has been changed).
3. Generating/import of, changing, or deleting of cryptographic keys (in addition to
the action itself a unique key name or key reference shall be logged).
4. Resetting passwords (name of related user account shall be logged).
5. [no other actions];
d) Specifically defined auditable events listed in Table 5-2.
Requirement Auditable Events Additional Content
NDcPP21:FAU_GEN.1 None None
NDcPP21:FAU_GEN.2 None None
NDcPP21:FAU_STG_EXT.1 None None
NDcPP21:FCS_CKM.1 None None
NDcPP21:FCS_CKM.2 None None
NDcPP21:FCS_CKM.4 None None
NDcPP21:FCS_COP.1/DataEncryption None None
NDcPP21:FCS_COP.1/Hash None None
NDcPP21:FCS_COP.1/KeyedHash None None
NDcPP21:FCS_COP.1/SigGen None None
NDcPP21:FCS_HTTPS_EXT.1 Failure to establish a HTTPS
Session.
Reason for failure.
NDcPP21:FCS_RBG_EXT.1 None None
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 12 of 32
NDcPP21:FCS_SSHS_EXT.1 Failure to establish an SSH
session.
Reason for failure.
NDcPP21:FCS_TLSC_EXT.2 Failure to establish a TLS
Session.
Reason for failure.
NDcPP21:FCS_TLSS_EXT.1 Failure to establish a TLS
Session.
Reason for failure.
NDcPP21:FIA_AFL.1 Unsuccessful login attempt limit
is met or exceeded.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_PMG_EXT.1
NDcPP21:FIA_UAU.7
NDcPP21:FIA_UAU_EXT.2 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_UIA_EXT.1 All use of identification and
authentication mechanism.
Origin of the attempt (e.g., IP
address).
NDcPP21:FIA_X509_EXT.1/Rev Unsuccessful attempt to validate
a certificate. Any addition,
replacement or removal of trust
anchors in the TOE's trust store
Reason for failure of certificate
validation Identification of
certificates added, replaced or
removed as trust anchor in the
TOE's trust store
NDcPP21:FIA_X509_EXT.2 None None
NDcPP21:FIA_X509_EXT.3 None None
NDcPP21:FMT_MOF.1/ManualUpdate Any attempt to initiate a manual
update.
NDcPP21:FMT_MTD.1/CoreData All management activities of TSF
data.
NDcPP21:FMT_SMF.1 All management activities of TSF
data.
NDcPP21:FMT_SMR.2 None None
NDcPP21:FPT_APW_EXT.1 None None
NDcPP21:FPT_SKP_EXT.1 None None
NDcPP21:FPT_STM_EXT.1 Discontinuous changes to time -
either Administrator actuated or
changed via an automated
process. (Note that no continuous
changes to time need to be
logged. See also application note
on FPT_STM_EXT.1)
For discontinuous changes to
time: The old and new values
for the time. Origin of the
attempt to change time for
success and failure (e.g., IP
address).
NDcPP21:FPT_TST_EXT.1
NDcPP21:FPT_TUD_EXT.1 Initiation of update; result of the
update attempt (success or
failure).
NDcPP21:FTA_SSL.3 The termination of a remote
session by the session locking
mechanism.
NDcPP21:FTA_SSL.4 The termination of an interactive
session.
NDcPP21:FTA_SSL_EXT.1 The termination of a local session
by the session locking
mechanism.
NDcPP21:FTA_TAB.1 None None
NDcPP21:FTP_ITC.1 Initiation of the trusted channel.
Termination of the trusted
channel. Failure of the trusted
channel functions.
Identification of the initiator
and target of failed trusted
channels establishment attempt.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 13 of 32
NDcPP21:FTP_TRP.1/Admin Initiation of the trusted path.
Termination of the trusted path.
Failure of the trusted path
functions.
Table 5-2 Auditable Events
NDcPP21:FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the cPP/ST, information specified in column three of Table 5-2.
5.1.1.2 User identity association (NDcPP21:FAU_GEN.2)
NDcPP21:FAU_GEN.2.1
For audit events resulting from actions of identified users, the TSF shall be able to associate each
auditable event with the identity of the user that caused the event.
5.1.1.3 Protected Audit Event Storage (NDcPP21:FAU_STG_EXT.1)
NDcPP21:FAU_STG_EXT.1.1
The TSF shall be able to transmit the generated audit data to an external IT entity using a trusted
channel according to FTP_ITC.1.
NDcPP21:FAU_STG_EXT.1.2
The TSF shall be able to store generated audit data on the TOE itself. [TOE shall consist of a
single standalone component that stores audit data locally,]
NDcPP21:FAU_STG_EXT.1.3
The TSF shall [overwrite previous audit records according to the following rule: [overwrite audit
data using a log file rotation which deletes the oldest archived log file]] when the local storage
space for audit data is full.
5.1.2 Cryptographic support (FCS)
5.1.2.1 Cryptographic Key Generation (NDcPP21:FCS_CKM.1)
NDcPP21:FCS_CKM.1.1
The TSF shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm: [
- RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Appendix B.3,
- FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526,
Section 3].
5.1.2.2 Cryptographic Key Establishment (NDcPP21:FCS_CKM.2)
NDcPP21:FCS_CKM.2.1
The TSF shall perform cryptographic key establishment in accordance with a specified
cryptographic key establishment method: [
- RSA-based key establishment schemes that meet the following: RSAES-PKCS1-v1_5 as
specified in Section 7.2 of RFC 8017, - Public-Key Cryptography Standards (PKCS)
#1: RSA Cryptography Specifications Version 2.1 (TD0402 applied),
- Key establishment scheme using Diffie-Hellman group 14 that meets the following:
RFC 3526, Section 3].
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 14 of 32
5.1.2.3 Cryptographic Key Destruction (NDcPP21:FCS_CKM.4)
NDcPP21:FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key
destruction method
- For plaintext keys in volatile storage, the destruction shall be executed by a [destruction
of reference to the key directly followed by a request for garbage collection];
- For plaintext keys in non-volatile storage, the destruction shall be executed by the
invocation of an interface provided by a part of the TSF that [logically addresses the
storage location of the key and performs a [single] overwrite consisting of [a new
value of the key]]
that meets the following: No Standard.
5.1.2.4 Cryptographic Operation (AES Data Encryption/Decryption)
(NDcPP21:FCS_COP.1/DataEncryption)
NDcPP21:FCS_COP.1.1/DataEncryption
The TSF shall perform encryption/decryption in accordance with a specified cryptographic
algorithm AES used in [CBC] mode and cryptographic key sizes [128 bits, 256 bits] that meet the
following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116].
5.1.2.5 Cryptographic Operation (Hash Algorithm) (NDcPP21:FCS_COP.1/Hash)
NDcPP21:FCS_COP.1.1/Hash
The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256, SHA-512] and message digest sizes [160, 256, 512]
that meet the following: ISO/IEC 10118-3:2004.
5.1.2.6 Cryptographic Operation (Keyed Hash Algorithm) (NDcPP21:FCS_COP.1/KeyedHash)
NDcPP21:FCS_COP.1.1/KeyedHash
The TSF shall perform keyed-hash message authentication in accordance with a specified
cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512] and
cryptographic key sizes [160, 256, 512] and message digest sizes [160, 256, 512] bits that meet the
following: ISO/IEC 9797-2:2011, Section 7 'MAC Algorithm 2'.
5.1.2.7 Cryptographic Operation (Signature Generation and Verification) (NDcPP21:FCS_COP.1/SigGen)
NDcPP21:FCS_COP.1.1/SigGen
The TSF shall perform cryptographic signature services (generation and verification) in
accordance with a specified cryptographic algorithm [
- RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits]]
that meet the following: [
- For RSA schemes: FIPS PUB 186-4, 'Digital Signature Standard (DSS)', Section 5.5,
using PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5;
ISO/IEC 9796-2, Digital signature scheme 2 or Digital Signature scheme 3].
5.1.2.8 HTTPS Protocol (NDcPP21:FCS_HTTPS_EXT.1)
NDcPP21:FCS_HTTPS_EXT.1.1
The TSF shall implement the HTTPS protocol that complies with RFC 2818.
NDcPP21:FCS_HTTPS_EXT.1.2
The TSF shall implement HTTPS using TLS.
NDcPP21:FCS_HTTPS_EXT.1.3
If a peer certificate is presented, the TSF shall [not require client authentication] if the peer
certificate is deemed invalid.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 15 of 32
5.1.2.9 Random Bit Generation (NDcPP21:FCS_RBG_EXT.1)
NDcPP21:FCS_RBG_EXT.1.1
The TSF shall perform all deterministic random bit generation services in accordance with
ISO/IEC 18031:2011 using [CTR_DRBG (AES)].
NDcPP21:FCS_RBG_EXT.1.2
The deterministic RBG shall be seeded by at least one entropy source that accumulates entropy
from [[two] software-based noise sources] with a minimum of [256 bits] of entropy at least equal
to the greatest security strength, according to ISO/IEC 18031:2011Table C.1 'Security Strength
Table for Hash Functions', of the keys and hashes that it will generate.
5.1.2.10 SSH Server Protocol (NDcPP21:FCS_SSHS_EXT.1)
NDcPP21:FCS_SSHS_EXT.1.1
The TSF shall implement the SSH protocol that complies with RFC(s) [4251, 4252, 4253, 4254].
(TD0398 applied)
NDcPP21:FCS_SSHS_EXT.1.2
The TSF shall ensure that the SSH protocol implementation supports the following authentication
methods as described in RFC 4252: public key-based, [password-based].
NDcPP21:FCS_SSHS_EXT.1.3
The TSF shall ensure that, as described in RFC 4253, packets greater than [256K] bytes in an SSH
transport connection are dropped.
NDcPP21:FCS_SSHS_EXT.1.4
The TSF shall ensure that the SSH transport implementation uses the following encryption
algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256-cbc].
NDcPP21:FCS_SSHS_EXT.1.5
The TSF shall ensure that the SSH public-key based authentication implementation uses [ssh-rsa]
as its public key algorithm(s) and rejects all other public key algorithms. (TD0424 applied)
NDcPP21:FCS_SSHS_EXT.1.6
The TSF shall ensure that the SSH transport implementation uses [hmac-sha2-256, hmac-sha2-
512] as its MAC algorithm(s) and rejects all other MAC algorithm(s).
NDcPP21:FCS_SSHS_EXT.1.7
The TSF shall ensure that [diffie-hellman-group14-sha1] and [diffie-hellman-group14-sha256]
are the only allowed key exchange methods used for the SSH protocol.
NDcPP21:FCS_SSHS_EXT.1.8
The TSF shall ensure that within SSH connections the same session keys are used for a threshold
of no longer than one hour, and no more than one gigabyte of transmitted data. After either of the
thresholds are reached a rekey needs to be performed.
5.1.2.11 TLS Client Protocol with authentication (NDcPP21:FCS_TLSC_EXT.2)
NDcPP21:FCS_TLSC_EXT.2.1
The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS
and SSL versions. The TLS implementation will support the following ciphersuites: [
- TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
- TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
- TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
- TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246].
NDcPP21:FCS_TLSC_EXT.2.2
The TSF shall verify that the presented identifier matches the reference identifier per RFC 6125
section 6.
NDcPP21:FCS_TLSC_EXT.2.3
When establishing a trusted channel, by default the TSF shall not establish a trusted channel if the
server certificate is invalid. The TSF shall also [Not implement any administrator override
mechanism].
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 16 of 32
NDcPP21:FCS_TLSC_EXT.2.4
The TSF shall [not present the Supported Elliptic Curves Extension] in the Client Hello.
NDcPP21:FCS_TLSC_EXT.2.5
The TSF shall support mutual authentication using X.509v3 certificates.
5.1.2.12 TLS Server Protocol (NDcPP21:FCS_TLSS_EXT.1)
NDcPP21:FCS_TLSS_EXT.1.1
The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] and reject all other TLS
and SSL versions. The TLS implementation will support the following ciphersuites: [
- TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268,
- TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268,
- TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246,
- TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246].
NDcPP21:FCS_TLSS_EXT.1.2
The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS 1.0, and [none].
NDcPP21:FCS_TLSS_EXT.1.3
The TSF shall [perform RSA key establishment with key size [2048 bits], generate Diffie-
Hellman parameters of size [2048 bits]].
5.1.3 Identification and authentication (FIA)
5.1.3.1 Authentication Failure Management (NDcPP21:FIA_AFL.1)
NDcPP21:FIA_AFL.1.1
The TSF shall detect when an Administrator configurable positive integer within [the range of 1
to 2,147,483,647] unsuccessful authentication attempts occur related to Administrators attempting
to authenticate remotely using a password. (TD0408 applied)
NDcPP21:FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been met, the TSF shall
[prevent the offending Administrator from successfully establishing remote session using any
authentication method that involves a password until an Administrator defined time period has
elapsed]. (TD0408 applied)
5.1.3.2 Password Management (NDcPP21:FIA_PMG_EXT.1)
NDcPP21:FIA_PMG_EXT.1.1
The TSF shall provide the following password management capabilities for administrative
passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case
letters, numbers, and the following special characters: ['!', '@', '#', '$', '%', '^', '&',
'*', '(', ')'];
b) Minimum password length shall be configurable to between [15] and [255] characters.
5.1.3.3 Protected Authentication Feedback (NDcPP21:FIA_UAU.7)
NDcPP21:FIA_UAU.7.1
The TSF shall provide only obscured feedback to the administrative user while the authentication
is in progress at the local console.
5.1.3.4 Password-based Authentication Mechanism (NDcPP21:FIA_UAU_EXT.2)
NDcPP21:FIA_UAU_EXT.2.1
The TSF shall provide a local [password-based, SSH public key-based] authentication mechanism
to perform local administrative user authentication. (TD0408 applied)
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 17 of 32
5.1.3.5 User Identification and Authentication (NDcPP21:FIA_UIA_EXT.1)
NDcPP21:FIA_UIA_EXT.1.1
The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate the
identification and authentication process:
- Display the warning banner in accordance with FTA_TAB.1;
- [no other actions].
NDcPP21:FIA_UIA_EXT.1.2
The TSF shall require each administrative user to be successfully identified and authenticated
before allowing any other TSF-mediated actions on behalf of that administrative user.
5.1.3.6 X.509 Certificate Validation (NDcPP21:FIA_X509_EXT.1/Rev)
NDcPP21:FIA_X509_EXT.1.1/Rev
The TSF shall validate certificates in accordance with the following rules:
- RFC 5280 certificate validation and certification path validation supporting a minimum
path length of three certificates.
- The certification path must terminate with a trusted CA certificate designated as a trust
anchor.
- The TSF shall validate a certification path by ensuring that all CA certificates in the
certification path contain the basicConstraints extension with the CA flag set to TRUE.
- The TSF shall validate the revocation status of the certificate using [Certificate
Revocation List (CRL) as specified in RFC 5759 Section 5]
- The TSF shall validate the extendedKeyUsage field according to the following rules:
 Certificates used for trusted updates and executable code integrity verification
shall have the Code Signing purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the
extendedKeyUsage field.
 Server certificates presented for TLS shall have the Server Authentication
purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
 Client certificates presented for TLS shall have the Client Authentication
purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
 OCSP certificates presented for OCSP responses shall have the OCSP Signing
purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.
NDcPP21:FIA_X509_EXT.1.2/Rev
The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is
present and the CA flag is set to TRUE.
5.1.3.7 X.509 Certificate Authentication (NDcPP21:FIA_X509_EXT.2)
NDcPP21:FIA_X509_EXT.2.1
The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for
[HTTPS, TLS], and [no additional uses].
NDcPP21:FIA_X509_EXT.2.2
When the TSF cannot establish a connection to determine the validity of a certificate, the TSF
shall [not accept the certificate].
5.1.3.8 X.509 Certificate Requests (NDcPP21:FIA_X509_EXT.3)
NDcPP21:FIA_X509_EXT.3.1
The TSF shall generate a Certification Request as specified by RFC 2986 and be able to provide
the following information in the request: public key and [Common Name, Organization,
Organizational Unit, Country].
NDcPP21:FIA_X509_EXT.3.2
The TSF shall validate the chain of certificates from the Root CA upon receiving the CA
Certificate Response.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 18 of 32
5.1.4 Security management (FMT)
5.1.4.1 Management of security functions behaviour (NDcPP21:FMT_MOF.1/ManualUpdate)
NDcPP21:FMT_MOF.1.1/ManualUpdate
The TSF shall restrict the ability to enable the functions to perform manual update to Security
Administrators.
5.1.4.2 Management of TSF Data (NDcPP21:FMT_MTD.1/CoreData)
NDcPP21:FMT_MTD.1.1/CoreData
The TSF shall restrict the ability to manage the TSF data to Security Administrators.
5.1.4.3 Specification of Management Functions (NDcPP21:FMT_SMF.1)
NDcPP21:FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
- Ability to administer the TOE locally and remotely;
- Ability to configure the access banner;
- Ability to configure the session inactivity time before session termination or locking;
- Ability to update the TOE, and to verify the updates using [digital signature] capability
prior to installing those updates;
- Ability to configure the authentication failure parameters for FIA_AFL.1;
- [Ability to configure audit behavior,
- Ability to configure the cryptographic functionality
- ]. (TD0408 applied)
5.1.4.4 Restrictions on Security Roles (NDcPP21:FMT_SMR.2)
NDcPP21:FMT_SMR.2.1
The TSF shall maintain the roles: - Security Administrator.
NDcPP21:FMT_SMR.2.2
The TSF shall be able to associate users with roles.
NDcPP21:FMT_SMR.2.3
The TSF shall ensure that the conditions
- The Security Administrator role shall be able to administer the TOE locally;
- The Security Administrator role shall be able to administer the TOE remotely are
satisfied.
5.1.5 Protection of the TSF (FPT)
5.1.5.1 Protection of Administrator Passwords (NDcPP21:FPT_APW_EXT.1)
NDcPP21:FPT_APW_EXT.1.1
The TSF shall store passwords in non-plaintext form.
NDcPP21:FPT_APW_EXT.1.2
The TSF shall prevent the reading of plaintext passwords.
5.1.5.2 Protection of TSF Data (for reading of all pre-shared, symmetric and private keys)
(NDcPP21:FPT_SKP_EXT.1)
NDcPP21:FPT_SKP_EXT.1.1
The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private keys.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 19 of 32
5.1.5.3 Reliable Time Stamps (NDcPP21:FPT_STM_EXT.1)
NDcPP21:FPT_STM_EXT.1.1
The TSF shall be able to provide reliable time stamps for its own use.
NDcPP21:FPT_STM_EXT.1.2
The TSF shall [allow the Security Administrator to set the time].
5.1.5.4 TSF testing (NDcPP21:FPT_TST_EXT.1)
NDcPP21:FPT_TST_EXT.1.1
The TSF shall run a suite of the following self-tests [: cryptographic self-tests run during initial
start-up (on power on), TSF integrity tests run periodically during normal operation] to
demonstrate the correct operation of the TSF: [cryptographic known answer self-tests and TOE
software integrity checks].
5.1.5.5 Trusted update (NDcPP21:FPT_TUD_EXT.1)
NDcPP21:FPT_TUD_EXT.1.1
The TSF shall provide Security Administrators the ability to query the currently executing version
of the TOE firmware/software and [no other TOE firmware/software version].
NDcPP21:FPT_TUD_EXT.1.2
The TSF shall provide Security Administrators the ability to manually initiate updates to TOE
firmware/software and [no other update mechanism].
NDcPP21:FPT_TUD_EXT.1.3
The TSF shall provide means to authenticate firmware/software updates to the TOE using a
[digital signature mechanism] prior to installing those updates.
5.1.6 TOE access (FTA)
5.1.6.1 TSF-initiated Termination (NDcPP21:FTA_SSL.3)
NDcPP21:FTA_SSL.3.1
The TSF shall terminate a remote interactive session after a Security Administrator-configurable
time interval of session inactivity.
5.1.6.2 User-initiated Termination (NDcPP21:FTA_SSL.4)
NDcPP21:FTA_SSL.4.1
The TSF shall allow Administrator-initiated termination of the Administrator's own interactive
session.
5.1.6.3 TSF-initiated Session Locking (NDcPP21:FTA_SSL_EXT.1)
NDcPP21:FTA_SSL_EXT.1.1
The TSF shall, for local interactive sessions, [- terminate the session]
after a Security Administrator-specified time period of inactivity.
5.1.6.4 Default TOE Access Banners (NDcPP21:FTA_TAB.1)
NDcPP21:FTA_TAB.1.1
Before establishing an administrative user session the TSF shall display a Security Administrator-
specified advisory notice and consent warning message regarding use of the TOE.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 20 of 32
5.1.7 Trusted path/channels (FTP)
5.1.7.1 Inter-TSF trusted channel (NDcPP21:FTP_ITC.1)
NDcPP21:FTP_ITC.1.1
The TSF shall be capable of using [TLS] to provide a trusted communication channel between
itself and authorized IT entities supporting the following capabilities: audit server, [no other
capabilities] that is logically distinct from other communication channels and provides assured
identification of its end points and protection of the channel data from disclosure and detection of
modification of the channel data.
NDcPP21:FTP_ITC.1.2
The TSF shall permit the TSF or the authorized IT entities to initiate communication via the
trusted channel.
NDcPP21:FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for [export to an audit server].
5.1.7.2 Trusted Path (NDcPP21:FTP_TRP.1/Admin)
NDcPP21:FTP_TRP.1.1/Admin
The TSF shall be capable of using [SSH, HTTPS, TLS] to provide a communication path between
itself and authorized remote Administrators that is logically distinct from other communication
paths and provides assured identification of its end points and protection of the communicated
data from disclosure and provides detection of modification of the channel data.
NDcPP21:FTP_TRP.1.2/Admin
The TSF shall permit remote Administrators to initiate communication via the trusted path.
NDcPP21:FTP_TRP.1.3/Admin
The TSF shall require the use of the trusted path for initial Administrator authentication and all
remote administration actions.
5.2 TOE Security Assurance Requirements
The SARs for the TOE are the components as specified in Part 3 of the Common Criteria. Note that the SARs have
effectively been refined with the assurance activities explicitly defined in association with both the SFRs and SARs.
Requirement Class Requirement Component
ADV: Development ADV_FSP.1: Basic Functional Specification
AGD: Guidance documents AGD_OPE.1: Operational User Guidance
AGD_PRE.1: Preparative Procedures
ALC: Life-cycle support ALC_CMC.1: Labelling of the TOE
ALC_CMS.1: TOE CM Coverage
ATE: Tests ATE_IND.1: Independent Testing - Conformance
AVA: Vulnerability assessment AVA_VAN.1: Vulnerability Survey
Table 5-3 Assurance Components
5.2.1 Development (ADV)
5.2.1.1 Basic Functional Specification (ADV_FSP.1)
ADV_FSP.1.1d
The developer shall provide a functional specification.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 21 of 32
ADV_FSP.1.2d
The developer shall provide a tracing from the functional specification to the SFRs.
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 TSF shall support mutual authentication of TLS clients using X.509v3 certificates.
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.
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.
5.2.2 Guidance documents (AGD)
5.2.2.1 Operational User Guidance (AGD_OPE.1)
AGD_OPE.1.1d
The developer shall provide operational user guidance.
AGD_OPE.1.1c
The operational user guidance shall describe, for each user role, the useraccessible 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 fulfill the security objectives for the operational environment as described in
the ST.
AGD_OPE.1.7c
The operational user guidance shall be clear and reasonable.
AGD_OPE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 22 of 32
5.2.2.2 Preparative Procedures (AGD_PRE.1)
AGD_PRE.1.1d
The developer shall provide the TOE, including its preparative procedures.
AGD_PRE.1.1c
The preparative procedures shall describe all the steps necessary for secure acceptance of the
delivered TOE in accordance with the developer's delivery procedures.
AGD_PRE.1.2c
The preparative procedures shall describe all the steps necessary for secure installation of the TOE
and for the secure preparation of the operational environment in accordance with the security
objectives for the operational environment as described in the ST.
AGD_PRE.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
AGD_PRE.1.2e
The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared
securely for operation.
5.2.3 Life-cycle support (ALC)
5.2.3.1 Labelling of the TOE (ALC_CMC.1)
ALC_CMC.1.1d
The developer shall provide the TOE and a reference for the TOE.
ALC_CMC.1.1c
The TOE shall be labelled with its unique reference.
ALC_CMC.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.3.2 TOE CM Coverage (ALC_CMS.1)
ALC_CMS.1.1d
The developer shall provide a configuration list for the TOE.
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.
ALC_CMS.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
5.2.4 Tests (ATE)
5.2.4.1 Independent Testing - Conformance (ATE_IND.1)
ATE_IND.1.1d
The developer shall provide the TOE for testing.
ATE_IND.1.1c
The TOE shall be suitable for testing.
ATE_IND.1.1e
The evaluator shall confirm that the information provided meets all requirements for content and
presentation of evidence.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 23 of 32
ATE_IND.1.2e
The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.
5.2.5 Vulnerability assessment (AVA)
5.2.5.1 Vulnerability Survey (AVA_VAN.1)
AVA_VAN.1.1d
The developer shall provide the TOE for testing.
AVA_VAN.1.1c
The TOE shall be suitable for testing.
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.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 24 of 32
6. TOE Summary Specification
This chapter describes the security functions:
 Security audit
 Cryptographic support
 Identification and authentication
 Security management
 Protection of the TSF
 TOE access
 Trusted path/channels
6.1 Security audit
The TOE acts as a network device generating audit data. The TOE can be configured to forward audit data to a remote
network device. This forwarding can include its own audit data. Thus, the TOE can be configured to send its own
audit data to an external network peer using a trusted channel protected by TLS.
All audit logs are stored in plain text and are archived and compressed when the audit log file reaches 200 MB. The
current log file is named audit.log. When the file reaches 200 MB, the file is compressed and renamed to audit.1.gz.
The file number increments each time that a log file is archived. QRadar stores up to 50 archived log files. These
audit files are accessible only to authenticated administrators.
The Security audit function satisfies the following security functional requirements:
 NDcPP21:FAU_GEN.1: Auditing is always being generated when the TOE is running. Thus, the start and
stop of auditing corresponds to boot and shutdown of the system. The boot and shutdown of the system are
audited. The TOE audits the events identified in Table 5-2 Auditable Events.
Audit records generated by the TOE include a date and time, event type, success or failure indication. For
actions that can be assigned to a specific user or network entity, a subject identifier (e.g., username or network
address) in included within the audit record. Audit records identified by Table 5-2 contain the additional
information described by column 3 of Table 5-2. Audit records contain a certificate’s entire domain name to
identify the certificate.
NDcPP21:FAU_GEN.2: For actions that can be assigned to a specific user or network entity, a subject
identifier (e.g., username or network address) in included within the audit record.
 NDcPP21:FAU_STG_EXT.1: The TOE can store audit data as well as transmit audit data to an external
audit server through a trusted channel protected by TLS. The external audit server can be any server
supporting the transmission of audit data tunneled within TLS. All audit logs when stored internally are
stored in plain text. These logs are archived and compressed when the audit log file size reaches 200 MB.
The current log file is named audit.log. When the file reaches 200 MB, the file is compressed and renamed
to audit.log.1.gz. The file number increments each time that a log file is archived. QRadar stores up to 50
archived log files. The TOE deletes the oldest archived log file, renumbering existing files when a new file
is to be archived.
6.2 Cryptographic support
The TOE utilizes cryptographic support from RedHat’s OpenSSL (1.0.2k-FIPS) and IBM FIPS JCE (version 1.8)
library. Both are multi-algorithm libraries providing general-purpose cryptographic services. The purpose of the
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 25 of 32
OpenSSL library is to provide an API for cryptographic functionality for system services. The OpenSSL library also
provides centralized control over FIPS-Approved mode status, provides availability of only CAVP/FIPS-Approved
algorithms or vendor-affirmed implementations of non FIPS-Approved algorithms, and provides for centralized
logging and reporting of the cryptographic engine.
The purpose of the IBM FIPS JCE library is to provide only CAVP verified algorithms for use in Java based processes
within the TOE. The TOE utilizes these libraries for cryptographic operations it performs (including those associated
with TLS, certificate operations, system integrity, and update verification). The libraries used by the TOE have
obtained CAVP certificates as shown in the following tables.
The TOE utilizes the IBM JCE library for cryptographic operations surrounding the trusted channel for TLS
communication to a syslog server. This includes cryptographic operations for signature generation, signature
verification, key establishment, random number generation, encryption, decryption, and hashing.
The TOE also uses the OpenSSL library to provide the same cryptographic operations in support of the TOE offered
trusted paths via the HTTPS/TLS protected Web UI and CLI protected SSH. Additionally, the TOE also uses the
OpenSSL library for the generation of keys during creation of a Certificate Signing Request (CSR).
The TOE runs on the QRadar 3129C Appliance, which includes an Intel® Xeon® Gold 5118 CPU and operating
system support from Red Hat Enterprise Linux server release 7.5.
C1207, C1208, and C1209
Table 6-1 CAVP Certificates for OpenSSL library
Functions Standards SFR
CAVP
Certificate
Encryption/Decryption
AES CBC (128 and 256
bits)
AES CTR (128 and 256
bits)
FIPS Pub 197
NIST SP 800-38A
ISO 18033-3 and ISO
10116
FCS_COP.1/DataEncryption C 1209
Cryptographic Signature Services
RSA 2048-bit
Signature Gen & Verify
FIPS Pub 186-4
ISO/IEC 9796-2
FCS_COP.1/SigGen C 1209
Cryptographic hashing
SHA-1/256/384/512 FIPS Pub 180-3
ISO/IEC 10118-3:2004
FCS_COP.1/Hash C 1209
Keyed-hash message authentication
HMAC-SHA-1,
HMAC_SHA2-256,
HMAC-SHA-384, HMAC-
SHA2-512 (digest sizes and
block sizes of 160, 256, and
512 bits)
FIPS Pub 198-1
FIPS Pub 180-3
ISO/IEC 9797-2:2011
FCS_COP.1/KeyedHash C 1209
Cryptographic Key Generation
RSA 2048-bit
Key Gen
FIPS Pub 186-4
ISO/IEC 9796-2
FCS_CKM.1 C 1209
Key Establishment
RSA RSAES-PKCS1-v1_5 FCS_CKM.2 Vendor
Affirmed
Random bit generation
CTR_DRBG (AES) FIPS SP 800-90B
ISO/IEC 18031:2011
FCS_RBG_EXT.1 C 1209
Table 6-2 CAVP Certificates for IBMFIPSJCE library
Functions Standards SFR CAVP
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 26 of 32
Certificate
Encryption/Decryption
AES CBC (128 and 256 bits) FIPS Pub 197
NIST SP 800-38A
ISO 18033-3 and ISO 10116
FCS_COP.1/DataEncryption C 1207
Cryptographic Signature Services
RSA 2048-bit
Signature Gen & Verify
FIPS Pub 186-4
ISO/IEC 9796-2
FCS_COP.1/SigGen C 1207
Cryptographic hashing
SHA-1/256/512 FIPS Pub 180-3
ISO/IEC 10118-3:2004
FCS_COP.1/Hash C 1207
Keyed-hash message authentication
HMAC-SHA-1, HMAC_SHA2-256,
HMAC-SHA2-512 (digest sizes and
block sizes of 160, 256, and 512 bits)
FIPS Pub 198-1
FIPS Pub 180-3
ISO/IEC 9797-2:2011
FCS_COP.1/KeyedHash C 1207
Cryptographic Key Generation
RSA 2048-bit
Key Gen
FIPS Pub 186-4
ISO/IEC 9796-2
FCS_CKM.1 C 1207
Key Establishment
RSA RSAES-PKCS1-v1_5 FCS_CKM.2 Vendor
Affirmed
Random bit generation
CTR_DRBG (AES) FIPS SP 800-90B
ISO/IEC 18031:2011
FCS_RBG_EXT.1 C 1207
The TOE also includes GNU GPG to perform verification of RSA signatures on product updates in support of
FPT_TUD_EXT.1. GPG utilizes the libgcrypt library (version 1.5.3-14.el7.x86_64), which has obtained CAVP
certs (see Table 6-3 CAVP Certificates for libgcrypt library) to demonstrate functions supporting signature
verification surrounding trusted updates.
Table 6-3 CAVP Certificates for libgcrypt library
Functions Standards SFR
CAVP
Certificate
Cryptographic signature services
RSA 2048-bit
Signature Gen & Verify
FIPS Pub 186-4
ISO/IEC 9796-2
FCS_COP.1/SigGen C 1208
Cryptographic hashing
SHA-1, SHS-256 FIPS Pub 180-3
ISO/IEC 10118-3:2004
FCS_COP.1/Hash C 1208
These supporting cryptographic functions are provided by the TOE to support the SSHv2 (compliant with RFCs
4251, 4252, 4253, and 4254), TLSv1.1 (compliant with RFC 4346), and TLSv1.2 (compliant with RFC 5289) secure
communication protocols. The TOE supports the TLS ciphersuites identified below. The TOE also supports Diffie-
Hellman key group 14 (2048 bit) key generation for SSH key establishment.
The TOE supports the following TLS ciphersuites to connect with external syslog audit servers (provided by the
IBMFIPSJCE library).
 TLS_RSA_WITH_AES_128_CBC_SHA
 TLS_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA256
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 27 of 32
The TOE allows inbound TLS connections using only the following ciphersuites (provided by OpenSSL library).
 TLS_RSA_WITH_AES_128_CBC_SHA
 TLS_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA256
 TLS_RSA_WITH_AES_256_CBC_SHA256
The TOE supports the secret keys, private keys and CSPs as shown in Table 6-4 Cryptographic Keys.
Table 6-4 Cryptographic Keys
Key or CSP: Zeroized upon: Stored in: Zeroized by:
SSH host RSA private
key
Administrative
action
/root/.ssh/id_rsa Generating new key, or
uninstalling the module
SSH host RSA public
key
Administrative
action
/root/.ssh/id_rsa.pub Generating new key, or
uninstalling the module
SSH session key Connection
Termination
RAM API call, power cycle, or host
reboot
TLS host RSA private
key
Administrative
action
/etc/httpd/conf/certs/cert.key Generating new private key, or
uninstalling the module
TLS host RSA digital
certificate
Administrative
action
/etc/httpd/conf/certs/cert.cert Generating new certificate, or
uninstalling the module
TLS pre-master secret Process Restart
(Manual)
RAM API call, power cycle, or host
reboot
TLS session key Process Restart RAM API call, power cycle, or host
reboot
DH Private Exponent Process Restart RAM API call, power cycle, or host
reboot
DH Public Key Process Restart RAM API call, power cycle, or host
reboot
Administrator/User
Passwords
User-driven
account
management
On disk, in hashed form Setting new password, or
uninstalling the module
GPG Update key Install/Setup and
Updates
Hard coded, internal to
shared library
Uninstalling the module
DRBG Seed System Reboot RAM API call, power cycle, or host
reboot
DRBG Value V System Reboot RAM API call, power cycle, or host
reboot
DRBG Constant C System Reboot RAM API call, power cycle, or host
reboot
The TOE stores all persistent secret and private keys on disk and stores all ephemeral keys in RAM (as indicated in
the above table). Additionally, the TOE is designed to zeroize secret and private keys when they are no longer required
by the TOE as detailed below. The TOE’s zeroization has been subjected to FIPS 140 validation. Note that zeroization
occurs as shown in column 4 of Table 6-4.
The Cryptographic support function satisfies the following security functional requirements:
NDcPP21:FCS_CKM.1: The TOE generates RSA keys of size 2048-bits using the Openssl library outlined in C1207,
C1208, and C1209
 Table 6-1 CAVP Certificates for OpenSSL library and Table 6-2 CAVP Certificates for IBMFIPSJCE
library.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 28 of 32
NDcPP21:FCS_CKM.2: The TOE generates RSA keys for use with both inbound and outbound TLS using
key establishment schemes identified by C1207, C1208, and C1209
 Table 6-1 CAVP Certificates for OpenSSL library and Table 6-2 CAVP Certificates for IBMFIPSJCE
library. The TOE also supports a Key establishment scheme using Diffie-Hellman group 14 that meets the
following: RFC 3526, Section 3. The TOE implements Diffie-Hellman group 14, using the modulus and
generator specified by Section 3 of RFC3526.
 NDcPP21:FCS_CKM.4: The TOE stores all persistent secret and private keys on disk and stores all
ephemeral keys in RAM (as indicated in the above table). The TOE clears these keys (i.e., plaintext keys in
volatile storage), by destroying the reference to the key and requesting a garbage collection action.
Additionally, the TOE is designed to zeroize secret and private keys when they are no longer required by the
TOE as detailed in Table 6-4 Cryptographic Keys. Note that zeroization occurs as follows: 1) when deleted
from disk, the previous value is overwritten once with zeroes; 2) when added or changed on disk, any old
value is overwritten completely with the new value; and, 3) the zeroization of values in RAM is achieved by
overwriting once with zeroes.
 NDcPP21:FCS_COP.1/DataEncryption: The TOE performs AES encryption and decryption. Refer to CAVP
Tables 6-1 and 6-2 for the specifics regarding this cryptographic functions and relevant CAVP certificates
for the TOE cryptographic libraries.
 NDcPP21:FCS_COP.1/Hash: The TOE performs cryptographic hashing using the algorithms shown in
Tables 6-1 and 6-2. Refer to these tables above for the specifics regarding this cryptographic functions and
relevant CAVP certificates.
 NDcPP21:FCS_COP.1/KeyedHash: The TOE performs keyed-hashing using the algorithms shown in Tables
6-1 and 6-2. Refer to these tables above for the specifics regarding this cryptographic functions and relevant
CAVP certificates.
 NDcPP21:FCS_COP.1/SigGen: The TOE performs cryptographic signature generation and verification
using 2048-bit RSA schemes per FIPS 186-4 as shown in Tables 6-1 and 6-2.
 NDcPP21:FCS_HTTPS_EXT.1: An HTTPS/TLS connection is available which presents Web GUI and Rest
API administrative interfaces. The TOE implements HTTPS per RFC 2818. A connection can be established
only if the peer initiates the connection.
 NDcPP21:FCS_RBG_EXT.1: The TOE includes the IBM CTR_DRBG (AES256). This DRBG is used for
all keys generated in support of cryptographic operations for TLS and SSH. The DRBG is seeded by drawing
256-bits from the Linux Kernel RNG which is augmented by noise from the JitterEntropy software noise
source.
 NDcPP21:FCS_SSHS_EXT.1: The TOE supports SSHv2 as defined by RFCs 4251, 4252, 4253, and 4254.
The TOE supports SSHv2 with AES (CBC) 128 or 256 bit ciphers, in conjunction with HMAC-SHA2-256,
and HMAC-SHA2-512. The TOE allow use of RSA for authentication. The TOE supports the following
key exchange methods: diffie-hellman-group14-sha1, and diffie-hellman-group14-sha256. While other
ciphers and hashes are implemented in the product, they are disabled while the TOE is operating in FIPS
mode. The TOE also supports RSA public-key authentication for users connecting to the TOE with a public-
key.
The SSHv2 authentication timeout period is 120 seconds allowing clients to retry only 5 times; both public-
key and password based authentication can be configured; and packets are limited to 256K bytes. Whenever
the timeout period or authentication retry limit is reached, the TOE closes the applicable TCP connection and
releases the SSH session resources. As SSH packets are being received, the TOE uses a buffer to build all
packet information. Once complete, the packet is checked to ensure it can be appropriately decrypted.
However, if it is not complete when the buffer becomes full (256K bytes) the packet will be dropped. An
SSH session is rekeyed by the TOE after being established one hour or after transmitting 1Gb of traffic
whichever comes first. A client initiated rekey, resets both the time and traffic counters.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 29 of 32
 NDcPP21:FCS_TLSC_EXT.2: The TOE provides TLS protected export of audit/event data with mutual
authentication using X.509v3 certificates. When a TLS server requests TLS authentication via certificates,
the TOE is capable of providing an X509v3 certificate.
The TOE includes support for TLSv1.1 and TLSv1.2 only. No older versions of TLS, and no version of SSL
are supported. The TOE supports the ciphersuites identified above. When validating a certificate, the TOE
ensures the distinguished name (DN) or Subject Alternate Name (SAN) fields in the certificate match the
peer identifier DNS name. The TOE supports the use of wildcard values within a certificate’s DN or SAN
field. The TOE does not support certificate pinning.
 NDcPP21:FCS_TLSS_EXT.1: An HTTPS/TLS connection is available which presents a Web GUI
administrative interface. Thus, the TOE acts as a TLS server supporting TLSv1.1 and TLSv1.2 only. No
older versions of TLS, and no version of SSL are supported. The TOE supports the ciphersuites identified
above.
TLS v1.2 is supported with AES (CBC) 128 or 256 bit ciphers, in conjunction with SHA-1 and SHA-256
and RSA. The TOE utilizes RSA w/ key sizes of 2048-bits and can support DH key exchanges with those
RSA keys.
6.3 Identification and authentication
The TOE offers administrative operations which are accessible via the CLI (command line interface) or HTTPS/TLS
protected interface only after a successful authentication.
The CLI is a text based interface which can be accessed from a directly connected terminal or via a remote terminal
using SSH. Administrators are authenticated through the SSH CLI using either a username and password, or a public
key. Users of the console and HTTPS/TLS interfaces are also authenticated using a username and password. No
The Identification and authentication function satisfies the following security functional requirements:
 NDcPP21:FIA_AFL.1: The TOE allows an administrator to configure the number of failed authentication
attempts that trigger the locking of a user account. The limit of failed authentication attempts (aka the Max
Login Failure limit) can be set to between 1 and 2,147,483,647. When the Max Login Failure limit is reached,
the user account is locked. This prevents successful login of that account using all remote administration
methods until the configured time limit has passed from the last failed authentication attempt. The configured
lockout time is specified by an administrator and can be set to between 1 minute and 2,147,483,647minutes.
Admin accounts are never locked out from using the local console.
 NDcPP21:FIA_PMG_EXT.1: The TOE supports user management capabilities which allow the
administrator to configure a minimum length password (including a length of 15 characters). The TOE also
supports us use of uppercase letters, lowercase letters, numeric values and special characters for passwords.
The special characters permitted to be used in passwords including “!”, “@”, “#”, “$”, %”, “^”, “&”, “*”, “(“
and “)”.
 NDcPP21:FIA_UAU.7: The TOE obscures passwords when entered by administrators.
 NDcPP21:FIA_UAU_EXT.2: The TOE authenticates administrators using a local password-based
mechanism or using a public-key based authentication mechanism (Note public-key authentication is
supported only for SSH connections).
 NDcPP21:FIA_UIA_EXT.1: The TOE does not offer any services through the administrative interfaces prior
to authenticating the connecting user other than the display of a TOE warning banner.
 NDcPP21:FIA_X509_EXT.1/Rev: The TOE supports the use of CRLs to determine the revocation status of
certificates. Certificates are validated as part of the authentication process when they are presented to the
TOE and when they are loaded into the TOE. The following fields are verified as appropriate:
 Expiration – certificate cannot be expired
 Common Name - Needs to be FQN device name or IP. Wildcards are allowed only for 1 level of
sub-domain and not allowed for the main domain. URI is not supported as an identifier type.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 30 of 32
 CA Field – must be true if CA certificate
 Key Usage - Need to have "Certificate Sign" in case of CA certificates and "Digital Signature" in
case of identity certificates.
 X509v3 Extended Key Usage - Need to rightly indicate whether it is for use as “server” certificate
or “client” certificate. If incorrect, connection is not allowed
 X509v3 CRL Distribution Points- Certificate must be valid per a current CRL. If this field is not
present, CRL check is not performed.
 Subject Alternative Method - Not a mandatory attribute. If present, the values stored in this will take
priority over the CN in Subject attribute.
 Basics Constraints - Attribute must be present and must have CA Field
 NDcPP21:FIA_X509_EXT.2: The TOE uses X509v3 certificates for TLS communications. Certificates are
validated as part of the authentication process when they are presented to the TOE and when they are loaded
into the TOE. The TOE attempts to obtain a CRL distribution point(s) from the presented certificate. If none
are found within the certificate, and all other checks deem the certificate to be valid, then the TOE accepts
the certificate. If there are distribution points within the certificate, the TOE attempts to download the CRL.
If either the download fails, the CRL is expired or the certificate is revoked, the TOE does not accept the
certificate as valid.
 NDcPP21:FIA_X509_EXT.3: An administrator can issue commands to generate a CSR on the TOE. The
administrator is asked for information to complete the CSR, including the following:
 Country Name (2 letter code) [XX]:
 State or Province Name (full name) []:
 Locality Name (e.g., city) [Default City]:
 Organization Name (e.g., company) [Default Company Ltd]:
 Organizational Unit Name (e.g., section) []:
 Common Name (e.g., your name or your server’s hostname) []:
 Email Address []:
6.4 Security management
The Security management function satisfies the following security functional requirements:
 NDcPP21:FMT_MOF.1/ManualUpdate: Only administrators can initiate a software update through the
command line interface only.
 NDcPP21:FMT_MTD.1/CoreData: Only security administrators can login to the TOE via its command line
or Web GUI interfaces.
 NDcPP21:FMT_SMF.1: The TOE provides the ability for security administrators to securely configure and
manage the TOE. Administrators can connect to the Command Line Interface (CLI) via either a remote SSH
connection or using a locally connected terminal. The CLI is used for initial configuration, creating CSR
requests, performing updates, reviewing local audit logs, and remediation of AIDE integrity check
discrepancies, Administrators perform administrative tasks using an HTTPS/TLS protected communication
channel offering a Web-based GUI and upload certificates through a RESTAPI interface. The TOE offers
the ability to configure a login banner and an inactivity timeout value that can be used for session termination
or session locking. The TOE also provides mechanisms to support an administrator's ability to verify and
install TOE updates; to configure audit behavior; and to configure cryptographic functionality.
 NDcPP21:FMT_SMR.2: The TOE supports local administration via a CLI or a locally attached network
device. Remote administration is provided through a CLI protected by SSH or through a web GUI protected
by HTTPS/TLS. The majority of administrative functionality is available only through the web GUI.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 31 of 32
6.5 Protection of the TSF
The TOE includes several mechanisms to support self-protection, including protection of sensitive data, accurate time,
self-testing, and trusted updates.
The mechanism to support verification of TOE updates utilizes IBM GPG keys. The IBM public key is inserted into
the root user’s keyring during system hardening/setup. The update is delivered as an executable with an embedded
payload. The embedded payload is a GPG signed package. When executed, the payload is verified and if valid it is
extracted. Upon failure of the signature check the extracted payload is deleted; upon success there is an indicator that
installation can proceed.
The Protection of the TSF function satisfies the following security functional requirements:
 NDcPP21:FPT_APW_EXT.1: Administrator passwords are stored SHA-512 hashed and salted. No interface
is offered by the TOE to present cleartext passwords.
 NDcPP21:FPT_SKP_EXT.1: Pre-shared keys, symmetric keys, and private keys stored by the TOE are AES
encrypted and never presented back to administrators as plaintext. The AES key protecting other keys is
never presented or displayed in any tools or UI.
 FPT_STM_EXT.1: The TOE uses the system time obtained from the hardware for use in audit records,
session timeouts, scheduling integrity validation and during certificate validation. The hardware-based time
value is considered reliable because it can be set and modified only by an administrator.
NDcPP21:FPT_TST_EXT.1: The TOE runs a suite of cryptographic self-tests during power-on and performs
TSF integrity checks daily. Thee tests include cryptographic known answer tests exercising the algorithms shown in
C1207, C1208, and C1209
 Table 6-1 CAVP Certificates for OpenSSL library, Table 6-2 CAVP Certificates for IBMFIPSJCE library
and Table 6-3 CAVP Certificates for libgcrypt library. For TSF integrity checking, the TOE uses
Advanced Intrusion Detection Environment (AIDE) tool to verify the integrity of TOE software. AIDE
(https://aide.github.io/) is a utility that creates a database of files on the system, and then uses that database
to ensure file integrity and detect system intrusions. After installation and configuration the administrator
creates an AIDE baseline database and schedules the integrity check to run at configured intervals using cron.
In the case where the AIDE tool identifies differences in the database the Administrator will review the
identified system changes. If all changes are approved the administrator will commit the new database,
otherwise the integrity of the device will be restored through a factory re-installation. In the event a self-test
fails, the administrator is expected to make a system image of the appliance for later investigation, and then
reinstall the system. Since the TOE provides services to other network devices, availability is an important
consideration in its design. To manage the time needed during startup, the AIDE tools is not run during TOE
initialization, but rather is scheduled on a daily basis. This allows the TOE to return to providing network
services quicker and to perform the TSF integrity checking more frequently. Guidance suggests that the
AIDE tool be scheduled on a daily basis, however, administrators can schedule it more frequently if desired.
 NDcPP21:FPT_TUD_EXT.1: IBM signs product updates using a 2048-bit RSA GPG key that is installed on
the TOE. The SHA-256 signature on an update is verified prior to installing the update (as described above).
Administrators must manually obtain updates and must take explicit actions to install an update (the TOE
does not automatically update itself). The TOE UI presents the currently running version upon request.
6.6 TOE access
The TOE access function satisfies the following security functional requirements:
 NDcPP21:FTA_SSL.3: For remote sessions, the TOE provides an inactivity timeout mechanism that is
configurable by an administrator. The timeout mechanism applies to the HTTPS-protected Web GUI and
RESTAPI interface, as well as to the SSH-protected CLI interface.
IBM Security QRadar SIEM (NDcPP21) Security Target Version 0.7, January 15, 2020
Page 32 of 32
 NDcPP21:FTA_SSL.4: All administrative users can issue a logout from a remote administrative session
using either the SSH, the Web GUI and the RESTAPI interfaces. Administrators can also logout from a local
console session.
 NDcPP21:FTA_SSL_EXT.1: The TOE provides an admin-specified timeout for inactivity at the local
console.
 NDcPP21:FTA_TAB.1: The TOE presents a warning banner to the user during login actions prior to
completing authentication on the Web GUI, the SSH interface and the local console.
6.7 Trusted path/channels
The Trusted path/channels function satisfies the following security functional requirements:
 NDcPP21:FTP_ITC.1: Communication with an external audit server (i.e., outbound) will utilize mutually
authenticated TLS. The external audit server would be expected to accept TLS communication initiated by
the TOE.
 NDcPP21:FTP_TRP.1: The TOE provides multiple methods of remote administration. A command line
interface is available remotely via an SSH protected channel. Additionally, an HTTPS/TLS connection is
available which presents a Web GUI administrative interface and the RESTAPI interface. Administrators
must initiate the connection to the TOE from a remote network entity.