National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
for the
MMA10G-IPX Series, Version 3.3
Report Number: CCEVS-VR-VID11277-2023
Dated: 02/10/2023
Version: 1.0
National Institute of Standards and Technology Department of Defense
Information Technology Laboratory ATTN: NIAP, SUITE: 6982
100 Bureau Drive 9800 Savage Road
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6982
®
TM
2
ACKNOWLEDGEMENTS
Validation Team
Jim Donndelinger
Swapna Katikaneni
Marybeth Panock
Viet Hung Le
Aerospace Corporation
Common Criteria Testing Laboratory
Shehan D Dissanayake
Rahul Joshi
Ashish Panchal
Acumen Security, LLC
3
Table of Contents
1 Executive Summary............................................................................................................... 4
2 Identification.......................................................................................................................... 5
3 Architectural Information .................................................................................................... 6
4 Security Policy........................................................................................................................ 8
5 Assumptions, Threats & Clarification of Scope ............................................................... 13
5.1 Assumptions..................................................................................................................................................13
5.2 Threats...........................................................................................................................................................14
5.3 Clarification of Scope...................................................................................................................................16
6 Documentation..................................................................................................................... 18
7 TOE Evaluated Configuration ........................................................................................... 18
7.1 Evaluated Configuration..............................................................................................................................19
7.1.1 Physical Boundaries and IT Testing Environment Components.........................................................19
7.1.2 Security Functions Provided by the TOE ..............................................................................................19
7.2 Excluded Functionality ................................................................................................................................19
8 IT Product Testing............................................................................................................... 21
8.1 Developer Testing .........................................................................................................................................21
8.2 Evaluation Team Independent Testing.......................................................................................................21
9 Results of the Evaluation .................................................................................................... 22
9.1 Evaluation of Security Target .....................................................................................................................22
9.2 Evaluation of Development Documentation...............................................................................................22
9.3 Evaluation of Guidance Documents............................................................................................................22
9.4 Evaluation of Life Cycle Support Activities...............................................................................................23
9.5 Evaluation of Test Documentation and the Test Activity .........................................................................23
9.6 Vulnerability Assessment Activity ..............................................................................................................23
9.7 Summary of Evaluation Results..................................................................................................................23
10 Validator Comments & Recommendations ...................................................................... 24
11 Annexes................................................................................................................................. 24
12 Security Target .................................................................................................................... 26
13 Glossary................................................................................................................................ 27
14 Bibliography......................................................................................................................... 28
4
1 Executive Summary
This Validation Report (VR) is intended to assist the end user of this product and any security
certification Agent for that end user in determining the suitability of this Information Technology (IT)
product for their environment. End users should review the Security Target (ST), which is where specific
security claims are made, in conjunction with this VR, which describes how those security claims were
tested and evaluated and any restrictions on the evaluated configuration. Prospective users should
carefully read the Assumptions and Clarification of Scope in Section 5 and the Validator Comments in
Section 10, where any restrictions on the evaluated configuration are highlighted.
This report documents the National Information Assurance Partnership (NIAP) assessment of the
evaluation of the MMA10G-IPX Series Target of Evaluation (TOE). It presents the evaluation results,
their justifications, and the conformance results. This VR is not an endorsement of the TOE by any
agency of the U.S. Government and no warranty of the TOE is either expressed or implied. This VR
applies only to the specific version and configuration of the product as evaluated and documented in the
ST.
The evaluation was completed by Acumen Security in February 2023. The information in this report is
largely derived from the Evaluation Technical Report (ETR) and associated test report, all written by
Acumen Security. The evaluation determined that the product is both Common Criteria Part 2 Extended
and Part 3 Extended, and meets the assurance requirements of the collaborative Protection Profile for
Network Devices, Version 2.2e, 27 March 2020 [PP-ND].
The TOE identified in this VR 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), as interpreted by
the Assurance Activities contained in the Protection Profile (PP). This VR 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 ETR are consistent with the evidence provided.
The validation team provided guidance on technical issues and evaluation processes and reviewed the
individual work units documented in the ETR and the Assurance Activities Report (AAR). The validation
team found that the evaluation showed that the product satisfies all of the functional requirements and
assurance requirements stated in the ST. Based on these findings, 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 ETR are consistent with the evidence produced.
5
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 trusted product evaluations.
Under this program, security evaluations are conducted by commercial testing laboratories called
Common Criteria Testing Laboratories (CCTLs). CCTLs evaluate products against PPs containing
Assurance Activities, which are interpretations of Common Evaluation Methodology (CEM) work
units specific to the technology described by the PP.
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality and consistency
across evaluations. Developers of IT 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 Product Compliant 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(s) 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 MMA10G-IPX Series, version 3.3
Protection Profile Collaborative Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-
ND]
Security Target MMA10G-IPX Series v3.3 Security Target, version 1.1, February 06,2023
Evaluation Technical
Report
Evaluation Technical Report for MMA10G-IPX Series v3.3, version 1.1
CC Version Version 3.1, Revision 5
Conformance Result CC Part 2 Extended and CC Part 3 Conformant
Sponsor Evertz Microsystems
Developer Evertz Microsystems
Common Criteria
Testing Lab (CCTL)
Acumen Security
Rockville, MD
CCEVS Validators Jim Donndelinger
Swapna Katikaneni
Marybeth Panock
Viet Hung Le
6
3 Architectural Information
The TOE (Internet Protocol Crosspoint (IPX) switch) is a network-based audio video distribution system
and is classified as a network device (a generic infrastructure device that can be connected to a
network). It is a 10 Gigabit (Gb) Internet Protocol (IP) switch optimized for video-over-IP traffic
(compressed or uncompressed). For the MMA10G and 3080 models, each IPX card occupies two (2) slots
(16- and 32-port IPX cards) or four (4) slots (64-port IPX cards) in an Evertz Modular Crosspoint (EMX)
frame. The 9080 models include the IPX cards and frame in a 1RU form factor. All IPX-compatible cards
may be inserted into any IPX frame configuration provided there are sufficient contiguous free slots
available.
Since video by nature has a unidirectional flow, and multiple copies of a single incoming video stream
are often sent to multiple output destinations, the IPX exclusively uses multicast IP addressing.
Equipment to prepare video for IP transport, or to convert it into other video formats, is outside the
scope of this TOE. Such equipment includes, but is not limited to, cameras, KVMs, codecs, video servers
and video displays. Equipment to perform functions such as embedding audio and/or other information
within the video stream is also outside the scope of this TOE.
The TOE provides secure remote management using an HTTPS/TLS web interface. Administrators only
may access IPX via a dedicated management workstation operating over an Out-of-Band Management
(OOBM) network. Sites may close this OOBM network or may operate IPX within an existing OOBM, as
long as the topology is compliant with the security parameters listed below. Users and administrators
may also access IPX software via direct connection using a terminal session.
The TOE generates audit logs and transmits the audit logs to a remote syslog server over a mutually
authenticated TLS channel. The TOE verifies the authenticity of software updates by verifying the digital
signature prior to installing any update.
The summary of the evaluated functionality provided by the TOE includes the following,
• Secure connectivity with remote audit servers and secure retention of audit logs locally
• Identification and authentication of the administrator of the TOE
• Secure remote administration of the TOE via TLS and secure Local administration of the TOE
• Secure access to the management functionality of the TOE
• Secure software updates
• Secure communication with the non-TOE ‘video switch control systems’ via TLS
The TOE hardware devices are the Evertz:
• MMA10G-IPX-16 running MMA10G-IPX-16-CC v3.3,
• MMA10G-IPX-32 running MMA10G-IPX-32-CC v3.3,
• MMA10G-IPX-64 running MMA10G-IPX-64-CC v3.3,
• 3080IPX-16-G3-CC running MMA10G-IPX-16-CC v3.3,
• 3080IPX-32-G3-CC running MMA10G-IPX-32-CC v3.3,
• 3080IPX-64-G6-CC running MMA10G-IPX-64-CC v3.3,
7
• 3080IPX-16-10G-CC running MMA10G-IPX-16-CC v3.3,
• 3080IPX-32-10G-CC running MMA10G-IPX-32-CC v3.3,
• 3080IPX-64-10G-CC running MMA10G-IPX-64-CC v3.3,
• 3080IPX-16-10G-HW-CC running MMA10G-IPX-16-CC v3.3,
• 3080IPX-32-10G-HW-CC running MMA10G-IPX-32-CC v3.3,
• 3080IPX-64-10G-HW-CC running MMA10G-IPX-64-CC v3.3,
• 3080IPX-16GE-CC running MMA10G-IPX-16-CC v3.3,
• 3080IPX-32GE-CC running MMA10G-IPX-32-CC v3.3,
• 3080IPX-64GE-CC running MMA10G-IPX-64-CC v3.3,
• 3080IPX-16GE-RJ45-CC running MMA10G-IPX-16-CC v3.3,
• 3080IPX-32GE-RJ45-CC running MMA10G-IPX-32-CC v3.3,
• 3080IPX-64GE-RJ45-CC running MMA10G-IPX-64-CC v3.3,
• 9080IPX-16-12RJ45-4SFP10GE-CC running MMA10G-IPX-16-CC v3.3,
• 9080IPX-16GE-12RJ45-4SFP-CC running MMA10G-IPX-16-CC v3.3,
• 9080IPX-32-28RJ45-4SFP10GE-CC running MMA10G-IPX-32-CC v3.3,
• 9080IPX-32-28RJ45-4SFP-CC running MMA10G-IPX-32-CC v3.3
and will be referred to as "IPX” throughout this document. The IPX appliances are Ethernet switches
optimized for video content.
NOTE: All the devices listed above run on the same Freescale MPC8377E PowerQUICC II processor and
use the same microarchitecture.
8
4 Security Policy
The TOE is comprised of several security features. Each of the security features identified above consists
of several security functionalities, as identified below.
• Security Audit
• Cryptographic Support
• Identification and Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channels
The TOE provides the security functions required by the Collaborative Protection Profile for Network
Devices, hereafter referred to as NDcPP v2.2e or NDcPP.
Security Audit
The TOE’s Audit security function supports audit record generation and review. The TOE provides date
and time information that is used in audit timestamps. Very broadly, the Audit events generated by the
TOE include:
• Establishment of a trusted path or channel session
• Failure to Establish a trusted path or channel session
• Termination of a trusted path or channel session
• Failure of trusted channel functions
• Identification and Authentication
• Unsuccessful attempt to validate a certificate
• Lockouts due to unsuccessful authentication attempts
• Any update attempt
• Result of the update attempt
• Management of TSF data
• Changes to Time
• Session timeouts
The TOE stores generated audit data on itself and sends audit events to a syslog server, using a TLS
protected collection method. Logs are classified into various predefined categories. The logging
categories help describe the content of the messages that they contain. Access to the logs is restricted
to only Security Administrators, who has no access to edit them, only to copy or delete (clear) them.
Audit records are protected from unauthorized modifications and deletions.
The TSF provides the capability to view audit data by using the Syslog tab in the web browser. The log
records the time, host name, facility, application, and “message” (the log details). The previous audit
records are overwritten when the allocated space for these records reaches the threshold on a FIFO
basis.
Cryptographic Support
The TOE includes an OpenSSL library (Version 1.1.1k with Fedora Patches) that implements CAVP
validated cryptographic algorithms for random bit generation, encryption/decryption, authentication,
9
and integrity protection/verification. These algorithms are used to provide security for the TLS/HTTPs
connections for secure management and secure connections to a syslog and authentication servers. TLS
and HTTPs are also used to verify firmware updates. The cryptographic services provided by the TOE are
described below:
Table 1 – TOE Cryptographic Protocols
Cryptographic
Protocol
Use within the TOE
HTTPS/TLS (client)
Secure connection to syslog
FCS_HTTPS_EXT.1, FCS_TLSC_EXT.1
HTTPS/TLS (server)
Peer connections to MAGNUM and remote management
FCS_HTTPS_EXT.1, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
AES
Provides encryption/decryption in support of the TLS protocol.
FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
DRBG
Deterministic random bit generation use to generate keys.
FCS_TLSS_EXT.1, FCS_TLSS_EXT.2, FCS_RBG_EXT.1
Secure hash
Used as part of digital signatures and firmware integrity checks.
FCS_COP.1/Hash, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
HMAC
Provides keyed hashing services in support of TLS.
FCS_COP.1/KeyedHash, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
EC-DH
Provides key establishment for TLS.
FCS_CKM.2, FCS_TLSC_EXT.1, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
ECDSA
Provides components for EC-DH key establishment.
FCS_CKM.1, FCS_CKM.2, FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
RSA
Provide key establishment, key generation and signature generation and
verification
(PKCS1_V1.5) in support of TLS.
FCS_CKM.1, FCS_COP.1/SigGen, FCS_COP.1/SigVer, FCS_TLSC_EXT.1,
FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
Each of these cryptographic algorithms have been validated for conformance to the requirements
specified in their respective standards, as identified below:
Table 2 – CAVP Algorithm Testing References
Algorithm Standard CAVP Certificate # Processors
10
AES 128/256-bit
CBC, GCM
IOS 19772 (GCM) A2454
PowerQUICC® II
Pro
MPC8377E
CTR DRBG using
AES
256
ISO/IEC 18031:2011 A2454
PowerQUICC® II
Pro
MPC8377E
EC-DH
NIST SP 800-56A (key
establishment)
A2454
PowerQUICC® II
Pro
MPC8377E
ECDSA FIPS PUB 186-4 (key generation) A2454
PowerQUICC® II
Pro
MPC8377E
HMAC-SHA-
1/256/384
ISO/IEC 9797-2:2011 A2454
PowerQUICC® II
Pro
MPC8377E
SHA-1/256/384 ISO/IEC 10118-3:2004 A2454
PowerQUICC® II
Pro
MPC8377E
RSA
2048/3072/4096
FIPS PUB 186-4 (key generation
and
Digital Signature)
ISO/IEC 9796-2 (digital signature)
A2454
PowerQUICC® II
Pro
MPC8377E
Identification and Authentication
All Administrators wanting to use TOE services are identified and authenticated prior to being allowed
access to any of the services other than the display of the warning banner. (“Regular” IPX users do not
access IPX directly; they control IP video switching through the IPX using a switch control system, such as
Evertz’ Magnum. The switching of those IP video transport stream is outside the scope of the TOE.)
Once an Administrator attempts to access the management functionality of the TOE, the TOE prompts
the Administrator for a username and password for password-based authentication. The identification
and authentication credentials are confirmed against a local user database. Only after the Administrator
presents the correct identification and authentication credentials will access to the TOE functionality be
granted. The TOE uses X.509v3 certificates as defined by RFC 5280 to support authentication for
TLS/HTTPS connections.
The TOE provides the capability to set password minimum length rules. This is to ensure the use of
strong passwords in attempts to protect against brute force attacks. The TOE also accepts passwords
11
composed of a variety of characters to support complex password composition. During authentication,
no indication is given of the characters composing the password.
Remote administrators are locked out after a configurable number of unsuccessful authentication
attempts.
The IPX requires a password-protected serial connection to perform initial configuration of the system IP
address(es). Once each address is established, administrators use IP connectivity for all further
administrative actions, including configuration, operations, and monitoring.
Security Management
The TOE provides secure administrative services for management of general TOE configuration and the
security functionality provided by the TOE. All TOE administration occurs either through a secure session
or a local console connection. The TOE provides the ability to perform the following actions:
• Administer the TOE locally and remotely
• Configure the access banner
• Configure the cryptographic services
• Configure number of unsuccessful login attempts that trigger a lockout
• Update the TOE and verify the updates using digital signature capability prior to installing
those updates
• Specify the time limits of session inactivity
All of these management functions are restricted to an Administrator, which covers all administrator
roles. Administrators are individuals who manage specific type of administrative tasks. In IPX, only the
only admin role exists, since there is no provision for “regular” users to access IPX directly (as described
above), and the portion of IPX they access and control are outside the scope of the TOE.
Primary management is done using the Webeasy web-based interface using HTTPS. This provides a
network administration console from which one can manage various identity services. These services
include authentication, authorization, and reporting. All of these services can be managed from the web
browser, which uses a menu-driven navigation system.
There is also a very simple serial-based connection (RS-232) that provides a simple menu interface. This
is used to configure the IP interface (IP address, etc.). It is password-protected, and is typically only used
once, for initial set-up.
Protection of the TSF
The TOE will terminate inactive sessions after an Administrator-configurable time period. Once a session
has been terminated the TOE requires the user to re-authenticate to establish a new session. The TOE
provides protection of TSF data (authentication data and cryptographic keys). In addition, the TOE
internally maintains the date and time. This date and time are used as the time stamp that is applied to
TOE generated audit records. The TOE also ensures firmware updates are from a reliable source. Finally,
the TOE performs testing to verify correct operation.
12
In order for updates to be installed on the TOE, an administrator initiates the process from the web
interface. IPX automatically uses the digital signature mechanism to confirm the integrity of the product
before installing the update.
TOE Access
Aside from the automatic Administrators session termination due to inactivity describes above, the TOE
also allows Administrators to terminate their own interactive session. Once a session has been
terminated the TOE requires the user to re-authenticate to establish a new session.
The TOE will display an Administrator-specified banner on the web browser management interface prior
to allowing any administrative access to the TOE.
Trusted Path/Channels
The TOE allows the establishment of a trusted path between a video control system (such as Evertz’
Magnum) and the IPX. The TOE also establishes a secure connection for sending audit data to a syslog
server using TLS and other external authentication stores using TLS-protected communications.
The TOE uses HTTPS/TLS to provide a trusted path between itself and remote administrative users. The
TOE does not implement any additional methods of remote administration. The remote administrative
users are responsible for initiating the trusted path when they wish to communicate with the TOE.
13
5 Assumptions, Threats & Clarification of Scope
5.1 Assumptions
The specific conditions listed in the following subsections are assumed to exist in the TOE’s
environment. These assumptions include both practical realities in the development of the TOE security
requirements and the essential environmental conditions on the use of the TOE.
Table 3 – Assumptions
ID Assumption
A.PHYSICAL_PROTECTION The Network Device is assumed to be physically
protected in its operational environment and not
subject to physical attacks that compromise the
security or interfere with the device’s physical
interconnections and correct operation. This
protection is assumed to be sufficient to protect the
device and the data it contains. As a result, the cPP
does not include any requirements on physical
tamper protection or other physical attack
mitigations. The cPP does not expect the product to
defend against physical access to the device that
allows unauthorized entities to extract data, bypass
other controls, or otherwise manipulate the device.
For vNDs, this assumption applies to the physical
platform on which the VM runs.
A.LIMITED_FUNCTIONALITY The device is assumed to provide networking
functionality as its core function and not provide
functionality/services that could be deemed as
general purpose computing. For example, the device
should not provide a computing platform for general
purpose applications (unrelated to networking
functionality).
A.NO_THRU_TRAFFIC_PROTECTION A standard/generic Network Device does not
provide any assurance regarding the protection of
traffic that traverses it. The intent is for the Network
Device to protect data that originates on or is
destined to the device itself, to include
administrative data and audit data. Traffic that is
traversing the Network Device, destined for another
network entity, is not covered by the ND cPP. It is
assumed that this protection will be covered by cPPs
and PP-Modules for particular types of Network
Devices (e.g., firewall).
14
ID Assumption
A.TRUSTED_ADMINISTRATOR The Security Administrator(s) for the Network Device
are assumed to be trusted and to act in the best
interest of security for the organization. This
includes appropriately trained, following policy, and
adhering to guidance documentation.
Administrators are trusted to ensure
passwords/credentials have sufficient strength and
entropy and to lack malicious intent when
administering the device. The Network Device is not
expected to be capable of defending against a
malicious Administrator that actively works to
bypass or compromise the security of the device.
For TOEs supporting X.509v3 certificate-based
authentication, the Security Administrator(s) are
expected to fully validate (e.g. offline verification)
any CA certificate (root CA certificate or
intermediate CA certificate) loaded into the TOE’s
trust store (aka 'root store', ' trusted CA Key Store',
or similar) as a trust anchor prior to use (e.g. offline
verification).
A.REGULAR_UPDATES The Network Device firmware and software is
assumed to be updated by an Administrator on a
regular basis in response to the release of product
updates due to known vulnerabilities.
A.ADMIN_CREDENTIALS_SECURE The Administrator’s credentials (private key) used to
access the Network Device are protected by the
platform on which they reside.
A.COMPONENTS_RUNNING For distributed TOEs it is assumed that the
availability of all TOE components is checked as
appropriate to reduce the risk of an undetected
attack on (or failure of) one or more TOE
components. It is also assumed that in addition to
the availability of all components it is also checked
as appropriate that the audit functionality is running
properly on all TOE components.
A.RESIDUAL_INFORMATION The Administrator must ensure that there is no
unauthorized access possible for sensitive residual
information (e.g. cryptographic keys, keying
material, PINs, passwords etc.) on networking
equipment when the equipment is discarded or
removed from its operational environment.
5.2 Threats
The following table lists the threats addressed by the TOE and the IT Environment. The assumed level of
expertise of the attacker for all the threats identified below is Enhanced-Basic.
15
Table 4 – Threats
ID Threat
T.UNAUTHORIZED_ADMINISTRATOR_ACCESS Threat agents may attempt to gain Administrator
access to the Network Device by nefarious means
such as masquerading as an Administrator to the
device, masquerading as the device to an
Administrator, replaying an administrative session
(in its entirety, or selected portions), or performing
man-in-the-middle attacks, which would provide
access to the administrative session, or sessions
between Network Devices. Successfully gaining
Administrator access allows malicious actions that
compromise the security functionality of the device
and the network on which it resides.
T.WEAK_CRYPTOGRAPHY Threat agents may exploit weak cryptographic
algorithms or perform a cryptographic exhaust
against the key space. Poorly chosen encryption
algorithms, modes, and key sizes will allow
attackers to compromise the algorithms, or brute
force exhaust the key space and give them
unauthorized access allowing them to read,
manipulate and/or control the traffic with minimal
effort.
T.UNTRUSTED_COMMUNICATION_CHANNELS Threat agents may attempt to target Network
Devices that do not use standardized secure
tunnelling protocols to protect the critical network
traffic. Attackers may take advantage of poorly
designed protocols or poor key management to
successfully perform man-in-the-middle attacks,
replay attacks, etc. Successful attacks will result in
loss of confidentiality and integrity of the critical
network traffic, and potentially could lead to a
compromise of the Network Device itself.
T.WEAK_AUTHENTICATION_ENDPOINTS Threat agents may take advantage of secure
protocols that use weak methods to authenticate
the endpoints, e.g. a shared password that is
guessable or transported as plaintext. The
consequences are the same as a poorly designed
protocol, the attacker could masquerade as the
Administrator or another device, and the attacker
could insert themselves into the network stream
and perform a man-in-the-middle attack. The result
is the critical network traffic is exposed and there
could be a loss of confidentiality and integrity, and
16
ID Threat
potentially the Network Device itself could be
compromised.
T.UPDATE_COMPROMISE Threat agents may attempt to provide a
compromised update of the software or firmware
which undermines the security functionality of the
device. Non-validated updates or updates validated
using non-secure or weak cryptography leave the
update firmware vulnerable to surreptitious
alteration.
T.UNDETECTED_ACTIVITY Threat agents may attempt to access, change,
and/or modify the security functionality of the
Network Device without Administrator awareness.
This could result in the attacker finding an avenue
(e.g., misconfiguration, flaw in the product) to
compromise the device and the Administrator
would have no knowledge that the device has been
compromised.
T.SECURITY_FUNCTIONALITY_COMPROMISE Threat agents may compromise credentials and
device data enabling continued access to the
Network Device and its critical data. The
compromise of credentials includes replacing
existing credentials with an attacker’s credentials,
modifying existing credentials, or obtaining the
Administrator or device credentials for use by the
attacker.
T.PASSWORD_CRACKING Threat agents may be able to take advantage of
weak administrative passwords to gain privileged
access to the device. Having privileged access to the
device provides the attacker unfettered access to
the network traffic and may allow them to take
advantage of any trust relationships with other
Network Devices.
T.SECURITY_FUNCTIONALITY_FAILURE An external, unauthorized entity could make use of
failed or compromised security functionality and
might therefore subsequently use or abuse security
functions without prior authentication to access,
change or modify device data, critical network
traffic or security functionality of the device.
5.3 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions that need
clarifying. This text covers some of the more important limitations and clarifications of this evaluation.
Note that:
• As with any evaluation, this evaluation only shows that the evaluated configuration meets the
security claims made, with a certain level of assurance. The level of assurance for this evaluation
17
is defined within the Collaborative Protection Profile for Network Devices, Version 2.2e, 27
March 2020 [PP-ND]
• Consistent with the expectations of the PP, this evaluation did not specifically search for, nor
seriously attempt to counter, 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
exploited with a minimum of understanding of the TOE, technical sophistication and resources.
• The evaluation of security functionality of the product was limited to the functionality specified
in the claimed PPs. Any additional security related functional capabilities included in the product
were not covered by this evaluation.
18
6 Documentation
The following documents were provided by the vendor with the TOE for evaluation:
• 3080IPX Integrated Switching Fabric User Manual, Version 1.9, June 2016
• IPX MMA10G-IPX Security Administration Manual, Revision 1b, Aug 16, 2019
• MMA10G-IPX Series v3.3 Security Target 1.1, February 06, 2023
• IPX MMA10G-IPX v3.3 Security Administrative Guide Addendum for Common Criteria, version
1.2, 03 February 2023
Any additional customer documentation provided with the product, or that is available online was not
included in the scope of the evaluation and therefore should not be relied upon when configuring or
operating the device as evaluated. . Consumers are encouraged to download the evaluated
administrative guidance documentation from the NIAP website.
19
7 TOE Evaluated Configuration
7.1 Evaluated Configuration
The section 1.2 of the ST provides an overview of the TOE architecture, including physical boundaries,
security functions, and relevant TOE documentation and references.
7.1.1 Physical Boundaries and IT Testing Environment Components
The physical boundaries of the TOE are outlined in section 1.2 of the ST. All physical boundaries are
required in the TOE Environment. The IT Testing Environment components used to test the TOE are
shown in Table 2 of the ST.
Typical system deployment of the TOE is depicted below and the IPX Switch Fabric is the only
component part of the TOE. All the other components of the IT environment are NOT part of the TOE
physical boundary.
7.1.2 Security Functions Provided by the TOE
The TOE provides the security functions required by the Collaborative Protection Profile for Network
Devices, hereafter referred to as NDcPP v2.2e or NDcPP.
7.2 Excluded Functionality
The following product functionality is not included in the CC evaluation:
• SNMP Traps (Alarms)
• VistaLINK PRO module
• External Authentication Servers for administrator authentication
These functions are outside the TOE. Alarm monitoring is the sending of SNMP traps to an alarm
monitoring system (which is assigned by an Administrator).
20
In addition, IPX provides IP video stream switching. This IP video switching does not provide security
functionality and was therefore not evaluated and is outside the scope of the TOE. The nature of video
encryption and decryption is that a video stream is encrypted at the sending end and decrypted at the
receiving end; since IPX is a midpoint device and therefore does not perform encryption or decryption
functionality. This functionality, while present in the TOE, was not evaluated.
21
8 IT Product Testing
This section describes the testing efforts of the developer and the evaluation team. It is derived from
information contained in ETR for MMA10G-IPX Series version 3.3, which is not publicly available. The
AAR provides an overview of testing and the prescribed assurance activities.
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 to the vendor-provided guidance documentation and
ran the tests specified in the collaborative Protection Profile for Network Devices, Version 2.2e, 27 March
2020 [PP-ND].
All testing was carried at the Acumen Security offices located in 2400 Research Blvd Suite #395, Rockville,
MD 20850. Testing occurred from January 2022 through February 2023.
The Independent Testing configuration is documented in section 4 of the AAR and the test activities are
documented in section 6 of the AAR , which is publicly available, and is not duplicated here.
.
22
9 Results of the Evaluation
The results of the assurance requirements are generally described in this section and are presented in
detail in the proprietary documents: the Detailed Test Report (DTR) and the ETR. The reader of this
document can assume that all activities and work units received a passing verdict.
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 TOE Name to be Part 2 extended, and
meets the SARs contained in the PP. Additionally, the evaluator performed the Assurance Activities
specified in the claimed PP.
9.1 Evaluation of Security Target
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 MMA10G-IPX Series v3.3 Security Target version 1.1 that are
consistent with the Common Criteria, and product security function descriptions that support the
requirements. Additionally, the evaluator performed an assessment of the Assurance Activities specified
in the collaborative Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND].
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.
9.2 Evaluation of Development Documentation
The evaluation team applied each EAL 1 ADV CEM work unit. 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 ST's TOE
Summary Specification. Additionally, the evaluator performed the Assurance Activities specified in the
collaborative Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND] related to
the examination of the information contained in the TOE Summary Specification.
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 Assurance Activities, and that the conclusion reached by the evaluation team was
justified.
9.3 Evaluation of Guidance Documents
The evaluation team applied each EAL 1 AGD CEM work unit. 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.
The guides were assessed during the design and testing phases of the evaluation to ensure they were
complete. Additionally, the evaluator performed the Assurance Activities specified in the collaborative
Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND] related to the examination
of the information contained in the operational guidance documents.
23
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 Assurance Activities, and that the conclusion reached by the evaluation team was
justified.
9.4 Evaluation of Life Cycle Support Activities
The evaluation team applied each EAL 1 ALC CEM work unit. 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.
9.5 Evaluation of Test Documentation and the Test Activity
The evaluation team applied each EAL 1 ATE CEM work unit. The evaluation team ran the set of tests
specified by the Assurance Activities in the collaborative Protection Profile for Network Devices, Version
2.2e, 27 March 2020 [PP-ND] and recorded the results in a Test Report, summarized in the ETR and AAR.
The validator reviewed the work of the evaluation team and found that sufficient evidence was provided
by the evaluation team to show that the evaluation activities addressed the test activities in the
collaborative Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND], and that the
conclusion reached by the evaluation team was justified.
9.6 Vulnerability Assessment Activity
The evaluation team applied each EAL 1 AVA CEM work unit. The evaluation team performed a public
search for vulnerabilities, performed vulnerability testing and did not discover any issues with the TOE.
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 addressed the
vulnerability analysis Assurance Activities in the collaborative Protection Profile for Network Devices,
Version 2.2e, 27 March 2020 [PP-ND], and that the conclusion reached by the evaluation team was
justified.
9.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 test activities 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 performed the Assurance Activities in the collaborative
Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND], and correctly verified that
the product meets the claims in the ST.
24
10 Validator Comments & Recommendations
The validation team notes that the evaluated configuration is dependent upon the TOE being configured
per the evaluated configuration instructions in the Common Criteria Administrator Guide.
Please note that the functionality evaluated is scoped exclusively to the security functional requirements
specified in the Security Target. The excluded functionality is specified in section 7.2 of this report. All
other items and scope issues have been sufficiently addressed elsewhere in this document.
25
11 Annexes
Not applicable.
26
12 Security Target
MMA10G-IPX Series v3.3 Security Target, version 1.1, February 06,2023
27
13 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.
• 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.
28
14 Bibliography
The Validation Team used the following documents to produce this Validation Report:
1. Assurance Activity Report for MMA10G-IPX Series v3.3, version 1.1
2. Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and
general model, Version 3.1 Revision 5.
3. Common Criteria for Information Technology Security Evaluation - Part 2: Security functional
requirements, Version 3.1 Revision 5.
4. Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance
requirements, Version 3.1 Revision 5.
5. Common Evaluation Methodology for Information Technology Security Evaluation, Version 3.1
Revision 5.
6. Evaluation Technical Report for MMA10G-IPX Series v3.3, version 1.1, February 07,2023.
7. IPX MMA10G-IPX v3.3 Security Administrative Guide Addendum for Common Criteria, version
1.2, 03 February 2023
8. collaborative Protection Profile for Network Devices, Version 2.2e, 27 March 2020 [PP-ND]
9. MMA10G-IPX Series v3.3 Security Target, version 1.1, February 06,2023