NIAP: View Technical Decision Details

NIAP

»»

Protection Profiles

»»

Technical Decisions

»»

View Details

TD0497: SFR Rationale, Consistency of SPD, and Implicitly Satisfied SFRs

Publication Date

2020.10.26

Protection Profiles

MOD_MDM_AGENT_V1.0

Other References

Section 5, Section 6, and Appendix H

Issue Description

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

Resolution

Section 5.4 is added as follows:

5.4 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.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(2)	The PP-Module includes FAU_GEN.1(2) to support this objective by defining the security-relevant events for which the TSF must generate audit records.
	FAU_SEL.1(2)	The PP-Module includes FAU_SEL.1(2) to support this objective by defining how the set of audited events can be configured.
	FAU_STG_EXT.3 (objective)	The PP-Module includes FAU_STG_EXT.3 to support this objective by optionally requiring the TSF to use platform-provided storage for the security-relevant audit data it generates.
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.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 (objective)	The PP-Module includes FPT_NET_EXT.1 to support this objective by optionally 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.
O.DATA_PROTECTION_TRANSIT Data exchanged between the MDM Server and the MDM Agent must be protected from being monitored, accessed, or altered.	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.
	FTP_ITC_EXT.1(2) (if MDF is Base-PP)	The PP-Module includes FTP_ITC_EXT.1(2) to support this objective because when the TOE is a mobile device, it must be required to ensure that MDM Server communications are protected.
	FTP_TRP.1(2) (if MDF is Base-PP)	The PP-Module includes FTP_ITC_EXT.1(2) to support this objective because when the TOE is a mobile device, it must be required to ensure that MDM Server enrollment communications are protected.
	FPT_ITT.1(2) (from MDM 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.
	FPT_NET_EXT.1 (objective)	The PP-Module includes FPT_NET_EXT.1 to support this objective by optionally requiring the TSF to detect when a sustained communications outage with the MDM Server has occurred as a possible indicator of communications issues.
O.STORAGE To address the issue of loss of confidentiality of user data in the event of loss of a mobile device (T.PHYSICAL), conformant TOEs will use platform provide key storage. The TOE is expected to protect its persistent secrets and private keys.	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 must be required to ensure that MDM Agent key data is stored securely.
	FCS_STG_EXT.1(2) (if MDM is Base-PP)	The PP-Module includes FCS_STG_EXT.1(2) to support this objective because when the TOE is a MDM Server with MDM Agent capability, it must be required to ensure that MDM Agent key data is stored securely.

Section 6.1.2 is replaced as follows:

6.1.2 Consistency of Security Problem Definition

The threats, assumptions, and OSPs defined by this PP-Module supplement those defined in the MDF PP as follows:

PP-Module Threat/Assumption/OSP	Consistency Rationale
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.
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 which provides networking services through various radios.
A.MOBILE_DEVICE_PLATFORM	This assumption expects that the TOE’s underlying hardware platform is validated against the MDF PP. This is consistent with the Base-PP by definition because the mobile device is within the TOE boundary and 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.

Section 6.2.2 is replaced as follows:

6.2.2 Consistency of Security Problem Definition

The threats, assumptions, and OSPs defined by this PP-Module supplement those defined in the MDM PP as follows:

PP-Module Threat/Assumption/OSP	Consistency Rationale
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.
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 general-purpose operating system 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.MOBILE_DEVICE_PLATFORM	This assumption expects that the TOE’s underlying hardware platform is validated against the MDF PP. This is consistent with the Base-PP because the portion of the TOE defined by the Base-PP runs on a general-purpose operating system 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.

Appendix H - Implicitly Satisfied Requirements is added as follows:

Appendix H - 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

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 mobile device to do this. In this case, FIA_ENR_EXT.2 and FMT_POL_EXT.1 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 mobile device. If the mobile device is part of the TOE, the MDF PP 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).

Justification

See issue description.

Site Map Contact Us Home