National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
Samsung SDS Co., LTD
Samsung SDS EMM and EMM Agent
for Android version 2.2.5
Report Number: CCEVS-VR-11013-2020
Dated: 27 January 2020
Version: 0.2
National Institute of Standards and Technology National Security Agency
Information Technology Laboratory Information Assurance Directorate
100 Bureau Drive 9800 Savage Road STE 6940
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6940
®
TM
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
ii
ACKNOWLEDGEMENTS
Validation Team
Sheldon Durrant
John Butterworth
Jenn Dotson
Clare Olin
Michelle Carlson
Randy Heimann
The MITRE Corporation
Common Criteria Testing Laboratory
Cornelius Haley
Raymond Smoley
Kevin Cummins
Gossamer Security Solutions, Inc.
Catonsville, MD
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
iii
Table of Contents
1 Executive Summary.................................................................................................... 1
2 Identification............................................................................................................... 1
3 Architectural Information ........................................................................................... 3
3.1 TOE Evaluated Platforms ................................................................................... 4
3.2 TOE Architecture................................................................................................ 4
3.3 Physical Boundaries............................................................................................ 4
4 Security Policy............................................................................................................ 5
4.1 Security audit ...................................................................................................... 5
4.2 Cryptographic support ........................................................................................ 5
4.3 User data protection ............................................................................................ 5
4.4 Identification and authentication......................................................................... 5
4.5 Security management.......................................................................................... 5
4.6 Protection of the TSF.......................................................................................... 6
4.7 TOE access.......................................................................................................... 6
4.8 Trusted path/channels ......................................................................................... 6
5 Assumptions................................................................................................................ 6
6 Documentation............................................................................................................ 6
7 IT Product Testing ...................................................................................................... 6
7.1 Developer Testing............................................................................................... 7
7.2 Evaluation Team Independent Testing ............................................................... 7
8 Evaluated Configuration ............................................................................................. 7
9 Results of the Evaluation ............................................................................................ 7
9.1 Evaluation of the Security Target (ASE) ............................................................ 8
9.2 Evaluation of the Development (ADV) .............................................................. 8
9.3 Evaluation of the Guidance Documents (AGD) ................................................. 8
9.4 Evaluation of the Life Cycle Support Activities (ALC) ..................................... 8
9.5 Evaluation of the Test Documentation and the Test Activity (ATE) ................. 9
9.6 Vulnerability Assessment Activity (VAN)......................................................... 9
9.7 Summary of Evaluation Results.......................................................................... 9
10 Validator Comments/Recommendations .................................................................... 9
11 Annexes....................................................................................................................... 9
12 Security Target............................................................................................................ 9
13 Glossary .................................................................................................................... 10
14 Bibliography ............................................................................................................. 10
i
1 Executive Summary
This report documents the assessment of the National Information Assurance Partnership
(NIAP) validation team of the evaluation of Samsung SDS EMM and EMM Agent for
Android version 2.2.5 solution provided by Samsung SDS Co., LTD. It presents the
evaluation results, their justifications, and the conformance results. This Validation
Report is not an endorsement of the Target of Evaluation by any agency of the U.S.
government, and no warranty is either expressed or implied.
The evaluation was performed by the Gossamer Security Solutions (Gossamer) Common
Criteria Testing Laboratory (CCTL) in Catonsville, MD, United States of America, and
was completed in January 2020. The information in this report is largely derived from the
Evaluation Technical Report (ETR) and associated test reports, all written by Gossamer
Security Solutions. The evaluation determined that the product is both Common Criteria
Part 2 Extended and Part 3 Conformant, and meets the assurance requirements of EAL 1.
The Target of Evaluation (TOE) is the Samsung SDS EMM and EMM Agent for Android
version 2.2.5.
The Target of Evaluation (TOE) identified in this Validation Report has been evaluated at
a NIAP approved Common Criteria Testing Laboratory using the Common Methodology
for IT Security Evaluation (Version 3.1, Rev 5) for conformance to the Common Criteria
for IT Security Evaluation (Version 3.1, Rev 5). This Validation Report applies only to
the specific version of the TOE as evaluated. The evaluation has been conducted in
accordance with the provisions of the NIAP Common Criteria Evaluation and Validation
Scheme and the conclusions of the testing laboratory in the evaluation technical report
are consistent with the evidence provided.
The validation team monitored the activities of the evaluation team, provided guidance
on technical issues and evaluation processes, and reviewed the individual work units and
successive versions of the ETR. The validation team found that the evaluation showed
that the product satisfies all of the functional requirements and assurance requirements
stated in the Security Target (ST). Therefore the validation team concludes that the
testing laboratory’s findings are accurate, the conclusions justified, and the conformance
results are correct. The conclusions of the testing laboratory in the evaluation technical
report are consistent with the evidence produced.
The Gossamer Security Solutions evaluation team concluded that the Common Criteria
requirements for Evaluation Assurance Level (EAL) 1.
The technical information included in this report was obtained from the Samsung SDS
Co. Ltd. EMM and EMM Agent for Android (MDMPP40/MDMA10/PKGTLS11)
Security Target,Version 0.9, 27 January 2020 and analysis performed by the Validation
Team.
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of
Standards and Technology (NIST) effort to establish commercial facilities to perform
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
ii
trusted product evaluations. Under this program, security evaluations are conducted by
commercial testing laboratories called Common Criteria Testing Laboratories (CCTLs)
using the Common Evaluation Methodology (CEM) for Evaluation Assurance Level
(EAL) 1 through 4 in accordance with National Voluntary Laboratory Assessment
Program (NVLAP) accreditation.
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality
and consistency across evaluations. Developers of information technology products
desiring a security evaluation contract with a CCTL and pay a fee for their product’s
evaluation. Upon successful completion of the evaluation, the product is added to
NIAP’s Validated Products List.
Table 1 provides information needed to completely identify the product, including:
• The Target of Evaluation (TOE): the fully qualified identifier of the product as
evaluated.
• The Security Target (ST), describing the security features, claims, and assurances of
the product.
• The conformance result of the evaluation.
• The Protection Profile to which the product is conformant.
• The organizations and individuals participating in the evaluation.
Table 1: Evaluation Identifiers
Item Identifier
Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme
TOE Samsung SDS EMM and EMM Agent for Android version 2.2.5
Protection Profile
(Specific models identified in Section 3.1)
PP-Configuration for Mobile Device Management (MDM) and MDM Agents,
Version 1.0, 2020-01-27
• The PP-Configuration is comprised of the following:
o Protection Profile for Mobile Device Management, Version 4.0, 2019-04-
25 (MDMPP40) with the following technical decisions: TD0438,
TD0461, and TD0467 and the following packages:
Functional Package for Transport Layer Security (TLS), Version 1.1, 1
March 2019 (PKGTLS11) with the following technical decisions:
TD0442 and TD0469
o PP-Module for MDM Agents, Version 1.0, 2019-04-25 (MDMA10) with
the following technical decisions: TD0497
ST Samsung SDS Co. Ltd. EMM and EMM Agent for Android
(MDMPP40/MDMA10/PKGTLS11) Security Target, Version 0.9, 27 January
2020
Evaluation Technical
Report
Evaluation Technical Report for Samsung SDS EMM and EMM Agent for
Android version 2.2.5, version 0.3, 27 January 2020
CC Version Common Criteria for Information Technology Security Evaluation, Version 3.1,
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
iii
Item Identifier
rev 5
Conformance Result CC Part 2 extended, CC Part 3 conformant
Sponsor Samsung SDS Co., LTD
Developer Samsung SDS Co., LTD
Common Criteria
Testing Lab (CCTL)
Gossamer Security Solutions, Inc.
CCEVS Validators
3 Architectural Information
Note: The following architectural description is based on the description presented in the
Security Target.
Samsung SDS offers the EMM as a software installation for Java 1.8 and Tomcat 9.0
running on the Microsoft Windows Server 2012 R2 or Windows Server 2016 operating
system. Once installed, the EMM allows administrators to configure policies for devices
and also serves as a Mobile Application Store (MAS) server to serve configured
applications to enrolled devices. Administrators connect securely to the EMM using a
web browser (whether local to the Server itself or remote) and through the EMM’s web
interface can enroll, audit, lock, unlock, manage, and set policies for enrolled mobile
devices. The EMM includes the RSA Crypto-J 6.2 cryptographic module as part of its
software, and the EMM’s Microsoft Windows platform includes SQL server 2008-2016
and a Microsoft CA certificate authority.
Note that one can install multiple EMM systems in order to allow the overall solution to
scale the supported number of mobile devices as a High Availability (HA) option. In this
case, the multiple EMM systems can operate concurrently and with the same policies and
other information by sharing the same SQL database.
Samsung SDS provides the EMM Agent for Android software for evaluated Samsung
mobile devices. The EMM Agent software, once installed and enrolled with the EMM,
will apply and enforce administrator configured policies communicated through the
EMM to the EMM Agents running on the mobile devices.
While Samsung SDS does not provide an iOS agent, the EMM is designed to work with
the iOS agents developed by Apple. Since the iOS agents are evaluated as part of the
Apple iOS evaluations, the EMM was tested to ensure it can manage those devices, but
the agent’s behavior on those devices was not otherwise tested.
The Target of Evaluation (TOE) is Samsung SDS EMM and EMM Agent for Android
version 2.2.5.
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
iv
The TOE consists of the EMM and EMM Agent, where the EMM provides centralized
management of mobile devices and the EMM Agent software (installed on each device)
enforces the policies of the EMM on each device.
3.1 TOE Evaluated Platforms
The evaluated configuration consists of the following models:
1) The EMM Server components (version 2.2.5) installed upon the Microsoft
Windows 2012 R2 or Windows Server 2016 operating system with Oracle JRE
1.8, Microsoft SQL Server 2008-2016, and Microsoft’s Certificate Authority
(CA).
2) The EMM Client version 2.2.5 APKs (EMM Agent, PushAgent, and EMM Agent
Resource) installed upon an evaluated Samsung device running Android 9, 8.1, or
8.0. (see Security Target for a mapping to Samsung mobile device evaluations)
3) The EMM Client version 2.2.5 application installed upon an evaluated iPhone
running iOS 12 or 11. (see Security Target for a mapping to Apple mobile device
evaluations)
3.2 TOE Architecture
The EMM actually consists of the following different servers (these components are
referred to collectively as EMM throughout subsequent sections of this document):
1. EMM Server – This is the main server running to which remote administrators
connect. The EMM Server bears responsibility for all logic needed to manage
mobile devices and to serve configured applications as a MAS server. When
multiple EMM Servers are configured in a single operational environment, they
are not directly associated or communicating with each other, but rather can
simply share the same SQL database. The EMM Server is installed as a single
component, but includes an integrated Tomcat server to implement the
administrator Web User Interface and also an integrated Push server
implementation (PUSH_SA) used to communicate with the other EMM server
components (Push and AppTunnel).
2. Push Server – The Push Server accepts connections from mobile devices and then
relays the messages to and from the EMM Server (for example, to send policies to
an agent, or to send back a reply from an agent). One can install multiple Push
Servers, in order to allow the overall solution to scale the supported number of
mobile devices. Each Push Server is installed as a single component, but includes
multiple internal modules (DCM/PS/SCM/ECM/ICM) to implement its full range
of communication channels among EMM components and agents.
a. Push Proxy – This is an alternate optional deployment of the Push Server
that serves to relay or proxy messages between the mobile devices and
Push Server. This deployment would normally be used to accommodate
network architectures with DMZs. Each Push Proxy is installed as a single
alternate deployment of the Push Server and also includes multiple
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
v
internal modules (DPP/PPP/EPP) to implement its full range of
communication channels among EMM components and agents in its proxy
role.
3. AppTunnel (AT) Server – this server accepts connections from the EMM Agent
(one of the three portions of the agent software on Android) and allows the Client
to upload log files or download mobile applications to be installed by the agent.
Each AT Server is installed as a single component and includes only a single
module to implement its role of managing secure channels for apps.
a. AT Relay – This is an alternate optional deployment of the AppTunnel
Server that serves to relay or proxy messages between the mobile devices
and AT Server. This deployment would normally be used to
accommodate network architectures with DMZs. Each AT Relay is
installed as a single alternate deployment of the AT Server and also
includes only a single module to implement its role of relaying secure
channels for apps.
The EMM allows administrators to create and enforce two different types of profiles:
An MDM Profile – to control all MDM configurable extensions (for example
enforcing password complexity requirements); and
EMM Agent profile – controls only the configuration of the SDS client app itself
(e.g., how a user logs in).
The EMM Agent for Android consists of two different components on evaluated Android
platforms (these components are referred to collectively as EMM Agent throughout
subsequent sections of this document):
1. The “EMM Agent” – at the highest level, this provides a UI through which the
user may enroll their mobile device. This Client is also responsible for uploading
audit logs to the EMM Server and for downloading mobile applications that the
Server directs the agent to install. The EMM Agent presents the UI to allow users
to start the enrollment process and, once enrolled, to log in and log out. This
component also provides most of the agent’s core functionality including the
application of policies, reporting policy event triggers to the Server, installation of
applications, communication with the Server, among other things. The Agent
enforces the policies of the Server.
2. The “Push Agent” – this lowest level component facilitates Push communications
with a Push server. It allows both the EMM Agent and other mobile applications
to send and receive Push messages.
The TOE includes a single component on evaluated iOS platforms:
1. The EMM Client – this iOS application provides a user interface to allow the user
to enroll their phone with their organization’s SDS EMM. The application relies
upon the evaluated, embedded Apple agent for all agent functionality. As such,
this component doesn’t provide any security functions.
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
vi
3.3 Physical Boundaries
The physical boundaries of the SDS EMM and EMM Agent for Android are the physical
perimeter of the servers hosting the EMM server components and the physical perimeter
of the mobile devices being managed by the EMM (put another way, the mobile devices
running the EMM Agent).
The EMM also interacts with Microsoft SQL server and a MS CA.
4 Security Policy
This section summaries the security functionality of the TOE:
1. Security audit
2. Communication
3. Cryptographic support
4. Identification and authentication
5. Security management
6. Protection of the TSF
7. TOE access
8. Trusted path/channels
4.1 Security audit
The EMM can generate and store audit records for security-relevant events as they occur.
These events are stored and protected by the EMM and can be reviewed by an authorized
administrator. The EMM can export the majority of audit events directly through the
HTTPS protected GUI in a CSV format. Some low-level events are maintained in text
files on the TOE platform and can be exported via RDP using the TOE platform. In both
cases, the EMM protects the exported audit records using TLS (as part of HTTPS and
RDP). The EMM also supports the ability to query information about MDM agents and
export MDM configuration information.
The EMM Agent includes the ability to indicate (i.e., respond) to the EMM Sever when it
has been enrolled and when it applies policies successfully. The EMM can be configured
to alert an administrator based on its configuration. For example, it can be configured to
alert the administrator when a policy update fails or an MDM Agent has been enrolled.
4.2 Cryptographic support
The EMM and EMM Agent both include or have access to cryptographic modules with
Cryptographic Algorithm Validation Program (CAVP) certified algorithms for a wide
range of cryptographic functions including: asymmetric key generation and
establishment, encryption/decryption, and cryptographic hashing and keyed-hash
message authentication. These functions are supported with suitable random bit
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
vii
generation, initialization vector generation, secure key storage, and key and protected
data destruction.
The primitive cryptographic functions are used to implement security communication
protocols (TLS and HTTPS) used for communication between the Server and Agent and
between the Server and remote administrators.
4.3 Identification and authentication
The EMM authenticates mobile device users (MD users) and administrators prior to
allowing those operators to perform any functions. This includes MD users enrolling
their device with the EMM using the EMM Agent as well as an administrator logging on
to manage the EMM configuration, MDM policies for mobile devices, etc.
In addition, both the EMM and EMM Agent utilize X.509 certificates, including
certificate validation checking, in conjunction with TLS to secure communications
between the EMM and EMM Agents as well as between the EMM and administrators
using a web-based user interface for remote administrative access.
4.4 Security management
The EMM is designed with two distinct user roles: administrator and mobile device user
(MD user). The former interacts directly with the EMM through HTTPS (using a
browser) while the latter is the user of a mobile device with the EMM Agent installed.
The EMM provides all the function necessary to manage its own security functions as
well as to manage mobile device policies that are sent to EMM Agents. In addition, the
EMM ensures that security management functions are limited to authorized
administrators while allowing MD users to perform only necessary functions such as
enrolling with the EMM.
The EMM Agents provide the functions necessary to securely communicate and enroll
with the EMM, apply policies received from the EMM, and report the results of applying
policies.
4.5 Protection of the TSF
The EMM and Agent work together to ensure that all security related communication
between the server and agent components is protected from disclosure and modification.
Both the EMM and Agent include self-testing capabilities to ensure that they are
functioning properly as well as to cryptographically verify that their executable images
have not been corrupted.
The EMM also includes mechanisms (i.e., verification of the digital signature of each
new image) so that the TOE itself can be updated while ensuring that the updates will not
introduce malicious or other unexpected changes in the TOE.
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
viii
4.6 TOE access
The MDM Server has the capability to display an advisory banner when users attempt to
login in order to manage the TOE.
4.7 Trusted path/channels
The EMM uses TLS/HTTPS to secure communication channels between its distributed
components and remote administrators accessing the Server via a web-based user
interface.
It also uses TLS to secure communication channels between itself and mobile device
users (MD users). In this latter case, the protected communication channel is established
between the EMM and EMM Agent.
5 Assumptions
The Security Problem Definition, including the assumptions, may be found in the
following documents:
• Protection Profile for Mobile Device Management, Version 4.0, 2019-04-25
(MDMPP40)
• PP-Module for MDM Agents, Version 1.0, 2019-04-25 (MDMA10)
• Functional Package for Transport Layer Security (TLS), Version 1.1, 1 March
2019 (PKGTLS11)
That information has not been reproduced here and the MDMPP40/MDMA10/
PKGTLS11 should be consulted if there is interest in that material.
The scope of this evaluation was limited to the functionality and assurances covered in
the MDMPP40/MDMA10/ PKGTLS11 as described for this TOE in the Security Target.
Other functionality included in the product was not assessed as part of this evaluation. All
other functionality provided by the devices needs to be assessed separately, and no
further conclusions can be drawn about their effectiveness.
6 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions
that need clarification. This text covers some of the more important limitations and
clarifications of this evaluation. Note that:
• This evaluation covers only the specific device models and software as identified
in this document, and not any earlier or later versions released or in process.
• This evaluation did not specifically search for, nor attempt to exploit,
vulnerabilities that were not “obvious” or vulnerabilities to objectives not claimed
in the ST. The CEM defines an “obvious” vulnerability as one that is easily
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
ix
exploited with a minimum of understanding of the TOE, technical sophistication
and resources.
7 Documentation
The following documents were available with the TOE for evaluation:
• Samsung SDS EMM Administrator’s Guide, Solution version 2.2.5, January 2020
• Samsung SDS EMM Installation Guide, Solution version 2.2.5, January 2020
• Samsung SDS EMM Configuration Guide for IPsec settings in Microsoft
Windows Server 2016 for Common Criteria Evaluation, Version 2.2.5, January
2020
8 IT Product Testing
This section describes the testing efforts of the developer and the Evaluation Team. It is
derived from information contained in the Detailed Test Report (MDMPP40/MDMA10/
PKGTLS11) for EMM, Version 0.2, 23 January 2020 (DTR).
8.1 Developer Testing
No evidence of developer testing is required in the assurance activities for this product.
8.2 Evaluation Team Independent Testing
The evaluation team verified the product according a Common Criteria Certification
document and ran the tests specified in the MDMPP40/MDMA10/ PKGTLS11 including
the tests associated with optional requirements.
9 Evaluated Configuration
The evaluated configuration consists of a collection of server components (MDM server)
and mobile device applications (MDM agent).
To use the product in the evaluated configuration, the product must be configured as
specified in the following documents.
• Samsung SDS EMM Installation Guide, Version 2.2.5, January 2020
• Samsung SDS EMM Administrator’s Guide, Version 2.2.5, January 2020
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
x
• Samsung SDS EMM Configuration Guide for IPsec settings in Microsoft
Windows Server 2016 for Common Criteria Evaluation, Version 2.2.5, January
2020
10 Results of the Evaluation
The results of the assurance requirements are generally described in this section and are
presented in detail in the proprietary ETR.
A verdict for an assurance component is determined by the resulting verdicts assigned to
the corresponding evaluator action elements. The evaluation was conducted based upon
CC version 3.1 rev 5 and CEM version 3.1 rev 5. The evaluation determined the Product
Name TOE to be Part 2 extended, and to meet the Part 3 Evaluation Assurance Level
(EAL 1).
10.1 Evaluation of the Security Target (ASE)
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the
ST contains a description of the environment in terms of policies and assumptions, a
statement of security requirements claimed to be met by the Samsung SDS EMM 2.2.5
products that are consistent with the Common Criteria, and product security function
descriptions that support the requirements.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.2 Evaluation of the Development (ADV)
The evaluation team assessed the design documentation and found it adequate to aid in
understanding how the TSF provides the security functions. The design documentation
consists of a functional specification contained in the Security target and Guidance
documents. Additionally the evaluator performed the assurance activities specified in the
MDMPP40/MDMA10/ PKGTLS11 related to the examination of the information
contained in the TSS.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.3 Evaluation of the Guidance Documents (AGD)
The evaluation team ensured the adequacy of the user guidance in describing how to use
the operational TOE. Additionally, the evaluation team ensured the adequacy of the
administrator guidance in describing how to securely administer the TOE. All of the
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
xi
guides were assessed during the design and testing phases of the evaluation to ensure they
were complete.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.4 Evaluation of the Life Cycle Support Activities (ALC)
The evaluation team found that the TOE was identified.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.5 Evaluation of the Test Documentation and the Test Activity (ATE)
The evaluation team ran the set of tests specified by the assurance activities in the
MDMPP40/MDMA10/ PKGTLS11 and recorded the results in a Test Report,
summarized in the AAR.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.6 Vulnerability Assessment Activity (VAN)
The evaluation team performed a public search for vulnerabilities on 01/08/2020 and did
not discover any public issues with the TOE. The terms used for the search were as
follows: "RSA Crypto J, Crypto-J, CryptoJ, Samsung SDS, SDS, Enterprise Mobility
Management, and EMM.
The validator reviewed the work of the evaluation team, and found that sufficient
evidence and justification was provided by the evaluation team to confirm that the
evaluation was conducted in accordance with the requirements of the CEM, and that the
conclusion reached by the evaluation team was justified.
10.7 Summary of Evaluation Results
The evaluation team’s assessment of the evaluation evidence demonstrates that the claims
in the ST are met. Additionally, the evaluation team’s testing also demonstrated the
accuracy of the claims in the ST.
The validation team’s assessment of the evidence provided by the evaluation team is that
it demonstrates that the evaluation team followed the procedures defined in the CEM, and
correctly verified that the product meets the claims in the ST.
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
xii
11 Validator Comments/Recommendations
The validators suggest that the consumer pay particular attention to the evaluated
configuration of the device(s). The functionality evaluated is scoped exclusively to the
security functional requirements specified in the Security Target, and only the
functionality implemented by the SFR’s within the Security Target was evaluated. All
other functionality provided by the devices, to include software that was not part of the
evaluated configuration, needs to be assessed separately and no further conclusions can
be drawn about their effectiveness.
12 Annexes
Not applicable
13 Security Target
Samsung SDS Co. Ltd. EMM and EMM Agent for Android
(MDMPP40/MDMA10/PKGTLS11) Security Target, Version 0.9, 27 January 2020.
14 Glossary
The following definitions are used throughout this document:
• Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP)
and approved by the CCEVS Validation Body to conduct Common Criteria-based
evaluations.
• Conformance. The ability to demonstrate in an unambiguous way that a given
implementation is correct with respect to the formal model.
• Evaluation. The assessment of an IT product against the Common Criteria using the
Common Criteria Evaluation Methodology to determine whether or not the claims
made are justified; or the assessment of a protection profile against the Common
Criteria using the Common Evaluation Methodology to determine if the Profile is
complete, consistent, technically sound and hence suitable for use as a statement of
requirements for one or more TOEs that may be evaluated.
• Evaluation Evidence. Any tangible resource (information) required from the sponsor
or developer by the evaluator to perform one or more evaluation activities.
• Feature. Part of a product that is either included with the product or can be ordered
separately.
• Target of Evaluation (TOE). A group of IT products configured as an IT system, or
an IT product, and associated documentation that is the subject of a security
evaluation under the CC.
Samsung SDS EMM Validation Report Version 0.2, 27 January 2020
xiii
• Validation. The process carried out by the CCEVS Validation Body leading to the
issue of a Common Criteria certificate.
• Validation Body. A governmental organization responsible for carrying out
validation and for overseeing the day-to-day operation of the NIAP Common Criteria
Evaluation and Validation Scheme.
15 Bibliography
The Validation Team used the following documents to produce this Validation Report:
[1] Common Criteria for Information Technology Security Evaluation: Part 1:
Introduction and General Model, Version 3.1, Revision 5, April 2017.
[2] Common Criteria for Information Technology Security Evaluation Part 2:
Security functional components, Version 3.1, Revision 5, April 2017.
[3] Common Criteria for Information Technology Security Evaluation Part 3:
Security assurance components, Version 3.1 Revision 5, April 2017.
[4] Protection Profile for Mobile Device Management, Version 4.0, 2019-04-25
(MDMPP40), PP-Module for MDM Agents, Version 1.0, 2019-04-25
(MDMA10), and Functional Package for Transport Layer Security (TLS),
Version 1.1, 1 March 2019 (PKGTLS11)
[5] Samsung SDS Co. Ltd. EMM and EMM Agent for Android
(MDMPP40/MDMA10/PKGTLS11) Security Target, Version 0.9, 27 January
2020 (ST)
[6] Assurance Activity Report (MDMPP40/MDMA10/PKGTLS11) for EMM,
Version 0.3, 27 January 2020 (AAR)
[7] Detailed Test Report (MDMPP40/MDMA10/ PKGTLS11) for EMM, Version
0.2, 23 January 2020 (DTR)
[8] Evaluation Technical Report for Samsung SDS EMM 2.2.5, ETR Version 0.3, 27
January 2020 (ETR)