Version | Date | Comment |
---|---|---|
1.0 | 2019-03-01 | Initial publication as PP-Module. |
1.1 | 2023-12-11 | Added GPOS PP base and incorporated NIAP Technical Decisions. |
Assurance | Grounds for confidence that a TOE meets the SFRs [CC]. |
Base Protection Profile (Base-PP) | Protection Profile used as a basis to build a PP-Configuration. |
Collaborative Protection Profile (cPP) | A Protection Profile developed by international technical communities and approved by multiple schemes. |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
Common Criteria Testing Laboratory | Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Extended Package (EP) | A deprecated document form for collecting SFRs that implement a particular protocol, technology, or functionality. See Functional Packages. |
Functional Package (FP) | A document that collects SFRs for a particular protocol, technology, or functionality. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
Protection Profile Module (PP-Module) | An implementation-independent statement of security needs for a TOE type complementary to one or more Base-PPs. |
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
Target of Evaluation (TOE) | The product under evaluation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in an ST. |
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. |
For changes to included SFRs, selections, and assignments required for this use case, see E.2 Enterprise-owned device for specialized, high-security use.
For changes to included SFRs, selections, and assignments required for this use case, see E.3 Personally owned device for personal and enterprise use.
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
If this feature is implemented by the TOE, the following requirements must be claimed in the ST:
Threat, Assumption, or OSP | Security Objectives | Rationale |
T.MALICIOUS_APPS | O.DATA_PROTECTION_TRANSIT | The threat T.MALICIOUS_APPS is countered by O.DATA_PROTECTION_TRANSIT as this provides the capability to protect app loading and updates against malicious insertion from the network. |
O.APPLY_POLICY | The threat T.MALICIOUS_APPS is countered by O.APPLY_POLICY as this provides a policy preventing loading of unapproved applications into the TOE. | |
T.BACKUP | O.DATA_PROTECTION_TRANSIT | The threat T.BACKUP is countered by O.DATA_PROTECTION_TRANSIT as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted between the MDM Agent and other entities. |
O.APPLY_POLICY | The threat T.BACKUP is countered by O.APPLY_POLICY as this provides a policy that enforces storage of backups only in secure, protected locations. | |
T.NETWORK_ATTACK | O.DATA_PROTECTION_TRANSIT | The threat T.NETWORK_ATTACK is countered by O.DATA_PROTECTION_TRANSIT as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted between the MDM Agent and other entities. |
O.APPLY_POLICY | The threat T.NETWORK_ATTACK is countered by O.APPLY_POLICY as this provides a secure configuration of the MDM Agent to protect data that it processes. | |
OE.IT_ENTERPRISE | The threat T.NETWORK_ATTACK is countered by OE.IT_ENTERPRISE by reducing the network exposure of the device. | |
T.NETWORK_EAVESDROP | O.DATA_PROTECTION_TRANSIT | The threat T.NETWORK_EAVESDROP is countered by O.DATA_PROTECTION_TRANSIT as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted between the MDM Agent and other entities. |
O.APPLY_POLICY | The threat T.NETWORK_EAVESDROP is countered by O.APPLY_POLICY as this provides a secure configuration of the MDM Agent to protect data that it processes. | |
OE.IT_ENTERPRISE | The threat T.NETWORK_EAVESDROP is countered by OE.IT_ENTERPRISE by reducing the network exposure of the device. | |
T.PHYSICAL_ACCESS | O.ACCOUNTABILITY | The threat T.PHYSICAL_ACCESS is countered by O.ACCOUNTABILITY as this provides the capability to log attempts by unauthorized personnel to access data, and to log any access or changes to the device or its data during the time when it is not under the control of an authorized user. |
O.APPLY_POLICY | The threat T.PHYSICAL_ACCESS is countered by O.APPLY_POLICY as this provides a secure configuration of the MDM Agent to protect data that it processes. | |
O.STORAGE | The threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores. | |
A.CONNECTIVITY | OE.WIRELESS_NETWORK | The OE objective OE.WIRELESS_NETWORK is realized through A.CONNECTIVITY. |
A.PLATFORM | OE.DEVICE_PLATFORM | The OE objective OE.DEVICE_PLATFORM is realized through A.PLATFORM. |
A.PROPER_ADMIN | OE.DATA_PROPER_ADMIN | The OE objective OE.DATA_PROPER_ADMIN is realized through A.PROPER_ADMIN. |
A.PROPER_USER | OE.DATA_PROPER_USER | The OE objective OE.DATA_PROPER_USER is realized through A.PROPER_USER. |
P.ACCOUNTABILITY | O.ACCOUNTABILITY | O.ACCOUNTABILITY provides logging of personnel actions to provide accountability for these actions. |
P.ADMIN | O.APPLY_POLICY | The TOE adheres to the enterprise security policy through the application of O.APPLY_POLICY. |
P.DEVICE_ENROLL | O.APPLY_POLICY | The TOE enrolls mobile devices for specific users with policy through the application of O.APPLY_POLICY. |
P.NOTIFY | O.APPLY_POLICY | The TOE provides the capability for the administrator to apply remediation actions via the MDM system through policy, which is applied through O.APPLY_POLICY. |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FCS_STG_EXT.4 | ||
No events specified | N/A | |
FTP_ITC_EXT.1/MDFCHANNEL | ||
Initiation of the trusted channel. | No additional information. | |
Termination of the trusted channel. | No additional information. | |
Failure of the trusted channel functions. | No additional information. | |
FTP_TRP.1/MDFENROLL | ||
Initiation of the trusted path. | No additional information. | |
Termination of the trusted path. | No additional information. | |
Failure of the trusted path functions. | No additional information. |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FCS_STG_EXT.1/MDMKEYS | ||
No events specified | N/A |
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FTP_ITC_EXT.1/OSCHANNEL | ||
Initiation of the trusted channel. | No additional information. | |
Termination of the trusted channel. | No additional information. | |
Failure of the trusted channel functions. | No additional information. | |
FTP_TRP.1/OSENROLL | ||
Initiation of the trusted path. | No additional information. | |
Termination of the trusted path. | No additional information. | |
Failure of the trusted path functions. | No additional information. |
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.
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FAU_ALT_EXT.2 | ||
Success or failure of sending alert. | No additional information. | |
FAU_GEN.1/AGENT | ||
No events specified | N/A | |
FAU_SEL.1/AGENT | ||
All modifications to the audit configuration that occur while the audit collection functions are operating. | No additional information. | |
FIA_ENR_EXT.2 | ||
Enrollment in management. | Reference identifier of the MDM Server. | |
FMT_POL_EXT.2 | ||
Failure of policy validation. | Reason for failure of validation. | |
FMT_SMF_EXT.4 | ||
Outcome (success or failure) of function. | No additional information. | |
FMT_UNR_EXT.1 | ||
[selection: Attempt to unenroll, None] | No additional information |
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
Objective | Addressed by | Rationale |
---|---|---|
O.ACCOUNTABILITY | FAU_ALT_EXT.2 | The PP-Module includes FAU_ALT_EXT.2 to support this objective by requiring the TSF to generate alerts back to an MDM Server when security-relevant events occur. |
FAU_GEN.1/AGENT | The PP-Module includes FAU_GEN.1/AGENT to support this objective by defining the security-relevant events for which the TSF must generate audit records. | |
FAU_SEL.1/AGENT | The PP-Module includes FAU_SEL.1/AGENT to support this objective by defining how the set of audited events can be configured. | |
FAU_STG_EXT.3 (implementation-dependent) | The PP-Module includes FAU_STG_EXT.3 to support this objective by requiring the TSF to use platform-provided storage for any security-relevant audit data it generates. | |
O.APPLY_POLICY | FIA_ENR_EXT.2 | The PP-Module includes FIA_ENR_EXT.2 to support this objective by requiring the TSF to identify the MDM Server so that the authenticity of policy updates can be determined. |
FMT_POL_EXT.2 | The PP-Module includes FMT_POL_EXT.2 to support this objective by requiring the TSF to only accept policy data that can prove its authenticity with a digital certificate. | |
FMT_SMF_EXT.4 | The PP-Module includes FMT_SMF_EXT.4 to support this objective by defining the management functions the TSF must implement to support its own configuration. | |
FMT_UNR_EXT.1 | The PP-Module includes FMT_UNR_EXT.1 to support this objective by preventing a user-directed unenrollment operation that would allow for MDM policies to be ignored. | |
FPT_NET_EXT.1 (implementation-dependent) | The PP-Module includes FPT_NET_EXT.1 to support this objective by requiring the TSF to detect when a sustained communications outage with the MDM Server has occurred to indicate that the TSF may be deprived of updated policy data in cases where unreachability thresholds are supported. | |
O.DATA_PROTECTION_TRANSIT | FCS_DTLSC_EXT.1 (from TLS Package) | The PP-Module includes FCS_DTLSC_EXT.1 from the TLS package by reference to support this objective because DTLS is one of the protocols the PP-Module allows to protect data in transit. |
FCS_DTLSS_EXT.1 (from TLS Package) | The PP-Module includes FCS_DTLSS_EXT.1 from the TLS package by reference to support this objective because DTLS is one of the protocols the PP-Module allows to protect data in transit. | |
FCS_TLS_EXT.1 (from TLS Package) | The PP-Module includes FCS_TLS_EXT.1 from the TLS package by reference to support this objective because it is mandatory to claim when the TLS Package applies so that the TSF’s usage of TLS is clearly defined. | |
FCS_TLSC_EXT.1 (from TLS Package) | The PP-Module includes FCS_TLSC_EXT.1 from the TLS package by reference to support this objective because TLS is one of the protocols the PP-Module allows to protect data in transit. | |
FCS_TLSC_EXT.2 (from TLS Package) | The PP-Module includes FCS_TLSC_EXT.2 from the TLS package by reference to support this objective because it requires TLS to be mutually-authenticated if claimed. | |
FCS_TLSS_EXT.1 (from TLS Package) | The PP-Module includes FCS_TLSS_EXT.1 from the TLS package by reference to support this objective because TLS is one of the protocols the PP-Module allows to protect data in transit. | |
FCS_TLSS_EXT.2 (from TLS Package) | The PP-Module includes FCS_TLSS_EXT.2 from the TLS package by reference to support this objective because it requires TLS to be mutually-authenticated if claimed. | |
FIA_X509_EXT.1(2) (if MDM is Base-PP) | This SFR is selection-based in the MDM PP but is required when the TOE includes this PP-Module because it is triggered by the MDM Agent being part of the TOE. This SFR supports the objective by authentication requirements for the trusted channel the TSF must use to secure connectivity between the MDM Server and MDM Agent components of the distributed TOE. | |
FTP_ITC_EXT.1 (if MDM is Base-PP) | This SFR from the MDM PP defines the trusted channel between the MDM Server and MDM Agent portions of the TOE. | |
FTP_ITC_EXT.1/MDFCHANNEL (if MDF is Base-PP) | The PP-Module includes FTP_ITC_EXT.1/MDFCHANNEL to support this objective because when the TOE is a mobile device, it must have a way to ensure that MDM Server communications are protected. | |
FTP_TRP.1/MDFENROLL (if MDF is Base-PP) | The PP-Module includes FTP_ITC_EXT.1/MDFCHANNEL to support this objective because when the TOE is a mobile device, it must have a way to ensure that MDM Server enrollment communications are protected. | |
FPT_ITT.1(2) (if MDM is Base-PP) | This SFR is selection-based in the MDM PP but is required when the TOE includes this PP-Module because it is triggered by the MDM Agent being part of the TOE. This SFR supports the objective by defining the trusted channel the TSF must use to secure connectivity between the MDM Server and MDM Agent components of the distributed TOE. | |
FTP_ITC_EXT.1/OSCHANNEL (if GPOS is Base-PP) | The PP-Module includes FTP_ITC_EXT.1/OSCHANNEL to support this objective because when the TOE runs on a GPOS, the operating system must have a way to ensure that MDM Server communications are protected. | |
FTP_TRP.1/OSENROLL (if GPOS is Base-PP) | The PP-Module includes FTP_TRP.1/OSENROLL to support this objective because when the TOE is a GPOS, it must have a way to ensure that MDM Server enrollment communications are protected. | |
FPT_NET_EXT.1 (implementation-dependent) | The PP-Module includes FPT_NET_EXT.1 to support this objective by requiring the TSF to detect when a sustained communications outage with the MDM Server has occurred as a possible indicator of communications issues in cases where unreachability thresholds are supported. | |
O.STORAGE | FCS_STG_EXT.1/MDMKEYS (if MDM is Base-PP) | The PP-Module includes FCS_STG_EXT.1/MDMKEYS to support this objective because when the TOE is an MDM Server with MDM Agent capability, it ensures that MDM Agent key data is stored securely. |
FCS_STG_EXT.4 (if MDF is Base-PP) | The PP-Module includes FCS_STG_EXT.4 to support this objective because when the TOE is a mobile device, it ensures that MDM Agent key data is stored securely. | |
FCS_STO_EXT.1 (if GPOS is Base-PP) | The GPOS PP defines the FCS_STO_EXT.1 requirement for protection of sensitive data, which can include user data or keys used to protect user data. |
PP-Module Threat, Assumption, OSP | Consistency Rationale |
---|---|
T.MALICIOUS_APPS | |
T.BACKUP | This threat protects user data from unauthorized logical access. An attacker would attempt to exploit this threat by first exploiting the T.PHYSICAL_ACCESS, T.MALICIOUS_APP, or T.PERSISTENT_PRESENCE threats defined in the Base-PP against the mobile device as a whole, and then using the device itself as an attack vector against any backup data stored on the TOE. |
T.NETWORK_ATTACK | |
T.NETWORK_EAVESDROP | |
T.PHYSICAL_ACCESS | |
A.CONNECTIVITY | 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 that provides networking services through various radios. |
A.PLATFORM | 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 MDF PP. |
A.PROPER_ADMIN | This assumption expects that the TOE administrator is trusted and competent in configuring the TSF. This assumption is consistent with the A.CONFIG assumption in the Base-PP which expects the TSF to be configured correctly regardless of the subject performing the configuration. |
A.PROPER_USER | This assumption expects that the TOE user is not willfully negligent or hostile in using the TSF. This assumption is consistent with the A.CONFIG assumption in the Base-PP which expects the TSF to be configured correctly regardless of the subject performing the configuration as well as the A.NOTIFY and A.PRECAUTION assumptions which define baseline expectations for the user’s level of responsibility. |
P.ACCOUNTABILITY | 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. |
P.ADMIN | 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. |
P.DEVICE_ENROLL | 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. |
P.NOTIFY | 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 objectives for the TOE are consistent with the MDF PP based on the following rationale:
PP-Module TOE Objective | Consistency Rationale |
---|---|
O.ACCOUNTABILITY | The Base-PP provides an objective, O.INTEGRITY, that ensures that the integrity of the mobile device is maintained. This objective assists in the implementation of O.INTEGRITY by providing records of administrative activity, which would include actions that could cause the integrity of the mobile device to be lost. |
O.APPLY_POLICY | This objective supports the implementation of the O.CONFIG objective defined in the Base-PP by specifying an additional method by which the TSF may be configured. |
O.DATA_PROTECTION_TRANSIT | This objective extends the Base-PP’s O.PROTECTED_COMMS objective by ensuring that the communications related to MDM Agent functionality are secured in the same manner as other sensitive data transmitted to and from the mobile device. |
O.STORAGE | This objective extends the Base-PP’s O.STORAGE objective by ensuring that the mobile device’s data-at-rest protection mechanisms can also be used to secure the MDM Agent and related data. |
The objectives for the TOE's OE are consistent with the MDF PP based on the following rationale:
PP-Module OE Objective | Consistency Rationale |
---|---|
OE.DATA_PROPER_ADMIN | This objective extends the Base-PP’s OE.CONFIG objective by expecting that TOE administrators act appropriately when installing or configuring the MDM Agent. |
OE.DATA_PROPER_USER | This objective extends the Base-PP’s OE.NOTIFY and OE.PRECAUTION objectives by setting reasonable expectations for user security behavior. |
OE.IT_ENTERPRISE | This objective helps mitigate the T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined by the Base-PP by reducing the network exposure of the mobile device. This does not conflict with the Base-PP because the Base-PP does not set specific expectations for the level of security that the enterprise provides. However, all use cases from the Base-PP set expectations that the mobile device is used for some enterprise purposes so it is reasonable to expect the enterprise have security controls in place to protect these functions. |
OE.DEVICE_PLATFORM | This objective is suitable because the MDM Agent can reasonably expect the device it has been deployed on to be secure. |
OE.WIRELESS_NETWORK | This objective is suitable because while the Base-PP does not define any availability metrics for wireless communications, the mobile device will always provide the ability to access a wireless network. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
This PP-Module does not modify any requirements when the MDF PP is the base. | |
Additional SFRs | |
FCS_STG_EXT.4 | This SFR requires the MDM Agent to use functionality defined by the Base-PP in FCS_CKM_EXT.1. |
FTP_ITC_EXT.1/MDFCHANNEL | The Base-PP includes FTP_ITC_EXT.1 to define the secure protocols used for trusted channel communications. This PP-Module iterates the SFR to specify a subset of these protocols that may be used for MDM Agent communications in particular. |
FTP_TRP.1/MDFENROLL | 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. |
Mandatory SFRs | |
FAU_ALT_EXT.2 | This SFR requires the MDM Agent to use a trusted channel defined by FTP_ITC_EXT.1 in the Base-PP to transmit data about its own behavior to the OE. |
FAU_GEN.1/AGENT | The Base-PP includes FAU_GEN.1; this PP-Module iterates the SFR to use the same audit mechanism to generate audit records for the MDM Agent’s behavior. It may alternatively allow the TSF to generate its own audit trail, which does not impede the MDF from enforcing its own security functionality. |
FAU_SEL.1/AGENT | The Base-PP includes FAU_SEL.1; this PP-Module iterates the SFR to use the same audit mechanism to select the auditable events to be generated by the MDM Agent. Note that the Base-PP does not mandate this requirement so it is possible that only the MDM Agent portion of the TOE may implement it. In this case, the SFR provides a selection for the MDM Agent to implement its own mechanism to perform this function rather than a platform-provided one. |
FIA_ENR_EXT.2 | This SFR requires the MDM Agent to record data that it receives from the OE. It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP. |
FMT_POL_EXT.2 | This SFR requires the MDM Agent to use a digital signature algorithm to validate data that it receives from the OE. To do this, the MDM Agent will use the functionality defined by the Base-PP in FCS_COP.1/SIGN. |
FMT_SMF_EXT.4 | This SFR defines the ability of the MDM Agent to interact with the mobile device to execute the management functions defined by FMT_MOF_EXT.1 in the Base-PP. The Base-PP specifically indicates in FMT_MOF_EXT.1.2 that some management functions may be performed via MDM. |
FMT_UNR_EXT.1 | This SFR defines the functions performed by the MDM Agent when unenrolled from an MDM. The Base-PP defines unenrollment actions in FMT_SMF_EXT.2, and goes on to note that these actions may be performed “perhaps via an MDM Agent,” so this is expected behavior. |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
This PP-Module does not define any Objective requirements. | |
Implementation-dependent SFRs | |
FAU_STG_EXT.3 | This SFR defines the ability of the MDM Agent to store generated audit data in the audit storage provided by the mobile device. The Base-PP defines the capability for audit storage in FAU_STG.1. |
FPT_NET_EXT.1 | This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FTP_ITC_EXT.1 of the Base-PP). It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP. |
Selection-based SFRs | |
This PP-Module does not define any Selection-based requirements. |
PP-Module Threat, Assumption, OSP | Consistency Rationale |
---|---|
T.MALICIOUS_APPS | |
T.BACKUP | This threat protects user data from unauthorized logical access. If the backup data is stored outside the MDM or the mobile device that it protects, then there is no conflict with the MDM PP since it is a different security boundary. If the backup data is stored either on the MDM or on the protected device, an attacker would attempt to exploit this threat by first exploiting any of the threats that the MDM PP defines (T.MALICIOUS_APPS, T.NETWORK_ATTACK, T.NETWORK_EAVESDROP, T.PHYSICAL_ACCESS), depending on where and how the backup data is stored, and then use successful exploitation of one of these threats to attempt to access the backup data itself. |
T.NETWORK_ATTACK | |
T.NETWORK_EAVESDROP | |
T.PHYSICAL_ACCESS | |
A.CONNECTIVITY | 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. |
A.PLATFORM | 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. |
A.PROPER_ADMIN | The Base-PP defines an A.PROPER_ADMIN assumption that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server. |
A.PROPER_USER | The Base-PP defines an A.PROPER_USER assumption that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server. |
P.ACCOUNTABILITY | 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. |
P.ADMIN | 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. |
P.DEVICE_ENROLL | The Base-PP defines a P.DEVICE_ENROLL OSP that is identical to the one defined by the PP-Module. The PP-Module just extends it to the entire TOE boundary rather than just the MDM Server. |
P.NOTIFY | 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. |
The objectives for the TOE are consistent with the MDM PP based on the following rationale:
PP-Module TOE Objective | Consistency Rationale |
---|---|
O.ACCOUNTABILITY | The MDM PP contains this same objective with the same purpose. |
O.APPLY_POLICY | The MDM PP contains this same objective with the same purpose. |
O.DATA_PROTECTION_TRANSIT | The MDM PP contains this same objective with the same purpose. |
O.STORAGE | This objective requires the MDM Agent to use platform key storage to protect secret and private key data. The MDM PP defines a requirement for key storage (FCS_STG_EXT.1) that allows the MDM Agent to satisfy this objective. |
The objectives for the TOE's OE are consistent with the MDM PP based on the following rationale:
PP-Module OE Objective | Consistency Rationale |
---|---|
OE.DATA_PROPER_ADMIN | The MDM PP contains an objective named OE.PROPER_ADMIN with the same purpose. |
OE.DATA_PROPER_USER | The MDM PP contains an objective named OE.PROPER_USER with the same purpose. |
OE.IT_ENTERPRISE | The MDM PP contains this same objective with the same purpose. |
OE.DEVICE_PLATFORM | The MDM PP environmental security objectives only relate to the security of the platform on which the MDM Server portion of the TOE is running. This objective extends the scope of the trusted platform to MDM Agent devices. |
OE.WIRELESS_NETWORK | The MDM PP contains this same objective with the same purpose. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
FIA_X509_EXT.1/2 | 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. |
FPT_ITT.1/2 | 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. |
Additional SFRs | |
FCS_STG_EXT.1/MDMKEYS | The Base-PP requires the TOE to define a method of key storage. This PP-Module iterates it to specify the use of platform key storage for MDM Agents. |
Mandatory SFRs | |
FAU_ALT_EXT.2 | This SFR provides the alerts that are received by the MDM Server as per FAU_ALT_EXT.1 in the Base-PP. |
FAU_GEN.1/AGENT | This SFR requires the MDM Agent to generate audit records of its behavior. The mechanism by which it does this is not relevant to the MDM Server portion of the TOE as they reside on different platforms. |
FAU_SEL.1/AGENT | The Base-PP includes FAU_SEL.1 as an optional SFR to limit the audit events that are generated by the TSF. This PP-Module adds another iteration that requires the MDM Agent to include this capability by default. |
FIA_ENR_EXT.2 | This SFR provides information during MDM Agent enrollment that is required by the MDM Server to meet the FIA_ENR_EXT.1 requirement defined by the Base-PP. |
FMT_POL_EXT.2 | The Base-PP includes an SFR (FMT_POL_EXT.1) that requires the MDM Server to provide digitally signed policies and policy updates to the MDM Agent. FMT_POL_EXT.2 completes this transaction by requiring the MDM Agent to accept only signed policies and policy updates. |
FMT_SMF_EXT.4 | This SFR requires the MDM Agent to interact with the underlying mobile device platform to enforce management functions that are configured by the MDM Server (FMT_SMF.1(1) in the Base-PP). |
FMT_UNR_EXT.1 | This SFR requires the TSF to define its behavior upon unenrollment from management. Unenrollment from management is a management function that is specified in the Base-PP. |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
This PP-Module does not define any Objective requirements. | |
Implementation-dependent SFRs | |
FAU_STG_EXT.3 | This SFR defines the ability of the MDM Agent to store generated audit data in the audit storage provided by the mobile device. This does not impact the Base-PP since it resides on a different platform from the MDM Agent. |
FPT_NET_EXT.1 | This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FPT_ITT.1(2) of the Base-PP). It does not otherwise impact the Base-PP since it describes behavior that occurs local to the MDM Agent during a period where it is not interacting with the MDM Server. |
Selection-based SFRs | |
This PP-Module does not define any Selection-based requirements. |
PP-Module Threat, Assumption, OSP | Consistency Rationale |
---|---|
T.MALICIOUS_APPS | |
T.BACKUP | This threat protects user data from unauthorized logical access. An attacker would attempt to exploit this threat by first exploiting the T.NETWORK_ATTACK, T.LOCAL_ATTACK, or T.LIMITED_PHYSICAL_ACCESS threats defined in the Base-PP against the operating system as a whole, and then using the access gained from that attack as an attack vector against any backup data stored on the TOE. |
T.NETWORK_ATTACK | |
T.NETWORK_EAVESDROP | |
T.PHYSICAL_ACCESS | |
A.CONNECTIVITY | 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. |
A.PLATFORM | 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 GPOS PP. |
A.PROPER_ADMIN | The GPOS PP contains this same assumption with the same purpose. |
A.PROPER_USER | The GPOS PP contains this same assumption with the same purpose. |
P.ACCOUNTABILITY | 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. |
P.ADMIN | 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. |
P.DEVICE_ENROLL | 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. |
P.NOTIFY | 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 objectives for the TOE are consistent with the GPOS PP based on the following rationale:
PP-Module TOE Objective | Consistency Rationale |
---|---|
O.ACCOUNTABILITY | The Base-PP defines an objective of the same name that serves the same purpose. The PP-Module's objective extends the scope of the objective to the MDM Agent capability of the TOE. |
O.APPLY_POLICY | This objective supports the implementation of the O.MANAGEMENT objective defined in the Base-PP by specifying an additional method by which the TSF may be configured. |
O.DATA_PROTECTION_TRANSIT | This objective extends the Base-PP’s O.PROTECTED_COMMS objective by ensuring that the communications related to MDM Agent functionality are secured in the same manner as other sensitive data transmitted to and from the OS. |
O.STORAGE | This objective extends the Base-PP’s O.PROTECTED_STORAGE objective by ensuring that the operating system's data-at-rest protection mechanisms can also be used to secure the MDM Agent and related data. |
The objectives for the TOE's OE are consistent with the GPOS PP based on the following rationale:
PP-Module OE Objective | Consistency Rationale |
---|---|
OE.DATA_PROPER_ADMIN | 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. |
OE.DATA_PROPER_USER | This objective extends the Base-PP’s OE.PROPER_USER objective by setting reasonable expectations for user security behavior. |
OE.IT_ENTERPRISE | This objective helps mitigate the T.NETWORK_EAVESDROP and T.NETWORK_ATTACK threats defined by the Base-PP by reducing the network exposure of the operating system. This does not conflict with the Base-PP because the Base-PP does not set specific expectations for the level of security that the enterprise provides. However, all use cases from the Base-PP set expectations that the operating system is used for some enterprise purposes so it is reasonable to expect the enterprise have security controls in place to protect these functions. |
OE.DEVICE_PLATFORM | This extends the OE.PLATFORM objective from the Base-PP to cover that the underlying platform of the MDM Agent is trusted. |
OE.WIRELESS_NETWORK | This objective is suitable because while the Base-PP does not define any availability metrics for wireless communications, it can be extended by a PP-Module for WLAN client capabilities, so support for wireless communications is a reasonable expectation for a GPOS. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
FCS_STO_EXT.1 | 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. |
Additional SFRs | |
FTP_ITC_EXT.1/OSCHANNEL | The Base-PP includes FTP_ITC_EXT.1 to define the secure protocols used for trusted channel communications. This PP-Module iterates the SFR to specify a subset of these protocols that may be used for MDM Agent communications in particular. |
FTP_TRP.1/OSENROLL | 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 GPOS PP already defines an iteration of this SFR for trusted administration, so this SFR is iterated to illustrate that this trusted path is used for a distinct function. |
Mandatory SFRs | |
FAU_ALT_EXT.2 | This SFR requires the MDM Agent to use a trusted channel defined by FTP_ITC_EXT.1 in the Base-PP to transmit data about its own behavior to the OE. |
FAU_GEN.1/AGENT | The Base-PP defines FAU_GEN.1; this PP-Module iterates the SFR to use the same audit mechanism to generate audit records for the MDM Agent’s behavior. It may alternatively allow the TSF to generate its own audit trail, which does not impede the MDF from enforcing its own security functionality. |
FAU_SEL.1/AGENT | 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. |
FIA_ENR_EXT.2 | This SFR requires the MDM Agent to record data that it receives from the OE. It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP. |
FMT_POL_EXT.2 | This SFR requires the MDM Agent to use a digital signature algorithm to validate data that it receives from the OE. To do this, the MDM Agent will use the functionality defined by the Base-PP in FCS_COP.1/SIGN. |
FMT_SMF_EXT.4 | This SFR defines the ability of the MDM Agent to interact with the underlying operating system to execute the management functions defined by FMT_MOF_EXT.1 in the Base-PP. The Base-PP does not preclude administration being performed in this manner. |
FMT_UNR_EXT.1 | This SFR defines the functions performed by the MDM Agent when unenrolled from an MDM. The Base-PP defines FMT_SMF_EXT.1 which allows for assigned management functions to be specified. This can include unenrollment behavior as defined by FMT_UNR_EXT.1. |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
This PP-Module does not define any Objective requirements. | |
Implementation-dependent SFRs | |
FAU_STG_EXT.3 | This SFR defines the ability of the MDM Agent to store generated audit data in platform-provided audit storage. The Base-PP defines the capability for audit storage in FDP_ACF_EXT.1. |
FPT_NET_EXT.1 | This SFR defines the ability of the MDM Agent to maintain information about its last successful connection with the environmental MDM Server (i.e., the last successful invocation of the trusted channel for that interface, as defined in FTP_ITC_EXT.1 of the Base-PP). It does not need to use any functionality defined in the Base-PP to do this, and doing this does not prevent the enforcement of any security requirements from the Base-PP. |
Selection-based SFRs | |
This PP-Module does not define any Selection-based requirements. |
This PP-Module does not define any Strictly Optional SFRs.
This PP-Module does not define any Objective SFRs.
Requirement | Auditable Events | Additional Audit Record Contents |
---|---|---|
FAU_STG_EXT.3 | ||
No events specified | N/A | |
FPT_NET_EXT.1 | ||
MDM Server connection reaching or exceeding unavailability threshold. | No additional information. |
This PP-Module does not define any Selection-based SFRs.
Functional Class | Functional Components |
---|---|
Cryptographic Support (FCS) | FCS_STG_EXT Trusted Channel |
Identification and Authentication (FIA) | FIA_ENR_EXT Enrollment |
Protection of the TSF (FPT) | FPT_NET_EXT Network Reachability |
Security Audit (FAU) | FAU_ALT_EXT MDM Alerts FAU_STG_EXT Protected Audit Event Storage |
Security Management (FMT) | FMT_POL_EXT Trusted Policy Update FMT_SMF_EXT Specification of Management Functions FMT_UNR_EXT Unenrollment |
FCS_STG_EXT.4, Cryptographic Key Storage, requires the TSF to define a specific location for its key storage.
There are no management functions foreseen.
There are no auditable events foreseen.
Hierarchical to: | No other components. |
Dependencies to: | FCS_CKM.1 Cryptographic Key Generation |
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.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
FPT_NET_EXT.1, Network Reachability, 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:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: | FPT_STM.1 Reliable Time Stamps |
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.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
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_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.
There are no management functions foreseen.
There are no auditable events foreseen.
FMT_POL_EXT.2, Agent Trusted Policy Update, 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/ST:
Hierarchical to: | No other components. |
Dependencies to: | FCS_COP.1 Cryptographic Operation FMT_POL_EXT.1 Trusted Policy Update |
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.
The following actions could be considered for the management functions in FMT:
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: | FCS_CKM.1 Cryptographic Key Generation |
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.
There are no management functions foreseen.
The following actions should be auditable if FAU_GEN Security audit data generation is included in the PP/ST:
Hierarchical to: | No other components. |
Dependencies to: | [FIA_ENR_EXT.1 Enrollment of Mobile Device into Management; or FMT_MOF_EXT.1 Management of Functions Behavior] |
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.2 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.
Requirement | Rationale for Satisfaction |
---|---|
FMT_MTD.1 - Management of TSF Data |
FAU_SEL.1 has a dependency on FMT_MTD.1 because the configuration settings that determine what events are audited is considered to be TSF data.
While FAU_SEL.1 determines the extent to which the TOE’s audit function is configured,
it relies on FMT_MTD.1 to determine the administrative roles that are permitted to manipulate this data.
This is not applicable to the PP-Module because there is no management interface for a TOE user to interact with; instead, all management functions are initiated by an MDM Server and performed by the MDM Agent which 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 | No matter which Base-PP is claimed for the TOE, the MDM Agent itself will be installed on a device. If the underlying device is part of the TOE, the dependency is satisfied by FPT_STM.1 if the MDF PP is the Base-PP, and FPT_STM.1 is implicitly satisfied per Appendix D of the GPOS PP if that is the Base-PP. If the device is not part of the TOE (i.e., because the Base-PP is the MDM PP), 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), and any GPOS is assumed to have access to a reliable hardware clock or network time interface. |
Acronym | Meaning |
---|---|
API | Application Programming Interface |
Base-PP | Base Protection Profile |
BYOD | Bring Your Own Device |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
cPP | Collaborative Protection Profile |
DN | Distinguished Name |
DTLS | Datagram Transport Layer Security |
EP | Extended Package |
FP | Functional Package |
GPOS | General Purpose Operating System |
HTTPS | Hypertext Transfer Protocol Secure |
MAS | Mobile Application Store |
MDF | Mobile Device Fundamentals |
MDM | Mobile Device Management |
OE | Operational Environment |
OS | Operating System |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
SAR | Security Assurance Requirement |
SFR | Security Functional Requirement |
ST | Security Target |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSS | TOE Summary Specification |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|
[CEM] | Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, CCMB-2012-09-004, Version 3.1 Revision 4, September 2012 |
[GPOS PP] | Protection Profile for General Purpose Operating Systems, Version 4.3, September 27, 2022 |
[MDF PP] | Protection Profile for Mobile Device Fundamentals, Version 3.3, September 12, 2022 |
[MDM PP] | Protection Profile for Mobile Device Management, Version 4.0, April 25, 2019 |