PP-Module for Enterprise-Management

Version: 2.0
2025-07-18
National Information Assurance Partnership

Revision History

Version	Date	Comment
2.0	2025-07-18	Initial draft (version numbering chosen for alignment with the ESM family of modules)

1Introduction 1.1Overview 1.2Terms 1.2.1Common Criteria Terms 1.2.2Technical Terms 1.3Compliant Targets of Evaluation 1.3.1TOE Boundary 1.3.2TOE Platform 1.4Use Cases 1.5Implementation-Based Features 1.5.1Distributed TOE 2Conformance Claims 3Security Problem Definition 3.1Threats 3.2Assumptions 3.3Organizational Security Policies 4Security Objectives 4.1Security Objectives for the Operational Environment 5Security Requirements 5.1 Protection Profile for Application Software Security Functional Requirements Direction 5.1.1 Modified SFRs 5.2TOE Security Functional Requirements 5.2.1Auditable Events for Mandatory SFRs 5.2.2Security Audit (FAU)5.2.3Identification and Authentication (FIA)5.2.4Management of the TSF (FMT)5.2.5Trusted Path/Channels (FTP)5.3TOE Security Functional Requirements Rationale 6Consistency 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.1Strictly Optional Requirements A.2Objective Requirements A.3Implementation-dependent Requirements A.3.1Communications (FCO)A.3.2Protection of the TSF (FPT)Appendix B - Selection-based Requirements B.1Security Audit (FAU)B.2Trusted Path/Channels (FTP)Appendix C - Extended Component Definitions C.1Extended Components Table C.2Extended Component Definitions C.2.1Communications (FCO)C.2.1.1FCO_CPC_EXT Component Registration Channel Definition C.2.2Security Audit (FAU)C.2.2.1FAU_ALT_EXT Server Alerts C.2.2.2FAU_CRP_EXT Support for Compliance Reporting Configuration C.2.2.3FAU_NET_EXT Network Reachability Review Appendix D - Inherently 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 Enterprise-Management product (EM) 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 Version 2.0

This Base-PP is valid because an EM 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

Endpoint	A computing device that runs a general purpose OS, mobile device OS, or network device OS. Endpoints can include desktops, servers, and mobile devices.
Endpoint Detection and Response (EDR)	A system that analyzes collected EDR Host Agent data for detecting, investigating, and remediating unauthorized activities on endpoints.
Enrolled State	The state in which an endpoint with a running Host Agent is managed by an EM. Also, referred to as Onboarding.
Enrollment	The process of transitioning an endpoint from an unenrolled to an enrolled state.
Enterprise Security Management (EM)	A type of application hosted on a server or cloud service that provides support for security management, information flows, reporting, policy, and data analytics in complex enterprise environments.
Host Agent	A logical piece of software that executes on endpoints to collect data about the endpoint and executes commands sent to the endpoint from an EM server or service. An example command sent to an endpoint could be to enforce a policy from an EM, to collect some files, or to run an OS command.
Operating System (OS)	Software that manages physical and logical resources and provides services for applications.
Unenrolled State	The state in which an endpoint, with or without a Host Agent, is not managed by an EM. Also, referred to as Offboarding.

1.3 Compliant Targets of Evaluation

The PP-Module for Enterprise-Management (EM) covers the security functionality needed for an EM server to manage the configuration and behavior of endpoint systems in an enterprise setting, and providing monitoring and reporting capabilities for managed endpoints. potentially update this sentence or add a second one that clarifies why this is distinct from ESM EDR since they both involve "central server interfacing with endpoints".

1.3.1 TOE Boundary

The boundary for Enterprise-Management includes all processes, all modules, and libraries bundled with the product, to be run on a single server or multiple servers in a load balancing or failover configuration. This includes any local or remote management interface that is used to access the TOE for the purpose of configuration (whether of itself or of endpoints under the TOE's control), audit review, or any other supported administrative function. The TOE boundary includes communications channels with external entities. The platform operating system or execution environment upon which the TOE is executing is outside the scope of an EM evaluation. The figure below shows a sample deployment of an EM product within its larger operational environment, including remote systems for which it is responsible for managing.TBD.

1.3.2 TOE Platform

The TOE platform consists of a general purpose OS or an Execution Environment on top of which the EM software executes.

1.4 Use Cases

Requirements in this PP-Module are designed to address the security problem for the following use cases. These use cases are intentionally very broad, as many different types of EM products may exist. As this PP-Module is revised to allow for more specific types of EM products, additional use cases may be devised.

[USE CASE 1] Interfacing with Endpoints: The TOE communicates with an endpoint system and issues commands to this system to push, edit, or retrieve data. This could include deployment or updates to system software, applying configuration settings, executing custom scripts against the system, or establishing interactive remote access to the system.
[USE CASE 2] System Inventory: The TOE collects data about endpoint systems that can be queried or browsed. This could include data about the system's hardware, software, or configuration
[USE CASE 3] System Monitoring: The TOE has a persistent connection to endpoint systems to monitor those systems for anomalous activity, such as disk utilization, memory usage, configuration of system permissions, or the starting and stopping of executable services or processes on the system. is this meant to be the policy management side of EDR? Or is this something distinct and/or broader? If this is just meant to be the stuff that the ESM EDR module intends to capture then we should ensure consistency between the two.

1.5 Implementation-Based Features

A conformant TOE may implement certain features that are not strictly necessary in order to achieve the desired level of security, but if these features are implemented, it is expected that they conform to certain requirements governing their behavior.

1.5.1 Distributed TOE

The TOE is distributed across multiple server instances.

If this feature is implemented by the TOE, the following requirements must be claimed in the ST:

FCO_CPC_EXT.1
FPT_ITT.1

2 Conformance Claims

Update URLs in Bib. for pp and mod cc refs Do we also need VPN Client here or is IPsec not an expected way these products will communicate? Note that neither EDR nor HA reference it so if we need those, we'll have to back them into the other modules

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 Endpoint Detection and Response (EDR), Version 2.0
PP-Module for Host Agent (HA), Version 2.0

Package Claim

This PP-Module is Functional Package for TLS, Version 2.1 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 TOE is expected to address, assumptions about the Operational Environment, and any organizational security policies that the TOE is expected to enforce. These extend any threats, assumptions, and organizational security policies defined by the Base-PP.

Note that these threats are nearly duplicates of the App PP and the things that are inherited from that PP do not need to be redefined; suggest reviewing these once SFRs are fully defined to adjust specifically to the context of this TOE (versus a general App PP TOE).

3.1 Threats

Note that this PP-Module does not repeat the threats identified in the [AppPP], though they all apply given the conformance and hence dependence of this PP-Module on the [AppPP].

T.NETWORK_ATTACK: An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with parts of the EM system with the intent of compromise. Engagement may consist of altering existing legitimate communications.
T.NETWORK_EAVESDROP: An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between parts of the EM system.
T.LOCAL_ATTACK: An attacker may compromise applications running on the same computing platform on which part of the EM system executes. The compromised application may provide maliciously formatted input to the EM system through a variety of channels including unprivileged system calls and messaging via the file system.
T.LIMITED_PHYSICAL_ACCESS: An attacker may attempt to access EM system data at rest on the endpoint devices.

3.2 Assumptions

This document does not define any additional assumptions.

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

This PP-Module does not define any objectives for the OE.

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 App PP, 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 TOE. This section describes any modifications that the ST author must make to the Base-PP SFRs to satisfy the required Enterprise-Management 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 1: Auditable Events for Mandatory Requirements
Requirement	Auditable Events	Additional Audit Record Contents
FAU_ALT_EXT.1
FAU_ALT_EXT.1
Type of alert	Identity of system or agent that sent alert
FAU_CRP_EXT.2
FAU_CRP_EXT.2
No events specified	N/A
FAU_GEN.1
FAU_GEN.1
No events specified	N/A
FAU_NET_EXT.1
FAU_NET_EXT.1
No events specified	N/A
FAU_STG.1
FAU_STG.1
No events specified	N/A
FIA_UAU.1
FIA_UAU.1
No events specified	N/A
FMT_MOF.1

	Issuance of command to perform function	Command sent and identity external recipients
Change of policy settings	Policy changed and value or full policy
FMT_SMF.1/External
FMT_SMF.1/External
No events specified	N/A
FMT_SMF.1/Internal
FMT_SMF.1/Internal
Success or failure of function	No additional information
FMT_SMR.1
FMT_SMR.1
No events specified	N/A
FTP_ITC.1
FTP_ITC.1
Initiation and termination of the trusted channel	Trusted channel protocol Non-TOE endpoint of connection
FTP_TRP.1
FTP_TRP.1
Initiation and termination of the trusted channel	Trusted channel protocol Identity of administrator

5.2.2 Security Audit (FAU)

FAU_ALT_EXT.1 Server Alerts

FAU_ALT_EXT.1.1

ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name

Note that the specific events that trigger an alert may need to be updated depending on the intended minimum functionality of the EM TOE.
The TSF shall alert the administrators in the event of any of the following:

Change in management status (i.e., adding system or agent to management, removing system or agent from management)
Failure to respond to heartbeat or check in during designated reporting interval
[selection: [assignment: other events], no other events]

Application Note: An alert can be defined as anything providing straightaway notice to the administrator. An alert is different from an audit record, however the fact that an alert was sent should be audited per FAU_GEN.1. Email, pop-up notifications, or other methods are acceptable forms of alerts.

The expectation of this requirement is that the TOE has a mechanism to configure the heartbeat or reporting interval of systems or agents that are under its management. The inability of the system or agent to maintain this mechanism should be flagged by the TSF as anomalous behavior requiring further examination and potential corrective action. This necessarily includes a mechanism to identify the assets under management and when they are added or removed.

FAU_CRP_EXT.2 Generation of Compliance Reports

FAU_CRP_EXT.2.1

ESR: auditing and compliance
Adapted from MDM PP requirement of the same name

Note that this is currently very generic because we will need TC/SME input on the minimum "compliance reporting" functionality of the EM TOE (i.e. is there a minimum set of things it needs to be able to check on, or potentially multiple such selectable sets depending on intended usage).
The TSF shall provide the ability to generate compliance reports of the configuration status of managed [selection: systems, agents] based on the following configuration attributes: channel that meets the secure channel requirements in FTP_ITC.1. The provided information for each enrolled [selection: systems, agents] includes:

TBD
List of configuration policies that are in place on the device (as defined in )

Application Note: The intent of this requirement is that the TOE be able to provide compliance information about managed systems, whether that is obtained through querying the system itself or by interfacing with an agent running on the system for this purpose.

FAU_GEN.1 Audit Data Generation

FAU_GEN.1.1

ESR: auditing and compliance
Adapted from MDM PP requirement of the same name (for management of MDM Agents)

Note that this is currently very generic because we will need TC/SME input on the minimum audit data generation functionality of the EM TOE (i.e. is there a minimum set of things it needs to be able to log, or potentially multiple such selectable sets depending on intended usage).
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:

All administrative actions
Commands issued to managed [selection: system, agent]
Specifically defined auditable events listed in Table t-audit-mandatory
[selection:
- Startup and shutdown of the audit functions
- Auditable events defined in Table t-audit-optional for Strictly Optional SFRs
- Auditable events defined in Table t-audit-objective for Objective SFRs
- Auditable events defined in Table t-audit-sel-based for Selection-Based SFRs
- Auditable events defined in the audit table for the TLS Functional Package (see Table 2)
- no other events
].

Application Note: This requirement outlines the events for which audit data must be generated by either the TOE or by its underlying platform. It is acceptable for this requirement to be met through a combination of platform-provided and TOE-provided audit functions, so long as the full set of required events are generated and include the required data.

Item a above requires all administrative actions to be auditable. Administrative actions refer to any management functions specified by FMT_MOF.1. Thus no additional specification for the auditability of these actions is specified in Table t-audit-mandatory aside from those that require additional record content.

Item b includes any commands that are performed against a managed system or agent. This need not go to the granularity of individual API calls, but it is expected that there is sufficient data to be clear to an administrator what actions the TOE may be performing against an external entity or what data it may be receiving from it.

Depending on the specific requirements selected by the ST author from SFR, optional requirements, selection-based requirements, and objective requirements, the ST author should include the appropriate auditable events from Table t-audit-optional, Table t-audit-sel-based, and Table t-audit-objective in the ST for the requirements selected.

In item d above, "startup and shutdown of the audit functions" may refer to the independent startup and shutdown of audit functionality specifically, or it may refer to startup and shutdown of the TOE itself, if auditing cannot be disabled separately from the operation of the TOE. It is outside the scope of the TOE boundary to consider the need to audit the startup and shutdown of auditing functionality used by the TOE platform, as this would be an inherent function of the host operating system.

The following table contains the events enumerated in the auditable events tables for the TLS Functional Package. Inclusion of these events in the ST is subject to selection above, inclusion of the corresponding SFRs in the ST, and support in the FP as represented by a selection in the FP audit table. This list is included here for reference.

Table 2: Auditable Events for Functional Packages

Requirement	Auditable Events	Additional Audit Data Contents
FCS_TLSC_EXT.1	Failure to establish a TLS session.	Reason for failure.
FCS_TLSC_EXT.1	Failure to verify presented identifier.	Presented identifier and reference identifier.
FCS_TLSS_EXT.1	Failure to establish a TLS session.	Reason for failure.
FCS_DTLSC_EXT.1	Failure of the certificate validity check.	Issuer Name and Subject Name of certificate.
FCS_DTLSS_EXT.1	Failure of the certificate validity check.	Issuer Name and Subject Name of certificate.

FAU_GEN.1.2

The TSF shall record within the audit data at least the following information:

date and time of the event
type of event
subject identity (if applicable)
and the outcome (success or failure) of the event
additional information in Table t-audit-mandatory
[selection:
- additional information defined in Table t-audit-optional for Strictly Optional SFRs
- additional information defined in Table t-audit-objective for Objective SFRs
- additional information defined in Table t-audit-sel-based for Selection-Based SFRs
- additional information defined in the audit table for the TLS Functional Package (see Table 2)
- no other additional 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, but may contain more information. The ST author must identify what audit data is generated by the TOE in its own audit mechanism versus audit data generated by the TOE platform based on the TOE's operation.

FAU_NET_EXT.1 Network Reachability Review

FAU_NET_EXT.1.1

ESR: configuration of EM system, auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall provide authorized administrators with the capability to read the network connectivity status of an external entity.

Application Note: Depending on whether the external entity is a system or a specific agent residing on the system, the network connectivity status may be registered with an ICMP ping or other generic mechanism, or through an API or other function that is specific to the agent or interface the TOE interacts with to perform management functions.

FAU_STG.1 Audit Data Storage Location

FAU_STG.1.1

ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall be able to store generated audit data on [selection: the TOE itself, an external IT entity using a trusted channel according to FTP_ITC, local platform storage].

Application Note:

Per FAU_GEN.1.1, audit data may be generated by the TOE, the platform, or both. If audit data is generated by the TOE, the TSF must have the ability to securely transmit this data to a remote entity. It may additionally store this data within the TOE boundary, in which case "the TOE itself" is selected and FAU_STG.2 must be included in the ST. Regardless of whether the TSF stores the audit data it generates within the TOE boundary, the TOE must always be able to securely transmit the audit data it generates to a remote entity. If audit data is generated by the platform, any secure local storage or secure remote transmission of this data is the responsibility of the platform.

Although the audit server is outside of the TOE, the TSF should still be able to support mutual authentication. There are no requirements levied on the audit server, but the TOE should be able to support TLS client certificate authentication. This way if the non-TOE audit server does support verifying client certs, the TSF is able to make use of that.

For distributed TOEs, each component must be able to export any audit data it generates across a protected channel. This may involve individual components independently transmitting audit data to the same environmental audit server via FTP_ITC.1, or it may involve one component of a distributed TOE aggregating audit data generated by other components prior to external transmission. In this case, the internal communication of audit data is protected via the mechanisms specifed in FTP_ITT.1. The intent of this requirement in the context of a distributed TOE is that all audit data generated by all components of the TSF be transmitted to an environmental entity entirely through trusted channels, regardless of whether it is transmitted directly from the TSF to the operational environment or whether it is first transmitted to another part of the TOE.

5.2.3 Identification and Authentication (FIA)

FIA_UAU.1 Timing of Authentication

FIA_UAU.1.1

ESR: authentication and authorization
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to allow [assignment: list of TSF mediated actions] on behalf of the user to be performed before the user is authenticated.

FIA_UAU.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] that requires each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.

Application Note: This requirement ensures that any user attempting to access the TSF must be authenticated. The ST author is responsible for assigning the list of actions that can take place (if any) before this authentication. The TSF or TOE platform may use enterprise authentication to meet this requirement (e.g., integration with enterprise directory services for single sign-on). An application that is installed in the context of a particular OS user such that the authentication context is inherited from logging in to the TOE platform as that user is also an example of authentication being facilitated through invocation of platform-provided functionality.

5.2.4 Management of the TSF (FMT)

FMT_MOF.1 Management of Security Functions Behavior

FMT_MOF.1.1

ESR: Endpoint and Agent Management; Permission Segregation
Adapted from MDM PP requirement of the same name
The TSF shall restrict the ability to perform the functions

listed in FMT_SMF.1/External
listed in FMT_SMF.1/Internal

to [assignment: authorized administrative roles for each function].

Application Note: This requirement defines the permissions necessary to execute or manage the behavior of functions used for both management of external entities (i.e., Enterprise-Management) as defined in FMT_SMF.1/Internal as well as the TOE itself. The ST author will define, for each claimed administrative function, any roles that are authorized to perform this function. Roles may be predefined by the TOE, inherited from an organizational directory, or custom based on privileges assigned to a role that the TOE has the ability to create.

Role assignment in and of itself may not be sufficient to authorize a function; it may be the case that scoping rules also define the specific set of objects that the function may be performed against. Examples could include a user having the ability to reset only their own password while an administrator has the ability to reset any user's password, or two different users being able to perform the same Enterprise-Management functions against two groups of external entities.

FMT_SMF.1/External Specification of Management Functions (Server configuration of External Systems)

FMT_SMF.1.1/External

ESR: The EM server/agents shall have a mechanism to report patch levels and initiate the patching process
ESR: The EM server/agents shall have a mechanism to report patch levels and initiate the patching process
Adapted from MDM PP requirement of the same name
Incomplete/placeholder as more things will likely be needed (whether mandatory or selectable) based on desired EM functionality.
The TSF shall be capable of performing the following management functions against external systems

1. Configuration of reporting interval
2. Query patch levels
3. Apply patches

and the following commands against external systems: do we actually need a separate list of "commands" vs "functions"? It seems like invoking APIs could exist separately from more holistic functions but not sure if we need to go into that granular detail or if we can just collectively bundle up related APIs into the notion of "functions" themselves
[selection: 4. TBD, 5. TBD].

Application Note: This requirement captures all the configuration functionality that the TSF provides to interact with external entities, whether these entities are standalone systems, or purpose-built agents running on these systems.

FMT_SMF.1/Internal Specification of Management Functions (Server Configuration of Server)

FMT_SMF.1.1/Internal

ESR: Compliance Adapted from MDM PP requirement of the same name (for management of the MDM Server itself)
Incomplete/placeholder as the management functionality necessary for the server must be defined (e.g. configuration of cryptographic channels, configuration of X.509 certs/trust anchors, configuration of user accounts). Note that some of this may be selectable as being implemented by the TOE or by the platform (or not at all, depending on what is claimed).
The TSF shall be capable of performing the following management functions for configuration of the TSF: [assignment: list of management functions]

Application Note: This requirement addresses the management functions the TOE provides to manage its own behavior (as opposed to managing the behavior of external entities)

FMT_SMR.1 Security Roles

FMT_SMR.1.1

ESR: Endpoint and Agent Management; Permission Segregation
Adapted from MDM PP requirement of the same name
The TSF shall maintain the roles [assignment: the authorized identified roles].

FMT_SMR.1.2

The TSF shall be able to associate users with roles.

Application Note: This PP-Module does not require a fixed set of arbitrarily-named roles. The purpose of this requirement is for the ST author to document how users are organized for the purpose of determining the authorizations they have to interact with the TSF, as specified in FMT_MOF.1.

5.2.5 Trusted Path/Channels (FTP)

FTP_ITC.1 Inter-TSF Trusted Channel (Authorized IT Entities)

FTP_ITC.1.1

ESR: confidentiality and integrity of data-at-rest and in-transit
Adapted from MDM PP requirement of the same name
The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec
SSH
mutually authenticated TLS
mutually authenticated DTLS
HTTPS
]
implement functionality using [selection:
IPsec as defined in the PP-Module for VPN Client
SSH as defined in the Functional Package for Secure Shell
mutually authenticated TLS as defined in the Package for Transport Layer Security
mutually authenticated DTLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base-PP
]

] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: connectivity to remote [selection: systems, agents], audit server, [selection: authentication server, [assignment: other capabilities]] that is logically distinct from other communication channels and provides assured identification of its endpoints and protection of the channel data from modification or disclosure.

Application Note: The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel with authorized IT entities that the TOE interacts with to perform its functions.

Protection (by one of the listed protocols) is required at least for communications with the IT entities managed by the TOE (whether those are systems that are managed using APIs provided by those systems by default, specialized agents running on systems that are designed for the purpose of interacting with the TOE, or both) and with the server that collects the audit information. If it communicates with an authentication server (e.g., RADIUS), then the ST author chooses "authentication server" in FTP_ITC.1.1 and this connection must be protected by one of the listed protocols. If other authorized IT entities (e.g., NTP server) are protected, the ST author makes the appropriate assignments (for those entities) and selections (for the protocols that are used to protect those connections).

To summarize, all communications with external entities that require protection of data in transit must be defined and must use one of the protocols specified in the requirement. At minimum, the TSF must communicate with external entities for the purpose of performing Enterprise-Management functions against them, and with a remote audit server for external storage of audit data. Additional channels are not required in order for the TOE to achieve its minimum required functionality, but if any such channels are implemented, appropriate protections must be provided for them.

The trusted channel uses IPsec, TLS, DTLS, or HTTPS as the protocol that preserves the confidentiality and integrity of external communications. The ST author chooses the mechanism or mechanisms supported by the TOE.

If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.

If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell. It should be noted that due to constraints imposed by this PP that SHA-1 cannot be used.

If the ST author selects "mutually authenticated TLS as defined in the Package for Transport Layer Security" or "mutually authenticated DTLS as defined in the Package for Transport Layer Security," the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:

FCS_TLS_EXT.1:
- either TLS or DTLS is selected depending on the selection made in FTP_ITC.1.1
- either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected
FCS_DTLSC_EXT.1.1 or FCS_DTLSS_EXT.1.1 (as appropriate):
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected

Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

The requirement implies that not only are communications protected when they are initially established, but also on resumption after an outage. It may be the case that some part of the TOE setup involves manually setting up tunnels to protect other communication, and if after an outage the TOE attempts to re-establish the communication automatically with (the necessary) manual intervention, there may be a window created where an attacker might be able to gain critical information or compromise a connection.

FTP_ITC.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, another trusted IT product] to initiate communication via the trusted channel.

FTP_ITC.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to initiate communication via the trusted channel for [assignment: list of functions for which a trusted channel is required].

Application Note: While there are no requirements on the party initiating the communication, the ST author lists in the assignment for FTP_ITC.1.3 the services for which the TOE can initiate the communication with the authorized IT entity.

FTP_TRP.1 Trusted Path

FTP_TRP.1.1

ESR: confidentiality and integrity of data-at-rest and in-transit
Adapted from MDM PP requirement of the same name
The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec
TLS
HTTPS
SSH
]
implement functionality using [selection:
IPsec as defined in the PP-Module for VPN Client
TLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base-PP
SSH as defined in the Functional Package for Secure Shell
]

] to provide a trusted communication path between itself as a [selection: server, peer] and [remote] administrators that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [modification, disclosure].

FTP_TRP.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [remote administrators] to initiate communication via the trusted path.

FTP_TRP.1.3

The TSF shall require the use of the trusted path for [initial administrator authentication, [remote administration]].

Application Note: This requirement ensures that authorized remote administrators initiate all communication with the TOE via a trusted path, and that all communications with the TOE by remote administrators is performed over this path. This requirement is optional because it may be the case that the TOE is launched as an application local to the server on which it is installed, such that if the administrator is accessing the TSF remotely, the remote access is achieved through a remote session with the TOE platform (as opposed to e.g. the TOE running a management application on a web server that allows for remote access to the TSF without separately accessing the underlying platform). 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 TOE.

If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell.

If the ST author selects "TLS as defined in the Package for Transport Layer Security" the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:

FCS_TLS_EXT.1:
- TLS must be selected
- Server must be selected
FCS_TLSS_EXT.1.1:
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.

Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

If HTTPS is chosen, FCS_HTTPS_EXT.1 must be included in the ST.

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 3: SFR Rationale
Threat	Addressed by	Rationale

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 Enterprise-Management 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 4: Consistency of Security Problem Definition (App PP base)
PP-Module Threat, Assumption, OSP	Consistency Rationale
T.NETWORK_ATTACK
T.NETWORK_EAVESDROP
T.LOCAL_ATTACK
T.LIMITED_PHYSICAL_ACCESS

6.1.3 Consistency of OE Objectives

This PP-Module does not define any objectives for the TOE's Operational Environment.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the App PP that are needed to support Enterprise-Management 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 5: 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
FAU_CRP_EXT.2
FAU_GEN.1
FAU_NET_EXT.1
FAU_STG.1
FIA_UAU.1
FMT_MOF.1
FMT_SMF.1/External
FMT_SMF.1/Internal
FMT_SMR.1
FTP_ITC.1
FTP_TRP.1
Optional SFRs
This PP-Module does not define any Optional requirements.
Objective SFRs
This PP-Module does not define any Objective requirements.
Implementation-dependent SFRs
FCO_CPC_EXT.1
FPT_ITT.1
Selection-based SFRs
FAU_SAR.1
FAU_STG.2
FTP_TRP.1/Join

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

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

A.3.1 Communications (FCO)

FCO_CPC_EXT.1 Component Registration Channel Definition

This component must be included in the ST if the TOE implements any of the following features:

Distributed TOE

FCO_CPC_EXT.1.1

ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require an Administrator to enable communications between any pair of TOE components before such communication can take place.

FCO_CPC_EXT.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to implement a registration process in which components establish and use a communications channel that uses [selection: A channel that meets the secure channel requirements in FPT_ITT.1 , A channel that meets the secure registration channel requirements in FTP_TRP.1/Join, No channel] for at least TSF data.

FCO_CPC_EXT.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to enable an administrator to disable communications between any pair of TOE components.

Application Note: This SFR is only applicable if the TOE is distributed and therefore has multiple components that need to communicate via an internal TSF channel. When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR.

Registration of the distributed TOE components may be accomplished either using the same trusted channel that subsequent communications occur on (FPT_ITT.1), a separate channel that exists for the purpose of facilitating this registration, i.e. a joining channel (FTP_TRP.1/Join), or no channel. In the case of the latter, registration would be accomplished by independent administrative configuration of each component.

A.3.2 Protection of the TSF (FPT)

FPT_ITT.1 Internal TOE TSF Data Transfer

This component must be included in the ST if the TOE implements any of the following features:

Distributed TOE

FPT_ITT.1.1

ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection:

invoke platform-provided functionality to use [selection:
IPsec
mutually authenticated TLS
mutually authenticated DTLS
HTTPS
SSH
]
implement functionality using [selection:
IPsec as defined in the PP-Module for VPN Client
mutually authenticated TLS as defined in the Package for Transport Layer Security
mutually authenticated DTLS as defined in the Package for Transport Layer Security
HTTPS in accordance with FCS_HTTPS_EXT.1 as defined in the Base-PP
SSH as defined in the Functional Package for Secure Shell
]

] to protect all data from [disclosure and modification] when it is transferred between separate parts of the TOE.

Application Note: This requirement ensures all communications between components of a distributed TOE are protected through the use of an encrypted communications channel. The data passed in this trusted communication channel are encrypted as defined in the protocol chosen in the second selection.

If "IPsec as defined in the PP-Module for VPN Client" is selected, the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module.

If the ST author selects "SSH as defined in the Functional Package for Secure Shell," the TSF must be validated against the FP for Secure Shell. It should be noted that due to constraints imposed by this PP that SHA-1 cannot be used.

If the ST author selects "mutually authenticated TLS as defined in the Package for Transport Layer Security" or "mutually authenticated DTLS as defined in the Package for Transport Layer Security," the TSF must be validated against requirements from the Package for Transport Layer Security, with the following selections made:

FCS_TLS_EXT.1:
- either TLS or DTLS is selected depending on the selection made in
- either client or server is selected as appropriate
FCS_TLSC_EXT.1.1 or FCS_TLSS_EXT.1.1 (as appropriate):
- The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
- mutual authentication must be selected

Protocol, RBG, Certificate validation, algorithm, and similar services may be met with platform-provided services.

This requirement is claimed if "FPT_ITT.1/INTER_XFER" is selected in FTP_ITC_EXT.1.

Appendix B - Selection-based Requirements

B.1 Security Audit (FAU)

FAU_SAR.1 Audit Review

FAU_SAR.1.1

ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide [authorized administrators] with the capability to read [all audit information] from the audit data.

FAU_SAR.1.2

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide the audit data in a manner suitable for the authorized administrators to interpret the information.

Application Note: The intent of this requirement is to ensure that the administrator can view and interpret the audit data and to prevent unauthorized users from accessing the logs.

FAU_STG.2 Audit Event Storage

FAU_STG.2.1

ESR: auditing and compliance
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to protect the stored audit data in the audit trail from unauthorized modification.

Application Note: If "store audit data locally" is selected in FAU_STG.1.1, this SFR must be included in the ST.

The purpose of this requirement is to ensure that audit data are stored securely. The ST author is responsible for selecting whether audit data are maintained when audit storage or failure occurs. The ST author must choose a means by which audit data are saved and select the events during which the data will be saved. The TSF may rely on the underlying operating system for this functionality, and the first selection should be made appropriately.

FAU_STG.2.2

The TSF shall be able to [selection, choose one of: prevent, detect] unauthorized modifications to the stored audit data in the audit trail.

B.2 Trusted Path/Channels (FTP)

FTP_TRP.1/Join Trusted Path (for Joining)

The inclusion of this selection-based component depends upon selection in FCO_CPC_EXT.1.2.

FTP_TRP.1.1/Join

ESR: Resiliency
Adapted from MDM PP requirement of the same name
The TSF shall [selection: invoke platform-provided functionality, implement functionality] to provide a communication path between itself and a joining component that is logically distinct from other communication paths and provides assured identification of [selection: the TSF endpoint, both joining component and TSF endpoint] and protection of the communicated data from [modification] and [selection: disclosure, none].

FTP_TRP.1.2/Join

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to permit [selection: the TSF, the joining component] to initiate communication via the trusted path.

FTP_TRP.1.3/Join

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to require the use of the trusted path for [joining components to the TSF under environmental constraints identified in [assignment: reference to operational guidance]].

Application Note: This SFR implements one of the types of channel identified in the main selection for FCO_CPC_EXT.1.2. The "joining component" in FTP_TRP.1/Join is the IT entity that is attempting to join the distributed TOE by using the registration process.

The effect of this SFR is to require the ability for components to communicate in a secure manner while the distributed TSF is being created (or when adding components to an existing distributed TSF). When creating the TSF from the initial pair of components, either of these components may be identified as the TSF for the purposes of satisfying the meaning of "TSF" in this SFR.

The selection at the end of FTP_TRP.1/Join recognises that in some cases confidentiality (i.e., protection of the data from disclosure) may not be provided by the channel. The ST author distinguishes in the TSS whether in this case the TOE relies on the environment to provide confidentiality (as part of the constraints referenced in FTP_TRP.1.3/Join) or whether the registration data exchanged does not require confidentiality (in which case this assertion must be justified). If "none" is selected, then this word may be omitted in the ST to improve readability.

The assignment in FTP_TRP.1.3/Join ensures that the ST highlights any specific details needed to protect the registration environment. Note that when the ST uses FTP_TRP.1/TRUSTPATH_JOIN for the registration channel then this channel cannot be reused as the normal inter-component communication channel defined in FPT_ITT.1.

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 6: Extended Component Definitions**
Functional Class	Functional Components
Communications (FCO)	FCO_CPC_EXT Component Registration Channel Definition
Security Audit (FAU)	FAU_ALT_EXT Server Alerts FAU_CRP_EXT Support for Compliance Reporting Configuration FAU_NET_EXT Network Reachability Review

C.2 Extended Component Definitions

C.2.1 Communications (FCO)

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

C.2.1.1 FCO_CPC_EXT Component Registration Channel Definition

Family Behavior

This family describes the registration process, including the capability for the administrator to enable or disable communications between a distributed TOE and other components of the TOE.

Component Leveling

FCO_CPC_EXT.1, Component Registration Channel Definition, defines requirements for the registration process for distributed TOEs.

Management: FCO_CPC_EXT.1

There are no management activities foreseen.

Audit: FCO_CPC_EXT.1

The following actions should be auditable if FAU_GEN security audit data generation is included in the PP or ST.

Enabling or disabling communications between a pair of components.
Identities of the endpoint's pairs enabled or disabled.

FCO_CPC_EXT.1 Component Registration Channel Definition

Hierarchical to:	No other components.
Dependencies to:	FPT_ITT.1 TSF Data Transfer FTP_TRP.1 Trusted Path

FCO_CPC_EXT.1.1

FCO_CPC_EXT.1.2

FCO_CPC_EXT.1.3

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to enable an administrator to disable communications between any pair of TOE components.

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

This family defines requirements for the TSF to alert administrators when a set of specified events occurs.

Component Leveling

FAU_ALT_EXT.1, Server Alerts, defines requirements for alerting the administrator to events.

Management: FAU_ALT_EXT.1

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

Install policies.

Audit: FAU_ALT_EXT.1

The following actions should be auditable if FAU_GEN security audit data generation is include in the PP or ST.

Type of alert.
Identity of external entity that sent alert.

FAU_ALT_EXT.1 Server Alerts

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

FAU_ALT_EXT.1.1

Change in management status (i.e., adding system or agent to management, removing system or agent from management)
Failure to respond to heartbeat or check in during designated reporting interval
[selection: [assignment: other events], no other events]

C.2.2.2 FAU_CRP_EXT Support for Compliance Reporting Configuration

Family Behavior

This family defines requirements for the TSF to generate compliance reports of the configuration of external entities.

Component Leveling

FAU_CRP_EXT.2, Generation of Compliance Reports, defines requirements for the contents and presentation of compliance reports.

Management: FAU_CRP_EXT.2

No specific management functions are identified.

Audit: FAU_CRP_EXT.2

There are no auditable events foreseen.

FAU_CRP_EXT.2 Generation of Compliance Reports

Hierarchical to:	No other components.
Dependencies to:	FTP_ITC.1 Inter-TSF Trusted Channel

FAU_CRP_EXT.2.1

TBD
List of configuration policies that are in place on the device (as defined in )

C.2.2.3 FAU_NET_EXT Network Reachability Review

Family Behavior

This family defines requirements for administrators to see network connectivity status of external entities managed by the TOE.

Component Leveling

FAU_NET_EXT.1, Network Reachability Review, defines requirements for authorized administrators to read network connectivity status.

Management: FAU_NET_EXT.1

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

Query connectivity status.

Audit: FAU_NET_EXT.1

There are no auditable events foreseen.

FAU_NET_EXT.1 Network Reachability Review

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

FAU_NET_EXT.1.1

Appendix D - Inherently 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.

Appendix E - Acronyms

Table 7: Acronyms
Acronym	Meaning
API	Application Programming Interface
Base-PP	Base Protection Profile
CC	Common Criteria
CEM	Common Evaluation Methodology
cPP	Collaborative Protection Profile
EA	Evaluation Activity
ECDSA	Elliptic Curve Digital Signature Algorithm
EDR	Endpoint Detection and Response
EM	Enterprise Security Management
EP	Extended Package
FIPS	Federal Information Processing Standards
FP	Functional Package
IP	Internet Protocol
ISO	International Organization for Standardization
IT	Information Technology
NIAP	National Information Assurance Partnership
NIST	National Institute of Standards and Technology
OE	Operational Environment
OS	Operating System
PP	Protection Profile
PP-Configuration	Protection Profile Configuration
PP-Module	Protection Profile Module
RSA	Rivest, Shamir, Adleman (digital signature algorithm)
SAR	Security Assurance Requirement
SFR	Security Functional Requirement
ST	Security Target
TOE	Target of Evaluation
TSF	TOE Security Functionality
TSFI	TSF Interface
TSS	TOE Summary Specification

Appendix F - Bibliography

Table 8: 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

PP-Module for Enterprise-Management

Revision History

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

1.5 Implementation-Based Features

1.5.1 Distributed TOE

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

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)

FAU_ALT_EXT.1 Server Alerts

FAU_CRP_EXT.2 Generation of Compliance Reports

FAU_GEN.1 Audit Data Generation

FAU_NET_EXT.1 Network Reachability Review

FAU_STG.1 Audit Data Storage Location

5.2.3 Identification and Authentication (FIA)

FIA_UAU.1 Timing of Authentication

5.2.4 Management of the TSF (FMT)

FMT_MOF.1 Management of Security Functions Behavior

FMT_SMF.1/External Specification of Management Functions (Server configuration of External Systems)

FMT_SMF.1/Internal Specification of Management Functions (Server Configuration of Server)

FMT_SMR.1 Security Roles

5.2.5 Trusted Path/Channels (FTP)

FTP_ITC.1 Inter-TSF Trusted Channel (Authorized IT Entities)

FTP_TRP.1 Trusted Path

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.3 Implementation-dependent Requirements

A.3.1 Communications (FCO)

FCO_CPC_EXT.1 Component Registration Channel Definition

A.3.2 Protection of the TSF (FPT)

FPT_ITT.1 Internal TOE TSF Data Transfer

Appendix B - Selection-based Requirements

B.1 Security Audit (FAU)

FAU_SAR.1 Audit Review

FAU_STG.2 Audit Event Storage

B.2 Trusted Path/Channels (FTP)

FTP_TRP.1/Join Trusted Path (for Joining)

Appendix C - Extended Component Definitions

C.1 Extended Components Table

C.2 Extended Component Definitions

C.2.1 Communications (FCO)

C.2.1.1 FCO_CPC_EXT Component Registration Channel Definition

Family Behavior

Component Leveling

Management: FCO_CPC_EXT.1

Audit: FCO_CPC_EXT.1

FCO_CPC_EXT.1 Component Registration Channel Definition

FCO_CPC_EXT.1.1

FCO_CPC_EXT.1.2

FCO_CPC_EXT.1.3

C.2.2 Security Audit (FAU)

C.2.2.1 FAU_ALT_EXT Server Alerts

Family Behavior

Component Leveling