2.0 National Information Assurance Partnership 2025-01-31 Mobile Device Management; MDM; MDM Agents 1.0 2019-03-01 Initial publication as PP-Module. 1.1 2023-12-11 Added PP_GPOS base and incorporated NIAP Technical Decisions. 2.0 2026-04-14 Converted to CC:2022 and incorporated NIAP Technical Decisions. Moved FAU_SEL.1/AGENT to optional. TDs Applied https://github.com/commoncriteria/tls master https://www.niap-ccevs.org/static_html/protection-profile/439/-439-/index.html https://github.com/commoncriteria/X509 master https://www.niap-ccevs.org/protectionprofiles/511

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: Protection Profile for Mobile Device Management (PP_MDM), Version 5.0 Protection Profile for Mobile Device Fundamentals (PP_MDF), Version 4.0 Protection Profile for General Purpose Operating Systems (PP_GPOS), Version 5.0 These s 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.

TSF Interface The person who is responsible for management activities, including setting the policy that is applied by the enterprise on the device. The state in which a device is managed by a policy from an MDM. A class of OSes designed to support a wide-variety of workloads consisting of many concurrent applications or services. Typical characteristics for OSes in this class include support for third-party applications, support for multiple users, and security separation between users and their respective resources. General Purpose Operating Systems also lack the real-time constraint that defines Real Time Operating Systems which are typically used in routers, switches, and embedded devices. A device enrolled and managed, or to be enrolled and managed, by an MDM system. This device is a mobile device typically evaluated under PP_MDF or a device utilizing a GPOS typically evaluated under PP_GPOS. 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. A device which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other MDs. 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. The person who uses and is held responsible for a managed device. Synonymous with 'local user' in the context of a managed device. 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. The state in which a device is not managed by an MDM system. See Managed Device User.

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 PP_MDF, PP_MDM, or PP_GPOS. 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 PP_MDF if the TOE is a native part of a mobile operating system. The TOE for this PP-Module combined with PP_MDF is the mobile device itself plus the MDM agent. If the MDM agent is part of the MD’s OS, the MDM agent may present multiple interfaces for configuring the MD, 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 PP_MDM 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 PP_MDM 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 PP_GPOS so that its baseline security capabilities can be assumed to be present. This PP-Module shall build on PP_GPOS if the TOE is a native part of a non-mobile GPOS. The TOE for this PP-Module combined with PP_GPOS 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.

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

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 PP_MDF and PP_GPOS, respectively.

This PP-Module defines four use cases: 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. 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. change-in-enrollment-state prevent-unenrollment 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. apply-remediation 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.

This section contains selections and assignments that are required when the listed Functional Packages are claimed by this PP-Module. Package Usage guidance defined in the TOE's relevant base PP applies to the usage of the packages for this module, unless explicitly stated otherwise in this section. This usage requirement applies to all implementations of TLS that support the MDM enrollment and MDM communication channels. In order to support the objectives of these channels, the ST author shall claim support for TLS or DTLS as a client. The selection shall correspond with the protocol(s) selected in any of the following SFRS: FTP_ITC_EXT.1.1/MDFCHANNEL, FTP_TRP.1/MDFENROLL, FTP_ITC_EXT.1.1/OSCHANNEL, FTP_TRP.1/OSENROLL. dummy-ref-id The communication channel for MDM traffic following enrollment (as defined in FTP_ITC_EXT.1/MDFCHANNEL and FTP_ITC_EXT.1/OSCHANNEL) requires the use of mutually authenticated TLS or DTLS client functionality. Since the TOE is expected to rely on the cryptographic protocol functionality defined in the claimed base PP, the ST author shall ensure that mutual authentication is included in the TLS or DTLS client claims made as part of conformance to the base PP. Depending on the base PP, this may already be required. dummy-ref-id

If the TOE implements the following features, then the SFRs associated with the features must be claimed. If the TOE is deployed on a mobile device or GPOS platform (i.e., the TOE does not use PP_MDM as its base PP), it is expected to rely on the underlying platform for secure storage of its audit records. 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 PP_MDM). This feature applies if either the TOE claims PP_MDM 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 PP_MDM and that MDM server's ST claims management function 56.

exact extended extended Protection Profile for General Purpose Operating Systems, Version 5.0 Protection Profile for Mobile Device Fundamentals, Version 4.0 Protection Profile for Mobile Device Management, Version 5.0 PP-Module for VPN Client, version 3.0 PP-Module for Bluetooth, version 2.0 PP-Module for WLAN Client, version 2.0 cPP-Module for Biometric Enrolment and Verification, version 2.0 Functional Package for Transport Layer Security Version 2.1 Functional Package for X.509 Version 1.0 The following threats are specific to MDM agents, and represents an addition to those identified in the base PPs. 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. FTP_ITC_EXT.1/MDFCHANNEL (additional to PP_MDF)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 PP_MDF)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 PP_GPOS)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 PP_GPOS)Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for enrollment into management. A malicious or careless user may operate a MD in such a way that it compromises the security of the device, its data, or its user. 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. 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. FAU_SEL.1/AGENT (optional)Mitigates the threat of a misused device by allowing the activity that triggers audit events for MDM agent behavior. 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. 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. FCS_STG_EXT.4 (additional to PP_MDF)Mitigates the threat of an unauthorized policy source by preventing substitution of the valid policy source. FCS_STG_EXT.1/MDMKEYS (additional to PP_MDM)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.

The TOE relies on network connectivity to carry out its management activities. The TOE will robustly handle instances when connectivity is unavailable or unreliable. The OE objective OE.WIRELESS_NETWORK is realized through A.CONNECTIVITY. 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. The OE objective OE.DEVICE_PLATFORM is realized through A.PLATFORM. 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. The OE objective OE.DATA_PROPER_ADMIN is realized through A.PROPER_ADMIN. Users are not willfully negligent or hostile, and use the device within compliance of a reasonable enterprise security policy. The OE objective OE.DATA_PROPER_USER is realized through A.PROPER_USER.

Personnel operating the TOE shall be accountable for their actions within the TOE. The use of a trusted device platform will include the necessary mechanisms to record user actions. The configuration of the device's security functions must adhere to the enterprise security policy. An environment that empowers only trusted administrators will satisfy the policy that the device is configured correctly. The MDM administrator must enroll a device for a specific user prior to it being used in the enterprise network. An environment that empowers only trusted administrators will satisfy the policy that the device is enrolled into management. The use of an enterprise IT network enables the infrastructure to facilitate device enrollment. 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. An environment with trained and trusted users can be expected to adhere to this policy.

TOE administrators are trusted to follow and apply all administrator guidance in a trusted manner. Device users are trained to securely use the device running the MDM agent and apply all guidance in a trusted manner. 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. 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. A wireless network will be available to devices running the MDM agent.

https://github.com/commoncriteria/mobile-device release-4.0 https://www.niap-ccevs.org/static_html/protection-profile/468/MDF%203.3%20PP/index.html

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 PP_MDM for all other definitions for this family. This SFR requires the MDM agent to use functionality defined by the base PP in FCS_CKM_EXT.1. requires the TSF to define a specific location for its key storage. There are no management functions foreseen. There are no auditable events foreseen. FCS_CKM.1 Cryptographic Key Generation 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. The evaluator shall verify that the TSS lists each persistent secret (credential, secret keys, authentication tokens) and private keys needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and, for each platform listed as supported in the ST, how it is stored. The evaluator shall verify that the MDM agent calls a platform-provided API to store persistent secrets and private keys. There are no guidance EAs for this component. There are no test EAs for this component. 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. 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 PP_MDF 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 PP_MDF. 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. Protocol, RBG, certificate validation, algorithm, and similar services may be met with platform provided services. For all other use cases, the mobile device initiates the communication; however, for MDM agents, the MDM server may also initiate communication. This element is iterated from PP_MDF; 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. The evaluator shall examine the TSS to determine that the methods of communication between the MDM agent and MDM server (and MAS server, if claimed) are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of remote TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions for configuring the communication channel between the MDM agent and the MDM server and conditionally, the MAS server for each supported method. For each supported identifier type (excluding Distinguished Names [DNs], the evaluator shall repeat the following tests: The evaluator shall ensure that communications using each method that is specified in the operational guidance is tested during the course of the evaluation, connections are set up as described in the operational guidance, and that communication is successful. The evaluator shall ensure, for each method of communication between the MDM server (and MAS server, if claimed), the channel data is not sent in plaintext. The evaluator shall ensure, for each communication channel with the MDM server (and MAS server, if claimed), that a protocol analyzer identifies the traffic as the protocol under testing. Further evaluation activities are associated with the specific protocols. 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. This 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. 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 PP_MDF, 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. The evaluator shall examine the TSS to determine that the methods of remote enrollment are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of enrollment are consistent with those specified in the requirement, and are included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions for establishing the enrollment sessions for each supported method. For each enrollment method that the ST claims: The evaluator shall ensure that communications using each specified (in the operational guidance) enrollment method is tested during the course of the evaluation, setting up the connections as described in the operational guidance, and ensuring that communication is successful. For each method of enrollment supported, the evaluator shall follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish enrollment sessions without invoking the trusted path. The evaluator shall ensure, for each method of enrollment, the channel data is not sent in plaintext. Further evaluation activities are associated with the specific protocols. 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. When this PP-Module is used to extend PP_MDF, 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. This threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the base PP. This threat exploits issues with local device configuration, consistent with T.PHYSICAL_ACCESS and T.MALICIOUS_APP threats defined in the base PP. This threat exploits malicious configuration which is a mechanism by which the T.PERSISTENT_PRESENCE threat defined in the base PP can be realized. This 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. This 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 PP_MDF. 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. 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. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. This objective extends the base PP’s OE.CONFIG objective by expecting that TOE administrators act appropriately when installing or configuring the MDM agent. This objective extends the base PP’s OE.NOTIFY and OE.PRECAUTION objectives by setting reasonable expectations for user security behavior. 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. This objective is suitable because the MDM agent can reasonably expect the device it has been deployed on to be secure. 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. 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. 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. The base PP includes FAU_SEL.1 as an objective SFR to limit the audit events that are generated by the TSF. This PP-Module adds another iteration that optionally allows the MDM agent to include this capability also. 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. 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. 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. 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. 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. 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. https://github.com/commoncriteria/mdm master https://www.niap-ccevs.org/static_html/protection-profile/428/-428-/index.html

There 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. 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/INTRA_XFER_AGENT in PP_MDM. 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 PP_MDM; 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 PP_MDM SFR claims must be made.

This SFR is modified in a way that accommodates an MDM agent, which is part of the TOE boundary when this PP-Module is claimed. 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/INTRA_XFER_AGENT from PP_MDM must also be claimed, as this SFR defines the channel used for secure communications between these two components.

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. This requirement ensures that persistent secrets (credentials, secret keys) and private keys are stored securely when not in use by the mobile platform. The evaluator shall verify that the TSS lists each persistent secret (credential, secret key) and private key needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and, for each platform listed as supported in the ST, how it is stored. The evaluator shall verify that the MDM agent calls a platform-provided API to store persistent secrets and private keys. There are no guidance EAs for this component. There are no test EAs for this component. 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 MDs and support the management functionality that the MDM server component implements. This threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the base PP. This threat exploits issues with configuration of the managed device, consistent with the T.MALICIOUS_APPS threat defined in the base PP. This threat exploits impersonation of a legitimate policy source, which is consistent with the T.NETWORK_ATTACK threat defined in the base PP. This 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. This 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. 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. 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. The 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. The 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. 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. The 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. PP_MDM contains an objective named OE.PROPER_ADMIN with the same purpose. PP_MDM contains an objective named OE.PROPER_USER with the same purpose. PP_MDM contains this same objective with the same purpose. PP_MDM 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. PP_MDM contains this same objective with the same purpose. This SFR provides the alerts that are received by the MDM server as per FAU_ALT_EXT.1 in the base PP. 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. 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 optionally allows the MDM agent to include this capability also. 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. 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. This SFR requires the MDM agent to interact with the underlying MD platform to enforce management functions that are configured by the MDM server (FMT_SMF.1/SERVER_CONF_AGENT in the base PP). 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. This SFR defines the ability of the MDM agent to store generated audit data in the audit storage provided by the MD. This does not impact the base PP since it resides on a different platform from the MDM agent. 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/INTRA_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. https://github.com/commoncriteria/operatingsystem release-5.0 https://www.niap-ccevs.org/static_html/protection-profile/469/OS%204.3%20PP/index.html

The 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. 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: FCS_STO_EXT.1.1 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.

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. 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 PP_GPOS 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 PP_GPOS. 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. Protocol, RBG, certificate validation, algorithm, and similar services may be met with platform provided services. The evaluator shall examine the TSS to determine that the methods of communication between the MDM agent and MDM server (and MAS server, if claimed) are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of remote TOE administration are consistent with those specified in the requirement, and are included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions for configuring the communication channel between the MDM agent and the MDM server and conditionally, the MAS server for each supported method. For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests: The evaluator shall ensure that communications using each specified (in the operational guidance) communication method between the MDM agent and MDM server (and MAS server, if claimed) is tested during the course of the evaluation, connections are set up as described in the operational guidance, and that communication is successful. The evaluator shall ensure, for each method of communication between the MDM agent and MDM server (and MAS server, if claimed), the channel data is not sent in plaintext. The evaluator shall ensure, for each communication channel between the MDM agent and MDM server (and MAS server, if claimed), that a protocol analyzer identifies the traffic as the protocol under testing. Further evaluation activities are associated with the specific protocols. 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. This 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. PP_GPOS 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. 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 PP_GPOS, 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. The evaluator shall examine the TSS to determine that the methods of remote enrollment are indicated, along with how those communications are protected. The evaluator shall also confirm that all protocols listed in the TSS in support of enrollment are consistent with those specified in the requirement, and are included in the requirements in the ST. The evaluator shall confirm that the operational guidance contains instructions for establishing the enrollment sessions for each supported method. For each enrollment method that the ST claims: The evaluator shall ensure that communications using each specified (in the operational guidance) enrollment method is tested during the course of the evaluation, connections are set up as described in the operational guidance, and that communication is successful. For each method of enrollment supported, the evaluator shall follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish enrollment sessions without invoking the trusted path. The evaluator shall ensure, for each method of enrollment, the channel data is not sent in plaintext. Further evaluation activities are associated with the specific protocols. 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. When this PP-Module is used to extend PP_GPOS, 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. This threat exploits network connectivity, consistent with T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined in the base PP. This threat exploits issues with local device configuration, consistent with the T.LOCAL_ATTACK threat defined in the base PP. This 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. This 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. This 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 PP_GPOS. PP_GPOS contains this same assumption with the same purpose. PP_GPOS contains this same assumption with the same purpose. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. The base PP does not define any OSPs so any OSPs defined by the PP-Module will not conflict with the base PP by definition. This objective extends the base PP’s OE.PROPER_ADMIN objective by expecting that TOE administrators act appropriately when installing or configuring the MDM agent. This objective extends the base PP’s OE.PROPER_USER objective by setting reasonable expectations for user security behavior. 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. This extends the OE.PLATFORM objective from the base PP to cover that the underlying platform of the MDM agent is trusted. This objective is suitable because while the base PP does not define any availability metrics for wireless communications, a PP-Module for WLAN client capabilities exists and can be used with PP_GPOS, so support for wireless communications is a reasonable expectation for a conformant TOE. 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. The 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. The base PP includes FAU_SEL.1 as an objective SFR to limit the audit events that are generated by the TSF. This PP-Module adds another iteration that optionally allows the MDM agent to include this capability also. 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. 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. 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. 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. 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. 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. 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. : Auditable Events for Mandatory SFRs 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 PP_MDM for all other definitions for this family. requires the TSF to define when and how an MDM agent generates alerts and transmits them to an MDM server based on its activity. The following actions could be considered for the management functions in FMT: Ability to configure the specific events that result in generation of alerts. 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.1 Server Alerts [FPT_ITT.1 Basic Internal TSF Data Transfer Protection; or FTP_ITC.1 Inter-TSF Trusted Channel] The trusted channel is defined in FPT_ITT.1/INTRA_XFER_AGENT of the base PP if the TOE claims PP_MDM, FTP_ITC_EXT.1/MDFCHANNEL in this PP-Module if the TOE claims the PP_MDF, and FTP_ITC_EXT.1/OSCHANNEL in this PP-Module if the TOE claims PP_GPOS. “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. If the trusted channel is not available, alerts must be queued. When the trusted channel becomes available, the queued alerts must be sent. The evaluator shall examine the TSS and verify that it describes how the alerts are implemented. The evaluator shall examine the TSS and verify that it describes how the candidate policy updates are obtained and the actions that take place for successful (policy update installed) and unsuccessful (policy update not installed) cases. The software components that are performing the processing must also be identified in the TSS and verified by the evaluator. The evaluator shall also ensure that the TSS describes how reachability events are implemented, and if configurable, are selected in FMT_SMF_EXT.4.2. The evaluator shall verify that this description clearly indicates whether the MDM agent or MDM server initiates reachability events. The evaluator shall ensure that the TSS describes under what circumstances, if any, the alert may not be generated (e.g., the device is powered off or disconnected from the trusted channel), how alerts are queued, and the maximum amount of storage for queued messages. There are no guidance EAs for this component. The evaluator shall perform a policy update from the test environment MDM server. The evaluator shall verify the MDM agent accepts the update, makes the configured changes, and reports the success of the policy update back to the MDM server. The evaluator shall perform each of the actions listed in FAU_ALT_EXT.2.1 and verify that the alert does in fact reach the MDM server. The evaluator shall configure the MDM agent to perform a network reachability test, both with and without such connectivity and ensure that results reflect each. The evaluator shall remove network connectivity from the MDM agent and generate an alert or event as defined in FAU_ALT_EXT.2.1. The evaluator shall restore network connectivity to the MDM agent and verify that the alert generated while the TOE was disconnected is sent by the MDM agent upon re-establishment of the connectivity. Success or failure of sending alert. No additional information. 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. 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. The evaluator shall check the TSS and ensure that it provides a format for audit data. Each audit data format type must be covered, along with a brief description of each field. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM agent; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity). There are no guidance EAs for this component. The evaluator shall use the TOE to perform the auditable events defined in the Auditable Events table in FAU_GEN.1.1/AGENT and shall observe that accurate audit data are generated with contents and formatting consistent with those described in the TSS. Note that this testing can be accomplished in conjunction with the testing of the security mechanisms directly. 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 PP_MDM for all other definitions for this family. requires the TSF to record specific information about the MDM server (i.e., the entity that is enrolling it) during the enrollment process. There are no management functions foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Minimal: Completion of enrollment process. FIA_ENR_EXT.1 Enrollment of Mobile Device into Management 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 PP_MDM. The evaluator shall examine the TSS to verify that it describes which types of reference identifiers are acceptable and how the identifier is specified (e.g. preconfigured in the MDM agent, by the user, by the MDM server, in a policy). The evaluator shall examine the operational guidance to verify that it describes how to configure the reference identifier of the MDM server’s certificate and, if different than the reference identifier, the Domain Name or IP address (for connectivity) of the MDM server. The evaluator shall follow the operational guidance to establish the reference identifier of the MDM server on the MDM agent and in conjunction with other evaluation activities verify that the MDM agent can connect to the MDM server and validate the MDM server’s certificate. Enrollment in management. Reference identifier of the MDM server. 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 PP_MDM for all other definitions for this family. requires the TSF to verify the validity of the source of a policy before applying it. There are no management functions foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Minimal: Failure to validate policy. FCS_COP.1 Cryptographic Operation FMT_POL_EXT.1 Trusted Policy Update 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/INTRA_XFER_AGENT in PP_MDM 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 PP_MDM. 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 evaluator shall ensure that the TSS describes how the candidate policies are obtained by the MDM agent, the processing associated with verifying the digital signature of the policy updates, and the actions that take place for successful (signature was verified) and unsuccessful (signature could not be verified) cases. The software components that are performing the processing must also be identified in the TSS and verified by the evaluator. There are no guidance EAs for this component. This evaluation activity is performed in conjunction with the evaluation activity for FIA_X509_EXT.1 and FIA_X509_EXT.2 as defined in the base PPs. The evaluator shall perform a policy update from an available configuration interface (such as through a test MDM server). The evaluator shall verify the update is signed and is provided to the MDM agent. The evaluator shall verify the MDM agent accepts the digitally signed policy. The evaluator shall perform a policy update from an available configuration interface (such as through a test MDM server). The evaluator shall provide an unsigned and an incorrectly signed policy to the MDM agent. The evaluator shall verify the MDM agent does not accept the unsigned and incorrectly signed policies. Failure of policy validation. Reason for failure of validation. 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 PP_MDF for all other definitions for this family. requires the TSF to support the execution of certain management functions that require interfacing with other TOE components. The following actions could be considered for the management functions in FMT: Execution of management functions. Configuration of management functions behavior. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Minimal: Successful and failed execution of management functions. FCS_CKM.1 Cryptographic Key Generation This requirement captures all the configuration functionality in the MDM agent to configure the underlying MD with the configuration policies sent from the MDM server to the MDM agent. The ST author selects the base PP (PP_MDF, PP_MDM, or PP_GPOS) as the source of the management functions. The administrator-provided management functions in PP_MDF are specified in the "Admin Only" column of Table 7 in PP_MDF 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 PP_GPOS 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 MDF or GPOS ST. This requirement captures all of the configuration in the MDM agent for configuration of itself. If the MDM agent is part of a MD, 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 MD, the MDM agent performs the function “enroll in management” by registering itself to the MD 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. This assurance activity may be performed in conjunction with other evaluation activities in the base PP. The evaluator shall verify that the assigned functions are described in the TSS and that these functions are documented as supported by the platform. The evaluator shall examine the TSS to verify that any differences between management functions and policies for each supported MD are listed. The evaluator shall verify that the TSS describes the methods in which the MDM agent can be enrolled. The TSS description shall make it clear whether the MDM agent supports multiple interfaces for enrollment and configuration (for example, both remote configuration and local configuration). The evaluator shall verify the AGD guidance includes detailed instructions for configuring each function in this requirement. If the MDM agent is a component of the MDM system (i.e., PP_MDM is the base PP), the evaluator shall verify, by consulting documentation for the claimed MD platforms, that the configurable functions listed for the MDM agent are supported by the platforms. If the MDM agent supports multiple interfaces for configuration (for example, both remote configuration and local configuration), the operational guidance makes it clear whether some functions are restricted to certain interfaces. In conjunction with the evaluation activities in the base PP, the evaluator shall attempt to configure each administrator-provided management function and shall verify that the MD executes the commands and enforces the policies. [conditional: if "import the certificates to be used for authentication of MDM agent communications" is selected in FMT_SMF_EXT.4.1, then] The evaluator shall configure the MDM agent authentication certificate in accordance with the configuration guidance. The evaluator shall verify that the MDM agent uses this certificate in performing the tests for PP_MDM SFR FPT_ITT.1/INTRA_XFER_AGENT (if PP_MDM is the base PP), the Additional SFR FTP_ITC_EXT.1/MDFCHANNEL (if PP_MDF is the base PP), or the Additional SFR FTP_ITC_EXT.1/OSCHANNEL (if PP_GPOS is the base PP). In conjunction with other evaluation activities, the evaluator shall attempt to enroll the MDM agent in management with each interface identified in the TSS, and verify that the MDM agent can manage the device and communicate with the MDM server. [conditional] In conjunction with the evaluation activity for FAU_ALT_EXT.2.1, the evaluator shall configure the periodicity for reachability events for several configured time periods and verify that the MDM server receives alerts on that schedule. [conditional] The evaluator shall design and perform tests to demonstrate that the assigned function may be configured and that the intended behavior of the function is enacted by the MD. Outcome (success or failure) of function. No additional information. Components in this family define requirements for TSF behavior when a user attempts to unenroll the TOE from an MDM. requires the TSF either to prevent unenrollment entirely or to take some corrective action in the event that an unenrollment is initiated. There are no management functions foreseen. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Minimal: Unenrollment from MDM. [FIA_ENR_EXT.1 Enrollment of Mobile Device into Management; or FMT_MOF_EXT.1 Management of Functions Behavior] 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, PP_MDF describes remediation actions performed upon unenrollment, such as wiping enterprise data, in FMT_SMF_EXT.2.1. PP_GPOS 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. The evaluator shall ensure that the TSS describes the mechanism used to prevent users from unenrolling or the remediation actions applied when unenrolled. The evaluator shall ensure that the administrative guidance instructs administrators on configuring the unenrollment prevention in each available configuration interface. If any configuration allows users to unenroll, the guidance also describes the actions that unenroll the MDM agent. If ‘prevent the unenrollment from occurring’ is selected, the evaluator shall configure the MDM agent according to the administrative guidance for each available configuration interface, attempt to unenroll the device, and verify that the attempt fails. If ‘apply remediation actions’ is selected, if any configuration allows the user to unenroll, the evaluator shall configure the MDM agent to allow user unenrollment, attempt to unenroll, and verify that the remediation actions are applied. Attempt to unenroll No additional information

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. If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked. It should be noted that this may be through a mechanism that is not implemented by the MDM agent; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity. The evaluator shall examine the operational guidance to determine that it contains instructions on how to define the set of auditable events as well as explains the syntax for multi-value selection (if applicable). The evaluator shall also verify that the operational guidance shall identify those audit records that are always recorded, regardless of the selection criteria currently being enforced. For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the administrative guidance) to be recorded. [conditional]: If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability is correctly implemented. The evaluator shall also, in the test plan, provide a short narrative justifying the set of tests as representative and sufficient to exercise the capability. All modifications to the audit configuration that occur while the audit collection functions are operating. No additional information.

: Auditable Events for Implementation-Dependent SFRs

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 PP_MDM for all other definitions for this family. requires the TSF to identify a location for audit record storage and the events that are stored at this location. There are no management functions foreseen. There are no auditable events foreseen. FAU_GEN.1 Audit Data Generation The evaluator shall verify that the TSS description of the audit records indicates how the records are stored. The evaluator shall verify that the MDM agent calls a platform-provided API to store audit records. There are no guidance EAs for this component. There are no test EAs for this component. Components in this family define requirements for tracking the availability of network components. requires the TSF to keep track of failed attempts to communicate with a remote entity. The following actions could be considered for the management functions in FMT: Configuration of unreachability threshold. The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP, PP-Module, functional package or ST: Minimal: Reaching or exceeding unreachability threshold. FPT_STM.1 Reliable Time Stamps The evaluator shall verify that the TSS contains a description of how the MDM agent determines how long it has been since the last successful connection with the MDM server (i.e., total number of missed reachability events or time). If "positive integer of missed reachability events occur" is selected, the evaluator shall verify that the TSS contains a description of how often the reachability events are sent. The evaluator shall verify that the operational guidance instructs the administrator, if needed, how to configure the TOE to detect when the time since the last successful connection with the server has been reached. The evaluator shall configure the MDM server configuration policy of the MDM agent per FMT_SMF.1.1/SERVER_CONF_AGENT, function 56 in PP_MDM. The device shall be placed in airplane mode or otherwise have its network capabilities disabled to prevent connectivity with the MDM server. The evaluator shall verify that after the configured time, the remediation actions selected in function 56 occur. MDM server connection reaching or exceeding unavailability threshold. No additional information. : Implicitly Satisfied Requirements Requirement Rationale for Satisfaction FMT_MTD.1 - Management of TSF 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 MD TOE, the MDM agent itself will be installed on a device. If the mobile device is part of the TOE, PP_MDF 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). CSA Computer Security Act of 1987, H.R. 145, June 11, 1987. Errata Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1) OMB Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.