PP-Module for MDM AgentsVersion: 1.02019-04-25National Information Assurance Partnership
Foreword
This is a Supporting Document (SD), intended to complement the Common Criteria version 3
and the associated Common Evaluation Methodology for
Information Technology Security Evaluation.
SDs may be “Guidance Documents”, that highlight specific approaches
and application of the standard to areas where no mutual recognition of
its application is required, and as such, are not of normative nature,
or “Mandatory Technical Documents”, whose application is mandatory for evaluations
whose scope is covered by that of the SD.
The usage of the latter class is not only mandatory, but certificates
issued as a result of their application are recognized under the CCRA.
Technical Editor:
National Information Assurance Partnership (NIAP)
Document history:
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.
General Purpose:
The purpose of this SD is to define evaluation methods for the functional behavior of
products.
Acknowledgements:
This SD was developed with support from NIAP
Technical Community members, with representatives from industry, Government
agencies, Common Criteria Test Laboratories, and members of academia.
1.1 Technology Area and Scope of Supporting Document
The scope of the MDM Agents PP-Module is
to describe the security functionality of a
Mobile Device Management Agent in terms of
[CC] and to define functional and assurance requirements for them.
The PP-Module is intended for use with the
following Base-PPs:
This SD is mandatory for evaluations of TOEs that claim conformance to a PP-Configuration that includes the PP-Module for MDM Agents, Version 1.0.
Although Evaluation Activities are defined mainly for the evaluators to follow, in general they also help Developers to prepare for evaluation by identifying specific requirements for their TOE.
The specific requirements in Evaluation Activities may in some cases clarify the meaning of Security
Functional Requirements (SFR), and may identify particular requirements for the content of Security
Targets (ST) (especially the TOE Summary Specification), user guidance documentation, and possibly
supplementary information (e.g. for entropy analysis or cryptographic key management architecture).
1.2 Structure of the Document
Evaluation Activities can be defined for both SFRs and Security Assurance Requirements (SAR),
which are themselves defined in separate sections of the SD.
If any Evaluation Activity cannot be successfully completed in an evaluation then
the overall verdict for the evaluation is a 'fail'.
In rare cases there may be acceptable reasons why an Evaluation Activity
may be modified or deemed not applicable for a particular TOE,
but this must be approved by the Certification Body for the evaluation.
In general, if all Evaluation Activities (for both SFRs and SARs) are successfully
completed in an evaluation then it would be expected that the overall verdict for
the evaluation is a ‘pass’.
To reach a ‘fail’ verdict when the Evaluation Activities have been successfully
completed would require a specific justification from the evaluator as to why the
Evaluation Activities were not sufficient for that TOE.
Similarly, at the more granular level of Assurance Components, if the Evaluation
Activities for an Assurance Component and all of its related SFR Evaluation
Activities are successfully completed in an evaluation then it would be expected
that the verdict for the Assurance Component is a ‘pass’.
To reach a ‘fail’ verdict for the Assurance Component when these Evaluation
Activities have been successfully completed would require a specific justification
from the evaluator as to why the Evaluation Activities were not sufficient for that TOE.
1.3 Terms
Common Criteria Terms
The following definitions are for Common Criteria terms used in this document:
Base Protection Profile (Base-PP)
Protection Profile used to build a PP-Configuration.
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.
Protection Profile (PP)
An implementation-independent set of security requirements for a category
of products.
A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module.
Protection Profile Module (PP-Module)
An implementation-independent statement of security needs for a TOE type
complementary to one or more Base Protection Profiles.
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 security functionality of 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.
Technical Terms
The following definitions define Technical terms used in this document:
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.
2 Evaluation Activities for SFRs
The EAs presented in this section capture the actions the evaluator performs
to address technology specific aspects covering specific SARs (e.g. ASE_TSS.1,
ADV_FSP.1, AGD_OPE.1, and ATE_IND.1) – this is in addition to the CEM work units
that are performed in 6 Evaluation Activities for SARs.
Regarding design descriptions (designated by the subsections labelled TSS, as
well as any required supplementary material that may be treated as proprietary),
the evaluator must ensure there is specific information that satisfies the EA.
For findings regarding the TSS section, the evaluator’s verdicts will be
associated with the CEM work unit ASE_TSS.1-1.
Evaluator verdicts associated with the supplementary evidence will also be
associated with ASE_TSS.1-1,
since the requirement to provide such evidence is specified in ASE in the cPP.
For ensuring the guidance documentation provides sufficient information for
the administrators/users as it pertains to SFRs, the evaluator’s verdicts will
be associated with CEM work units ADV_FSP.1-7, AGD_OPE.1-4, and AGD_OPE.1-5.
Finally, the subsection labelled Tests is where the authors have determined
that testing of the product in the context of the associated SFR is necessary.
While the evaluator is expected to develop tests, there may be instances where
it is more practical for the developer to construct tests, or where the
developer may have existing tests.
Therefore, it is acceptable for the evaluator to witness developer-generated
tests in lieu of executing the tests.
In this case, the evaluator must ensure the developer’s tests are executing both
in the manner declared by the developer and as mandated by the EA.
The CEM work units that are associated with the EAs specified in this section
are: ATE_IND.1-3, ATE_IND.1-4, ATE_IND.1-5, ATE_IND.1-6, and ATE_IND.1-7.
2.1 Mobile Device Fundamentals Protection Profile
The EAs defined in this section are only applicable in cases where the TOE claims conformance
to a PP-Configuration that includes the MDF PP.
2.1.1 Modified SFRs
The PP-Module does not modify any requirements when the
MDF PP is the base.
2.1.2 Additional SFRs
2.1.2.1 Cryptographic Support (FCS)
FCS_STG_EXT.4 Cryptographic Key Storage
TSS
The evaluator will verify that the TSS lists each persistent
secret (credential, secret key) and private key needed to meet the requirements in
the ST. For each of these items, the evaluator will confirm that
the TSS lists for what purpose it is used, and, for each
platform listed as supported in the ST, how it is stored. The
evaluator shall verify that the Agent calls a platform-provided API to store
persistent secrets and private keys.
2.1.2.2 Trusted Path/Channels (FTP)
FTP_ITC_EXT.1(2) Trusted Channel Communication
TSS
The evaluator shall examine the TSS to determine that the
methods of Agent-Server communication are indicated, along with how those
communications are protected. The evaluator shall also confirm that all protocols
listed in the TSS in support of remote TOE
administration are consistent with those specified in the requirement, and are
included in the requirements in the ST.
Guidance
The evaluator shall confirm that the operational guidance contains
instructions for configuring the communication channel between the MDM Agent and
the MDM Server and conditionally, the MAS Server for each supported
method.
Tests
For each supported identifier type (excluding DNs), the evaluator shall
repeat the following tests:
Test 1: The evaluators shall ensure that communications using each specified (in
the operational guidance) Agent-Server communication method is tested during
the course of the evaluation, setting up the connections as described in the
operational guidance and ensuring that communication is
successful.
Test 2: The evaluator shall ensure, for each method of Agent-Server communication,
the channel data is not sent in plaintext.
Test 3: The evaluator shall ensure, for each communication channel with the MDM
Server, that a protocol analyzer identifies the traffic as the protocol under
testing.
Further evaluation activities are associated with the specific protocols.
FTP_TRP.1(2) Trusted Path (for Enrollment)
TSS
The evaluator shall examine the TSS to determine that the
methods of remote enrollment are indicated, along with how those communications
are protected. The evaluator shall also confirm that all protocols listed in the
TSS in support of enrollment are consistent with those
specified in the requirement, and are included in the requirements in the ST.
Guidance
The evaluator shall confirm that the operational guidance contains
instructions for establishing the enrollment sessions for each supported
method.
Tests
For each MDM Agent/platform listed as supported in the
ST:
Test 1: The evaluators shall ensure that communications using each specified (in
the operational guidance) enrollment method is tested during the course of the
evaluation, setting up the connections as described in the operational
guidance and ensuring that communication is successful.
Test 2: For each method of enrollment supported, the evaluator shall follow the
operational guidance to ensure that there is no available interface that can
be used by a remote user to establish enrollment sessions without invoking the
trusted path.
Test 3: The evaluator shall ensure, for each method enrollment, the channel data
is not sent in plaintext.
Further evaluation activities are associated with the specific protocols.
2.2 Mobile Device Management Protection Profile
The EAs defined in this section are only applicable in cases where the TOE claims conformance
to a PP-Configuration that includes the MDM PP.
2.2.1 Modified SFRs
The PP-Module does not modify any requirements when the
MDM PP is the base.
2.2.2 Additional SFRs
2.2.2.1 Cryptographic Support (FCS)
FCS_STG_EXT.1(2) Cryptographic Key Storage
TSS
The evaluator will verify that the TSS lists each persistent
secret (credential, secret key) and private key needed to meet the requirements in
the ST. For each of these items, the evaluator will confirm that
the TSS lists for what purpose it is used, and, for each
platform listed as supported in the ST, how it is stored. The
evaluator shall verify that the Agent calls a platform-provided API to store
persistent secrets and private keys.
2.2.3 TOE SFR Evaluation Activities
2.2.4 Security Audit (FAU)
FAU_ALT_EXT.2 Agent Alerts
TSS
The evaluator shall examine the TSS and verify that it describes how the alerts are implemented.
The evaluator shall examine the TSS and verify that it describes how the candidate policy updates are obtained and the actions that take place for successful (policy update installed) and unsuccessful (policy update not installed) cases. The software components that are performing the processing must also be identified in the TSS and verified by the evaluator.
The evaluator also ensures that the TSS describes how reachability events are implemented, and if configurable are selected in FMT_SMF_EXT.4.2. The evaluator verifies that this description clearly indicates who (MDM Agent or MDM Server) initiates reachability events.
The evaluator shall ensure that the TSS describes under what circumstances, if any, the alert may not be generated (e.g., the device is powered off or disconnected from the trusted channel), how alerts are queued, and the maximum amount of storage for queued messages.
Tests
Test 1: The evaluator shall perform a policy update from the test environment MDM server. The evaluator shall verify the MDM Agent accepts the update, makes the configured changes, and reports the success of the policy update back to the MDM Server.
Test 2: The evaluator shall perform each of the actions listed in FAU_ALT_EXT.2.1 and verify that the alert does in fact reach the MDM Server.
Test 3: The evaluator shall configure the MDM Agent to perform a network reachability test, both with and without such connectivity and ensure that results reflect each.
Test 4: The evaluator shall remove network connectivity from the MDM Agent and generate an alert/event as defined in FAU_ALT_EXT.2.1. The evaluator shall restore network connectivity to the MDM Agent and verify that the alert generated while the TOE was disconnected is sent by the MDM Agent upon re-establishment of the connectivity.
FAU_GEN.1(2) Audit Data Generation
TSS
The evaluator shall check the TSS and ensure that it provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field.
If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM Agent; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).
Tests
The evaluator shall use the TOE to perform the auditable
events defined in the Auditable Events table in FAU_GEN.1.1(2) and observe that
accurate audit records are generated with contents and formatting consistent with
those described in the TSS. Note that this testing can be
accomplished in conjunction with the testing of the security mechanisms
directly.
FAU_SEL.1(2) Security Audit Event Selection
TSS
If "invoke platform-provided functionality" is selected, the evaluator shall
examine the TSS of the ST to verify that it
describes (for each supported platform) how this functionality is invoked (it should
be noted that this may be through a mechanism that is not implemented by the MDM
Agent; nonetheless, that mechanism will be identified in the TSS
as part of this evaluation activity).
Guidance
The evaluator shall examine the operational guidance to determine that it
contains instructions on how to define the set of auditable events as well as
explains the syntax for multi-value selection (if applicable). The evaluator shall
also verify that the operational guidance shall identify those audit records that
are always recorded, regardless of the selection criteria currently being
enforced.
Tests
Test 1: For each attribute listed in the requirement, the evaluator shall devise a
test to show that selecting the attribute causes only audit events with that
attribute (or those that are always recorded, as identified in the
administrative guidance) to be recorded.
Test 2: [conditional]: If the TSF supports specification of more complex audit
pre-selection criteria (e.g., multiple attributes, logical expressions using
attributes) then the evaluator shall devise tests showing that this capability
is correctly implemented. The evaluator shall also, in the test plan, provide a
short narrative justifying the set of tests as representative and sufficient to
exercise the capability.
2.2.5 Identification and Authentication (FIA)
FIA_ENR_EXT.2 Agent Enrollment of Mobile Device into Management
TSS
The evaluator shall examine the TSS to verify that it describes
which types of reference identifiers are acceptable and how the identifier is
specified (e.g. preconfigured in the MDM Agent, by the user, by
the MDM server, in a policy).
Guidance
The evaluator shall examine the operational guidance to verify that it
describes how to configure reference identifier of the MDM
Server’s certificate and, if different than the reference identifier, the Domain
Name or IP address (for connectivity) of the MDM
Server.
Tests
The evaluator shall follow the operational guidance to establish the reference
identifier of the MDM server on the MDM Agent
and in conjunction with other evaluation activities verify that the MDM Agent can connect to the MDM Server and validate
the MDM Server’s certificate.
2.2.6 Security Management (FMT)
FMT_POL_EXT.2 Agent Trusted Policy Update
TSS
The evaluator ensures that the TSS describes how the candidate policies are obtained by the MDM Agent, the processing associated with verifying the digital signature of the policy updates, and the actions that take place for successful (signature was verified) and unsuccessful (signature could not be verified) cases. The software components that are performing the processing must also be identified in the TSS and verified by the evaluators.
Tests
This evaluation activity is performed in conjunction with the evaluation activity for FIA_X509_EXT.1 and FIA_X509_EXT.2 as defined in the Base-PPs.
Test 1: The evaluator shall perform a policy update from an available configuration interface (such as through a test MDM Server). The evaluator shall verify the update is signed and is provided to the MDM Agent. The evaluator shall verify the MDM Agent accepts the digitally signed policy.
Test 2: The evaluator shall perform a policy update from an available configuration interface (such as through a test MDM Server). The evaluator shall provide an unsigned and an incorrectly signed policy to the MDM Agent. The evaluator shall verify the MDM Agent does not accept the digitally signed policy.
FMT_SMF_EXT.4 Specification of Management Functions
TSS
The evaluator shall verify that the any assigned functions are described in the TSS and that these functions are documented as supported by the platform. The evaluator shall examine the TSS to verify that any differences between management functions and policies for each supported mobile device are listed.
The evaluator shall verify that the TSS describes the methods in which the MDM Agent can be enrolled.
The TSS description shall make clear if the MDM Agent supports multiple interfaces for enrollment and configuration (for example, both remote configuration and local configuration).
Guidance
The evaluator shall verify the AGD guidance includes detailed instructions for configuring each function in this requirement.
If the MDM Agent is a component of the MDM system (i.e. MDM Server is the Base-PP), the evaluator shall verify, by consulting documentation for the claimed mobile device platforms, that the configurable functions listed for this Agent are supported by the platforms.
If the MDM Agent supports multiple interfaces for configuration (for example, both remote configuration and local configuration), the AGD guidance makes clear whether some functions are restricted to certain interfaces.
Tests
Test 1: In conjunction with the evaluation activities in the Base-PP, the evaluator shall attempt to configure each administrator-provided management function and shall verify that the mobile device executes the commands and enforces the policies.
Test 2: The evaluator shall configure the MDM Agent authentication certificate in accordance with the configuration guidance. The evaluator shall verify that the MDM Agent uses this certificate in performing the tests for FPT_ITT.1.
Test 3: In conjunction with other evaluation activities, the evaluator shall attempt to enroll the MDM Agent in management with each interface identified in the TSS, and verify that the MDM Agent can manage the device and communicate with the MDM Server.
Test 4: [conditional] In conjunction with the evaluation activity for FAU_ALT_EXT.2.1, the evaluator shall configure the periodicity for reachability events for several configured time periods and shall verify that the MDM Server receives alerts on that schedule.
Test 5: [conditional] The evaluator shall design and perform tests to demonstrate that the assigned function may be configured and that the intended behavior of the function is enacted by the mobile device.
FMT_UNR_EXT.1 User Unenrollment Prevention
TSS
The evaluator shall ensure that the TSS describes the
mechanism used to prevent users from unenrolling or the remediation actions applied
when unenrolled.
Guidance
The evaluator shall ensure that the administrative guidance instructs
administrators in configuring the unenrollment prevention in each available
configuration interface. If any configuration allows users to unenroll, the guidance
also describes the actions that unenroll the Agent.
Tests
Test 1: If ‘prevent the unenrollment from occurring’ is selected: The evaluator shall configure the Agent according to the administrative guidance for each available configuration interface, shall attempt to unenroll the device, and shall verify that the attempt fails.
Test 2: If ‘apply remediation actions’ is selected: If any configuration allows the user to unenroll, the evaluator shall configure the Agent to allow user unenrollment, attempt to unenroll, and verify that the remediation actions are applied.
3 Evaluation Activities for Optional SFRs
The PP-Module does not define any optional requirements.
4 Evaluation Activities for Selection-Based SFRs
The PP-Module does not define any selection-based requirements.
5 Evaluation Activities for Objective SFRs
5.1 Security Audit (FAU)
FAU_STG_EXT.3 Security Audit Event Storage
TSS
The evaluator shall verify that the TSS description of the
audit records indicates how the records are stored. The evaluator shall verify that
the Agent calls a platform-provided API to store audit records.
5.2 Protection of the TSF (FPT)
FPT_NET_EXT.1 Network Reachability
TSS
The evaluator shall verify that the TSS contains a description
of how the Agent determines how long it has been since the last successful
connection with the Server (i.e., total number of missed reachability events or
time). If total number of missed reachability events is selected, the evaluator
shall verify that the TSS contains a description of how often the
reachability events are sent.
Guidance
The evaluator shall verify that the AGD guidance instructs the
administrator, if needed, how to configure the TOE to detect when
the time since last successful connection with the server has been
reached.
Tests
The evaluator shall configure the Server configuration policy of the Agent per
FMT_SMF.1.1(1) function 56 within the Mobile Device Managment PP. The device shall be placed in airplane mode to prevent
connectivity with the Server. The evaluator shall verify that after the configured
time, the remediation actions selected in function 56 occur.
6 Evaluation Activities for SARs
The PP-Module does not define any SARs beyond those defined within the
base-PP to which it must claim conformance.
It is important to note that a TOE that is evaluated against the PP-Module is
inherently evaluated against the Base-PP as well.
The Base-PP includes a number of Evaluation Activities associated with both SFRs and SARs.
Additionally, the PP-Module includes a number of SFR-based Evaluation Activities
that similarly refine the SARs of the Base-PPs.
The evaluation laboratory will evaluate the TOE against the chosen Base-PP
and supplement that evaluation with the necessary SFRs that are taken from the PP-Module.
7 Required Supplementary Information
This Supporting Document has no required supplementary information beyond the ST, operational
guidance, and testing.
Appendix A - References
Identifier
Title
[CC]
Common Criteria for Information Technology Security Evaluation -
