NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0552:  SFR Rationale and Implicitly Satisfied SFRs

Publication Date
2020.10.26

Protection Profiles
PP_MDM_V4.0

Other References
Section 6 and Appendix I

Issue Description

Evaluation of the PP during the first evaluation found failed work units. Therefore, the PP needs to be updated to add the SFR Rationale and add an Implicitly Satisfied SFRs Appendix.

Resolution

Section 6.3 is added as follows:

6.3 TOE Security Requirements Rationale

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

SFR

Rationale

O.ACCOUNTABILITY

The TOE must provide logging facilities which record management actions undertaken by its administrators.

FAU_ALT_EXT.1

The PP includes FAU_ALT_EXT.1 to define the ability of the TSF to generate alerts when certain actions occur.

FAU_GEN.1(1)

The PP includes FAU_GEN.1(1) to require the TSF to generate audit records of security-relevant events, including management actions.

FAU_NET_EXT.1

The PP includes FAU_NET_EXT.1 to require the TSF to record the connectivity status of enrolled agents.

FAU_STG_EXT.1

The PP includes FAU_STG_EXT.1 for the TSF to securely transmit its audit data to an external entity.

FAU_SAR.1 (optional)

The PP includes FAU_SAR.1 to optionally require the TSF to provide a method to review stored audit data.

FAU_SEL.1 (optional)

The PP includes FAU_SEL.1 to optionally require the TSF to define the actions that are accounted for.

FAU_GEN.1(2) (selection-based)

The PP includes FAU_GEN.1(2) to require the TSF to generate records of MAS Server functionality if the TSF supports this capability.

FAU_STG_EXT.2 (selection-based)

The PP includes FAU_STG_EXT.2 to require the TSF to protect stored audit records from unauthorized modification if these records are stored locally.

FAU_CRP_EXT.1 (objective)

The PP includes FAU_CRP_EXT.1 to optionally require the TSF to collect information about the configuration of enrolled devices.

O.APPLY_POLICY

The TOE must facilitate configuration and enforcement of enterprise security policies on mobile devices via interaction with the mobile OS and the MDM Server. This will include the initial enrollment of the device into management through its entire lifecycle, including policy updates and its possible unenrollment from management services.

FIA_ENR_EXT.1

The PP includes FIA_ENR_EXT.1 for the TSF to perform the initial enrollment of devices into management, including applying restrictions on what devices can be enrolled.

FMT_MOF.1(1)

The PP includes FMT_MOF.1(1) to define the supported TSF management functions, including those used to enable, disable, and apply policies to enrolled devices.

FMT_MOF.1(2)

The PP includes FMT_MOF.1(2) for the TSF to restrict the enrollment process to authorized administrators and mobile device users.

FMT_SMF.1(1)

The PP includes FMT_SMF.1(1) to specify that the TSF is capable of sending configuration information and enterprise security policies to an MDM Agent.

FMT_MOF.1(3) (selection-based)

The PP includes FMT_MOF.1(3) to enforce restrictions on access to the MAS Server from enrolled devices based on applied policies.

FMT_SMF.1(3) (selection-based)

The PP includes FMT_SMF.1(3) to specify that the TSF is capable of configuring the MAS Server to enforce restrictions on enrolled devices attempting to access it.

FMT_SMR.1(2) (selection-based)

The PP includes FMT_SMR.1(2) to define roles on the MAS Server, if this capability is supported, that are used to determine the extent to which enrolled devices can access data on the MAS Server.

FIA_UAU_EXT.4(1) (objective)

 

The PP includes FIA_UAU_EXT.4(1) to optionally require the TSF to limit enrollment through the prevention of reuse of enrollment authentication data.

FIA_UAU_EXT.4(2) (objective)

The PP includes FIA_UAU_EXT.4(2) to provide access controls to prevent the reuse of enrollment data related to device enrollment. The TSF shall prevent two devices to be enrolled using the same unique identifier.

FMT_SAE_EXT.1 (objective)

The PP includes FMT_SAE_EXT.1 for the TSF to enforce restriction on agent enrollment by limiting the length of time that enrollment authentication data is valid.

O.DATA_PROTECTION_TRANSIT

Data exchanged between the MDM Server and the MDM Agent must be protected from being monitored, accessed, or altered.

FAU_STG_EXT.1

The PP includes FAU_STG_EXT.1 which requires the TSF to use a trusted channel for the external transmission of audit data.

FCS_CKM_EXT.4

The PP includes FCS_CKM_EXT.4 to ensure that the TSF destroys plaintext keying material and critical security parameters when no longer needed in support of securing data in transit.

FCS_CKM.1

The PP includes FCS_CKM.1(1) to define whether the TSF or the platform generates asymmetric keys that are used in support of securing data in transit.

FCS_CKM.2

The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment in support of securing data in transit.

FCS_COP.1(1)

The PP includes FCS_COP.1(1) to define the symmetric AES encryption algorithms used in support of securing data in transit.

FCS_COP.1(2)

The PP includes FCS_COP.1(2) to define the hash algorithms used in support of securing data in transit.

FCS_COP.1(3)

The PP includes FCS_COP.1(3) to define the digital signature algorithms used in support of securing data in transit.

FCS_COP.1(4)

The PP includes FCS_COP.1(4) to define the HMAC algorithms used in support of securing data in transit.

FCS_RBG_EXT.1

The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. The TOE may rely on the use of a random bit generator to create keys that are subsequently used in support of securing data in transit.

FCS_STG_EXT.1

The PP includes FCS_STG_EXT.1 to define whether the TSF or the Operational Environment protects key data that may be used in support of securing data in transit.

FIA_ENR_EXT.1

The PP includes FIA_ENR_EXT.1 which requires the TSF to use a trusted channel for the agent enrollment process.

FIA_X509_EXT.1(1)

The PP includes FIA_X509_EXT.1(1) to define validation rules for X.509 certificates that may be used in support of securing data in transit.

FIA_X509_EXT.2

The PP includes FIA_X509_EXT.2 to define the TOE functions that support the use of X.509 certificates. This includes protection of data in transit.

FIA_X509_EXT.5

The PP includes FIA_X509_EXT.5 to require the TSF to enforce uniqueness for client certificates that are used in support of securing data in transit.

FTP_ITC_EXT.1

The PP includes FTP_ITC_EXT.1 to

define the trusted channels used by the TOE where security of data in transit is enforced.

FTP_ITC.1(1)

The PP includes FTP_ITC.1(1) to define a trusted communication channel between itself and trusted external servers.

FTP_TRP.1(1)

The PP includes FTP_TRP.1(1) to define requirements for securing data in transit for administrative communications.

FTP_TRP.1(2)

The PP includes FTP_TRP.1(2) to define requirements for securing data in transit for agent enrollment.

FCS_HTTPS_EXT.1 (selection-based)

The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol.

FCS_IV_EXT.1 (selection-based)

The PP includes FCS_IV_EXT.1 to define the initialization vector generation to ensure secure implementation of cryptography used to secure data in transit.

FCS_STG_EXT.2 (selection-based)

The PP includes FCS_STG_EXT.2 to define the method the TSF uses to protect stored key data that may be used in support of securing data in transit.

FIA_X509_EXT.1(2) (selection-based)

The PP includes FIA_X509_EXT.1(1) to define validation rules for X.509 certificates that may be used in support of securing data in transit in the specific case where the TOE is distributed across multiple remote nodes.

FPT_ITT.1(1) (selection-based)

The PP includes FPT_ITT.1(1) to define how data is secured in transit between TOE components if the MDM server itself is distributed.

FPT_ITT.1(2) (selection-based)

The PP includes FPT_ITT.1(2) to define how data is secured in transit between the MDM server and MDM agent if both are part of the TOE.

FTP_ITC.1(2) (selection-based)

The PP includes FTP_ITC.1(1) to define a trusted communication channel between itself and an MDM agent if the MDM agent is not part of the TOE.

FAU_CRP_EXT.1 (objective)

The PP includes FAU_CRP_EXT.1 to require certain data to be collected from remote agents using a secure channel.

FCO_CPC_EXT.1 (objective)

The PP includes FCO_CPC_EXT.1 to define secure connectivity between different TOE components, including security of data in transit.

FIA_X509_EXT.3 (objective)

The PP includes FIA_X509_EXT.3 to define X.509 enrollment activities using PKCS#10 to allow the TOE to obtain a signed certificate for use when establishing trusted communications.

FIA_X509_EXT.4 (objective)

The PP includes FIA_X509_EXT.3 to define X.509 enrollment activities using EST to allow the TOE to obtain a signed certificate for use when establishing trusted communications.

FTP_TRP.1(3) (objective)

The PP includes FTP_TRP.1(3) to define requirements for securing data in transit between TOE components when establishing initial connectivity if the MDM server itself is distributed and a separate registration channel is used.

O.INTEGRITY

The TOE will provide the capability to perform self tests to ensure the integrity of critical functionality, software, firmware, and data has been maintained. The TOE will also provide a means to verify the integrity of downloaded updates.

FCS_COP.1(2)

The PP includes FCS_COP.1(2) to require the TSF to include a mechanism to cryptographically assert and verity the integrity of data using a hash algorithm.

FCS_COP.1(3)

The PP includes FCS_COP.1(3) to require the TSF to include a mechanism to cryptographically assert and verify the integrity of data using a digital signature.

FIA_X509_EXT.2

The PP includes FIA_X509_EXT.2 to define the TOE functions that support the use of X.509 certificates. This includes code signing for system software updates, integrity verification, and policy signing.

FMT_POL_EXT.1

The PP includes FMT_POL_EXT.1 to ensure the integrity of the policies and policy updates to the MDM Agent are digitally signed to protect their integrity.

FPT_TST_EXT.1

The PP includes FPT_TST_EXT.1 to require The TSF to run a suite of self tests to ensure the correct operation of the TSF and the integrity of stored TSF executable code.

FPT_TUD_EXT.1

The PP includes FPT_TUD_EXT.1 to define requirements for trusted update of TSF executable code, including that the integrity of this update data can be verified.

O.MANAGEMENT

The TOE provides access controls around its management functionality.

FIA_UAU.1

The PP includes FIA_UAU.1 to require the TSF to enforce access control on its management interface by requiring user authentication.

FMT_MOF.1(1)

The PP includes FMT_MOF.1(1) for the TSF to restrict the functions to enable, disable, modify, and monitor functions and policies to authorized administrators.

FMT_MOF.1(2)

The PP includes FMT_MOF.1(2) to restrict the enrollment process to authorized administrators and mobile device users.

FMT_SMF.1(1)

The PP includes FMT_SMF.1(1) to define the security-relevant management functions that the MDM server is capable of communicating to the MDM Agent.

FMT_SMF.1(2)

The PP includes FMT_SMF.1(2) to define the security-relevant management functions that the MDM server has for its own configuration.

FMT_SMR.1(1)

The PP includes FMT_SMR.1(1) to define the security management roles that are used as the basis for access control enforcement.

FAU_SAR.1 (optional)

The PP includes FAU_SAR.1 to optionally require the TSF to implement management functionality to review audit data that is restricted to authorized users.

FAU_SEL.1 (optional)

The PP includes FAU_SEL.1 to optionally require the TSF to implement management functionality for configuring the events that are audited.

FTA_TAB.1 (optional)

The PP includes FTA_TAB.1 to display an Administrator-specified advisory notice and consent warning message regarding use of the TOE.

FMT_SMF.1(3) (selection-based)

The PP includes FMT_SMF.1(3) to define the MAS Server management functionality if this capability is supported.

FMT_SMR.1(2) (selection-based)

The PP includes FMT_SMR.1(2) to define the management roles that apply to the MAS Server if this capability is supported.

O.QUALITY

To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs.

FPT_API_EXT.1

The PP includes FPT_API_EXT.1 to enforce quality of implementation by ensuring that the MDM software uses only documented platform APIs to supports its security functionality.

FPT_LIB_EXT.1

The PP includes FPT_LIB_EXT.1 to

enforce quality of implementation by ensuring that the MDM software does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability.

 

Appendix I - Implicitly Satisfied Requirements is added as follows:

Appendix I - Implicitly Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP-Module. However, 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

FIA_UID.1 – Timing of Identification

FIA_UAU.1 has a dependency on FIA_UID.1 because authentication of an external entity requires that entity to first identify itself so that its identity can be validated by the authentication process.

This SFR has not been defined in this PP-Module because authentication of a user implicitly requires them to be identified as well.

There are two cases in which a user must be authenticated by the TSF per the application note in FIA_UAU.1: enrollment of a user’s mobile device into management, and authentication of a user to the TOE’s management interface. FIA_ENR_EXT.1 requires authentication of the user using a method such as a directory server, which implicitly expects that the user must identify themselves as well as provide a credential associated with the claimed identity. For management, FMT_SMR.1(1) requires the TSF to maintain an administrator role but it does not specify whether authentication to this role is role-based or identity-based. Therefore, the PP is not concerned with the specific mechanism by which an administrator presents their identity to the TSF, only that there is a mechanism to validate and authorize whatever information they do present.

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.

The PP allows FAU_SEL.1 to be implemented either by the TSF or by the TOE platform because the TOE may rely on the audit functionality provided by the OS it runs on. If this is configured entirely through the platform, the administrator does not necessarily need to be authenticated by the TOE to do this. Therefore, requiring FMT_MTD.1 does not make sense in this situation. If this is configured through the TOE, it can be implied from a review of FMT_SMR.1(1) that the ‘MD user’ role cannot perform this function as they lack the authority to manage the TSF. It is therefore understood that this function can be performed by the ‘administrator’ role or potentially by one or more roles specified by the ST author if the selection to specify additional roles is chosen. An additional SFR that explicitly identifies the roles permitted to manage this function is redundant in this context.

FPT_STM.1 – Reliable time stamps

The PP’s iterations of FAU_GEN.1 as well as its cryptographic functionality have a dependency on FPT_STM.1 because audit records require accurate timestamps as well as some cryptographic operations, such as determining if a presented X.509 certificate is expired. The TOE is installed on a general-purpose computer or specialized network device that is assumed to have the ability to provide certain functions to the TOE as specified in A.MDM_SERVER_PLATFORM. This assumption explicitly lists ‘reliable timestamps’ as a function that the TSF is expected to have available to it.

 

 

 

Justification

see issue description.

 
 
Site Map              Contact Us              Home