Version | Date | Comment |
---|---|---|
1.0 | 2013-10-21 | Initial Release |
1.1 | 2014-02-07 | Typographical changes and clarifications to front-matter |
2.0 | 2014-12-31 | Separation of MDM Agent SFRs. Updated cryptography, protocol, X.509 requirements. Added objective requirement for Agent audit storage. New requirement for unenrollment prevention. Initial Release of MDM Agent EP. |
3.0 | 2016-11-21 | Updates to align with Technical Decisions. Added requirements to support BYOD use case. |
4.0 | 2019-03-01 | Convert to PP-Module. |
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 mobile device. |
Enrolled State | The state in which a mobile device is managed by a policy from an MDM. |
Mobile Application Store (MAS) | Mobile Application Store |
Mobile Device Management (MDM) | Mobile Device Management |
Mobile Device User | The person who uses and is held responsible for a mobile device. |
Operating System | Software which runs at the highest privilege level and can directly control hardware resources. 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 mobile 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 D.2 Enterprise-owned device for specialized, high-security use.
For changes to included SFRs, selections, and assignments required for this use case, see D.3 Personally owned device for personal and enterprise use.
This PP-Module inherits exact conformance as required from the specified Base-PP and as defined in the CC and CEM addenda for Exact Conformance, Selection-based SFRs, and Optional SFRs (dated May 2017).
The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP-Module.
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/updates against malicious insertion from the network. |
O.APPLY_POLICY | The threat T.MALICIOUS_APPS is countered by O.APPLY_POLICY as this provides policy preventing loading of unapproved apps 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 Agent and other entities. |
O.APPLY_POLICY | The threat T.BACKUP is countered by O.APPLY_POLICY as this provides policy to enforce that backups be stored 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 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 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 mobile 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 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 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 mobile 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 to the data or the device, as well as changes to the device 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 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 Operational Environment objective OE.WIRELESS_NETWORK is realized through A.CONNECTIVITY. |
A.MOBILE_DEVICE_PLATFORM | OE.MOBILE_DEVICE_PLATFORM | The Operational Environment objective OE.MOBILE_DEVICE_PLATFORM is realized through A.MOBILE_DEVICE_PLATFORM. |
A.PROPER_ADMIN | OE.DATA_PROPER_ADMIN | The Operational Environment objective OE.DATA_PROPER_ADMIN is realized through A.PROPER_ADMIN. |
A.PROPER_USER | OE.DATA_PROPER_USER | The Operational Environment objective OE.DATA_PROPER_USER is realized through A.PROPER_USER. |
P.ACCOUNTABILITY | O.ACCOUNTABILITY | O.ACCOUNTABILITY provides logging of personnel actions in order to provide accountability of all personnel actions within the TOE. |
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 |
---|---|---|
FAU_ALT_EXT.2 | Success/failure of sending alert. | No additional information. |
FAU_GEN.1 | None. | N/A |
FAU_SEL.1 | All modifications to the audit configuration that occur while the audit collection functions are operating. | No additional information. |
FCS_STG_EXT.4/ FCS_STG_EXT.1(2) |
None. | |
FCS_TLSC_EXT.1 | Failure to establish a TLS session. | Reason for failure. |
Failure to verify presented identifier. | Presented identifier and reference identifier. | |
Establishment/termination of a TLS session. | Non-TOE endpoint of connection. | |
FIA_ENR_EXT.2 | Enrollment in management. | Reference identifier of MDM Server. |
FMT_POL_EXT.2 | Failure of policy validation. | Reason for failure of validation. |
FMT_SMF_EXT.4 | Outcome (Success/failure) of function. | No additional information. |
FMT_UNR_EXT.1.1 | [selection: Attempt to unenroll, none ] | No additional information. |
FTP_ITC_EXT.1(2) | Initiation and termination of trusted channel. | Trusted channel protocol. Non-TOE endpoint of connection. |
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, FAU_GEN.1(2), FAU_SEL.1(2) | FILL IN |
O.APPLY_POLICY | FAU_STG_EXT.3(objective), FIA_ENR_EXT.2, FMT_POL_EXT.2, FMT_SMF_EXT.4,FMT_UNR_EXT.1 | FILL IN |
O.DATA_PROTECTION_TRANSIT | FCS_DTLSS_EXT.1 (from TLS Package), FCS_DTLSC_EXT.1 (from TLS Package), FCS_TLSC_EXT.1 (from TLS Package), FCS_TLSC_EXT.2 (from TLS Package), FCS_TLSS_EXT.1 (from TLS Package), FCS_TLSS_EXT.2 (from TLS Package), FPT_NET_EXT.1 (objective), FTP_ITC_EXT.1(2) (if MDF is Base-PP), FTP_TRP.1(2) (if MDF is Base-PP) | FILL IN |
O.STORAGE | FCS_STG_EXT.1(2) (if MDM is Base-PP), FCS_STG_EXT.4 (if MDF is Base-PP) | FILL IN |
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, T.FLAWAPP, or T.PERSISTENT 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 | |
A.MOBILE_DEVICE_PLATFORM | |
A.PROPER_ADMIN | |
A.PROPER_USER | |
P.ACCOUNTABILITY | |
P.ADMIN | |
P.DEVICE_ENROLL | |
P.NOTIFY |
The objectives for the TOEs are consistent with the MDM Agents 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.COMMS objective by ensuring that the communications related to MDM Agent functionality are secured in the same manner as other sensitive data transmitted to/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 MDM Agents 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.EAVESDROP and T.NETWORK 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, but 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.MOBILE_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 associate any availability metrics with 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 MDM Agents 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/TRUSTCHAN | The Base-PP defines 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/TRUSTPATH | 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 | |
FAU_GEN.1/AUDITGEN | |
FAU_SEL.1/EVENTSEL | |
FIA_ENR_EXT.2 | |
FMT_POL_EXT.2 | |
FMT_SMF_EXT.4 | |
FMT_UNR_EXT.1 | |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
FAU_STG_EXT.3 | |
FPT_NET_EXT.1 | |
Implementation-dependent SFRs | |
This PP-Module does not define any Implementation-dependent requirements. | |
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 | |
A.MOBILE_DEVICE_PLATFORM | |
A.PROPER_ADMIN | |
A.PROPER_USER | |
P.ACCOUNTABILITY | |
P.ADMIN | |
P.DEVICE_ENROLL | |
P.NOTIFY |
The objectives for the TOEs 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 this same objective with the same purpose. |
OE.DATA_PROPER_USER | The MDM PP contains this same objective with the same purpose. |
OE.IT_ENTERPRISE | The MDM PP contains this same objective with the same purpose. |
OE.MOBILE_DEVICE_PLATFORM | The MDM PP contains this same objective with the same purpose. |
OE.WIRELESS_NETWORK | The MDM PP contains this same objective with the same purpose. |
PP-Module Requirement | Consistency Rationale |
---|---|
Modified SFRs | |
This PP-Module does not modify any requirements when the MDM PP is the base. | |
Additional SFRs | |
FCS_STG_EXT.1/KEYSTO | 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 | |
FAU_GEN.1/AUDITGEN | |
FAU_SEL.1/EVENTSEL | |
FIA_ENR_EXT.2 | |
FMT_POL_EXT.2 | |
FMT_SMF_EXT.4 | |
FMT_UNR_EXT.1 | |
Optional SFRs | |
This PP-Module does not define any Optional requirements. | |
Objective SFRs | |
FAU_STG_EXT.3 | |
FPT_NET_EXT.1 | |
Implementation-dependent SFRs | |
This PP-Module does not define any Implementation-dependent requirements. | |
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 Implementation-dependent SFRs.
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 (Agent) 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(2) 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] |
Acronym | Meaning |
---|---|
API | Application Programming Interface |
Base-PP | Base Protection Profile |
BYOD | Bring Your Own Device |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
COPE | Corporately Owned, Personally Enabled |
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 |
IP | Internet Protocol |
IPSec | Internet Protocol Security |
MAS | Mobile Application Store |
MD | Mobile Device |
MDF | Mobile Device Fundamentals |
MDM | Mobile Device Management |
OE | Operational Environment |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
RBG | Random Bit Generation |
SAR | Security Assurance Requirement |
SD | Supporting Document |
SFR | Security Functional Requirement |
ST | Security Target |
ST | Security Target |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
VPN | Virtual Private Network |
WiFi | Wireless Fidelity |
Identifier | Title |
---|---|
[CC] | Common Criteria for Information Technology Security Evaluation -
|