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 (MDMPP), Version 4.0
Protection Profile for Mobile Device Fundamentals (MDFPP), Version 3.3
Protection Profile for General Purpose Operating Systems (GPOSPP), Version 4.3
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.
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 MDFPP, the MDMPP, or the GPOSPP. 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 MDFPP if the
TOE is a native part of a mobile operating system. The TOE for
this PP-Module combined with the MDFPP 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 MDMPP 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 MDMPP 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 GPOSPP so that
its baseline security capabilities can be assumed to be present. If the TOE conforms to the GPOSPP, 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 GPOSPP if the TOE is a native part of a non-mobile GPOS.
The TOE for this PP-Module combined with the GPOSPP 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-ModuleTOE 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 the MDFPP and GPOSPP, respectively.
[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.
[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.
[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 MDMPP 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:
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 MDMPP). This feature applies if either the TOE claims the MDMPP 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 MDMPP 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:
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.
cPP-Module for Biometric Enrolment and Verification - for unlocking the device, version 1.1
Package Claim
This PP-Module is
Functional Package for Transport Layer Security Version 2.1 conformant.
This PP-Module is
Functional Package for X.509 Version 1.0 conformant.
This PP-Module is
Assurance Package for Flaw Remediation Version 1.0 conformant.
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.
An 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:
Refinement operation (denoted by bold text or strikethrough
text): Is used to add details to a requirement or to remove part of the requirement that is made irrelevant
through the completion of another operation, and thus further restricts a requirement.
Selection (denoted by italicized text): Is used to select one or more options
provided by the [CC] in stating a requirement.
Assignment operation (denoted by italicized text): Is used to assign a
specific value to an unspecified parameter, such as the length of a password. Showing the
value in square brackets indicates assignment.
Iteration operation: Is indicated by appending the SFR name with a slash and unique identifier
suggesting the purpose of the operation, e.g. "/EXAMPLE1."
5.1
Protection Profile for Mobile Device Fundamentals
Security Functional Requirements Direction
In a PP-Configuration that includes the MDFPP,
the TOE is expected to rely on some of the security functions implemented by the
Mobile Device
as a whole and evaluated against the MDFPP.
The following sections describe any modifications that the ST author must make to the SFRs
defined in the MDFPP in addition to what is mandated by Section 5.4 TOE Security Functional Requirements.
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 MDFPP is
claimed as the Base-PP.
5.1.2.1 Auditable Events for MDF PP Additional SFRs
Table 2: Auditable Events for MDFPP Additional SFRs
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
] 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 MDFPP 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 MDFPP. 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 MDFPP, 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 MDFST. If "TLS" or "DTLS" is selected, the following selections from
Functional Package for Transport Layer Security (TLS),
version
2.1 must be made:
The TSF shall permit the TSFand 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 MDFPP;
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.
] 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 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 MDFPP, 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 MDFST. If "TLS" is selected,
the following selections from Functional Package for Transport Layer Security (TLS),
version
2.1 must be made:
The cipher suites selected must correspond with the algorithms and
hash functions allowed in FCS_COP.1 from the MDFPP.
5.2
Protection Profile for Mobile Device Management
Security Functional Requirements Direction
In a PP-Configuration that includes the MDMPP,
the TOE is expected to rely on some of the security functions implemented by the
MDM Server
as a whole and evaluated against the MDMPP.
The following sections describe any modifications that the ST author must make to the SFRs
defined in the MDMPP 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 MDMPP 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 MDMPP. 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 MDMPP; 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 MDMPPSFR 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 MDMPP 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 MDMPP is
claimed as the Base-PP.
5.2.2.1 Auditable Events for MDM PP Additional SFRs
Table 3: Auditable Events for MDMPP Additional SFRs
The MDM Agent portion of theTSF 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 GPOSPP,
the TOE is expected to rely on some of the security functions implemented by the
Operating System
as a whole and evaluated against the GPOSPP.
The following sections describe any modifications that the ST author must make to the SFRs
defined in the GPOSPP 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 GPOSPP 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.1.2 Security Management (FMT)
FMT_SMF_EXT.1: Specification of Management Functions
The text of the requirement is replaced with:
Functions 1 - 23 are assigned mandatory in the "Administrator" column. An additional column of "Admin Only (When enrolled in management)" is added to the table and functions 1, 2, and 8 are moved to mandatory in this column.
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 GPOSPP is
claimed as the Base-PP.
5.3.2.1 Auditable Events for GPOS PP Additional SFRs
Table 4: Auditable Events for GPOSPP Additional SFRs
The OS shall use
[selection: mutually authenticatedTLS as conforming to Functional Package for Transport Layer Security (TLS),
version
2.1 as a [client], mutually authenticatedDTLS 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 GPOSPP 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 GPOSPP. 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 GPOSPP, 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:
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 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 GPOSPP, 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-PPSFR 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
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 MDMPP,
FTP_ITC_EXT.1/MDFCHANNEL in this PP-Module if the TOE claims the
MDFPP, and FTP_ITC_EXT.1/OSCHANNEL in this PP-Module if the TOE claims the GPOSPP.
“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 MDMPP.
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.
The MDM Agent shall [selection: invoke platform-provided functionality, implement functionality] to generate audit data of the
following auditable events:
All auditable events for the [not specified] level of audit; and
[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:
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];
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.
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:
[event type]
[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 MDMPP.
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 SFRFTP_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 MDMPP.
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 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 MDFPP, administrator-provided device management functions in MDMPP, administrator-provided device management functions in GPOSPP]
[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 (MDFPP, MDMPP, or GPOSPP) as the source of the management functions.
The
administrator-provided management functions in the MDFPP are specified
in the "Admin Only" column of Table 7 in MDFPP and in FPT_TUD_EXT.1 (for version
queries). The administrator-provided device management functions in the MDMPP are specified in FMT_SMF.1/SERVER_CONF_AGENT; the functions in the selection
of FMT_SMF.1/SERVER_CONF_AGENT in the MDMPP are required to correspond to the functions available on the
platforms supported by the MDM Agent.
The administrator-provided management functions in the GPOSPP 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 GPOSST.
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.
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 MDFPP describes remediation
actions performed upon unenrollment, such as wiping enterprise data, in
FMT_SMF_EXT.2.1. The GPOSPP 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:
Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for transmission of policies.
Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for enrollment into management.
Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for transmission of policies.
Mitigates the threat of insecure communications by defining the use of a trusted channel to communicate with an MDM server for enrollment into management.
Mitigates 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.
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.
Mitigates 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 MDFPP, 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 (MDFPP base)
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 the MDFPP.
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.
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 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 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
MDFPP that are needed to support
MDM Agent functionality.
This is considered to be consistent because the functionality provided by the
MDFPP 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
MDFPP are as follows:
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.
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.
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; 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.
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.
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 MDMPP, 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 (MDMPP base)
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.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.
6.2.3
Consistency of OE Objectives
Table 11: Consistency of OE Objectives (MDMPP base)
The MDMPP 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.
The MDMPP contains this same objective with the same purpose.
6.2.4
Consistency of Requirements
This PP-Module identifies several SFRs from the
MDMPP that are needed to support
MDM Agent functionality.
This is considered to be consistent because the functionality provided by the
MDMPP 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
MDMPP are as follows:
Table 12: Consistency of Requirements (MDMPP base)
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.
FTP_ITC_EXT.1
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 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 requires the MDM Agent to include this
capability by default.
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 mobile device 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 mobile device. 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/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.
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 GPOSPP, 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 (GPOSPP base)
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 the GPOSPP.
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 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 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
GPOSPP that are needed to support
MDM Agent functionality.
This is considered to be consistent because the functionality provided by the
GPOSPP 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
GPOSPP are as follows:
Table 15: Consistency of Requirements (GPOSPP base)
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.
FMT_SMF_EXT.1
The PP-Module changes this SFR to make additional management functions necessary when an MDM Agent is based off of the GPSO PP. This is done to match the management functions required in the MDMPP.
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.
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. The GPOSPP 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.
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.
This 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.
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 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:
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 MDMBase-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 MDMPP 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 MDMBase-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
MDMPP 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_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 MDMBase-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
MDMPP 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:
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 MDMBase-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
MDMPP 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 MDMBase-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
MDMPP 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:
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 MDFBase-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 MDFPP 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 MDFPP, administrator-provided device management functions in MDMPP, administrator-provided device management functions in GPOSPP]
[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_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:
[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.
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 MDFPP 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
