Comment: Comment-1-

PP-Module for Endpoint Detection And Response (EDR)

NIAP Logo
Version: 2.0
2025-06-13
National Information Assurance Partnership

Revision History

VersionDateComment
1.02020-10-23First version released
2.02025-06-13CC:2022 conversion

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.3.2TOE Platform1.4Use Cases2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the Operational Environment4.2Security Objectives Rationale5Security Requirements5.1 Protection Profile for Application Software Security Functional Requirements Direction 5.1.1 Modified SFRs 5.2TOE Security Functional Requirements5.2.1Auditable Events for Mandatory SFRs5.2.2Security Audit (FAU)5.2.3Identification and Authentication (FIA)5.2.4Security Management (FMT)5.2.5Protection of the TSF (FPT)5.2.6Trusted Path/Channels (FTP)5.3TOE Security Functional Requirements Rationale6Consistency Rationale6.1 Protection Profile for Application Software6.1.1 Consistency of TOE Type 6.1.2 Consistency of Security Problem Definition 6.1.3 Consistency of OE Objectives 6.1.4 Consistency of Requirements Appendix A - Optional SFRsA.1Strictly Optional Requirements A.2Objective Requirements A.2.1Auditable Events for Objective SFRsA.2.2Security Management (FMT)A.3Implementation-dependent Requirements Appendix B - Selection-based Requirements Appendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Identification and Authentication (FIA)C.2.1.1FIA_AUT_EXT Dashboard Authentication MechanismsC.2.1.2FIA_PWD_EXT Password AuthenticationC.2.2Security Audit (FAU)C.2.2.1FAU_ALT_EXT Server AlertsC.2.2.2FAU_COL_EXT Collected Endpoint DataC.2.3Security Management (FMT)C.2.3.1FMT_SRF_EXT Specification of Remediation FunctionsC.2.3.2FMT_TRM_EXT Trusted Remediation FunctionsAppendix D - Implicitly Satisfied RequirementsAppendix E - AcronymsAppendix F - Bibliography

1 Introduction

1.1 Overview

The scope of this PP-Module is to describe the security functionality of an Endpoint Detection and Response (EDR) system in terms of [CC] and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs: This Base-PP is valid because an EDR is deployed as a software application on a general-purpose operating system.

1.2 Terms

The following sections list Common Criteria and technology terms used in this document.

1.2.1 Common Criteria Terms

Assurance
Grounds for confidence that a TOE meets the SFRs [CC].
Base Protection Profile (Base-PP)
Protection Profile used as a basis to build a PP-Configuration.
Collaborative Protection Profile (cPP)
A Protection Profile developed by international technical communities and approved by multiple schemes.
Common Criteria (CC)
Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408).
Common Criteria Testing Laboratory
 Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations.
Common Evaluation Methodology (CEM)
Common Evaluation Methodology for Information Technology Security Evaluation.
Direct Rationale
 A type of Protection Profile, PP-Module, or Security Target in which the security problem definition (SPD) elements are mapped directly to the SFRs and possibly to the security objectives for the operational environment. There are no security objectives for the TOE.
Distributed TOE
A TOE composed of multiple components operating as a logical whole.
Extended Package (EP)
A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages.
Functional Package (FP)
A document that collects SFRs for a particular protocol, technology, or functionality.
Operational Environment (OE)
Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy.
Protection Profile (PP)
An implementation-independent set of security requirements for a category of products.
Protection Profile Configuration (PP-Configuration)
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs.
Security Assurance Requirement (SAR)
A requirement to assure the security of the TOE.
Security Functional Requirement (SFR)
A requirement for security enforcement by the TOE.
Security Target (ST)
A set of implementation-dependent security requirements for a specific product.
Target of Evaluation (TOE)
The product under evaluation.
TOE Security Functionality (TSF)
The security functionality of the product under evaluation.
TOE Summary Specification (TSS)
A description of how a TOE satisfies the SFRs in an ST.

1.2.2 Technical Terms

Alert
An event or notification on the management dashboard that highlights potentially unauthorized activity.
Endpoint
A computing device that runs a general purpose OS, a mobile device OS, or network device OS. Endpoints can include desktops, servers, and mobile devices.
Endpoint Detection and Response (EDR)
Server software that analyzes collected EDR Host Agent data for detecting, investigating, and remediating unauthorized activities on endpoints. The terms TOE and EDR are interchangeable in this document.
Endpoint Detection and Response System
The EDR server and the Host Agents they operate with.
Enroll
The act of registering an HA endpoint with the EDR.
Host Agent
Complementary software that executes on endpoints to collect data about the endpoint and executes commands sent to the endpoint from an Enterprise Security Management (ESM) server or service. An example command sent to an endpoint could be to enforce a policy from an ESM, to collect some files, or to run an OS command.
Management Dashboard
A management interface for the configuration of EDR policy, visualization of collected endpoint alert data, and issuing of remediation commands.
Potentially Unauthorized Activity
This refers to the set of activities detected by the TOE, specific items detected may be unique to the TOE
SOC Analyst
Security Operations Center (SOC) Analyst is typically the person responsible for reviewing potentially unauthorized activities via alerts and performing remediation and clean up.

1.3 Compliant Targets of Evaluation

An EDR is enterprise management software that collects endpoint host data to detect potentially unauthorized activity on endpoints and to enable threat hunting and other incident response actions to remediate malicious behaviors. These requirements cover basic security characteristics and behaviors for EDR products; the platform on which the EDR runs may be a physical or virtual Operating System (OS), and on-premises or in a cloud environment.

EDR products rely on additional software running on the endpoint, called the Host Agent, to communicate commands or policy changes and to receive endpoint host data. Security requirements for the Host Agent are addressed in the separate PP-Module. Evaluation of an EDR system will require evaluations of different system components consisting of EDR and . Each evaluation must satisfy the requirements in both the EDR and HA in addition to its Base-PP Application Software. Evaluation of an EDR system will require evaluation of different system components consisting of one EDR and at least one Host Agent. Therefore, the evaluation must claim conformance to a PP-Configuration that includes the PP-Module for Endpoint Detection and Response (EDR) and the PP-Module for Host Agent.

There are two primary architectural categories addressed by requirements in this PP-Module, as seen in Figure 1.

Figure 1: Primary EDR Architectures

1.3.1 TOE Boundary

The TOE boundary for the EDR encompasses all the software from the TOE vendor that represents the server or enterprise management side of the EDR system. This will typically, but not always, be software running behind a web application or dashboard, and possibly with other software services running to send and receive data with a Host Agent. The EDR may also make use of a database to store collected and analyzed data. Any database software itself is outside the scope of the TOE, as is any web server software used to serve a web application or dashboard, and the underlying operating system or cloud platform. The figure below shows EDR (right) communicating with its Host Agent (left) over an untrusted network.

The requirements for the Host Agent are not covered in this PP-Module, however it is expected that an ESM system will evaluate against a PP-Configuration that includes both the EDR PP-Module and the PP-Module.

Figure 2: EDR and Host Agent Communications

1.3.2 TOE Platform

The TOE platform, which consists of the OS or Cloud platform on which the EDR software executes, is outside the scope of evaluation. However, the security of the EDR relies upon it.

Any communications with trusted remote file reputation or threat intelligence services is relevant to overall EDR system security but is also outside the scope of evaluation.

1.4 Use Cases

Requirements in this PP-Module are designed to address the security problem for the following use cases. An EDR's functionality may be extended by add-ons, plug-ins, threat feeds, or other reputation services. These are out of scope of this PP-Module.
[USE CASE 1] Detection of Potential Unauthorized Activity
The detection of potentially unauthorized activity, software, or users is enabled by the collection of host-based endpoint data to a central EDR where the data is analyzed.
[USE CASE 2] Remediation of Malicious Activity
The ability to initiate remediation commands to attempt a clean up of detected malicious activity is a key use case of EDR.
[USE CASE 3] Discovery
The capability to effectively browse, query, and export aggregated host-based endpoint data enables a SOC analyst to discover adversaries in post-compromise scenarios.

2 Conformance Claims

Conformance Statement

An ST must claim exact conformance to this PP-Module.

The evaluation methods used for evaluating the TOE are a combination of the workunits defined in [CEM] as well as the Evaluation Activities for ensuring that individual SFRs and SARs have a sufficient level of supporting evidence in the Security Target and guidance documentation and have been sufficiently tested by the laboratory as part of completing ATE_IND.1. Any functional packages this PP claims similarly contain their own Evaluation Activities that are used in this same manner.
CC Conformance Claims

This PP-Module is conformant to Part 2 (extended) and Part 3 (extended) of Common Criteria CC:2022, Revision 1.
PP Claim

This PP-Module does not claim conformance to any Protection Profile.

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
Package Claim

The functional packages to which the PP conforms may include SFRs that are not mandatory to claim for the sake of conformance. An ST that claims one or more of these functional packages may include any non-mandatory SFRs that are appropriate to claim based on the capabilities of the TSF and on any triggers for their inclusion based inherently on the SFR selections made.

3 Security Problem Definition

The security problem is described in terms of the threats that the EDR is expected to address, assumptions about the OE, and any organizational security policies that the EDR is expected to enforce. These extend any threats, assumptions, and organizational security policies defined by the Base-PP.

3.1 Threats

T.MISCONFIGURATION
An attacker is a legitimate privileged user with access to change the configuration of the EDR's security capabilities or is not a legitimate privileged user trying to access without proper authorization. Attackers may attempt to hide malicious activities from other privileged users.
T.CREDENTIAL_REUSE
An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may guess or harvest legitimate credentials from the EDR, endpoints, or insecure network activity.

3.2 Assumptions

These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security functionality specified in the PP-Module can be provided by the TOE. If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality.
A.CONNECTIVITY
The TSF relies on network connectivity to carry out its management activities. The OE will provide reliable network connectivity for the EDR to operate. The EDR will robustly handle occasional instances when connectivity is unavailable or unreliable.

3.3 Organizational Security Policies

An organization deploying the TOE is expected to satisfy the organizational security policy listed below in addition to all organizational security policies defined by the claimed Base-PP.

This document does not define any additional OSPs.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve. This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means. The assumptions identified in Section 3 are incorporated as security objectives for the environment. The following security objectives for the Operational Environment assist the EDR in correctly providing its security functionality. These track with the assumptions about the environment.
OE.RELIABLE_TRANSIT
Wired or wireless network traffic between the EDR and host agents will provide reasonably reliable connectivity.

4.2 Security Objectives Rationale

This section describes how the assumptions and organizational security policies map to operational environment security objectives.
Table 1: Security Objectives Rationale
Assumption or OSPSecurity ObjectivesRationale
A.CONNECTIVITYOE.RELIABLE_​TRANSITThe OE objective OE.RELIABLE_TRANSIT is realized through A.CONNECTIVITY.

5 Security Requirements

This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

5.1 Protection Profile for Application Software Security Functional Requirements Direction

In a PP-Configuration that includes , the TOE is expected to rely on some of the security functions implemented by the application as a whole and evaluated against the Base-PP. The SFRs listed in this section are defined in the Base-PP and relevant to the secure operation of the EDR. This section describes any modifications that the ST author must make to the Base-PP SFRs to satisfy the required EDR functionality.

5.1.1 Modified SFRs

This PP-Module does not modify any SFRs defined by the App PP.

5.2 TOE Security Functional Requirements

The following section describes the SFRs that must be satisfied by any TOE that claims conformance to this PP-Module. These SFRs must be claimed regardless of which PP-Configuration is used to define the TOE.

5.2.1 Auditable Events for Mandatory SFRs

Table 2: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_ALT_EXT.1
No events specifiedN/A
FAU_COL_EXT.1
No events specifiedN/A
FAU_GEN.1/EDR
No events specifiedN/A
FIA_AUT_EXT.1
No events specifiedN/A
FIA_PWD_EXT.1
No events specifiedN/A
FMT_SMF.1/ENDPOINT
No events specifiedN/A
FMT_SMF.1/HOST
No events specifiedN/A
FMT_SMR.1
No events specifiedN/A
FMT_SRF_EXT.1
No events specifiedN/A
FPT_ITT.1
No events specifiedN/A
FTP_TRP.1
No events specifiedN/A

5.2.2 Security Audit (FAU)

FAU_ALT_EXT.1 Server Alerts

The TSF shall alert authorized users on a management dashboard in the event of: detection of potentially unauthorized activity on enrolled endpoints.
Application Note: The intent of this requirement is to specify the minimum set of management dashboard alert capabilities the EDR must be capable of displaying to an authorized user.

Examples of detection of potentially unauthorized activity on enrolled endpoints include; anomalous activity, escalation of privileges, and lateral movement.
The TSF shall provide a visualization of detected alerts of potentially unauthorized incidents, and shall include:
  1. An initial incident severity and [selection: assessment, categorization, score, ranking],
  2. An incident timeline.
Application Note: The intent of this requirement is to specify the minimum set of incident visualizations the EDR must be capable of displaying to an authorized user. Visualization is broadly defined as the display of incident data to an authorized user on the management dashboard. The visualization is not required to be interactive.
The TSF shall provide a data export capability for selected alerts with a specified standards-based format of [selection:
  • Structured Threat Information expression (STIX)
  • Cyber Observable expression (CybOX)
  • Incident Object Description Exchange Format (IODEF)
  • Common Event Format (CEF)
  • Log Event Extended Format (LEEF)
] .
Application Note: The intent of this requirement is to specify a selection of standards-based formats the EDR must provide for the export of selected alerts, at least one must be selected.

FAU_COL_EXT.1 Collected Endpoint Data

The TSF shall collect the following minimum set of endpoint data from a Host Agent:
  1. Operating System (OS) version, architecture, and IP Address,
  2. Privileged and unprivileged endpoint account login activity,
  3. Process creation,
  4. Libraries and modules loaded by processes,
  5. Filenames and [selection: [assignment: other metadata], no other metadata] of files created and [selection: [assignment: other activities performed to files], no other activities] on persistent storage,
  6. [selection: [assignment: other host data], no other host data].
Application Note: The intent of this requirement is to specify the minimum set of endpoint data that the EDR must be capable of collecting. The assignments may be a single item or multiple items.

FAU_GEN.1/EDR Audit Data Generation

The TSF shall be able to generate audit data of the following auditable events:
  1. Start-up and shutdown of the audit functions;
  2. All auditable events for the [not specified] level of audit;
[
  1. EDR management dashboard log in activity;
  2. Remediation commands sent to a Host Agent, affected endpoint, or network devices;
  3. EDR configuration changes;
  4. Change in Host Agent enrollment status;
  5. [assignment: Other auditable events]
].
Application Note: The intent of this requirement is to specify the minimum set of audit data generated about actions on the EDR. Changes made to configuration files at the OS level will be audited by the OS and are not covered by this requirement.
The TSF shall record within the audit data at least the following information:
  1. date and time of the event,
  2. type of event,
  3. subject identity (if applicable),
  4. and the outcome (success or failure) of the event,
  5. For each auditable event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package, or ST, [assignment: other audit relevant information].
Application Note: This requirement outlines the information to be included in audit data. All audits must contain at least the information mentioned in FAU_GEN.1.2/EDR, but may contain more information which can be assigned.

5.2.3 Identification and Authentication (FIA)

FIA_AUT_EXT.1 Dashboard Authentication Mechanisms

The TSF shall [selection:
  • leverage the platform for authentication
  • provide authentication based on username/password and [selection:
    • authentication with external smart card and PIN
    • no other factors
    ]
] to support logins to any management dashboard or API.
Application Note: The selection specifies if Smartcards are also supported, one selection must be made.

FIA_PWD_EXT.1 Password Authentication

The TSF shall support the following for the Password Authentication Factor:
  1. Passwords shall be able to be composed of any combination of [selection: upper and lower case letters, [assignment: a character set of at least 52 characters]], numbers, and special characters: [selection: "!", "@", "#", "$", "%", "^", "&", "*", "(", ")", [assignment: other characters]],
  2. Password length up to [assignment: an integer greater than or equal to 64] characters shall be supported.
Application Note: The ST author selects the character set: either the upper and lower case Basic Latin letters or another assigned character set containing at least 52 characters. The assigned character set must be well defined: either according to an international encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by the TOE; they may optionally list additional special characters supported using the assignment.

5.2.4 Security Management (FMT)

FMT_SMF.1/ENDPOINT Specification of Management Functions (EDR Management of EDR)

The TSF shall be capable of performing the following management functions:

Table 3: Management Functions

[Status Markers:
M - Mandatory
O - Optional or Objective
- - Not Applicable
#Management FunctionAdministratorSOC AnalystRead-Only User
1Configure the amount of time to retain data collected by the EDR [assignment: time frame to retain data]
MMandatory
OOptional/Conditional
-N/A
2 Obtain or display the connectivity status of a Host Agent
MMandatory
OOptional/Conditional
OOptional/Conditional
3 Define a configurable list of [selection: filenames, folders, file hashes, [assignment: other factors]]
OOptional/Conditional
MMandatory
-N/A
4 Configure visual suppression of incident alerts based on a configurable list of [selection: filenames, folders, file hashes, [assignment: other factors]]
OOptional/Conditional
MMandatory
-N/A
]
Application Note: This requirement captures all the configuration functionality the TSF provides the administrator to configure the EDR. Both configurable lists mentioned in the table, above, are intended to match one another.

FMT_SMF.1/HOST Specification of Management Functions (EDR Management of Host Agent)

The TSF shall be capable of performing the following management functions that control behavior of the Host Agent:
[ Table 4: Management Functions

[Status Markers:
M - Mandatory
O - Optional or Objective
- - Not Applicable
#Management FunctionAdministratorSOC AnalystRead-Only User
5Configure the frequency for sending Host Agent data to the EDR [assignment: list of configurable frequencies]
MMandatory
OOptional/Conditional
-N/A
6Assign a label or tag to categorize or group individual endpoint systems
MMandatory
OOptional/Conditional
-N/A
]
Application Note: This requirement captures all the configuration functionality the EDR provides the administrator to configure the EDR Host Agents. The frequency for sending data to the EDR can be specified as a time value, but does not have to be. A value like Aggressive, Normal, Low Bandwidth is a measure of control of frequency and meets the requirement. For EDR products, some management is performed through a product’s configuration files stored at the OS level. In these cases, the OS administrator can be considered the administrator of the TOE.

FMT_SMR.1 Security Management Roles

The TSF shall maintain the roles [administrator, SOC analyst, read-only user].
The TSF shall be able to associate users with roles.
Application Note: The EDR will be configured, maintained, and used by different user roles. At a minimum, one administrative role shall be supported, one SOC analyst who can issue remediation commands to host agents, and one read-only user who can only view data.

The user accounts need not be named literally, but they must have the implication of such roles.

CC Part 2 specifies FIA_UID.1 as a dependency of this requirement because the TSF must have some way of identifying users so that they can be associated with management roles. This dependency is implicitly addressed through FIA_AUT_EXT.1, which specifies an alternative method of user identification.

FMT_SRF_EXT.1 Specification of Remediation Functions

The TSF shall be capable of performing the following remediation functions: Table 5: Management Functions

[Status Markers:
M - Mandatory
O - Optional or Objective
- - Not Applicable

#Management FunctionAdministratorSOC AnalystRead-Only User
7 Quarantine an endpoint by [selection: logically quarantining the endpoint from the network unless allowlisted, quarantining the malicious file on the endpoint]
OOptional/Conditional
MMandatory
-N/A
8 Terminate a running process on an endpoint
OOptional/Conditional
MMandatory
-N/A
9 Retrieve potentially unauthorized or affected files from an endpoint
OOptional/Conditional
OOptional/Conditional
-N/A
]
Application Note:

This requirement captures all the remediation functionality the EDR provides the SOC Analyst and optionally the Administrator.

Logically quarantine from the network refers to restricting communications from the endpoint to the rest of the network, it may include a restricted allowlist.

Any function that is not mandatory for at least one role is considered optional for the TOE.

5.2.5 Protection of the TSF (FPT)

FPT_ITT.1 Basic Internal TSF Data Transfer Protection

The EDR shall [selection:
  • implement [selection: TLS as defined in the TLS Package, HTTPS as defined in the Base-PP]
  • invoke platform-provided functionality for [selection: TLS, HTTPS]
] to protect TSF data from [modification, disclosure] when it is transmitted between separate parts of the TOE.
Application Note: The intent of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel between the EDR and the Host Agent, which are considered to be separate parts of the TOE. The TLS Package permits the use of either TLS or DTLS. Only TLS, DTLS, or HTTPS can be used in this trusted channel.

This requirement is to ensure that the transmission of any logs, process lists, system information, etc, when commanded, or at configurable intervals, is properly protected. This internal channel also protects any commands and policies sent by the EDR to the Host Agent. Either the Host Agent or the EDR is able to initiate the connection.

This internal channel protects both the connection between an enrolled Host Agent and the EDR and the connection between an unenrolled Host Agent and the EDR during the enrollment operation. Different protocols can be used for these two connections, and the description in the TSS should make this difference clear.

The internal channel uses a protocol from the TLS Package or HTTPS as the protocol that preserves the confidentiality and integrity of EDR communications. The ST author chooses the mechanism or mechanisms supported by the EDR, and then ensures the correct requirements are included in the ST if not already present. Protocol, RBG, certificate validation, algorithm, and similar services may be met with platform-provided services.

5.2.6 Trusted Path/Channels (FTP)

FTP_TRP.1 Trusted Path

The TSF shall [selection:
  • implement [selection: TLS as defined in the TLS Package, HTTPS as defined in the Base-PP]
  • invoke platform-provided functionality for [selection: TLS, HTTPS]
] to provide a communication path between itself and [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 [modification, disclosure].
The TSF shall [selection: implement functionality, invoke platform-provided functionality] to permit [remote administrators] to initiate communication via the trusted path.
The TSF shall [selection: implement functionality, invoke platform-provided functionality] to require the use of the trusted path for [all remote administration actions].
Application Note: This requirement ensures that authorized remote administrators initiate all communication with the EDR via a trusted path, and that all communications with the EDR by remote administrators is performed over this path. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the first selection. The ST author chooses the mechanism or mechanisms supported by the EDR.

5.3 TOE Security Functional Requirements Rationale

The following rationale provides justification for each SFR for the TOE, showing that the SFRs are suitable to address the specified threats:

Table 6: SFR Rationale
ThreatAddressed byRationale
T.MISCONFIGURATIONFAU_ALT_EXT.1The PP-Module includes FAU_ALT_EXT.1 to facilitate management by providing a function for authorized users to interact with security-relevant data that is provided to the TSF.
FAU_COL_EXT.1The PP-Module includes FAU_COL_EXT.1 to facilitate management by defining the security-relevant data that is collected by the TSF.
FAU_GEN.1/EDRThe PP-Module includes FAU_GEN.1/EDR to ensure that the TOE provides accountability through the generation of audit data for security-relevant events.
FIA_AUT_EXT.1The PP-Module includes FIA_AUT_EXT.1 to define how management users are authenticated by the TSF to limit the subjects that can execute management functions on the TOE.
FIA_PWD_EXT.1The PP-Module includes FIA_PWD_EXT.1 to define composition requirements for the Password Authentication Factor to ensure that an authorized user cannot access protected management functions without authorization.
FMT_SMF.1/ENDPOINTThe PP-Module includes FMT_SMF.1/ENDPOINT to define the management functions that can be performed to control the behavior of the TSF and the management roles that are authorized to perform those functions.
FMT_SMF.1/HOSTThe PP-Module includes FMT_SMF.1/HOST to define the management functions that can be performed to control the behavior of Host Agents that are connected to the TOE and the management roles that are authorized to perform those functions.
FMT_SMR.1The PP-Module includes FMT_SMR.1 to define the management roles that the TSF supports so that its management functions can be separated by role.
FMT_SRF_EXT.1The PP-Module includes FMT_SRF_EXT.1 to define the remediation functions that are available to authorized users to issue corrective actions on a system that has a connected Host Agent.
FMT_TRM_EXT.1The PP-Module includes FMT_TRM_EXT.1 to provide an optional capability to ensure the integrity of management commands and policies issued to external Host Agents through use of a digital signature.
T.CREDENTIAL_​REUSEFPT_ITT.1The PP-Module includes FPT_ITT.1 to define the internal trusted channel that the TSF uses to communicate with connected Host Agents as well as the communications protocols used to establish these trusted channels.
FTP_TRP.1The PP-Module includes FTP_TRP.1 to define the communications protocols used to support secure remote administration of the TSF.

6 Consistency Rationale

6.1 Protection Profile for Application Software

6.1.1 Consistency of TOE Type

If this PP-Module is used to extend the Application Software PP, the TOE type for the overall TOE is still a software-based application. The TOE boundary is simply extended to include the EDR functionality that is built into the application so that additional security functionality is claimed within the scope of the TOE.

6.1.2 Consistency of Security Problem Definition

Table 7: Consistency of Security Problem Definition (App PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.MISCONFIGURATIONThis threat applies to management functionality that is introduced in this PP-Module and does not affect the functionality described by the Base-PP.
T.CREDENTIAL_REUSEThis threat applies to authentication functionality that is introduced in this PP-Module and does not affect the functionality described by the Base-PP.
A.CONNECTIVITYThis assumption is consistent with the Base-PP because assuming network availability is consistent with the A.PLATFORM assumption defined by the Base-PP, which expects the TOE to have a trustworthy computing platform.

6.1.3 Consistency of OE Objectives

Table 8: Consistency of OE Objectives (App PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.RELIABLE_TRANSIT This objective relates to an external interface that does not exist in the Base-PP and does not affect Base-PP functionality.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the App PP that are needed to support Endpoint Detection and Response (EDR) functionality. This is considered to be consistent because the functionality provided by the App PP is being used for its intended purpose. The rationale for why this does not conflict with the claims defined by the App PP are as follows:
Table 9: Consistency of Requirements (App PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
This PP-Module does not modify any requirements when the App PP is the base.
Additional SFRs
This PP-Module does not add any requirements when the App PP is the base.
Mandatory SFRs
FAU_ALT_EXT.1 This SFR defines auditable alerts for the EDR. It does not impact the functionality.
FAU_COL_EXT.1 This SFR defines the minimum event data that the EDR collects from a Host Agent. It does not impact the functionality.
FAU_GEN.1/EDR This SFR defines the minimum event data that the EDR server must record about authorized management dashboard activity. It does not impact the functionality.
FIA_AUT_EXT.1 This SFR defines authentication mechanisms for the EDR. It does not impact the functionality.
FIA_PWD_EXT.1 This SFR defines specific authentication criteria for passwords. It does not impact the functionality.
FMT_SMF.1/ENDPOINTThis SFR defines a specific set of management functions for an EDR by an EDR. It does not impact the functionality.
FMT_SMF.1/HOSTThis SFR defines a specific set of management functions for a Host Agent by an EDR. It does not impact the functionality.
FMT_SMR.1 This SFR defines a specific set of management roles for an EDR. It does not impact the functionality.
FMT_SRF_EXT.1 This SFR defines a specific set of remediation functions for an EDR. It does not impact the functionality.
FPT_ITT.1 This SFR defines a specific set of functions for logically distinct secure communication with a Host Agent. It does not impact the functionality.
FTP_TRP.1This SFR defines a specific set of functions for secure remote administration of the EDR. It does not impact functionality.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
FMT_TRM_EXT.1This SFR defines protections for the integrity of commands sent to the Host Agent. It does not impact the functionality.
Implementation-dependent SFRs
This PP-Module does not define any Implementation-dependent requirements.
Selection-based SFRs
This PP-Module does not define any Selection-based requirements.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

This PP-Module does not define any Strictly Optional SFRs or SARs.

A.2 Objective Requirements

A.2.1 Auditable Events for Objective SFRs

Table 10: Auditable Events for Objective Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FMT_TRM_EXT.1
No events specifiedN/A

A.2.2 Security Management (FMT)

FMT_TRM_EXT.1 Trusted Remediation Functions

The [selection: EDR, EDR Platform] shall digitally sign commands and policies sent to the Host Agent using [selection: RSA, ECDSA] signatures that meet FIPS PUB 186-5.
Application Note: The intent of this requirement is to cryptographically tie any policy updates or commands sent to the Host Agent as being from the EDR. This is not to protect the policies in transit as they are already protected by FPT_ITT.1. If the TSF implements this function, any signature algorithms used should be consistent with any selections made in FCS_COP.1/Sig Gen and FCS_COP.1/SigVer in the Protection Profile for Application Software, Version 2.0.

A.3 Implementation-dependent Requirements

This PP-Module does not define any Implementation-dependent SFRs.

Appendix B - Selection-based Requirements

This PP-Module does not define any Selection-based SFRs.

Appendix C - Extended Component Definitions

This appendix contains the definitions for all extended requirements specified in the PP-Module.

C.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:
Table 11: Extended Component Definitions
Functional ClassFunctional Components
Identification and Authentication (FIA)FIA_AUT_EXT Dashboard Authentication Mechanisms
FIA_PWD_EXT Password Authentication
Security Audit (FAU)FAU_ALT_EXT Server Alerts
FAU_COL_EXT Collected Endpoint Data
Security Management (FMT)FMT_SRF_EXT Specification of Remediation Functions
FMT_TRM_EXT Trusted Remediation Functions

C.2 Extended Component Definitions

C.2.1 Identification and Authentication (FIA)

This PP-Module defines the following extended components as part of the FIA class originally defined by CC Part 2:

C.2.1.1 FIA_AUT_EXT Dashboard Authentication Mechanisms

Family Behavior

Components in this family define requirements for authentication behavior that is unique to an EDR TOE.

Component Leveling

FIA_AUT_EXT1

FIA_AUT_EXT.1, Dashboard Authentication Mechanisms, identifies the only authentication factors that may be used for authentication to a management interface of an EDR.

Management: FIA_AUT_EXT.1

There are no management functions foreseen.

Audit: FIA_AUT_EXT.1

There are no audit events foreseen.

FIA_AUT_EXT.1 Dashboard Authentication Mechanisms

Hierarchical to:No other components.
Dependencies to:No dependencies.

FIA_AUT_EXT.1.1

The TSF shall [selection:
  • leverage the platform for authentication
  • provide authentication based on username/password and [selection:
    • authentication with external smart card and PIN
    • no other factors
    ]
] to support logins to any management dashboard or API.

C.2.1.2 FIA_PWD_EXT Password Authentication

Family Behavior

Components in this family define requirements for password authentication criteria.

Component Leveling

FIA_PWD_EXT1

FIA_PWD_EXT.1, Password Authentication, defines the length and character set requirements for password authentication factors.

Management: FIA_PWD_EXT.1

There are no management functions foreseen.

Audit: FIA_PWD_EXT.1

There are no audit events foreseen.

FIA_PWD_EXT.1 Password Authentication

Hierarchical to:No other components.
Dependencies to:FIA_AUT_EXT.1 Dashboard Authentication Mechanisms

FIA_PWD_EXT.1.1

The TSF shall support the following for the Password Authentication Factor:
  1. Passwords shall be able to be composed of any combination of [selection: upper and lower case letters, [assignment: a character set of at least 52 characters]], numbers, and special characters: [selection: "!", "@", "#", "$", "%", "^", "&", "*", "(", ")", [assignment: other characters]],
  2. Password length up to [assignment: an integer greater than or equal to 64] characters shall be supported.

C.2.2 Security Audit (FAU)

This PP-Module defines the following extended components as part of the FAU class originally defined by CC Part 2:

C.2.2.1 FAU_ALT_EXT Server Alerts

Family Behavior

Components in this family define requirements for system activity that causes the TSF to generate an alert of the activity and for the contents of these alerts.

Component Leveling

FAU_ALT_EXT1

FAU_ALT_EXT.1, Server Alerts, describes alert triggers and the information contained in alerts.

Management: FAU_ALT_EXT.1

The following actions could be considered for the management functions in FMT:

  • Configure visual suppression of alerts.

Audit: FAU_ALT_EXT.1

There are no auditable events foreseen.

FAU_ALT_EXT.1 Server Alerts

Hierarchical to:No other components.
Dependencies to:No dependencies.

FAU_ALT_EXT.1.1

The TSF shall alert authorized users on a management dashboard in the event of: detection of potentially unauthorized activity on enrolled endpoints.

FAU_ALT_EXT.1.2

The TSF shall provide a visualization of detected alerts of potentially unauthorized incidents, and shall include:
  1. An initial incident severity and [selection: assessment, categorization, score, ranking],
  2. An incident timeline.

FAU_ALT_EXT.1.3

The TSF shall provide a data export capability for selected alerts with a specified standards-based format of [assignment: alert format].

C.2.2.2 FAU_COL_EXT Collected Endpoint Data

Family Behavior

Components in this family define requirements for the data that is collected from a Host Agent.

Component Leveling

FAU_COL_EXT1

FAU_COL_EXT.1, Collected Endpoint Data, identifies the specific data collected from a Host Agent.

Management: FAU_COL_EXT.1

The following actions could be considered for the management functions in FMT:

  • Configuration of the time period for transmission of collected data.
  • Configuration of label or tag information to associate collected data with individual endpoint systems or groups of systems.

Audit: FAU_COL_EXT.1

There are no auditable events foreseen.

FAU_COL_EXT.1 Collected Endpoint Data

Hierarchical to:No other components.
Dependencies to:No dependencies.

FAU_COL_EXT.1.1

The TSF shall collect the following minimum set of endpoint data from a Host Agent:
  1. Operating System (OS) version, architecture, and IP Address,
  2. Privileged and unprivileged endpoint account login activity,
  3. Process creation,
  4. Libraries and modules loaded by processes,
  5. Filenames and [selection: [assignment: other metadata], no other metadata] of files created and [selection: [assignment: other activities performed to files], no other activities] on persistent storage,
  6. [selection: [assignment: other host data], no other host data].

C.2.3 Security Management (FMT)

This PP-Module defines the following extended components as part of the FMT class originally defined by CC Part 2:

C.2.3.1 FMT_SRF_EXT Specification of Remediation Functions

Family Behavior

Components in this family define requirements for remediation functions that an EDR can perform to affect the behavior of an endpoint system.

Component Leveling

FMT_SRF_EXT1

FMT_SRF_EXT.1, Specification of Remediation Functions, lists the supported remediation functions and identifies the management roles that may perform these functions.

Management: FMT_SRF_EXT.1

There are no management functions foreseen.

Audit: FMT_SRF_EXT.1

There are no audit events foreseen.

FMT_SRF_EXT.1 Specification of Remediation Functions

Hierarchical to:No other components.
Dependencies to:FMT_SMR.1 Security Management Roles

FMT_SRF_EXT.1.1

The TSF shall be capable of performing the following remediation functions: Table 12: Management Functions

[Status Markers:
M - Mandatory
O - Optional or Objective
- - Not Applicable

#Management FunctionAdministratorSOC AnalystRead-Only User
7 Quarantine an endpoint by [selection: logically quarantining the endpoint from the network unless allowlisted, quarantining the malicious file on the endpoint]
OOptional/Conditional
MMandatory
-N/A
8 Terminate a running process on an endpoint
OOptional/Conditional
MMandatory
-N/A
9 Retrieve potentially unauthorized or affected files from an endpoint
OOptional/Conditional
OOptional/Conditional
-N/A
]

C.2.3.2 FMT_TRM_EXT Trusted Remediation Functions

Family Behavior

Components in this family define how the TOE can assert the authenticity of the remediation actions it requests from Host Agents.

Component Leveling

FMT_TRM_EXT1

FMT_TRM_EXT.1, Trusted Remediation Functions, requires all management activities bound for a Host Agent to be digitally signed.

Management: FMT_TRM_EXT.1

There are no management functions foreseen.

Audit: FMT_TRM_EXT.1

There are no audit events foreseen.

FMT_TRM_EXT.1 Trusted Remediation Functions

Hierarchical to:No other components.
Dependencies to:No dependencies.

FMT_TRM_EXT.1.1

The [selection: EDR, EDR Platform] shall digitally sign commands and policies sent to the Host Agent using [selection: RSA, ECDSA] signatures that meet FIPS PUB 186-5.

Appendix D - Implicitly Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.3 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP-Module provides evidence that these controls are present and have been evaluated.

Requirement Rationale for Satisfaction
FIA_UID.1 - Timing of Identification CC Part 2 specifies FIA_UID.1 as a dependency of FMT_SMR.1 because the TSF must have some way of identifying users so that they can be associated with management roles. This dependency is implicitly addressed through FIA_AUT_EXT.1, which specifies an alternative method of user identification.
FPT_STM.1 - Reliable Time Stamps CC Part 2 specifies FPT_STM.1 as a dependency of FAU_GEN.1 because the audit data require a reliable timestamp to satisfy FAU_GEN.1.2. This dependency is implicitly addressed through the A.PLATFORM assumption of the Base-PP because a "trustworthy computing platform" is assumed to include a reliable system clock.

Appendix E - Acronyms

Table 13: Acronyms
AcronymMeaning
APIApplication Programming Interface
Base-PPBase Protection Profile
CCCommon Criteria
CEFCommon Event Format
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
CybOXCyber Observable expression
DRBGDeterministic Random Bit Generator
DSSDigital Signature Standard
DTLSDatagram Transport Layer Security
EDREndpoint Detection and Response
EDREndpoint Detection and Response
EPExtended Package
FPFunctional Package
HTTPSHypertext Transfer Protocol Secure
IODEFIncident Object Description Exchange Format
IPInternet Protocol
ITInformation Technology
LEEFLog Event Extended Format
OEOperational Environment
OSOperating System
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
RBGRandom Bit Generator
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
STSecurity Target
STIXStructured Threat Information expression
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSFITSF Interface
TSSTOE Summary Specification

Appendix F - Bibliography

Table 14: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -