PP-Module for MDM Agent

NIAP Logo
Version: 1.2
2025-01-31
National Information Assurance Partnership

Revision History

VersionDateComment
1.02019-03-01 Initial publication as PP-Module.
1.12023-12-11 Added GPOS PP base and incorporated NIAP Technical Decisions.
1.22025-01-31 Converted to CC:2022 and incorporated NIAP Technical Decisions.

Contents

1Introduction1.1Overview1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.4Use Cases1.5Implementation-Dependent Features1.5.1Platform Auditing1.5.2Supports Network Reachability Thresholds2Conformance Claims3Security Problem Definition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the Operational Environment4.2Security Objectives Rationale5Security Requirements5.1 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction 5.1.1 Modified SFRs 5.1.2 Additional SFRs5.1.2.1Auditable Events for MDF PP Additional SFRs5.1.2.2Cryptographic Support (FCS)5.1.2.3Trusted Path/Channels (FTP)5.2 Protection Profile for Mobile Device Management Security Functional Requirements Direction 5.2.1 Modified SFRs 5.2.1.1Protection of the TSF (FPT)5.2.1.2Trusted Path/Channels (FPT)5.2.2 Additional SFRs5.2.2.1Auditable Events for MDM PP Additional SFRs5.2.2.2Cryptographic Support (FCS)5.3 Protection Profile for General Purpose Operating System Security Functional Requirements Direction 5.3.1 Modified SFRs 5.3.1.1Cryptographic Support (FCS)5.3.2 Additional SFRs5.3.2.1Auditable Events for GPOS PP Additional SFRs5.3.2.2Trusted Path/Channels (FTP)5.4TOE Security Functional Requirements5.4.1Auditable Events for Mandatory SFRs5.4.2Security Audit (FAU)5.4.3Identification and Authentication (FIA)5.4.4Security Management (FMT)5.5TOE Security Functional Requirements Rationale6Consistency Rationale6.1 Protection Profile for Mobile Device Fundamentals6.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 6.2 Protection Profile for Mobile Device Management6.2.1 Consistency of TOE Type 6.2.2 Consistency of Security Problem Definition 6.2.3 Consistency of OE Objectives 6.2.4 Consistency of Requirements 6.3 Protection Profile for General Purpose Operating System6.3.1 Consistency of TOE Type 6.3.2 Consistency of Security Problem Definition 6.3.3 Consistency of OE Objectives 6.3.4 Consistency of Requirements Appendix A - Optional SFRsA.1Strictly Optional Requirements A.2Objective Requirements A.3Implementation-dependent Requirements A.3.1Auditable Events for Implementation-Dependent SFRsA.3.2Security Audit (FAU)A.3.3Protection of the TSF (FPT)Appendix B - Selection-based Requirements Appendix C - Extended Component DefinitionsC.1Extended Components TableC.2Extended Component DefinitionsC.2.1Cryptographic Support (FCS)C.2.1.1FCS_STG_EXT Trusted ChannelC.2.2Identification and Authentication (FIA)C.2.2.1FIA_ENR_EXT EnrollmentC.2.3Protection of the TSF (FPT)C.2.3.1FPT_NET_EXT Network ReachabilityC.2.4Security Audit (FAU)C.2.4.1FAU_ALT_EXT MDM AlertsC.2.4.2FAU_STG_EXT Protected Audit Event StorageC.2.5Security Management (FMT)C.2.5.1FMT_POL_EXT Trusted Policy UpdateC.2.5.2FMT_SMF_EXT Specification of Management FunctionsC.2.5.3FMT_UNR_EXT UnenrollmentAppendix D - Implicitly Satisfied RequirementsAppendix E - Use Case TemplatesE.1Enterprise-owned device for general-purpose enterprise useE.2Enterprise-owned device for specialized, high-security useE.3Personally owned device for personal and enterprise useE.4Personally owned device for personal and limited enterprise useAppendix F - AcronymsAppendix G - Bibliography

1 Introduction

1.1 Overview

The scope of the MDM Agent Protection Profile Module (PP-Module) is to describe the security functionality of a Mobile Device Management (MDM) Agent in terms of Common Criteria (CC) and to define functional and assurance requirements for such products. This PP-Module is intended for use with the following Base-PPs:
These Base-PPs are valid because an MDM Agent is either a third-party application manufactured by the MDM Server vendor or is a native application deployed on a mobile device or GPOS.

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.
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

Administrator
The person who is responsible for management activities, including setting the policy that is applied by the enterprise on the device.
Enrolled State
The state in which a device is managed by a policy from an MDM.
Mobile Application Store (MAS)
An MDM feature that allows for an organization to substitute a device manufacturer's application store for one that restricts what applications are made available to users.
Mobile Device Management (MDM)
Products that allow enterprises to apply security policies to end user devices. This system consists of two primary components: the MDM Server and the MDM Agent.
Mobile Device User
The person who uses and is held responsible for a mobile device. Synonymous with 'local user' in the context of a mobile device.
Operating System (OS)
 Software which runs at the highest privilege level and can directly control hardware resources. These include mobile device and general purpose operating systems (GPOS). Mobile device operating systems have general purpose functionality but are typically integrated more tightly with purpose-built mobile hardware and limit a user's ability to interact with the operating system. Modern mobile devices typically have at least two primary operating systems: one which runs on the cellular baseband processor and one which runs on the application processor. The platform of the application processor handles most user interaction and provides the execution environment for apps. The platform of the cellular baseband processor handles communications with the cellular network and may control other peripherals. The term OS, without context, may be assumed to refer to the platform of the application.
Unenrolled State
 The state in which a device is not managed by an MDM system.
User
See Mobile Device User.

1.3 Compliant Targets of Evaluation

The MDM system consists of two primary components: the MDM Server software and the MDM Agent. This PP-Module specifically addresses the MDM Agent, which establishes a secure connection back to the MDM Server, from which it receives policies to enforce on the device. Optionally, the MDM Agent interacts with a MAS Server to download and install enterprise-hosted applications.

A compliant MDM Agent is installed on a device as an application (supplied by the developer of the MDM Server software) or is part of a mobile device or GPOS This PP-Module builds on the MDF PP, the MDM PP, or the GPOS PP. A TOE that claims conformance to this PP-Module must also claim conformance to one of those PPs as its Base-PP. To mitigate the threats that this PP-Module defines, a compliant TOE is obligated to implement the functionality the Base-PP requires, along with the additional functionality defined in this PP-Module.

This PP-Module shall build on the MDF PP if the TOE is a native part of a mobile operating system. The TOE for this PP-Module combined with the MDF PP is the mobile device itself plus the MDM Agent. If the MDM Agent is part of the mobile device’s OS, the MDM Agent may present multiple interfaces for configuring the mobile device, such as a local and remote interface. MDM Agents conforming to this PP-Module must at least offer an interface with a trusted channel that serves as one piece of an MDM system. Conformant MDM Agents may also offer other interfaces, and the configuration aspects of these additional interfaces are in scope of this PP-Module.

This PP-Module shall build on the MDM PP if the TOE is a third-party application that is provided with an MDM Server and installed on a device by the user after acquiring the device. The distributed TOE for this PP-Module combined with the MDM PP is the entire MDM environment, which includes both the MDM Server and the MDM Agent. Even though the device itself is not part of the TOE, it is expected to be evaluated against the MDF or GPOS PP so that its baseline security capabilities can be assumed to be present. If the TOE conforms to the GPOS PP, evaluating the hardware platform against the Protection Profile for General Purpose Computing Platforms (GPCP PP) may also be considered so that assurance of the underlying platform hardware can be obtained.

This PP-Module shall build on the GPOS PP if the TOE is a native part of a non-mobile GPOS. The TOE for this PP-Module combined with the GPOS PP is the operating system itself plus the MDM Agent. If the MDM Agent is part of the OS, the MDM Agent may present multiple interfaces for configuring the OS, such as a local and remote interface. The MDM Agent does not need to provide a dedicated management interface that is separate from the means by which administrators interact with the OS as a whole. However, if it does provide any such interfaces, the configuration aspects of these additional interfaces are in scope of this PP-Module.

1.3.1 TOE Boundary

Figure 1 shows a high-level example of the PP-Module TOE boundary and its OE where the TOE runs on a mobile device. A use case where the TOE runs on a GPOS is identical aside from the specific type of device on which it runs. As stated above, the MDM Agent may either be provided as part of the device itself (shown in red) or distributed as a third-party application from the developer of the MDM Server software (shown in blue).


Figure 1: MDM Agent Operating Environment

The MDM Agent must closely interact with or be part of the mobile device or OS platform so that it can establish policies and to perform queries about device status. The mobile device and OS platform, in turn, have their own security requirements specified in the MDF PP and GPOS PP, respectively.

1.4 Use Cases

This PP-Module defines four use cases:

[USE CASE 1] Enterprise-owned device for general-purpose enterprise use
An enterprise-owned device for general-purpose business use is commonly called Corporately Owned, Personally Enabled. This use case entails a significant degree of enterprise control over configuration and software inventory. enterprise administrators use an MDM product to establish policies on the devices prior to user issuance. Users may use internet connectivity to browse the web, access corporate mail, or run enterprise applications, but this connectivity may be under significant control of the enterprise. The user may also be expected to store data and use applications for personal, non-enterprise use. The enterprise administrator uses the MDM product to deploy security policies and query device status. The MDM may issue commands for remediation actions.
[USE CASE 2] Enterprise-owned device for specialized, high-security use
An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. As in the previous use case, the MDM product is used to establish such policies on devices prior to issuance to users. The device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the internet. Use of the device may require compliance with usage policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information.

For changes to included SFRs, selections, and assignments required for this use case, see E.2 Enterprise-owned device for specialized, high-security use.

[USE CASE 3] Personally owned device for personal and enterprise use
A personally owned device, which is used, for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device.

However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require certain security policies, for example a password or screen lock policy, and health reporting, such as the integrity of the system software, before allowing access. The administrator of the MDM can establish remediation actions, such as wiping enterprise data for non-compliant devices. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the device.

For changes to included SFRs, selections, and assignments required for this use case, see E.3 Personally owned device for personal and enterprise use.

[USE CASE 4] Personally owned device for personal and limited enterprise use
A personally owned device may also be given access to limited enterprise services such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the device are not compromised. Based on the OE and the acceptable risk level of the enterprise, those SFRs outlined in Section 5 of this PP-Module are sufficient for the secure implementation of this BYOD use case.

1.5 Implementation-Dependent Features

If the TOE implements the following features, then the SFRs associated with the features must be claimed.

1.5.1 Platform Auditing

If the TOE is deployed on a mobile device or GPOS platform (i.e., the TOE does not use the MDM PP as its Base-PP), it is expected to rely on the underlying platform for secure storage of its audit records.

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

1.5.2 Supports Network Reachability Thresholds

An MDM Agent may support the ability to determine if it has been out of connectivity with an MDM Server for too long. The configuration of the number of allowed missed reachability events or time limit since last successful connection with the MDM Server is handled in the MDM Server's configuration policy of the MDM Agent (the first selection of function 56 in FMT_SMF.1.1/SERVER_CONF_AGENT within the MDM PP). This feature applies if either the TOE claims the MDM PP as its Base-PP and management function 56 is claimed, or if the TOE's OE includes an MDM Server that was separately validated against the MDM PP and that MDM Server's ST claims management function 56.

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

2 Conformance Claims

Conformance Statement

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

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

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

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

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

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

3 Security Problem Definition

3.1 Threats

The following threats are specific to MDM Agents, and represents an addition to those identified in the Base-PPs.
T.INSECURE_MDM_COMMUNICATIONS
A malicious user or process may inspect network communications between the MDM agent and an MDM server to illicitly determine, modify, or prevent these communications in such a way that the MDM agent fails to enforce the intended policy.
T.MISUSED_DEVICE
A malicious or careless user may operate a mobile device in such a way that it compromises the security of the device, its data, or its user.
T.UNAUTHORIZED_POLICY_SOURCE
A malicious user or process can send illegitimate policy data to the TOE in an attempt to cause it to enter an insecure or unknown state.

3.2 Assumptions

These assumptions are made on the Operational Environment (OE) in order to be able to ensure that the security functionality specified in the PP-Module can be provided by the TOE. If the TOE is placed in an OE that does not meet these assumptions, the TOE may no longer be able to provide all of its security functionality.
A.CONNECTIVITY
The TOE relies on network connectivity to carry out its management activities. The TOE will robustly handle instances when connectivity is unavailable or unreliable.
A.PLATFORM
The MDM Agent relies upon platform and hardware functionality that can be assumed to provide policy enforcement, cryptographic services, data protection, trusted updates, and software integrity verification of the MDM Agent.
A.PROPER_ADMIN
One or more competent, trusted personnel who are not careless, willfully negligent, or hostile, are assigned and authorized as the TOE administrators, and do so using and abiding by guidance documentation.
A.PROPER_USER
Users are not willfully negligent or hostile, and use the device within compliance of a reasonable enterprise security policy.

3.3 Organizational Security Policies

P.ACCOUNTABILITY
Personnel operating the TOE shall be accountable for their actions within the TOE.
P.ADMIN
The configuration of the device's security functions must adhere to the enterprise security policy.
P.DEVICE_ENROLL
The MDM administrator must enroll a device for a specific user prior to it being used in the enterprise network.
P.NOTIFY
The user must immediately notify the administrator if a device is lost or stolen so that the administrator may apply remediation actions via the MDM system.

4 Security Objectives

4.1 Security Objectives for the Operational Environment

The OE of the TOE implements technical and procedural measures to assist the TOE in correctly providing its security functionality (which is defined by the security objectives for the TOE). The security objectives for the OE consist of a set of statements describing the goals that the OE should achieve. This section defines the security objectives that are to be addressed by the IT domain or by non-technical or procedural means. The assumptions identified in Section 3 are incorporated as security objectives for the environment.
OE.DATA_PROPER_ADMIN
TOE administrators are trusted to follow and apply all administrator guidance in a trusted manner.
OE.DATA_PROPER_USER
Device users are trained to securely use the device running the MDM Agent and apply all guidance in a trusted manner.
OE.IT_ENTERPRISE
The enterprise IT infrastructure provides security for a network that is available to the TOE and the device on which it runs that prevents unauthorized access.
OE.DEVICE_PLATFORM
The MDM Agent relies upon the trusted platform and hardware to provide policy enforcement as well as cryptographic services and data protection. The platform also provides trusted updates and software integrity verification of the MDM Agent.
OE.WIRELESS_NETWORK
A wireless network will be available to devices running the MDM Agent.

4.2 Security Objectives Rationale

This section describes how the assumptions and organizational security policies map to operational environment security objectives.
Table 1: Security Objectives Rationale
Assumption or OSPSecurity ObjectivesRationale
A.CONNECTIVITYOE.WIRELESS_​NETWORKThe OE objective OE.WIRELESS_NETWORK is realized through A.CONNECTIVITY.
A.PLATFORMOE.DEVICE_​PLATFORMThe OE objective OE.DEVICE_PLATFORM is realized through A.PLATFORM.
A.PROPER_​ADMINOE.DATA_​PROPER_​ADMINThe OE objective OE.DATA_PROPER_ADMIN is realized through A.PROPER_ADMIN.
A.PROPER_​USEROE.DATA_​PROPER_​USERThe OE objective OE.DATA_PROPER_USER is realized through A.PROPER_USER.
P.ACCOUNTABILITYOE.DEVICE_​PLATFORMThe use of a trusted device platform will include the necessary mechanisms to record user actions.
P.ADMINOE.DATA_​PROPER_​ADMINAn environment that empowers only trusted administrators will satisfy the policy that the device is configured correctly.
P.DEVICE_​ENROLLOE.DATA_​PROPER_​ADMINAn environment that empowers only trusted administrators will satisfy the policy that the device is enrolled into management.
OE.IT_​ENTERPRISEThe use of an enterprise IT network enables the infrastructure to facilitate device enrollment.
P.NOTIFYOE.DATA_​PROPER_​USERAn environment with trained and trusted users can be expected to adhere to this policy.

5 Security Requirements

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

5.1 Protection Profile for Mobile Device Fundamentals Security Functional Requirements Direction

In a PP-Configuration that includes the MDF PP, the TOE is expected to rely on some of the security functions implemented by the Mobile Device as a whole and evaluated against the MDF PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the MDF PP in addition to what is mandated by Section 5.4 TOE Security Functional Requirements.

5.1.1 Modified SFRs

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

5.1.2 Additional SFRs

This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the MDF PP is claimed as the Base-PP.

5.1.2.1 Auditable Events for MDF PP Additional SFRs

Table 2: Auditable Events for MDF PP Additional SFRs
RequirementAuditable EventsAdditional Audit Record Contents
FCS_STG_EXT.4
No events specifiedN/A
FTP_ITC_EXT.1/MDFCHANNEL
Initiation of the trusted channel.No additional information.
Termination of the trusted channel.No additional information.
Failure of the trusted channel functions.No additional information.
FTP_TRP.1/MDFENROLL
Initiation of the trusted path.No additional information.
Termination of the trusted path.No additional information.
Failure of the trusted path functions.No additional information.

5.1.2.2 Cryptographic Support (FCS)

FCS_STG_EXT.4 Cryptographic Key Storage

The MDM Agent shall use the platform provided key storage for all persistent secret and private keys.
Application Note: This requirement ensures that persistent secrets (credentials, secret keys, authentication tokens) and private keys are stored securely when not in use by the mobile platform.

5.1.2.3 Trusted Path/Channels (FTP)

FTP_ITC_EXT.1/MDFCHANNEL Trusted Channel Communication

The TSF shall use [selection: ] and [no other protocols] to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
Application Note: The intent of this requirement is to protect the communications channel between MDM Server and MDM Agent, post enrollment. FTP_TRP.1/MDFENROLL is to protect the communications channel between MDM Server and MDM Agent during enrollment.

This requirement is to ensure that the transmission of any audit logs, mobile device information data (software version, hardware model, and application versions), and configuration data collected by the MDM Agent and sent from the MDM Agent to the MDM Server, when commanded, or at configurable intervals, is properly protected. This trusted channel also protects any commands and policies sent by the MDM Server to the MDM Agent. Either the MDM Agent or the MDM Server is able to initiate the connection.

This requirement is iterated from the MDF PP to indicate the protocols that the MDM Agent can use for a trusted channel. The mobile device is required to perform the mandated cryptographic protocols as in the Base-PP for communication channels mandated in the MDF PP. The ST author must select one of TLS, DTLS, or HTTPS in order to establish and maintain a trusted channel between the MDM Agent and the MDM Server. Only TLS, DTLS, or HTTPS are acceptable for this trusted channel.

Since this requirement is only for the case when the PP-Module builds on the MDF PP, and in this case it is expected that the MDM Agent will be a native part of the mobile operating system, it is expected that the MDM Agent will use the mobile device's implementation of the selected protocols. HTTPS (FCS_HTTPS_EXT.1) and TLS (FCS_TLSC_EXT.1) are already mandatory for an MDF ST. If "TLS" or "DTLS" is selected, the following selections from Functional Package for Transport Layer Security (TLS), version 2.1 must be made:
  • FCS_TLS_EXT.1:
  • FCS_TLSC_EXT.1.1:
    • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1 from the MDF PP.
    • Mutual authentication must be selected.
Protocol, RBG, certificate validation, algorithm, and similar services may be met with platform provided services.

The TSF shall permit the TSF and the MDM Server and [selection: MAS Server, no other IT entities] to initiate communication via the trusted channel.
Application Note: For all other use cases, the mobile device initiates the communication; however, for MDM Agents, the MDM Server may also initiate communication.
The TSF shall initiate communication via the trusted channel for all communication between the MDM Agent and the MDM Server and [selection: all communication between the MAS Server and the MDM Agent, no other communication].
Application Note: This element is iterated from the MDF PP; it is expected that the mobile device will initiate the trusted channel between the MDM Agent and the MDM Server for administrative communication and may initiate other trusted channels to other trusted IT entities for other uses.

FTP_TRP.1/MDFENROLL Trusted Path (for Enrollment)

The TSF shall use [selection:
  • TLS client as defined in the Package for Transport Layer Security
  • HTTPS
] to provide a trusted communication path between itself and an MDM Server that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [modification, disclosure].
The TSF shall permit [local users] to initiate communication via the trusted path.
The TSF shall require the use of the trusted path for [[MDM enrollment]].
Application Note: This requirement ensures that a trusted connection is used for initial enrollment to an MDM; security of ongoing MDM Server communications after enrollment is implemented through FTP_ITC_EXT.1/MDFCHANNEL.

The ST author chooses the mechanism or mechanisms supported by the TOE. The data passed in this trusted communication channel are encrypted as defined by the protocol selected.

Since this requirement is only for the case when the PP-Module builds on MDF PP, and in this case it is expected that the MDM Agent will be a native part of the mobile operating system, it is expected that the MDM Agent will use the mobile device's implementation of the selected protocols. HTTPS (FCS_HTTPS_EXT.1) and TLS (FCS_TLSC_EXT.1) are already mandatory for an MDF ST. If "TLS" is selected, the following selections from Functional Package for Transport Layer Security (TLS), version 2.1 must be made:
  • FCS_TLS_EXT.1:
    • TLS or DTLS must be selected.
    • Client must be selected.
  • FCS_TLSC_EXT.1.1:
    • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1 from the MDF PP.

5.2 Protection Profile for Mobile Device Management Security Functional Requirements Direction

In a PP-Configuration that includes the MDM PP, the TOE is expected to rely on some of the security functions implemented by the MDM Server as a whole and evaluated against the MDM PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the MDM PP in addition to what is mandated by Section 5.4 TOE Security Functional Requirements.

5.2.1 Modified SFRs

The SFRs listed in this section are defined in the MDM PP and relevant to the secure operation of the TOE.

5.2.1.1 Protection of the TSF (FPT)

FPT_ITT.1/INTER_XFER_AGENT: Internal TOE TSF Data Transfer (MDM Agent)

This PP-Module requires that communications between the MDM Server and MDM Agent portions of the TOE are secured in the manner specified by FPT_ITT.1/INTER_XFER_AGENT in the MDM PP. This PP-Module does not require that this channel be established in a specific manner beyond this function using one of the methods specified in the MDM PP; a registration channel over an untrusted network, a registration channel over an environmentally protected network, or registration without the use of a registration channel is permitted. Depending on the method used, the appropriate MDM PP SFR claims must be made.

5.2.1.2 Trusted Path/Channels (FPT)

FTP_ITC_EXT.1: Trusted Channel

This PP-Module requires the ST author to select that an MDM Agent is internal to the TOE because the TOE boundary includes both an MDM Server and MDM Agent by definition when this PP-Module is claimed. As noted above, the fact that the TOE includes both MDM Server and MDM Agent components means that FPT_ITT.1/INTER_XFER_AGENT from the MDM PP must also be claimed, as this SFR defines the channel used for secure communications between these two components.

5.2.2 Additional SFRs

This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the MDM PP is claimed as the Base-PP.

5.2.2.1 Auditable Events for MDM PP Additional SFRs

Table 3: Auditable Events for MDM PP Additional SFRs
RequirementAuditable EventsAdditional Audit Record Contents
FCS_STG_EXT.1/MDMKEYS
No events specifiedN/A

5.2.2.2 Cryptographic Support (FCS)

FCS_STG_EXT.1/MDMKEYS Cryptographic Key Storage

The MDM Agent portion of the TSF shall use [platform-provided key storage] for all persistent secret and private keys.
Application Note: This requirement ensures that persistent secrets (credentials, secret keys) and private keys are stored securely when not in use by the mobile platform.

5.3 Protection Profile for General Purpose Operating System Security Functional Requirements Direction

In a PP-Configuration that includes the GPOS PP, the TOE is expected to rely on some of the security functions implemented by the Operating System as a whole and evaluated against the GPOS PP. The following sections describe any modifications that the ST author must make to the SFRs defined in the GPOS PP in addition to what is mandated by Section 5.4 TOE Security Functional Requirements.

5.3.1 Modified SFRs

The SFRs listed in this section are defined in the GPOS PP and relevant to the secure operation of the TOE.

5.3.1.1 Cryptographic Support (FCS)

FCS_STO_EXT.1: Storage of Sensitive Data

There is no change to this SFR from the Base-PP beyond ensuring that it also applies to the MDM Agent portion of the TOE.

The text of the requirement is replaced with:

The OS shall implement functionality to encrypt sensitive data including any data used for MDM Agent functionality stored in non-volatile storage and provide interfaces to applications to invoke this functionality.

5.3.2 Additional SFRs

This section defines additional SFRs that must be added to the TOE boundary in order to implement the functionality in any PP-Configuration where the GPOS PP is claimed as the Base-PP.

5.3.2.1 Auditable Events for GPOS PP Additional SFRs

Table 4: Auditable Events for GPOS PP Additional SFRs
RequirementAuditable EventsAdditional Audit Record Contents
FTP_ITC_EXT.1/OSCHANNEL
Initiation of the trusted channel.No additional information.
Termination of the trusted channel.No additional information.
Failure of the trusted channel functions.No additional information.
FTP_TRP.1/OSENROLL
Initiation of the trusted path.No additional information.
Termination of the trusted path.No additional information.
Failure of the trusted path functions.No additional information.

5.3.2.2 Trusted Path/Channels (FTP)

FTP_ITC_EXT.1/OSCHANNEL Trusted Channel Communication

The OS shall use [selection: mutually authenticated TLS as conforming to Functional Package for Transport Layer Security (TLS), version 2.1 as a [client], mutually authenticated DTLS as conforming to Functional Package for Transport Layer Security (TLS), version 2.1 as a [client]] to provide a trusted communication channel between itself and authorized IT entities supporting the following capabilities: [[MDM Server communications, [selection: MAS Server communications, no other communications]]] that is logically distinct from other communication channels and provides assured identification of its end points and protection of the channel data from disclosure and detection of modification of the channel data.
Application Note: The intent of this requirement is to protect the communications channel between MDM Server and Agent, post enrollment. FTP_TRP.1/OSENROLL is to protect the communications channel between MDM Server and Agent during enrollment.

This requirement is to ensure that the transmission of any audit logs, system data (hardware, software, or application), and configuration data collected by the MDM Agent and sent from the MDM Agent to the MDM Server, when commanded, or at configurable intervals, is properly protected. This trusted channel also protects any commands and policies sent by the MDM Server to the MDM Agent. Either the MDM Agent or the MDM Server is able to initiate the connection.

This requirement is iterated from the GPOS PP to indicate the protocols that the MDM Agent can use for a trusted channel. The operating system is required to perform the mandated cryptographic protocols as in the Base-PP for communication channels mandated in the GPOS PP. The ST author must select one of TLS or DTLS in order to establish and maintain a trusted channel between the MDM Agent and the MDM Server. Only TLS or DTLS are acceptable for this trusted channel.

Since this requirement is only for the case when the PP-Module builds on the GPOS PP, and in this case it is expected that the MDM Agent will be a native part of the operating system, it is expected that the MDM Agent will use the operating system's implementation of the selected protocols. Depending on whether "TLS" or "DTLS" is selected, the following selections from the Functional Package for Transport Layer Security (TLS), version 2.1 must be made:
  • FCS_TLS_EXT.1:
  • FCS_TLSC_EXT.1.1:
    • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1 from the GPOS PP.
    • Mutual authentication must be selected.
Protocol, RBG, certificate validation, algorithm, and similar services may be met with platform provided services.

FTP_TRP.1/OSENROLL Trusted Path (for Enrollment)

The TSF shall provide a communication path between itself and a [remote] MDM Server that is logically distinct from other communication paths and provides assured identification of its endpoints and protection of the communicated data from [modification, disclosure].
The TSF shall permit [selection: local users, remote users] to initiate communication via the trusted path.
The TSF shall require the use of the trusted path for [[MDM enrollment]].
Application Note: This requirement ensures that a trusted connection is used for initial enrollment to an MDM; security of ongoing MDM Server communications after enrollment is implemented through FTP_ITC_EXT.1/OSCHANNEL.

Since this requirement is only for the case when the PP-Module builds on GPOS PP, and in this case it is expected that the MDM Agent will be a native part of the operating system, it is expected that the MDM Agent will use the operating system's implementation of a trusted protocol defined in the Base-PP SFR FTP_ITC_EXT.1 for this trusted path.

5.4 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.4.1 Auditable Events for Mandatory SFRs

The auditable events specified in this PP-Module are included in an ST if the incorporating PP, cPP, or PP-Module supports audit event reporting through FAU_GEN.1, and if all other criteria in the incorporating PP or PP-Module are met.

Table 5: Auditable Events for Mandatory Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_ALT_EXT.2
Success or failure of sending alert.No additional information.
FAU_GEN.1/AGENT
No events specifiedN/A
FAU_SEL.1/AGENT
All modifications to the audit configuration that occur while the audit collection functions are operating.No additional information.
FIA_ENR_EXT.2
Enrollment in management.Reference identifier of the MDM Server.
FMT_POL_EXT.2
Failure of policy validation.Reason for failure of validation.
FMT_SMF_EXT.4
Outcome (success or failure) of function.No additional information.
FMT_UNR_EXT.1
[selection: Attempt to unenroll, None]No additional information

5.4.2 Security Audit (FAU)

FAU_ALT_EXT.2 Agent Alerts

The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the event of any of the following audit events:
  • successful application of MDM policies,
  • [selection: receiving, generating] periodic reachability events,
  • [selection:
    • change in enrollment state
    • failure to install an application from the MAS Server
    • failure to update an application from the MAS Server
    • [assignment: other events]
    • no other events
    ].
Application Note: The trusted channel is defined in FPT_ITT.1/INTER_XFER_AGENT of the Base-PP if the TOE claims the MDM PP, FTP_ITC_EXT.1/MDFCHANNEL in this PP-Module if the TOE claims the MDF PP, and FTP_ITC_EXT.1/OSCHANNEL in this PP-Module if the TOE claims the GPOS PP. “Alert” in this requirement could be as simple as an audit record or a notification. If any prior alerts exist in the queue, per FAU_ALT_EXT.2.2, those alerts must be sent when the trusted channel is available.

This requirement is to ensure that the MDM Agent must notify the MDM Server whenever one of the events listed above occurs. Lack of receipt of a successful policy installation indicates the failure of the policy installation.

The periodic reachability events ensure that either the MDM Agent responds to MDM Server polls to determine device network reachability, or the MDM Agent can be configured to regularly notify the MDM Server that it is reachable. The ST author must select “receiving” in the first case and “generating” in the second. The corresponding requirement for the MDM Server is FAU_NET_EXT.1 in the MDM PP.

The ST author must either assign further events or select the “no other events” option. Note that alerts may take time to reach the MDM Server, or not arrive, due to poor connectivity.

The MDM Agent shall queue alerts if the trusted channel is not available.
Application Note: If the trusted channel is not available, alerts must be queued. When the trusted channel becomes available, the queued alerts must be sent.

FAU_GEN.1/AGENT Audit Data Generation

The MDM Agent shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the following auditable events:
  1. Startup and shutdown of the MDM Agent;
  2. All auditable events for the [not specified] level of audit; and
  3. [MDM policy updated, any modification commanded by the MDM Server, specifically defined auditable events listed in Table 5 and [selection: Table 2, Table 3, Table 4, Table 16, no other tables], and [selection: [assignment: other events], no other events]].
Application Note: This requirement outlines the information to be included in the MDM Agent’s audit data. For each claimed SFR, any corresponding auditable events must be claimed. The auditable events are included in different tables because SFRs depend on the claimed Base-PP or supported TOE implementation; the ST author selects all tables that contain an SFR that the TOE claims.

If “MDM policy updated” is selected, it must indicate that an update to the policy occurred. The event record need not contain the differences between the prior policy and the new policy; optionally, the specific changes to policy that were included in that update may be detailed. All updates to policy should trigger this alert. Modifications commanded by the MDM Server are those commands listed in FMT_SMF.1.1.

The selection for the FMT_UNR_EXT.1 auditable event in the Auditable Events table corresponds to the selection in FMT_UNR_EXT.1. If “apply remediation actions” is selected in FMT_UNR_EXT.1, then the ST author selects “attempt to unenroll” in FAU_GEN.1.1/AGENT Auditable Events table for FMT_UNR_EXT.1; otherwise, "none" is selected.
The [selection: TSF, TOE platform] shall record within the MDM Agent audit data at least the following information:
  1. Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event, and additional information in Table 5 and [selection: Table 2, Table 3, Table 4, Table 16, no other tables];
  2. For each audit event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [assignment: other audit relevant information].
Application Note: All audits must contain at least the information mentioned in FAU_GEN.1.2/AGENT, but may contain more information which can be assigned. The ST author must identify which information in the given audit data that is populated by the MDM Agent and which is populated by the MDM Agent’s platform.

FAU_SEL.1/AGENT Security Audit Event Selection

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to select the set of events to be audited from the set of all auditable events based on the following attributes:
  1. [event type]
  2. [success of auditable security events, failure of auditable security events, [assignment: other attributes]].
Application Note: The intent of this requirement is to identify all criteria that can be selected to trigger an audit event. For the ST author, the assignment is used to list any additional criteria that may be used but are not captured by the selection. This selection may be configured by the MDM Server.

5.4.3 Identification and Authentication (FIA)

FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management

The MDM Agent shall record the reference identifier of the MDM Server during the enrollment process.
Application Note: The reference identifier of the MDM Server may be the Distinguished Name, Domain Name, or the IP address of the MDM Server. This requirement allows the specification of the information to be to be used to establish a network connection and the reference identifier for authenticating the trusted channel between the MDM Server and MDM Agent, as defined in the MDM PP.

5.4.4 Security Management (FMT)

FMT_POL_EXT.2 Agent Trusted Policy Update

The MDM Agent shall only accept policies and policy updates that are digitally signed by a private key that has been authorized for policy updates by the MDM Server.
Application Note: The intent of this requirement is to cryptographically tie the policies to the enterprise that mandated the policy, not to protect the policies in transit, as this is addressed by other SFRs (FPT_ITT.1/INTER_XFER_AGENT in the MDM Base PP or the Additional SFR FTP_ITC_EXT.1/MDFCHANNEL or FTP_ITC_EXT.1/OSCHANNEL, depending on the claimed Base-PP). This is especially critical for users who connect to multiple enterprises.

Policies must be digitally signed by the enterprise using the algorithms in FCS_COP.1/SIGN_ALG in the MDM PP.

The signing private key is associated with a certificate or raw public key used by the MDM Agent to verify the signature on the policy.
The MDM Agent shall not install policies if the signature check fails.

FMT_SMF_EXT.4 Specification of Management Functions

The MDM Agent shall be capable of interacting with the platform to perform the following functions:
  • [selection: import the certificates to be used for authentication of MDM Agent communications, import the server public key],
  • [selection: administrator-provided management functions in MDF PP, administrator-provided device management functions in MDM PP, administrator-provided device management functions in GPOS PP]
  • [selection: [assignment: additional functions], no additional functions].
Application Note: This requirement captures all the configuration functionality in the MDM Agent to configure the underlying mobile device with the configuration policies sent from the MDM Server to the MDM Agent. The ST author selects the Base-PP (MDF PP, MDM PP, or GPOS PP) as the source of the management functions.

The administrator-provided management functions in the MDF PP are specified in the "Admin Only" column of Table 7 in MDF PP and in FPT_TUD_EXT.1 (for version queries). The administrator-provided device management functions in the MDM PP are specified in FMT_SMF.1/SERVER_CONF_AGENT; the functions in the selection of FMT_SMF.1/SERVER_CONF_AGENT in the MDM PP are required to correspond to the functions available on the platforms supported by the MDM Agent. The administrator-provided management functions in the GPOS PP are specified in FMT_SMF_EXT.1.

The ST author can add more commands and configuration policies by completing the assignment statement; the device must support these additional commands or configuration policies.

The MDM Agent must configure the platform based on the commands and configuration policies received from the MDM Server. The ST author must not claim any functionality not provided by the supported device. All selections and assignments performed by the ST author in this requirement should match the selections and assignments of the validated mobile device or GPOS ST.

The MDM Agent shall be capable of performing the following functions:
  • enroll in management
  • configure whether users can unenroll from management
  • [selection: configure periodicity of reachability events, [assignment: other management functions], no other functions].
Application Note: This requirement captures all of the configuration in the MDM Agent for configuration of itself.

If the MDM Agent is part of a mobile device, enrollment is a single function both of the MDM Agent and of the device (FMT_SMF_EXT.4.1).

If the MDM Agent is an application developed separately from a mobile device or operating system, the MDM Agent performs the function “enroll in management” by registering itself to the mobile device or OS as an administrator. The MDM Agent itself is enrolled in management by configuring the MDM Server to which the MDM Agent answers.

If the MDM Agent does not support unenrollment prevention, remediation actions should be applied upon unenrollment (per FMT_UNR_EXT.1).

If the MDM Agent generates periodic reachability events in FAU_ALT_EXT.2.1 and the periodicity of these events is configurable, “configure periodicity of reachability events” must be selected.

FMT_UNR_EXT.1 User Unenrollment Prevention

The MDM Agent shall provide a mechanism to enforce the following behavior upon an attempt to unenroll the device from management: [selection: prevent the unenrollment from occurring, apply remediation actions].
Application Note: Unenrolling is the action of transitioning from the enrolled state to the unenrolled state. If preventing the user from unenrolling is configurable, administrators configure whether users are allowed to unenroll through the MDM Server.

For those configurations where unenrollment is allowed, for example a BYOD usage, the MDF PP describes remediation actions performed upon unenrollment, such as wiping enterprise data, in FMT_SMF_EXT.2.1. The GPOS PP does not explicitly describe the case of unenrollment but a GPOS has interfaces that an MDM Agent can invoke to perform the desired unenrollment functionality. The MDM Agent is limited to those actions supported by the device on which the MDM Agent is operating.

5.5 TOE Security Functional Requirements Rationale

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

Table 6: SFR Rationale
ThreatAddressed byRationale
T.INSECURE_​MDM_​COMMUNICATIONS
FTP_ITC_EXT.1/MDFCHANNEL (additional to MDF PP)Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for transmission of policies.
FTP_TRP.1/MDFENROLL (additional to MDF PP)Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for enrollment into management.
FTP_ITC_EXT.1/OSCHANNEL (additional to GPOS PP)Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for transmission of policies.
FTP_TRP.1/OSENROLL (additional to GPOS PP)Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for enrollment into management.
T.MISUSED_​DEVICE
FAU_ALT_EXT.2Mitigates the threat of a misused device by causing the generation of alerts based on the usage of the device.
FAU_GEN.1/AGENTMitigates the threat of a misused device by generating audit events regarding the use and behavior of the MDM agent.
FAU_SEL.1/AGENTMitigates the threat of a misused device by allowing the activity that triggers audit events for MDM agent behavior.
FMT_UNR_EXT.1Mitigates the threat of a misused device by preventing the unenrollment of the device from management or by taking some other security-relevant action if unenrollment is performed.
FPT_NET_EXT.1 (implementation-dependent)Mitigates the threat of a misused device by tracking when the device has lost contact with the MDM server as a basis for triggering automatic fail-safe behavior.
FAU_STG_EXT.3 (implementation-dependent)Mitigates the threat of a misused device by using trusted platform storage to protect against destruction of evidence related to misuse.
T.UNAUTHORIZED_​POLICY_​SOURCE
FCS_STG_EXT.4 (additional to MDF PP)Mitigates the threat of an unauthorized policy source by preventing substitution of the valid policy source.
FCS_STG_EXT.1/MDMKEYS (additional to MDM PP)Mitigates the threat of an unauthorized policy source by preventing substitution of the valid policy source.
FIA_ENR_EXT.2Mitigates the threat of an unauthorized policy source by recording the identifier of the MDM server that it enrolled to.
FMT_POL_EXT.2Mitigates the threat of an unauthorized policy source by applying only policies that are digitally signed by an authorized source.
FMT_SMF_EXT.4Mitigates the threat of an unauthorized policy source by requiring authorization by the underlying platform to manage the TSF.

6 Consistency Rationale

6.1 Protection Profile for Mobile Device Fundamentals

6.1.1 Consistency of TOE Type

When this PP-Module is used to extend the MDF PP, the TOE type for the overall TOE is still a mobile device. The TOE boundary is simply extended to include the MDM Agent application that runs on the mobile device.

6.1.2 Consistency of Security Problem Definition

Table 7: Consistency of Security Problem Definition (MDF PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.INSECURE_MDM_COMMUNICATIONSThis threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the Base-PP.
T.MISUSED_DEVICEThis threat exploits issues with local device configuration, consistent with T.PHYSICAL_ACCESS and T.MALICIOUS_APP threats defined in the Base-PP.
T.UNAUTHORIZED_POLICY_SOURCEThis threat exploits malicious configuration which is a mechanism by which the T.PERSISTENT_PRESENCE threat defined in the Base-PP can be realized.
A.CONNECTIVITYThis assumption expects that networking services will be available for the TOE to use. This is consistent with the Base-PP because the TOE is installed on a mobile device defined by the Base-PP, which provides networking services through various radios.
A.PLATFORMThis assumption expects that the TOE’s underlying platform is trustworthy. This is consistent with the Base-PP by definition because a mobile device is within the TOE boundary and is evaluated against the MDF PP.
A.PROPER_ADMIN This assumption expects that the TOE administrator is trusted and competent in configuring the TSF. This assumption is consistent with the A.CONFIG assumption in the Base-PP, which expects the TSF to be configured correctly regardless of the subject performing the configuration.
A.PROPER_USER This assumption expects that the TOE user is not willfully negligent or hostile in using the TSF. This assumption is consistent with the A.CONFIG assumption in the Base-PP, which expects the TSF to be configured correctly regardless of the subject performing the configuration as well as the A.NOTIFY and A.PRECAUTION assumptions which define baseline expectations for the user’s level of responsibility.
P.ACCOUNTABILITYThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.ADMINThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.DEVICE_ENROLLThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.NOTIFYThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.

6.1.3 Consistency of OE Objectives

Table 8: Consistency of OE Objectives (MDF PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.DATA_PROPER_ADMIN This objective extends the Base-PP’s OE.CONFIG objective by expecting that TOE administrators act appropriately when installing or configuring the MDM Agent.
OE.DATA_PROPER_USER This objective extends the Base-PP’s OE.NOTIFY and OE.PRECAUTION objectives by setting reasonable expectations for user security behavior.
OE.IT_ENTERPRISE This objective helps mitigate the T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined by the Base-PP by reducing the network exposure of the mobile device. This does not conflict with the Base-PP because the Base-PP does not set specific expectations for the level of security that the enterprise provides. However, all use cases from the Base-PP set expectations that the mobile device is used for some enterprise purposes so it is reasonable to expect the enterprise have security controls in place to protect these functions.
OE.DEVICE_PLATFORM This objective is suitable because the MDM Agent can reasonably expect the device it has been deployed on to be secure.
OE.WIRELESS_NETWORK This objective is suitable because while the Base-PP does not define any availability metrics for wireless communications, the mobile device will always provide the ability to access a wireless network.

6.1.4 Consistency of Requirements

This PP-Module identifies several SFRs from the MDF PP that are needed to support MDM Agent functionality. This is considered to be consistent because the functionality provided by the MDF PP is being used for its intended purpose. The PP-Module identifies new SFRs that are used entirely to provide functionality for MDM Agent. The rationale for why this does not conflict with the claims defined by the MDF PP are as follows:
Table 9: Consistency of Requirements (MDF PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
This PP-Module does not modify any requirements when the MDF PP is the base.
Additional SFRs
FCS_STG_EXT.4 This SFR requires the MDM Agent to use functionality defined by the Base-PP in FCS_CKM_EXT.1.
FTP_ITC_EXT.1/MDFCHANNEL The Base-PP includes FTP_ITC_EXT.1 to define the secure protocols used for trusted channel communications. This PP-Module iterates the SFR to specify a subset of these protocols that may be used for MDM Agent communications in particular.
FTP_TRP.1/MDFENROLLThis SFR uses the trusted channel protocols defined by the Base-PP in FTP_ITC_EXT.1 to facilitate a trusted path that the MDM Agent can use to enroll the mobile device it runs on into management. Even though the Base-PP does not define FTP_TRP.1, the requirement was given an iteration label for consistency with the MDM Server requirement of the same name.
Mandatory SFRs
FAU_ALT_EXT.2 This SFR requires the MDM Agent to use a trusted channel defined by FTP_ITC_EXT.1 in the Base-PP to transmit data about its own behavior to the OE.
FAU_GEN.1/AGENT The Base-PP includes FAU_GEN.1; this PP-Module iterates the SFR to use the same audit mechanism to generate audit data for the MDM Agent’s behavior. It may alternatively allow the TSF to generate its own audit trail, which does not impede the MDF from enforcing its own security functionality.
FAU_SEL.1/AGENT The Base-PP includes FAU_SEL.1; this PP-Module iterates the SFR to use the same audit mechanism to select the auditable events to be generated by the MDM Agent. Note that the Base-PP does not mandate this requirement so it is possible that only the MDM Agent portion of the TOE may implement it. In this case, the SFR provides a selection for the MDM Agent to implement its own mechanism to perform this function rather than a platform-provided one.
FIA_ENR_EXT.2 This SFR requires the MDM Agent to record data that it receives from the OE. It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP.
FMT_POL_EXT.2 This SFR requires the MDM Agent to use a digital signature algorithm to validate data that it receives from the OE. To do this, the MDM Agent will use the functionality defined by the Base-PP in FCS_COP.1/SIGN.
FMT_SMF_EXT.4 This SFR defines the ability of the MDM Agent to interact with the mobile device to execute the management functions defined by FMT_MOF_EXT.1 in the Base-PP. The Base-PP specifically indicates in FMT_MOF_EXT.1.2 that some management functions may be performed via MDM.
FMT_UNR_EXT.1 This SFR defines the functions performed by the MDM Agent when unenrolled from an MDM. The Base-PP defines unenrollment actions in FMT_SMF_EXT.2, and goes on to note that these actions may be performed “perhaps via an MDM Agent,” so this is expected behavior.
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
FAU_STG_EXT.3 This SFR defines the ability of the MDM Agent to store generated audit data in the audit storage provided by the mobile device. The Base-PP defines the capability for audit storage in FAU_STG.2.
FPT_NET_EXT.1 This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FTP_ITC_EXT.1 of the Base-PP). It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP.
Selection-based SFRs
This PP-Module does not define any Selection-based requirements.

6.2 Protection Profile for Mobile Device Management

6.2.1 Consistency of TOE Type

When this PP-Module is used to extend the MDM PP, the TOE type for the overall TOE is still mobile device management. The TOE boundary is simply extended to include the MDM Agents that reside on individual mobile devices and support the management functionality that the MDM Server component implements.

6.2.2 Consistency of Security Problem Definition

Table 10: Consistency of Security Problem Definition (MDM PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.INSECURE_MDM_COMMUNICATIONSThis threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the Base-PP.
T.MISUSED_DEVICEThis threat exploits issues with configuration of the managed device, consistent with the T.MALICIOUS_APPS threat defined in the Base-PP.
T.UNAUTHORIZED_POLICY_SOURCEThis threat exploits impersonation of a legitimate policy source, which is consistent with the T.NETWORK_ATTACK threat defined in the Base-PP.
A.CONNECTIVITYThis assumption expects that networking services will be available for the TOE to use. This is consistent with the Base-PP because the portion of the TOE defined by the Base-PP runs on a GPOS or specialized network appliance. The Base-PP does not make any assumptions about the environmental functionality that this PP-Module relies on, so there is nothing in this PP-Module that would contradict it.
A.PLATFORMThis assumption expects that the TOE’s underlying hardware platform is appropriately secure. This is consistent with the Base-PP because the portion of the TOE defined by the Base-PP runs on a GPOS or specialized network appliance. The Base-PP does not make any assumptions about the environmental functionality that this PP-Module relies on, so there is nothing in this PP-Module that would contradict it.
A.PROPER_ADMIN The Base-PP defines an A.PROPER_ADMIN assumption that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.
A.PROPER_USER The Base-PP defines an A.PROPER_USER assumption that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.
P.ACCOUNTABILITYThe Base-PP defines a P.ACCOUNTABILITY OSP that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.
P.ADMINThe Base-PP defines a P.ADMIN OSP that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.
P.DEVICE_ENROLL The Base-PP defines a P.DEVICE_ENROLL OSP that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.
P.NOTIFYThe Base-PP defines a P.NOTIFY OSP that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server.

6.2.3 Consistency of OE Objectives

Table 11: Consistency of OE Objectives (MDM PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.DATA_PROPER_ADMIN The MDM PP contains an objective named OE.PROPER_ADMIN with the same purpose.
OE.DATA_PROPER_USER The MDM PP contains an objective named OE.PROPER_USER with the same purpose.
OE.IT_ENTERPRISE The MDM PP contains this same objective with the same purpose.
OE.DEVICE_PLATFORMThe MDM PP environmental security objectives only relate to the security of the platform on which the MDM Server portion of the TOE is running. This objective extends the scope of the trusted platform to MDM Agent devices.
OE.WIRELESS_NETWORKThe MDM PP contains this same objective with the same purpose.

6.2.4 Consistency of Requirements

This PP-Module identifies several SFRs from the MDM PP that are needed to support MDM Agent functionality. This is considered to be consistent because the functionality provided by the MDM PP is being used for its intended purpose. The PP-Module identifies new SFRs that are used entirely to provide functionality for MDM Agent. The rationale for why this does not conflict with the claims defined by the MDM PP are as follows:
Table 12: Consistency of Requirements (MDM PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FPT_ITT.1/INTER_XFER_AGENTThere is no modification to this SFR, but it is mandatory for a TOE that conforms to this PP-Module because it must always be claimed when an MDM includes an MDM Agent as part of the TOE.
FTP_ITC_EXT.1This SFR is modified in a way that accommodates an MDM Agent, which is part of the TOE boundary when this PP-Module is claimed.
Additional SFRs
FCS_STG_EXT.1/MDMKEYS The Base-PP requires the TOE to define a method of key storage. This PP-Module iterates it to specify the use of platform key storage for MDM Agents.
Mandatory SFRs
FAU_ALT_EXT.2 This SFR provides the alerts that are received by the MDM Server as per FAU_ALT_EXT.1 in the Base-PP.
FAU_GEN.1/AGENT This SFR requires the MDM Agent to generate audit data of its behavior. The mechanism by which it does this is not relevant to the MDM Server portion of the TOE as they reside on different platforms.
FAU_SEL.1/AGENT The Base-PP includes FAU_SEL.1 as an optional SFR to limit the audit events that are generated by the TSF. This PP-Module adds another iteration that requires the MDM Agent to include this capability by default.
FIA_ENR_EXT.2 This SFR provides information during MDM Agent enrollment that is required by the MDM Server to meet the FIA_ENR_EXT.1 requirement defined by the Base-PP.
FMT_POL_EXT.2 The Base-PP includes an SFR (FMT_POL_EXT.1) that requires the MDM Server to provide digitally signed policies and policy updates to the MDM Agent. FMT_POL_EXT.2 completes this transaction by requiring the MDM Agent to accept only signed policies and policy updates.
FMT_SMF_EXT.4 This SFR requires the MDM Agent to interact with the underlying mobile device platform to enforce management functions that are configured by the MDM Server (FMT_SMF.1/SERVER_CONF_AGENT in the Base-PP).
FMT_UNR_EXT.1 This SFR requires the TSF to define its behavior upon unenrollment from management. Unenrollment from management is a management function that is specified in the Base-PP.
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
FAU_STG_EXT.3 This SFR defines the ability of the MDM Agent to store generated audit data in the audit storage provided by the mobile device. This does not impact the Base-PP since it resides on a different platform from the MDM Agent.
FPT_NET_EXT.1 This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FPT_ITT.1/INTER_XFER_AGENT of the Base-PP). It does not otherwise impact the Base-PP since it describes behavior that occurs local to the MDM Agent during a period where it is not interacting with the MDM Server.
Selection-based SFRs
This PP-Module does not define any Selection-based requirements.

6.3 Protection Profile for General Purpose Operating System

6.3.1 Consistency of TOE Type

When this PP-Module is used to extend the GPOS PP, the TOE type for the overall TOE is still a GPOS. The TOE boundary is simply extended to include the MDM Agent application that runs on that GPOS platform.

6.3.2 Consistency of Security Problem Definition

Table 13: Consistency of Security Problem Definition (GPOS PP base)
PP-Module Threat, Assumption, OSPConsistency Rationale
T.INSECURE_MDM_COMMUNICATIONSThis threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the Base-PP.
T.MISUSED_DEVICEThis threat exploits issues with local device configuration, consistent with the T.LOCAL_ATTACK threat defined in the Base-PP.
T.UNAUTHORIZED_POLICY_SOURCEThis threat exploits malicious configuration which can enable a local attack, consistent with the T.LOCAL_ATTACK threat defined in the Base-PP can be realized.
A.CONNECTIVITYThis assumption expects that networking services will be available for the TOE to use. This is consistent with the Base-PP because the Base-PP includes mandatory requirements for a GPOS that have network connectivity as a prerequisite.
A.PLATFORMThis assumption expects that the TOE’s underlying platform is sufficiently trusted. This is consistent with the Base-PP by definition because the OS is within the TOE boundary and evaluated against the GPOS PP.
A.PROPER_ADMIN The GPOS PP contains this same assumption with the same purpose.
A.PROPER_USER The GPOS PP contains this same assumption with the same purpose.
P.ACCOUNTABILITYThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.ADMINThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.DEVICE_ENROLLThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.
P.NOTIFYThe Base-PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the Base-PP by definition.

6.3.3 Consistency of OE Objectives

Table 14: Consistency of OE Objectives (GPOS PP base)
PP-Module OE ObjectiveConsistency Rationale
OE.DATA_PROPER_ADMINThis objective extends the Base-PP’s OE.PROPER_ADMIN objective by expecting that TOE administrators act appropriately when installing or configuring the MDM Agent.
OE.DATA_PROPER_USER This objective extends the Base-PP’s OE.PROPER_USER objective by setting reasonable expectations for user security behavior.
OE.IT_ENTERPRISE This objective helps mitigate the T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined by the Base-PP by reducing the network exposure of the operating system. This does not conflict with the Base-PP because the Base-PP does not set specific expectations for the level of security that the enterprise provides. However, all use cases from the Base-PP set expectations that the operating system is used for some enterprise purposes so it is reasonable to expect the enterprise have security controls in place to protect these functions.
OE.DEVICE_PLATFORMThis extends the OE.PLATFORM objective from the Base-PP to cover that the underlying platform of the MDM Agent is trusted.
OE.WIRELESS_NETWORK This objective is suitable because while the Base-PP does not define any availability metrics for wireless communications, it can be extended by a PP-Module for WLAN client capabilities, so support for wireless communications is a reasonable expectation for a GPOS.

6.3.4 Consistency of Requirements

This PP-Module identifies several SFRs from the GPOS PP that are needed to support MDM Agent functionality. This is considered to be consistent because the functionality provided by the GPOS PP is being used for its intended purpose. The PP-Module identifies new SFRs that are used entirely to provide functionality for MDM Agent. The rationale for why this does not conflict with the claims defined by the GPOS PP are as follows:
Table 15: Consistency of Requirements (GPOS PP base)
PP-Module RequirementConsistency Rationale
Modified SFRs
FCS_STO_EXT.1The PP-Module does not change this SFR; it only notes that the concept of "sensitive data" may be expanded to include any sensitive data created or used by the portion of the TOE described by the PP-Module.
Additional SFRs
FTP_ITC_EXT.1/OSCHANNEL The Base-PP includes FTP_ITC_EXT.1 to define the secure protocols used for trusted channel communications. This PP-Module iterates the SFR to specify a subset of these protocols that may be used for MDM Agent communications in particular.
FTP_TRP.1/OSENROLLThis SFR uses the trusted channel protocols defined by the Base-PP in FTP_ITC_EXT.1 to facilitate a trusted path that the MDM Agent can use to enroll the operating system it runs on into management. The GPOS PP already defines an iteration of this SFR for trusted administration, so this SFR is iterated to illustrate that this trusted path is used for a distinct function.
Mandatory SFRs
FAU_ALT_EXT.2 This SFR requires the MDM Agent to use a trusted channel defined by FTP_ITC_EXT.1 in the Base-PP to transmit data about its own behavior to the OE.
FAU_GEN.1/AGENTThe Base-PP defines FAU_GEN.1; this PP-Module iterates the SFR to use the same audit mechanism to generate audit data for the MDM Agent’s behavior. It may alternatively allow the TSF to generate its own audit trail, which does not impede the MDF from enforcing its own security functionality.
FAU_SEL.1/AGENTThis SFR requires the TSF to have the ability to limit the auditable events it generates for MDM Agent functionality. Since this applies exclusively to MDM Agent functionality, it does not conflict with the Base-PP events which must always be audited.
FIA_ENR_EXT.2 This SFR requires the MDM Agent to record data that it receives from the OE. It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP.
FMT_POL_EXT.2 This SFR requires the MDM Agent to use a digital signature algorithm to validate data that it receives from the OE. To do this, the MDM Agent will use the functionality defined by the Base-PP in FCS_COP.1/SIGN.
FMT_SMF_EXT.4 This SFR defines the ability of the MDM Agent to interact with the underlying operating system to execute the management functions defined by FMT_MOF_EXT.1 in the Base-PP. The Base-PP does not preclude administration being performed in this manner.
FMT_UNR_EXT.1 This SFR defines the functions performed by the MDM Agent when unenrolled from an MDM. The Base-PP defines FMT_SMF_EXT.1 which allows for assigned management functions to be specified. This can include unenrollment behavior as defined by FMT_UNR_EXT.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
FAU_STG_EXT.3 This SFR defines the ability of the MDM Agent to store generated audit data in platform-provided audit storage. The Base-PP defines the capability for audit storage in FDP_ACF_EXT.1.
FPT_NET_EXT.1 This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FTP_ITC_EXT.1 of the Base-PP). It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP.
Selection-based SFRs
This PP-Module does not define any Selection-based requirements.

Appendix A - Optional SFRs

A.1 Strictly Optional Requirements

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

A.2 Objective Requirements

This PP-Module does not define any Objective SFRs.

A.3 Implementation-dependent Requirements

A.3.1 Auditable Events for Implementation-Dependent SFRs

Table 16: Auditable Events for Implementation-dependent Requirements
RequirementAuditable EventsAdditional Audit Record Contents
FAU_STG_EXT.3
No events specifiedN/A
FPT_NET_EXT.1
MDM Server connection reaching or exceeding unavailability threshold.No additional information.

A.3.2 Security Audit (FAU)

FAU_STG_EXT.3 Security Audit Event Storage

This component must be included in the ST if the TOE implements any of the following features:
The MDM Agent shall store MDM audit records in the platform-provided audit storage.

A.3.3 Protection of the TSF (FPT)

FPT_NET_EXT.1 Network Reachability

This component must be included in the ST if the TOE implements any of the following features:
The TSF shall detect when a configurable [selection: positive integer of missed reachability events occur, time limit is exceeded] related to when the last successful connection with the server has been reached.

Appendix B - Selection-based Requirements

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

Appendix C - Extended Component Definitions

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

C.1 Extended Components Table

All extended components specified in the PP-Module are listed in this table:
Table 17: Extended Component Definitions
Functional ClassFunctional Components
Cryptographic Support (FCS)FCS_STG_EXT Trusted Channel
Identification and Authentication (FIA)FIA_ENR_EXT Enrollment
Protection of the TSF (FPT)FPT_NET_EXT Network Reachability
Security Audit (FAU)FAU_ALT_EXT MDM Alerts
FAU_STG_EXT Protected Audit Event Storage
Security Management (FMT)FMT_POL_EXT Trusted Policy Update
FMT_SMF_EXT Specification of Management Functions
FMT_UNR_EXT Unenrollment

C.2 Extended Component Definitions

C.2.1 Cryptographic Support (FCS)

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

C.2.1.1 FCS_STG_EXT Trusted Channel

This family is defined in both the MDF and the MDM Base-PPs. This PP-Module augments the extended family by adding one additional component, FCS_STG_EXT.4 as an additional SFR for MDF. This new component and its impact on the extended family’s component leveling are shown below; reference the MDF or MDM PP for all other definitions for this family.

FCS_STG_EXT.4, Cryptographic Key Storage, requires the TSF to define a specific location for its key storage.

Management: FCS_STG_EXT.4

There are no management functions foreseen.

Audit: FCS_STG_EXT.4

There are no auditable events foreseen.

FCS_STG_EXT.4 Cryptographic Key Storage

Hierarchical to:No other components.
Dependencies to:FCS_CKM.1 Cryptographic Key Generation

FCS_STG_EXT.4.1

The MDM Agent shall use the platform provided key storage for all persistent secret and private keys.

C.2.2 Identification and Authentication (FIA)

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

C.2.2.1 FIA_ENR_EXT Enrollment

This family is defined in the MDM Base-PP. This PP-Module augments the extended family by adding one additional component, FIA_ENR_EXT.2. This new component and its impact on the extended family’s component leveling are shown below; reference the MDM PP for all other definitions for this family.

FIA_ENR_EXT.2, Agent Enrollment of Mobile Device into Management, requires the TSF to record specific information about the MDM Server (i.e., the entity that is enrolling it) during the enrollment process.

Management: FIA_ENR_EXT.2

There are no management functions foreseen.

Audit: FIA_ENR_EXT.2

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Completion of enrollment process.

FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management

Hierarchical to:No other components.
Dependencies to:FIA_ENR_EXT.1 Enrollment of Mobile Device into Management

FIA_ENR_EXT.2.1

The MDM Agent shall record the reference identifier of the MDM Server during the enrollment process.

C.2.3 Protection of the TSF (FPT)

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

C.2.3.1 FPT_NET_EXT Network Reachability

Family Behavior

Components in this family define requirements for tracking the availability of network components.

Component Leveling

FPT_NET_EXT1

FPT_NET_EXT.1, Network Reachability, requires the TSF to keep track of failed attempts to communicate with a remote entity.

Management: FPT_NET_EXT.1

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

  • Configuration of unreachability threshold.

Audit: FPT_NET_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Reaching or exceeding unreachability threshold.

FPT_NET_EXT.1 Network Reachability

Hierarchical to:No other components.
Dependencies to:FPT_STM.1 Reliable Time Stamps

FPT_NET_EXT.1.1

The TSF shall detect when a configurable [selection: positive integer of missed reachability events occur, time limit is exceeded] related to when the last successful connection with the server has been reached.

C.2.4 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.4.1 FAU_ALT_EXT MDM Alerts

This family is defined in the MDM Base-PP. This PP-Module augments the extended family by adding one additional component, FAU_ALT_EXT.2. This new component and its impact on the extended family’s component leveling are shown below; reference the MDM PP for all other definitions for this family.

FAU_ALT_EXT.2, Agent Alerts, requires the TSF to define when and how an MDM Agent generates alerts and transmits them to an MDM Server based on its activity.

Management: FAU_ALT_EXT.2

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

  • Ability to configure the specific events that result in generation of alerts.

Audit: FAU_ALT_EXT.2

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Success or failure of sending alert.

FAU_ALT_EXT.2 Agent Alerts

Hierarchical to:No other components.
Dependencies to: FAU_ALT_EXT.1 Server Alerts
[FPT_ITT.1 Basic Internal TSF Data Transfer Protection; or
FTP_ITC.1 Inter-TSF Trusted Channel]

FAU_ALT_EXT.2.1

The MDM Agent shall provide an alert via the trusted channel to the MDM Server in the event of any of the following audit events:
  • successful application of MDM policies,
  • [selection: receiving, generating] periodic reachability events,
  • [selection:
    • change in enrollment state
    • failure to install an application from the MAS Server
    • failure to update an application from the MAS Server
    • [assignment: other events]
    • no other events
    ].

FAU_ALT_EXT.2.2

The MDM Agent shall queue alerts if the trusted channel is not available.

C.2.4.2 FAU_STG_EXT Protected Audit Event Storage

This family is defined in the MDM Base-PP. This PP-Module augments the extended family by adding one additional component, FAU_STG_EXT.3. This new component and its impact on the extended family’s component leveling are shown below; reference the MDM PP for all other definitions for this family.

FAU_STG_EXT.3, Security Audit Event Storage, requires the TSF to identify a location for audit record storage and the events that are stored at this location.

Management: FAU_STG_EXT.3

There are no management functions foreseen.

Audit: FAU_STG_EXT.3

There are no auditable events foreseen.

FAU_STG_EXT.3 Security Audit Event Storage

Hierarchical to:No other components.
Dependencies to:FAU_GEN.1 Audit Data Generation

FAU_STG_EXT.3.1

The MDM Agent shall store MDM audit records in the platform-provided audit storage.

C.2.5 Security Management (FMT)

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

C.2.5.1 FMT_POL_EXT Trusted Policy Update

This family is defined in the MDM Base-PP. This PP-Module augments the extended family by adding one additional component, FMT_POL_EXT.2. This new component and its impact on the extended family’s component leveling are shown below; reference the MDM PP for all other definitions for this family.

FMT_POL_EXT.2, Agent Trusted Policy Update, requires the TSF to verify the validity of the source of a policy before applying it.

Management: FMT_POL_EXT.2

There are no management functions foreseen.

Audit: FMT_POL_EXT.2

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Failure to validate policy.

FMT_POL_EXT.2 Agent Trusted Policy Update

Hierarchical to:No other components.
Dependencies to:FCS_COP.1 Cryptographic Operation
FMT_POL_EXT.1 Trusted Policy Update

FMT_POL_EXT.2.1

The MDM Agent shall only accept policies and policy updates that are digitally signed by a private key that has been authorized for policy updates by the MDM Server.

FMT_POL_EXT.2.2

The MDM Agent shall not install policies if the signature check fails.

C.2.5.2 FMT_SMF_EXT Specification of Management Functions

This family is defined in the MDF Base-PP. This PP-Module augments the extended family by adding one additional component, FMT_SMF_EXT.4. This new component and its impact on the extended family’s component leveling are shown below; reference the MDF PP for all other definitions for this family.

FMT_SMF_EXT.4, Specification of Management Functions, requires the TSF to support the execution of certain management functions that require interfacing with other TOE components.

Management: FMT_SMF_EXT.4

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

  • Execution of management functions.
  • Configuration of management functions behavior.

Audit: FMT_SMF_EXT.4

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Successful and failed execution of management functions.

FMT_SMF_EXT.4 Specification of Management Functions

Hierarchical to:No other components.
Dependencies to:FCS_CKM.1 Cryptographic Key Generation

FMT_SMF_EXT.4.1

The MDM Agent shall be capable of interacting with the platform to perform the following functions:
  • [selection: import the certificates to be used for authentication of MDM Agent communications, import the server public key],
  • [selection: administrator-provided management functions in MDF PP, administrator-provided device management functions in MDM PP, administrator-provided device management functions in GPOS PP]
  • [selection: [assignment: additional functions], no additional functions].

FMT_SMF_EXT.4.2

The MDM Agent shall be capable of performing the following functions:
  • enroll in management
  • configure whether users can unenroll from management
  • [selection: configure periodicity of reachability events, [assignment: other management functions], no other functions].

C.2.5.3 FMT_UNR_EXT Unenrollment

Family Behavior

Components in this family define requirements for TSF behavior when a user attempts to unenroll the TOE from an MDM.

Component Leveling

FMT_UNR_EXT1

FMT_UNR_EXT.1, User Unenrollment Prevention, requires the TSF either to prevent unenrollment entirely or to take some corrective action in the event that an unenrollment is initiated.

Management: FMT_UNR_EXT.1

There are no management functions foreseen.

Audit: FMT_UNR_EXT.1

The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:

  • Minimal: Unenrollment from MDM.

FMT_UNR_EXT.1 User Unenrollment Prevention

Hierarchical to:No other components.
Dependencies to: [FIA_ENR_EXT.1 Enrollment of Mobile Device into Management; or
FMT_MOF_EXT.1 Management of Functions Behavior]

FMT_UNR_EXT.1.1

The MDM Agent shall provide a mechanism to enforce the following behavior upon an attempt to unenroll the device from management: [selection: prevent the unenrollment from occurring, apply remediation actions].

Appendix D - Implicitly Satisfied Requirements

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

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

Table 18: Implicitly Satisfied Requirements
Requirement Rationale for Satisfaction
FMT_MTD.1 - Management of TSF Data FAU_SEL.1 has a dependency on FMT_MTD.1 because the configuration settings that determine what events are audited is considered to be TSF data. While FAU_SEL.1 determines the extent to which the TOE’s audit function is configured, it relies on FMT_MTD.1 to determine the administrative roles that are permitted to manipulate this data.

This is not applicable to the PP-Module because there is no management interface for a TOE user to interact with; instead, all management functions are initiated by an MDM Server and performed by the MDM Agent that has sufficient privileges on the underlying device to do this. In this case, FIA_ENR_EXT.2 and FMT_POL_EXT.2 are sufficient to validate that the source of the policy data is identified and authenticated before the policy change is accepted. It is not necessary to define a management role associated with this function because the MDM Server does not need to assume a ‘role’ on the TOE to communicate policy data; it is sufficient for the TSF to determine the policy is genuine.
FPT_STM.1 - Reliable Time Stamps Regardless of whether the MDM Agent is part of an MDM Server or mobile device TOE, the MDM Agent itself will be installed on a device. If the mobile device is part of the TOE, the MDF PP that it conforms to explicitly defines FPT_STM.1, which therefore satisfies the dependency in this case. If the mobile device is not part of the TOE, a reliable time source can still be assumed because all mobile devices must include some method to update time data from a cellular carrier network, and can also reasonably be assumed to include a method to update network time if it is instead connected to a network via WLAN radio (such as when in airplane mode).

Appendix E - Use Case Templates

E.1 Enterprise-owned device for general-purpose enterprise use

The use case [USE CASE 1] Enterprise-owned device for general-purpose enterprise use makes no changes to the base requirements.

E.2 Enterprise-owned device for specialized, high-security use

The configuration for [USE CASE 2] Enterprise-owned device for specialized, high-security use modifies the base requirements as follows:
From FAU_ALT_EXT.2.1:
* select change in enrollment state
From FMT_UNR_EXT.1.1:
* select prevent the unenrollment from occurring

E.3 Personally owned device for personal and enterprise use

The configuration for [USE CASE 3] Personally owned device for personal and enterprise use modifies the base requirements as follows:
From FMT_UNR_EXT.1.1:
* select apply remediation actions

E.4 Personally owned device for personal and limited enterprise use

The use case [USE CASE 4] Personally owned device for personal and limited enterprise use makes no changes to the base requirements.

Appendix F - Acronyms

Table 19: Acronyms
AcronymMeaning
APIApplication Programming Interface
Base-PPBase Protection Profile
BYODBring Your Own Device
CCCommon Criteria
CEMCommon Evaluation Methodology
cPPCollaborative Protection Profile
DNDistinguished Name
DTLSDatagram Transport Layer Security
EPExtended Package
FPFunctional Package
GPOSGeneral Purpose Operating System
HTTPSHypertext Transfer Protocol Secure
MASMobile Application Store
MDFMobile Device Fundamentals
MDMMobile Device Management
OEOperational Environment
OSOperating System
PPProtection Profile
PP-ConfigurationProtection Profile Configuration
PP-ModuleProtection Profile Module
SARSecurity Assurance Requirement
SFRSecurity Functional Requirement
STSecurity Target
TLSTransport Layer Security
TOETarget of Evaluation
TSFTOE Security Functionality
TSSTOE Summary Specification

Appendix G - Bibliography

Table 20: Bibliography
IdentifierTitle
[CC]Common Criteria for Information Technology Security Evaluation -
[CEM]Common Methodology for Information Technology Security Evaluation -
[GPOS PP]Protection Profile for General Purpose Operating Systems, Version 4.3, September 27, 2022
[MDF PP]Protection Profile for Mobile Device Fundamentals, Version 3.3, September 12, 2022
[MDM PP] Protection Profile for Mobile Device Management, Version 4.0, April 25, 2019