National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
Bivio Networks, Inc.
Bivio 6110-NC and Bivio 6120-NC
Report Number: CCEVS-VR-VID10847-2017
Dated: August 28, 2017
Version: 1.0
National Institute of Standards and Technology
Information Technology Laboratory
100 Bureau Drive
Gaithersburg, MD 20899
National Security Agency
Information Assurance Directorate
9800 Savage Road STE 6940
Fort George G. Meade, MD 20755-6940
2
Acknowledgements
Validation Panel
Dianne Hale
NIAP
Patrick Mallett, PhD.
MITRE Corporation, McLean, Va.
Kenneth Stutterheim
The Aerospace Corporation, Columbia Md.
Common Criteria Testing Laboratory
Michael C. Baron
Kenji Yoshino
Ryan Day
UL Verification Services Inc.
San Luis Obispo, CA
3
Table of Contents
1 Executive Summary......................................................................................5
2 Identification of the TOE ..............................................................................7
3 Interpretations.............................................................................................7
4 Security Policy..............................................................................................8
4.1 Audit................................................................................................................................. 8
4.2 Cryptographic Operations................................................................................................ 8
4.3 Identification and Authentication.................................................................................... 8
4.4 Protection of the TSF........................................................................................................ 9
4.5 TOE Access........................................................................................................................ 9
4.6 Trusted Path/Channels..................................................................................................... 9
5 TOE Security Environment..........................................................................10
5.1 Secure Usage Assumptions ............................................................................................ 10
5.2 Threats Countered by the TOE....................................................................................... 11
5.3 Organizational Security Policies..................................................................................... 12
5.4 Clarification of Scope ..................................................................................................... 12
6 Architectural Information...........................................................................12
6.1 Architecture Overview ................................................................................................... 12
6.1.1 TOE Hardware.....................................................................................................................13
6.1.2 TOE Software ......................................................................................................................13
7 Documentation ..........................................................................................13
7.1 Design Documentation................................................................................................... 13
7.2 Guidance Documentation .............................................................................................. 13
7.3 Test Documentation....................................................................................................... 14
7.4 Vulnerability Assessment Documentation..................................................................... 14
7.5 Security Target ............................................................................................................... 14
8 IT Product Testing.......................................................................................14
8.1 Developer Testing .......................................................................................................... 14
8.2 Evaluation Team Independent Testing .......................................................................... 14
8.3 Vulnerability Analysis..................................................................................................... 15
4
9 Results of the Evaluation............................................................................16
10 Validator Comments/Recommendations....................................................16
11 Security Target ...........................................................................................16
12 Terms.........................................................................................................16
12.1 Acronyms.................................................................................................................... 16
13 Bibliography...............................................................................................17
List of Figures
Figure 1 – Functional Testing Components Diagram..........................................15
List of Tables
Table 1: Operational Environment Components .................................................6
Table 2: Product Identification............................................................................7
Table 3: Assumptions........................................................................................10
Table 4: Threats ................................................................................................11
Table 5: Organizational Security Policies...........................................................12
5
1 Executive Summary
This report documents the NIAP validators’ assessment of the CCEVS evaluation of the Bivio
6110-NC and Bivio 6120-NC.
This report is intended to assist the end-user of this product with determining the suitability of
this IT product in their environment. End-users should review both the Security Target (ST),
which is where specific security claims are made, in conjunction with this Validation Report
(VR), which describes how those security claims were evaluated.
The TOE is classified as a Network Device (a generic infrastructure device that can be connected
to a network).
The Bivio 6110-NC and 6120-NC devices can be used to run a variety of applications for
processing network data. It is out of scope for this certification process to include all those
applications for evaluation, so a standard application factory-installed to all Bivio 6110-NC and
6120NC devices as part of the base BiviOS will be provided. This application inspects packets
and will either drop or forward those packets based on configuration. It uses the default
mechanisms for packet handling and represents other packet processing applications that a
customer may choose to install. It is left to the end customer to decide whether they want to
pursue certification for applications other than the default BiviOS functionality.
The TOE consists of the following hardware:
• B6110-NC-M1D1
• B6110-NC-M1D2
• B6110-NC-M1D3
• B6110-NC-M2D1
• B6110-NC-M2D2
• B6110-NC-M2D3
• B6110-NC-M3D1
• B6110-NC-M3D2
• B6110-NC-M3D3
• B6120-NC-M1D1
• B6120-NC-M1D2
• B6120-NC-M1D3
• B6120-NC-M2D1
• B6120-NC-M2D2
• B6120-NC-M2D3
• B6120-NC-M3D1
• B6120-NC-M3D2
• B6120-NC-M3D3
Running the following software:
• BiviOS 8.0.3
The guidance documentation is also part of the TOE. A list of the guidance documents can be
found in Table 12 of the [ST].
The TOE’s operational environment must provide the following services to support the secure
operation of the TOE:
• Local Console
• Syslog Server
• An SSHv2 Client
6
• A TLSv1.2 client
This table identifies components that must be present in the Operational Environment to
support the operation of the TOE.
Component Description
Local Console • A local console with an RS-232 port for use with the Bivio provided
console cable.
Syslog Server
(Remote Audit
Server)
• Syslog server conformant to RFC 5424 (Syslog over TCP capable of
receiving an SSH tunnel from the TOE.
SSHv2 Client
(Remote
Administrative
Access)
• Administrators will need an SSHv2 Client conformant to RFCs 4251,
4252, 4253, 4254, and 6668.
o The SSHv2 client will need to be capable of supporting
AES128-CBC and AES256-CBC encryption algorithms, using
HMAC-SHA2-256 or HMAC-SHA2-512 integrity algorithms,
and performing key exchange using Diffie-Hellman Group14-
SHA1.
o To perform public key authentication to the TOE, the SSHv2
client will need to be capable of supporting SSH-RSA.
TLS Client
(Remote
Administrative
Access)
• The TOE also provides a CSfC TLS protected server capability, which
requires a TLSv1.2 client capable of negotiating one of the following
ciphersuites:
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in
RFC 5289
Table 1: Operational Environment Components
7
2 Identification of the TOE
Table 2 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 organizations and individuals participating in the evaluation.
Evaluation Scheme United States Common Criteria Evaluation Validation Scheme
Evaluated Target of
Evaluation
Bivio 6110-NC and Bivio 6120-NC
Protection Profile collaborative Protection Profile for Network Devices, Version
1.0, dated February 27, 2015 [NDcPP]
Security Target Bivio 6110-NC and 6120-NC Security Target
Dates of Evaluation July-August 2017
Conformance Result Pass
Common Criteria Version 3.1r4
Common Evaluation
Methodology (CEM) Version
3.1r4
Evaluation Technical Report
(ETR)
17-3586-R-0021 V1.2
Sponsor/Developer Bivio Networks, Inc.
Common Criteria Testing Lab
(CCTL)
UL Verification Services Inc.
CCTL Evaluators Michael C. Baron, Kenji Yoshino, Ryan Day
CCEVS Validators Dianne Hale, Patrick Mallett, PhD., Kenneth Stutterheim
Table 2: Product Identification
3 Interpretations
The Evaluation Team performed an analysis of the international interpretations of the CC and
the CEM and determined that none of the International interpretations issued by the Common
Criteria Interpretations Management Board (CCIMB) were applicable to this evaluation.
The TOE is also compliant with all international interpretations with effective dates on or before
August 2, 2017.
8
4 Security Policy
This section contains the product features and denotes which are within the logical boundaries
of the TOE. The following Security Functions are supported by the TOE:
• Audit
• Cryptography
• Identification and Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channels
4.1 Audit
• The TOE will audit all events and information defined in Table 7 of the [ST].
• The TOE will also include the identity of the user that caused the event (if applicable),
date and time of the event, type of event, and the outcome of the event.
• The TOE protects storage of audit information from unauthorized deletion.
• The TOE prevents unauthorized modifications to the stored audit records.
• The TOE can transmit audit data to an external IT entity using SSH protocol.
4.2 Cryptographic Operations
The TSF performs the following cryptographic operations:
For TLS:
• AES-128 in CBC mode for data ciphering, using SHA-1 hashing and RSA key exchange.
AES-256 in GCM mode for data ciphering, using SHA-384 hashing and ECDHE key
exchange.
For SSH:
• AES-128 or AES-256 in CBC mode, HMAC-SHA2-256 or HMAC-SHA2-512 hashing and DH
key exchange.
• Public key authentication via SSH-RSA, using HMAC-SHA1 hashing.
The TSF zeroizes all plaintext secret and private cryptographic keys and CSPs once they are no
longer required.
4.3 Identification and Authentication
• The TSF supports passwords consisting of alphanumeric and special characters with 15
characters or more. The TSF also allows administrators to set a minimum password
length.
• The TSF requires all administrative-users to authenticate before allowing the user to
perform any actions other than:
9
o Viewing the warning banner
o Responding to ICMP echo requests
o Responding to ARP requests with ARP replies
o Responding to DNS requests
4.4 Protection of the TSF
• The TSF stores and protects the following data:
o Syslog data, user account data, and local authentication data (such as
administrator passwords).
o Cryptographic keys, including pre-shared keys, symmetric keys, and private keys.
• There are two classes of users on the TOE:
o First, the Admin user. The Admin user has full control over the TOE and can
create other users (for instance, multiple administrative users) and control their
level of access to the TOE.
o Second, any administrator-created non-administrative user accounts. This would
be a highly unusual configuration, as in most cases there is no reason to create a
non-administrator account for the TOE. The TOE does not offer any functionality
that requires users to authenticate other than to perform administration of the
TOE.
• Management of the TSF:
o The administrator can perform manual updates, determine the behavior of or
modify the behavior of the handling of audit data, modify the behavior of the
TSF, enable or disable services offered by the TOE, determine the behavior of or
modify the behavior of audit functionality when local audit storage is full,
manage TSF data, modify or delete or generate or import cryptographic keys,
configure the access banner, and configure the session inactivity timeout period.
o The administrator may perform these functions locally or remotely using the
trusted path provided by SSH and defined in FTP_TRP.1.
4.5 TOE Access
• The TOE provides the capability to terminate either a remote or a local interactive
session after an Authorized Administrator configurable period of session inactivity.
• The TOE allows Administrator-initiated termination of the Administrator’s own
interactive session.
• Before establishing an administrative user session, the TOE is capable of displaying an
Authorized Administrator-specified advisory notice and consent warning message
regarding unauthorized use of the TOE.
4.6 Trusted Path/Channels
• The TOE uses SSH to provide a trusted communication channel between itself and all
authorized IT entities that is logically distinct from other communication channels and
provides assured identification of its end points and protection of the channel data from
disclosure and detection of modification of the channel data.
10
• The TOE permits the TSF, or the authorized IT entities, to initiate communication via the
trusted channel.
• The TOE uses either SSH or TLS to provide a trusted communication path between itself
and authorized administrative users that is logically distinct from other communication
channels. The TOE also provides assured identification of its end points and protection
of the channel data from disclosure and can detect modification of the channel data.
• The TOE permits remote administrators to initiate communication via the trusted path.
• The TOE requires the use of the trusted path for initial administrator authentication and
all remote administration actions.
5 TOE Security Environment
5.1 Secure Usage Assumptions
The following assumptions are made about the usage of the TOE:
Table 3: Assumptions
Assumption Description
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 and/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 will not include any
requirements on physical tamper protection or other physical attack
mitigations. The cPP will 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.
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
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 for particular types of network devices (e.g, firewall).
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 being 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.
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.
11
Table 3: Assumptions
Assumption Description
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.
5.2 Threats Countered by the TOE
The TOE is designed to counter the following threats:
Table 4: Threats
Threat Description
T.UNAUTHORIZED_ADMINIST
RATOR_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_COMMUNICAT
ION_CHANNELS
Threat agents may attempt to target network devices that do not use
standardized secure tunneling 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_E
NDPOINTS
Threat agents may take advantage of secure protocols that use weak methods to
authenticate the endpoints – e.g., 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 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
include replacing existing credentials with an attacker’s credentials, modifying
12
Table 4: Threats
Threat Description
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
A component of the network device may fail during start-up or during operations
causing a compromise or failure in the security functionality of the network
device, leaving the device susceptible to attackers.
5.3 Organizational Security Policies
The TOE enforces the following OSPs:
Table 5: Organizational Security Policies
OSP Description
P.ACCESS_BANNER The TOE shall display an initial banner describing restrictions of use, legal
agreements, or any other appropriate information to which users consent
by accessing the TOE.
5.4 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:
• As with any evaluation, this evaluation only shows that the evaluated configuration
meets the security claims made, with a certain level of assurance (the assurance
activities specified in the claimed PPs and performed by the evaluation team).
• This evaluation covers only the specific hardware models and software version
identified in this document, and not any earlier or later versions released or in process.
• The evaluation of security functionality of the product was limited to the functionality
specified in the claimed PP. Any additional security related functional capabilities of the
product discussed in supporting documentation were not covered by this evaluation.
• 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 exploited with a minimum of
understanding of the TOE, technical sophistication and resources.
6 Architectural Information
The TOE is classified as Network Device for Common Criteria purposes.
6.1 Architecture Overview
The TOE consists of hardware and software components.
13
6.1.1 TOE Hardware
The TOE consists of the following hardware:
• B6110-NC-M1D1
• B6110-NC-M1D2
• B6110-NC-M1D3
• B6110-NC-M2D1
• B6110-NC-M2D2
• B6110-NC-M2D3
• B6110-NC-M3D1
• B6110-NC-M3D2
• B6110-NC-M3D3
• B6120-NC-M1D1
• B6120-NC-M1D2
• B6120-NC-M1D3
• B6120-NC-M2D1
• B6120-NC-M2D2
• B6120-NC-M2D3
• B6120-NC-M3D1
• B6120-NC-M3D2
• B6120-NC-M3D3
6.1.2 TOE Software
The TOE runs the following software:
• BiviOS 8.0.3
7 Documentation
This section details the documentation that is (a) delivered to the customer, and (b) was used
as evidence for the evaluation of the Bivio 6110-NC and Bivio 6120-NC TOE. In these tables, the
following conventions are used:
• Documentation that is delivered to the customer is shown with bold titles.
• Documentation that was used as evidence but is not delivered is shown in a normal
typeface.
• Documentation that is delivered as part of the product but was not used as evaluation is
shown with a hashed background.
The guidance documents are provided to the product consumer via download from a web-
based customer portal provided by the vendor. These documents apply to the CC Evaluated
configuration:
7.1 Design Documentation
Document Revision Date
Bivio 6110 Development and Design Assessment Q
& A
1.0 March 1, 2016
Bivio 6110 Lifecycle and Product Labelling Q & A 1.0 March 4, 2016
7.2 Guidance Documentation
14
Document Revision Date
Bivio 6110-NC/6120-NC Common Criteria
Administrative Guidance
8.0 June 5, 2017
BiviOS™ User Guide for the Bivio 6110 and Bivio
6110-NC Platforms
Rev A N/A
Bivio 6110 and Bivio 6110-NC Platform Hardware
Installation and Configuration Guide
Rev A N/A
7.3 Test Documentation
Document Revision Date
16-3586-R-0067 Test Report 1.5 August 18, 2017
The test documentation is evaluation sensitive, and the results were summarized in the
evaluation associated Assurance Activity report.
7.4 Vulnerability Assessment Documentation
Document Revision Date
16-3586-R-0067 Test Report 1.5 August 18,
2017
7.5 Security Target
Document Revision Date
Bivio 6110-NC and 6120-NC Security Target 1.11 August 17, 2017
8 IT Product Testing
This section describes the testing efforts of the Developer and the Evaluation Team.
8.1 Developer Testing
No testing was performed by the developer.
8.2 Evaluation Team Independent Testing
The evaluation team performed the independent testing activities to confirm the TOE operates
to the TOE security functional requirements as specified in the ST for a product claiming
conformance to the collaborative Protection Profile for Network Devices, Version 1.0, February
27, 2015. The evaluation team devised a Test Plan based on the Testing Assurance Activities
specified in the NDcPP. The Test Plan described how each test activity was to be performed.
15
The evaluation team executed the tests specified in the Test Plan and documented the results
in ‘Test Document’ listed above in Section 7.3.
Independent testing was performed at the UL facility in San Luis Obispo, CA. The
hardware/software was provided in the same form that normal customers would receive it. The
evaluator installed and configured the TOE in accordance with the vendor provided guidance
documentation and performed the testing procedures as described in the Test Documentation.
Figure 1 – Functional Testing Components Diagram
8.3 Vulnerability Analysis
The evaluation team performed a vulnerability assessment and penetration testing based on an
initial port scan of the TOE. This comprehensive port scan identified any and all open ports and
acquired all possible identifying information from the TOE. This information was compared to
those services listed in the ST, and used as input into the public domain search.
Based on the output from the port scan, CVEdetails.org and ncd.nist.gov were searched with
the following terms:
• Bivio
• Bivio 6110
• Bivio 6110-NC
• BiviOS
• BiviOS 8.0.3
Based on the results, no vulnerabilities existed in the TOE that were exploitable at the time of
the search. In addition to the above information, the evaluators searched for vulnerabilities
that affect installed third party libraries. All CVEs identified do not affect the TOE’s specific
version of the third party libraries that are accessible over the network.
16
9 Results of the Evaluation
The evaluation was carried out in accordance with the Common Criteria Evaluation and
Validation Scheme (CCEVS) processes and procedures. The TOE was evaluated against the
criteria contained in the Common Criteria for Information Technology Security Evaluation,
Version 3.1 Revision 4. The evaluation methodology used by the Evaluation Team to conduct
the evaluation is the Common Methodology for Information Technology Security Evaluation,
Version 3.1 Revision 4
UL Verification Services Inc. has determined that the TOE meets the security criteria in the
Security Target. A team of Validators, on behalf of the CCEVS Validation Body, monitored the
evaluation. The evaluation was completed in August 2017.
10 Validator Comments/Recommendations
The Bivio products were evaluated against the Collaborative Protection Profile for Network
Devices. Although the products provide extensive functionality, only the security functional
requirements associated with the protection profile were evaluated. All other claims of device
functionality were not tested and no claims can be made regarding their effectiveness or
correct operation.
Note that the Bivio 6110 device can be used to run a variety of applications for processing
network data. It is out of scope for this certification to include these applications for evaluation.
It is left to the customer to decide whether they want to pursue certification for applications
other than the default BiviOS functionality.
Note that some hyperlinks in the ETR (AVA_VAN section) require manual modification to
function properly.
11 Security Target
Bivio 6110-NC and 6120-NC Security Target Version 1.11, August 17, 2017
12 Terms
12.1 Acronyms
CC Common Criteria
CSP Critical Security Parameters
DAC Discretionary Access Control
EAL Evaluation Assurance Level
FIPS Federal Information Processing Standards Publication 140-2
IDS Intrusion Detection System
IPS Intrusion Prevention System
I/O Input/Output
17
MIB Management Information Base
NIST National Institute of Standards and Technology
OCSP Online Certificate Status Protocol
PP Protection Profile
SF Security Functions
SFR Security Functional Requirements
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
13 Bibliography
[1] Common Criteria for Information Technology Security Evaluation – Part 1: Introduction
and general model, dated September 2012, Version 3.1 Revision 4, CCMB-2012-09-001.
[2] Common Criteria (CC) for Information Technology Security Evaluation – Part 2: Security
functional components, September 2012, Version 3.1, Revision 4, CCMB-2012-09-002.
[3] Common Criteria for Information Technology Security Evaluation – Part 3: Security
assurance components, September 2012, Version 3.1, Revision 4, CCMB-2012-09-003.
[4] Common Methodology for Information Technology Security Evaluation – Evaluation
methodology, September 2012, Version 3.1, Revision 4, CCMB-2012-09-004.
[5] Bivio 6110-NC and 6120-NC Security Target, 16-3586-R-0007, Version: 1.11, 2017-08-17
[6] Assurance Activity Report, VID10847, 17-3586-R-0022 V1.2, August 18, 2017
[7] Common Criterial Evaluation Technical Report, VID10847, 17-3586-R-0022 V1.2, August
18, 2017 <Evaluation Sensitive>
[8] Bivio 6110 Development and Design Assessment, Q & A, Version 1.0, 3/1/16 <Evaluation
Sensitive>
[9] Bivio 6110 Lifecycle and Product Labelling, Q & A Version 1.0, 3/4/16 <Evaluation
Sensitive>
[10] BiviOS User Guide for the Bivio 6110 and Bivio 6110-NC Platforms, Revision A, Document
Part Number: 64000-00122, 2016
[11] Bivio 6110-NC/6120-NC Common Criteria Administrative Guidance, Version 8.0, June 5,
2017