© 2017 Symantec Corporation 1 of 50 Updated 1/15/2019
Symantec Corporation
Blue Coat ProxySG, Blue Coat Reverse
Proxy, Blue Coat Reverse Proxy Virtual
Appliance, Blue Coat Secure Web
Gateway Virtual Appliance, and
Symantec Advanced Secure Gateway
Software Version: 6.7
Security Target
Document Version: 1.6
© 2017 Symantec Corporation 2 of 50 Updated 1/15/2019
Contact Information
Americas:
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
www.symantec.com
Copyright © 2017 Symantec Corp. All rights reserved. Symantec, the Symantec Logo, the Checkmark Logo, Blue Coat,
and the Blue Coat logo are trademarks or registered trademarks of Symantec Corp. or its affiliates in the U.S. and other
countries. Other names may be trademarks of their respective owners. This document is provided for informational
purposes only and is not intended as advertising. All warranties relating to the information in this document, either
express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject
to change without notice.
THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE
EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL
NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING,
PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS
DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. SYMANTEC CORPORATION PRODUCTS,
TECHNICAL SERVICES, AND ANY OTHER TECHNICAL DATA REFERENCED IN THIS DOCUMENT ARE
SUBJECT TO U.S. EXPORT CONTROL AND SANCTIONS LAWS, REGULATIONS AND REQUIREMENTS, AND
MAY BE SUBJECT TO EXPORT OR IMPORT REGULATIONS IN OTHER COUNTRIES. YOU AGREE TO COMPLY
STRICTLY WITH THESE LAWS, REGULATIONS AND REQUIREMENTS, AND ACKNOWLEDGE THAT YOU HAVE
THE RESPONSIBILITY TO OBTAIN ANY LICENSES, PERMITS OR OTHER APPROVALS THAT MAY BE
REQUIRED IN ORDER TO EXPORT, RE-EXPORT, TRANSFER IN COUNTRY OR IMPORT AFTER DELIVERY TO
YOU.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
© 2017 Symantec Corporation 3 of 50 Updated 1/15/2019
Table of Contents
1. INTRODUCTION ...................................................................................................................... 5
1.1 PURPOSE .......................................................................................................................... 5
1.2 SECURITY TARGET AND TOE REFERENCES ........................................................................ 5
1.3 PRODUCT OVERVIEW ......................................................................................................... 5
1.3.1 BLUE COAT PROXYSG APPLIANCES ................................................................................... 6
1.3.2 BLUE COAT REVERSE PROXY APPLIANCES AND VIRTUAL APPLIANCE ................................... 6
1.3.3 SYMANTEC ADVANCED SECURE GATEWAY APPLIANCES ...................................................... 7
1.3.4 BLUE COAT SWG VA ........................................................................................................ 7
1.4 TOE OVERVIEW ................................................................................................................ 8
1.5 TOE EVALUATED CONFIGURATION ..................................................................................... 9
1.6 TOE ARCHITECTURE ....................................................................................................... 10
1.6.1 Physical Boundaries........................................................................................... 10
1.6.2 Logical Boundaries............................................................................................. 11
2. CONFORMANCE CLAIMS .................................................................................................... 15
2.1 CC CONFORMANCE ......................................................................................................... 15
2.2 PROTECTION PROFILE CONFORMANCE ............................................................................. 15
2.3 CONFORMANCE RATIONALE.............................................................................................. 17
3. SECURITY PROBLEM DEFINITION ..................................................................................... 18
3.1 THREATS......................................................................................................................... 18
3.1.1 Communication with Network Devices............................................................... 18
3.1.2 Valid Updates ..................................................................................................... 19
3.1.3 Audited Activity................................................................................................... 19
3.1.4 Administrator and Device Credentials Data ....................................................... 20
3.1.5 Device Failure .................................................................................................... 20
3.2 ASSUMPTIONS ................................................................................................................. 21
3.2.1 A.PHYSICAL_PROTECTION ............................................................................ 21
3.2.2 A.LIMITED_FUNCTIONALITY ........................................................................... 21
3.2.3 A.NO_THRU_TRAFFIC_PROTECTION............................................................ 21
3.2.4 A.TRUSTED_ADMINISTRATOR ....................................................................... 21
3.2.5 A.REGULAR_UPDATES ................................................................................... 21
3.2.6 A.ADMIN_CREDENTIALS_SECURE................................................................ 21
3.3 ORGANIZATIONAL SECURITY POLICY................................................................................. 21
3.3.1 P.ACCESS_BANNER ........................................................................................ 22
4. SECURITY OBJECTIVES...................................................................................................... 23
4.1 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT .......................................... 23
4.1.1 OE.PHYSICAL ................................................................................................... 23
4.1.2 OE.NO_GENERAL_PURPOSE......................................................................... 23
4.1.3 OE.NO_THRU_TRAFFIC_PROTECTION......................................................... 23
4.1.4 OE.TRUSTED_ADMIN....................................................................................... 23
4.1.5 OE.UPDATES .................................................................................................... 23
4.1.6 OE.ADMIN_CREDENTIALS_SECURE ............................................................. 23
5. SECURITY REQUIREMENTS................................................................................................ 24
5.1 CONVENTIONS ................................................................................................................. 24
5.2 TOE SECURITY FUNCTIONAL REQUIREMENTS ................................................................... 24
5.2.1 Class: Security Audit (FAU) ............................................................................... 25
5.2.2 Class: Cryptographic Support (FCS).................................................................. 26
5.2.3 Class: Identification and Authentication (FIA) .................................................... 29
© 2017 Symantec Corporation 4 of 50 Updated 1/15/2019
5.2.4 Class: Security Management (FMT) .................................................................. 29
5.2.5 Class: Protection of the TSF (FPT).................................................................... 30
5.2.6 Class: TOE Access (FTA) .................................................................................. 30
5.2.7 Class: Trusted Path/Channels (FTP) ................................................................. 31
5.3 TOE SFR DEPENDENCIES RATIONALE FOR SFRS............................................................. 31
5.4 SECURITY ASSURANCE REQUIREMENTS............................................................................ 31
6. TOE SUMMARY SPECIFICATION ........................................................................................ 33
7. EXTENDED COMPONENT DEFINITIONS............................................................................ 40
7.1 FAU_STG_EXT.1 PROTECTED AUDIT EVENT STORAGE................................................... 40
7.2 FCS_RBG_EXT.1 RANDOM BIT GENERATION ................................................................. 41
7.3 FCS_HTTPS_EXT.1 HTTPS PROTOCOL ....................................................................... 41
7.4 FCS_SSHS_EXT.1 SSH SERVER PROTOCOL................................................................. 42
7.5 FCS_TLSS_EXT.1 TLS SERVER PROTOCOL .................................................................. 43
7.6 FIA_PMG_EXT.1 PASSWORD MANAGEMENT................................................................... 44
7.7 FIA_UIA_EXT.1 USER IDENTIFICATION AND AUTHENTICATION .......................................... 45
7.8 FIA_UAU_EXT.2 PASSWORD-BASED AUTHENTICATION MECHANISM ................................ 45
7.9 FPT_SKP_EXT.1 PROTECTION OF TSF DATA (FOR READING OF ALL SYMMETRIC KEYS).... 46
7.10 FPT_TST_EXT.1 TSF TESTING ...................................................................................... 47
7.11 FPT_TUD_EXT.1 TRUSTED UPDATE ............................................................................... 47
7.12 FTA_SSL_EXT.1 TSF-INITIATED SESSION LOCKING........................................................ 49
8. ACRONYMS........................................................................................................................... 50
List of Figures
FIGURE 1 PHYSICAL BOUNDARY FOR THE PROXYSG, RP, AND ASG S400 AND S500 APPLIANCES ..................10
FIGURE 2 PHYSICAL BOUNDARY FOR THE SWG AND RP VA...........................................................................10
List of Tables
TABLE 1 ST AND TOE REFERENCES ...............................................................................................................5
TABLE 2 PHYSICAL CHARACTERISTICS (S400) .................................................................................................8
TABLE 3 PHYSICAL CHARACTERISTICS (S500) .................................................................................................9
TABLE 4 IT ENVIRONMENT COMPONENTS .........................................................................................................9
TABLE 5 PROVIDED CRYPTOGRAPHY..............................................................................................................12
TABLE 6 TOE SECURITY FUNCTIONAL REQUIREMENTS AND AUDITABLE EVENTS ..............................................24
TABLE 7 SECURITY ASSURANCE REQUIREMENTS ............................................................................................32
TABLE 8 TOE SUMMARY SPECIFICATION SFR DESCRIPTION...........................................................................33
TABLE 9 EXTENDED COMPONENTS ................................................................................................................40
TABLE 10 ACRONYMS ...................................................................................................................................50
© 2017 Symantec Corporation 5 of 50 Updated 1/15/2019
1. Introduction
1.1 Purpose
This is a Non-Proprietary Security Target for the Blue Coat ProxySG, Blue Coat Reverse Proxy, Blue Coat
Reverse Proxy Virtual Appliance, Blue Coat Secure Web Gateway Virtual Appliance, and Symantec
Advanced Secure Gateway. This Non-Proprietary Security Target describes how the ProxySG, Reverse
Proxy (RP), Secure Web Gateway Virtual Appliance (SWG VA), and Advanced Secure Gateway (ASG)
meet the security requirements for the Network Device Collaborative Protection Profile. More information
can be found at https://www.niap-ccevs.org/Profile/Info.cfm?id=372.
1.2 Security Target and TOE References
Table 1 below shows the ST and TOE references.
Table 1 ST and TOE References
ST Title Symantec Corporation Blue Coat ProxySG, Blue Coat
Reverse Proxy, Blue Coat Reverse Proxy Virtual Appliance,
Blue Coat Secure Web Gateway Virtual Appliance, and
Symantec Advanced Secure Gateway Software Version: 6.7
Security Target
ST Version 1.6
ST Author Acumen Security, LLC.
ST Publication Date January 15, 2019
TOE Reference Blue Coat ProxySG, Blue Coat Reverse Proxy, Blue Coat
Reverse Proxy Virtual Appliance, Blue Coat Secure Web
Gateway Virtual Appliance, and Symantec Advanced Secure
Gateway
TOE Software Version Version 6.7.3.103
Build 216856 (ProxySG, RP, RP VA, SWG VA)
Build 216878 (ASG)
TOE Hardware Version S400-20, S400-30, S400-40, S500-10, S500-20, S500-301
TOE Developer Symantec Corporation
1.3 Product Overview
This section will provide a high level overview the ProxySG, Reverse Proxy (RP), RP VA, SWG VA, and
ASG products and their intended use.
1
S500-30 – This hardware model is only applicable to the Blue Coat ProxySG and Blue Coat Reverse Proxy.
© 2017 Symantec Corporation 6 of 50 Updated 1/15/2019
1.3.1 Blue Coat ProxySG Appliances
The foundation of Symantec’s application delivery infrastructure, Blue Coat ProxySG appliances establish
points of control that accelerate and secure business applications for users across the distributed
organization. Symantec appliances serve as an Internet proxy and wide area network (WAN) optimizer.
The purpose of the appliances is to provide a layer of security between an Internal and External Network
(typically an office network and the Internet), and to provide acceleration and compression of transmitted
data.
As the world’s leading proxy appliance, the Blue Coat ProxySG is a powerful yet flexible tool for improving
both application performance and security, removing the need for compromise:
• Security: Symantec’s industry leading security architecture addresses a wide range of
requirements, including filtering Web content, preventing spyware and other malicious mobile
code, scanning for viruses, inspecting encrypted Secure Sockets Layer (SSL) traffic, and
controlling instant messaging (IM), Voice-over-IP (VoIP), peer-to-peer (P2P), and streaming
traffic.
• Performance: Symantec’s patented “MACH5” acceleration technology combines five different
capabilities onto one box. Together, they optimize application performance and help ensure
delivery of critical applications. User and application fluent, MACH5 improves the user experience
no matter where the application is located, internally or externally on the Internet.
• Control: Symantec’s patented Policy Processing Engine empowers administrators to make
intelligent decisions. Using a wide range of attributes such as user, application, content and others,
organizations can effectively align security and performance policies with corporate priorities.
The ProxySG appliances run software that differs only in platform-specific configuration data, which
describes the intended hardware platform to the OS. Differences between product models allow for different
capacity, performance, and scalability options.
1.3.2 Blue Coat Reverse Proxy Appliances and Virtual Appliance
The Blue Coat Reverse Proxy appliances (both physical and virtual) combine robust security, high
performance content delivery, and operational simplicity, allowing organizations to secure and accelerate
their web applications and public websites.
• Protects Web Servers: Reverse Proxy securely isolates general-purpose servers from direct
Internet access, acting as an intermediary between web applications and the external clients who
attempt to access them. Reverse Proxy provides robust authentication and policy support and
can either challenge users or transparently check authentication credentials using an
organization’s existing security framework. For high performance, low-latency virus scanning of
all uploaded content to web servers, Reverse Proxy integrates with CAS and offers a choice of
leading anti-virus engines. To ensure confidentiality, Reverse Proxy can be configured to encrypt
communications between users and web applications using Secure Sockets Layer (SSL).
• Accelerates Web Content: At the heart of the Reverse Proxy solution is SGOS, a secure,
object-based operating system specifically designed to handle web content. SGOS combines
patented proxy caching technology with an optimized TCP stack for efficient web content
acceleration. SGOS’s intelligent use of its integrated cache allows 60-90% of an application’s web
objects to be cached and served directly to users, further enhancing site performance and
scalability. In addition, optional SSL services provide hardware-accelerated key negotiation,
encryption, and decryption support.
• Simplifies Operations: An integrated, optimized appliance that combines proxy software and
hardware, Reverse Proxy is easy to install, configure, and maintain. The Reverse Proxy’s Visual
Policy Manager (VPM) provides an intuitive, graphical interface to define and manage a wide range
© 2017 Symantec Corporation 7 of 50 Updated 1/15/2019
of policy rules. Comprehensive logging and reporting provide detailed accounting information,
giving administrators the visibility necessary to assess web usage patterns and track security
issues.
The Reverse Proxy appliances run software that differs only in platform-specific configuration data, which
describes the intended hardware platform to the OS. Differences between product models allow for different
capacity, performance, and scalability options
1.3.3 Symantec Advanced Secure Gateway Appliances
The Symantec Advanced Secure Gateway (ASG) appliances combine the functionality of Symantec’s
industry-leading Secure Web Gateway (ProxySG), with the intelligence of the Content Analysis System
(CAS) to offer a single, powerful web security solution that delivers world-class threat protection. ASG is a
scalable proxy designed to secure web communications and accelerate business applications. The
Gateway’s unique proxy architecture allows it to effectively monitor, control and secure traffic to ensure a
safe web (cloud) experience.
ASG appliances establish points of control that accelerate and secure business applications for users
across the distributed organization. ProxySG serves as an Internet proxy and wide area network (WAN)
optimizer. The purpose of the appliances is to provide a layer of security between an Internal and External
Network (typically an office network and the Internet), to provide acceleration and compression of
transmitted data, and to provide advanced threat protection for users and IT infrastructure.
ASG is a powerful yet flexible tool for improving both application performance and security, removing the
need for compromise:
• Security: Symantec’s industry leading security architecture addresses a wide range of requirements,
including filtering Web content, preventing spyware and other malicious mobile code, scanning for
viruses, inspecting encrypted Secure Sockets Layer (SSL) traffic, and controlling instant messaging
(IM), Voice-over-IP (VoIP), peer-to-peer (P2P), and streaming traffic.
• Control: Symantec’s patented Policy Processing Engine empowers administrators to make intelligent
decisions. Using a wide range of attributes such as user, application, content and others,
organizations can effectively align security and performance policies with corporate priorities.
• Advanced Threat Protection (ATP): ASG provides content and malware analysis to detect known
attacks, zero-day threats, and other advanced persistent threats. Unlike other ATP solutions,
information derived during content and malware analysis is used in real time to update policies so that
future instances of malware are blocked at the gateway. ATP features include malware
• Content Acceleration and Optimization: ASG performs caching, acceleration, and optimization of a
wide variety of popular and important protocols and content streaming standards.
The ASG appliances run software that differs only in platform-specific configuration data, which describes
the intended hardware platform to the OS. Differences between product models allow for different capacity,
performance, and scalability options.
1.3.4 Blue Coat SWG VA
The Blue Coat Secure Web Gateway Virtual Appliance (SWG VA) combines the unparalleled security
capabilities of ProxySG with the flexibility of virtualization. Together, they create a truly scalable virtual
Secure Web Gateway appliance for the data center. A pillar of Symantec’s Integrated Cyber Defense,
the SWG VAallows strong web security and enables corporate and regulatory compliance. The use of
virtual infrastructure on a common platform reduces costs and IT resources.
© 2017 Symantec Corporation 8 of 50 Updated 1/15/2019
The SWG VA is a powerful yet flexible tool for providing security and control, threat prevention, and
accelerated disaster recovery in an easy-to-deploy virtual appliance:
• Web 2.0 Security and Control – The Symantec Unified Security Solution is uniquely designed to
offer a comprehensive, enterprise-wide web security solution that can help close network security
gaps and protect users wherever they work. SWG VA extends the same rich policy controls in
ProxySG to the branch environment. With unified reporting that provides a single pane of glass
visibility across all users, and centralized management through the Symantec Director, the SWG VA
solution allows enterprises to seamlessly extend full protection and control to their branch offices
• Advanced Threat Protection – Integrating with Symantec WebPulse, the SWG VA is able to protect
against zero-day attacks through Negative-Day Defense. At any given time, the Global Intelligence
Network monitors over 1,500 sources identified as attack and malware launchers. By perpetually
monitoring the source of two-thirds of all malware, Symantec pinpoints suspicious behavior and
thwarts attacks at their origin. With Negative-Day Defense, Symantec defends against malicious
attacks before they ever launch.
• Disaster Recovery – With SWG VA, enterprises can quickly bring up an SWG deployment in case of
disaster recovery, and even leverage a backup image of the solution.
• Simplified Deployment – The SWG VA greatly simplifies the deployment by enabling hardware
consolidation and alleviating much of the IT administrative overhead. Running on VMWare ESX and
ESXi, SWG VA shares the same server hardware with other virtual appliances, which significantly
streamlines and accelerates the SWG deployment process. As a result, deployment that once took
days can now be completed in just hours.
1.4 TOE Overview
The TOE is the Blue Coat ProxySG, Blue Coat RP, Blue Coat RP VA, Blue Coat SWG VA, and Symantec
ASG. The ProxySG, RP, and ASG run on the S400 and S500 hardware platforms. The SWG VA and RP
VA are virtual appliances and are not tied to any specific hardware. The TOE type is a network device. The
purpose of the TOE is to provide a layer of security between an Internal and External Network (typically an
office network and the Internet). The TOE allows administrators to create and manage configurable policies
on controlled protocol traffic to and from the Internal Network users. A policy may include authentication,
authorization, content filtering, and auditing.
The TOE provides Administrative access via the serial port and Ethernet port. Administrators access the
serial port using a terminal emulator over a direct serial connection to the appliance. The serial port controls
access to the Setup Console (used for initial configuration only) and the Command Line Interface (CLI),
which is used for normal administrative operations. Administrators can also access the CLI using SSH over
an Ethernet connection. Administrators access the Management Console using HTTPS over an Ethernet
connection for normal administrative operations. The TOE provides secure management of the TOE’s
security capabilities. The tangible assets and management functions are protected by restricting access to
administrators. Only administrators can log into the TOE’s management interfaces, access the TOE
configuration, and configure policies. In addition, the TOE supports administrative user roles for managing
the TOE components. Figure 6 shows the details of the evaluated configuration of the TOE.)
The following table identifies the physical characteristics of the TOE:
Table 2 Physical Characteristics (S400)
S400-20 S400-30 S400-40
Interfaces Front • LED Display
• Control Buttons
© 2017 Symantec Corporation 9 of 50 Updated 1/15/2019
S400-20 S400-30 S400-40
• USB Ports
Rear • Serial Port
• (1) Ethernet Port (MGT)
• (4) Ethernet Port (Data)
• Power Switch
• Serial Port
• (1) Ethernet Port (MGT)
• (4) Ethernet Port (Data)
• Power Switch
• Serial Port
• (1) Ethernet Port (MGT)
• (4) Ethernet Port (Data)
• Power Switch
Disk Drives • 3 x 1TB SAS • 6 x 1TB SAS • 8 x 1TB SAS
Enclosure • 1 Rack-Unit (1RU)
• Weight: 28 lbs
Power Supply • (2) AC power connectors
Software 6.7.3
Table 3 Physical Characteristics (S500)
S500-10 S500-20 S500-30
Interfaces Front • LED Display
• Control Buttons
• USB Ports
Rear • Serial Port
• (1) Ethernet Port (MGT)
• (4) 10G Base T Ethernet
Port
• Serial Port
• (1) Ethernet Port (MGT)
• (4) 10G Base T Ethernet
Port
• Serial Port
• (1) Ethernet Port
(MGT)
• (4) 10G Base T
Ethernet Port
Disk Drives • 8 x 1TB SAS • 16 x 1TB SAS • 24 x 1TB SAS
Enclosure • 2 Rack-Unit (2RU)
• Weight: 66 lbs
Power Supply • (2) AC power connectors
Software 6.7.3
1.5 TOE Evaluated Configuration
The TOE evaluated configuration for the physical appliances is comprised of at least one of the following:
S400-20, S400-30, S400-40, S500-10, S500-20, or S500-30. For the SWG VA and the RP VA, the TOE
evaluated configuration is comprised of one instance of the VA executing on a Dell Precision T3610
hardware platform with ESXi 6.5. The evaluated configuration also supports the following external IT
entities;
Table 4 IT Environment Components
Component Required Usage/Purpose Description for TOE performance
Remote Management
Workstation (GUI).
Yes This includes any IT Environment Management workstation with
a web browser installed that is used by the TOE administrator to
support TOE administration through HTTPS and TLS protected
channels.
Remote Management
Workstation (CLI).
Yes This includes any IT Environment Management workstation with
an SSH client installed that is used by the TOE administrator to
support TOE administration through SSH protected channels.
Local Management
Workstation (CLI).
Yes This includes any IT Environment Management workstation with
a local CLI support that is used by the TOE administrator to
support TOE administration through a direct connection.
Audit Server Yes The audit server is used for remote storage of audit records that
have been generated by and pulled from the TOE.
© 2017 Symantec Corporation 10 of 50 Updated 1/15/2019
1.6 TOE Architecture
1.6.1 Physical Boundaries
The TOE is a hardware and software solution that is comprised of the network device and its 3
configurations described in section 1.4. The diagram below depicts the evaluated configuration. The red
rectangle represents the physical boundary of the TOE.
Figure 1 Physical Boundary for the ProxySG, RP, and ASG S400 and S500 appliances
Figure 2 Physical Boundary for the SWG and RP VA
© 2017 Symantec Corporation 11 of 50 Updated 1/15/2019
The IPv4 network on which the TOE resides is considered part of the environment. The software for the
physical appliances is pre-installed and is comprised of only the software versions identified in section 1.
The TOE physical boundary includes the following appliances:
• S400-20
• S400-30
• S400-40
• S500-10
• S500-20
• S500-30
The TOE boundary includes the following software:
• Software version 6.7.3
Note that the software distributions for SWG VA and RP VA are identical. Licenses activate different
features in the executable.
For the virtual appliances, the TOE physical boundary also includes the following:
• VMware ESXi 6.5 Hypervisor
• A single Guest Virtual Machine (SWG VA or RP VA)
• Hardware platform (Dell Precision T3610 for this evaluation) providing:
o Intel Xeon processor E5-1600 with up to 6 cores
o Minimum 4GB memory
o Integrated Gigabit Ethernet controller
o Minimum 1 hard drive with at least 100GB free space
No other virtual machines may be installed on the same hardware platform as the SWG VA or RP VA.
The TOE boundary includes the following guidance documentation,
• Symantec Corporation Blue Coat ProxySG, Blue Coat Reverse Proxy, Blue Coat Secure Web
Gateway Virtual Appliance, and Symantec Advanced Secure Gateway Firmware Version: 6.7.3
Common Criteria Administrative Guidance Document version 0.3
• SGOS Administration Guide Version 6.7.x Document Revision: SGOS 6.7.2.1—11/2017-N
• Command Line Interface Reference Version 6.7.x Document Revision: SGOS 6.7.x—07/2017-B
1.6.2 Logical Boundaries
The TOE provides several types of security functionalities, including.
• Security Audit
• Cryptography Support
• Identification & Authentication
• Security Management
• Protection of the TSF
• TOE Access
• Trusted Path/Channel
These features are described in more detail in the subsections below. In addition, the TOE implements all
RFCs of the Collaborative Protection Profile for Network Devices necessary to satisfy testing/ assurance
measures prescribed therein.
© 2017 Symantec Corporation 12 of 50 Updated 1/15/2019
1.6.2.1 Security Audit
The Network Appliances provide extensive auditing capabilities. The TOE generates a comprehensive set
of audit logs that identify specific TOE operations. For each event, the TOE records the date and time of
each event, the type of event, the subject identity, and the outcome of the event. Auditable events include:
• Start-up of the TOE from both cold boot and reboot,
• Shutdown of the TOE (when shut down from the local CLI, Remote CLI, and GUI),
• All administrative actions (both security relevant and non-security relevant) from the local CLI,
Remote CLI, and GUI,
• Remote administrative HTTPS/TLS connection establishment ,
• Remote administrative HTTPS/TLS connection closure,
• Errors during Remote administrative HTTPS/TLS connection establishment,
• Remote administrative SSH connection establishment,
• Remote administrative SSH connection closure,
• Errors during Remote administrative SSH connection establishment,
• Generation of self-signed certificates,
• Import of certificates,
• Deletion of certificates,
• Successful authentication attempts (from the local CLI, Remote CLI, and GUI),
• Unsuccessful authentication attempts (from the local CLI, Remote CLI, and GUI),
• All attempts to update the TOE software,
• Changes to time,
• Start of a local administrative session,
• End of a local administrative session,
• Administration session timeout (from the local CLI, Remote CLI, and GUI).
The TOE is configured to transmit its audit messages to an external audit server. Communication with the
audit server is protected using TLS.
The logs for all of the appliances can be viewed via the remote GUI interface or through the CLI. The
records include the date/time the event occurred, the event/type of event, the user ID associated with the
event, and additional information of the event and its success and/or failure.
1.6.2.2 Cryptographic Support
The TOE provides cryptographic support for the following features,
• TLSv1.1, TLSv 1.2 and HTTPS connectivity with the following entities:
o Management Web Browser,
o Audit Server.
• SSH connectivity with the following entities:
o Management SSH Client.
• Secure software update
The Cryptographic services provided by the TOE are described below;
Table 5 Provided Cryptography
Cryptographic Method Use within the TOE
AES • TLS Traffic Encryption/Decryption
• SSH Traffic Encryption/Decryption
RSA • TLS Session Establishment
• SSH Session Establishment
© 2017 Symantec Corporation 13 of 50 Updated 1/15/2019
• Software Upgrade
SP800-90A • TLS Session Establishment
• SSH Session Establishment
SHS • Used to provide TLS traffic integrity verification
• Used to provide SSH traffic integrity verification
HMAC-SHS • Used to provide TLS traffic integrity verification
• Used to provide SSH traffic integrity verification
SP800-56A • TLS Session Establishment`
• SSH Session Establishment
SP800-135rev1 • TLS Session Key Derivation
• SSH Session Key Derivation
1.6.2.3 Identification and Authentication
The TOE provides authentication services for administrative users to connect to the TOEs administrator
interfaces (local CLI, remote CLI, and remote GUI). The TOE requires Authorized Administrators to
authenticate prior to being granted access to any of the management functionality. In the Common Criteria
evaluated configuration, the TOE is configured to require a minimum password length of 15 characters.
The TOE provides administrator authentication against a local user database. Password-based
authentication can be performed on any TOE administrative.
1.6.2.4 Security Management
The TOE provides secure administrative services for management of general TOE configuration and the
security functionality provided by the TOE. Management can take place over a variety of interfaces
including:
• Local console command line administration;
• Remote CLI administration via SSH;
• Remote GUI administration via HTTPS/TLS.
All administration functions can be accessed via, remote CLI, remote GUI or via a direct connection to the
TOE. The TOE provides the ability to securely manage the below listed functions;
• All TOE administrative users;
• All identification and authentication;
• All audit functionality of the TOE;
• All TOE cryptographic functionality;
• The timestamps maintained by the TOE;
• Update to the TOE.
1.6.2.5 Protection of the TSF
The TOE protects against interference and tampering by untrusted subjects by implementing identification,
authentication, and access controls to limit configuration to Administrators. The TOE prevents reading of
cryptographic keys and passwords. Additionally, the TOE software (6.7.3) is custom-built for the appliance.
The TOE internally maintains the date and time. This date and time is used as the timestamp that is applied
to audit records generated by the TOE. Administrators can update the TOE’s clock manually. Finally, the
TOE performs testing to verify correct operation of the security appliances themselves. The TOE verifies
all software updates via digital signature (2048-bit RSA/SHA-256) and requires administrative intervention
prior to the software updates being installed on the TOE to avoid the installation of unauthorized software.
© 2017 Symantec Corporation 14 of 50 Updated 1/15/2019
1.6.2.6 TOE Access
The TOE can terminate inactive sessions after an Authorized 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 displays an Authorized Administrator specified banner on both the CLI and GUI management
interfaces prior to allowing any administrative access to the TOE.
1.6.2.7 Trusted Path/Channels
The TOE supports several types of secure communications, including,
• Trusted paths with remote administrators over SSH,
• Trusted paths with remote administrators over TLS/HTTPS,
• Trusted channels with remote IT environment audit servers over TLS.
© 2017 Symantec Corporation 15 of 50 Updated 1/15/2019
2. Conformance Claims
2.1 CC Conformance
This TOE is conformant to:
• Common Criteria for Information Technology Security Evaluations Part 1, Version 3.1, Revision 5,
April 2017
• Common Criteria for Information Technology Security Evaluations Part 2, Version 3.1, Revision 5,
April 2017: Part 2 extended
• Common Criteria for Information Technology Security Evaluations Part 3, Version 3.1, Revision 5,
April 2017: Part 3 conformant
2.2 Protection Profile Conformance
The TOE is conformant to:
• Collaborative Protection Profile for Network Devices, Version 1.0, 27 February 2015 [NDcPP].
This document conforms to the following Technical Decisions:
• 0291 - NIT technical decision for DH14 and FCS_CKM.1
• 0290 - NIT technical decision for physical interruption of trusted path/channel.
• 0289 - NIT technical decision for FCS_TLSC_EXT.x.1 Test 5e
• 0281 - NIT Technical Decision for Testing both thresholds for SSH rekey
• 0255 - NIT Technical Decision for TLS Server Tests - Issue 3: Verification of application of encryption
• 0235 – NIT Technical Decision adding DH group 14 to the selection in FCS_CKM.2
• 0227 – Technical Decision for TOE acting as a TLS Client and RSA key generation
• 0226 – NIT Technical Decision for TLS Encryption Algorithms
• 0199 – NIT Technical Decision for Elliptic Curves for Signatures
• 0189 – NIT Technical Decision for SSH Server Encryption Algorithms
• 0188 – NIT Technical Decision for Optional use of X.509 certificates for digital signatures
• 0185 – NIT Technical Decision for Channel for Secure Update.
• 0183 – NIT Technical Decision for Use of the Supporting Document
• 0181 – NIT Technical Decision for Self-testing of integrity of firmware and software.
• 0170 – NIT Technical Decision for SNMPv3 Support
• 0167 – NIT Technical Decision for Testing SSH 2^28 packets
• 0164 – NIT Technical Decision for Negative testing for additional ciphers for SSH
• 0156 – NIT Technical Decision for SSL/TLS Version Testing in the NDcPP v1.0 and FW cPP v1.0
• 0155 – NIT Technical Decision for TLSS tests using ECDHE in the NDcPP v1.0.
• 0154 – NIT Technical Decision for Versions of TOE Software in the NDcPP v1.0 and FW cPP v1.0
• 0153 – NIT Technical Decision for Auditing of NTP Time Changes in the NDcPP v1.0 and FW cPP v1.0
• 0151 – NIT Technical Decision for FCS_TLSS_EXT Testing - Issue 1 in NDcPP v1.0.
• 0150 – NIT Technical Decision for Removal of SSH re-key audit events in the NDcPP v1.0 and FW cPP v1.0
• 0143 – NIT Technical Decision for Failure testing for TLS session establishment in NDcPP and FWcPP
• 0130 – NIT Technical Decision for Requirements for Destruction of Cryptographic Keys
• 0126 – NIT Technical Decision for TLS Mutual Authentication
• 0125 – NIT Technical Decision for Checking validity of peer certificates for HTTPS servers
• 0116 – NIT Technical Decision for a Typo in reference to RSASSA-PKCS1v1_5 in NDcPP and FWcPP
• 0114 – NIT Technical Decision for Re-Use of FIPS test results in NDcPP and FWcPP
© 2017 Symantec Corporation 16 of 50 Updated 1/15/2019
• 0113 – NIT Technical Decision for testing and trusted updates in the NDcPP v1.0 and FW cPP v1.0
• 0112 – NIT Technical Decision for TLS testing in the NDcPP v1.0 and FW cPP v1.0.
• 0111 – NIT Technical Decision for third party libraries and FCS_CKM.1 in NDcPP and FWcPP
• 0096 – NIT Technical Interpretation regarding Virtualization
• 0095 – NIT Technical Interpretations regarding audit, random bit generation, and entropy in NDcPP
• 0094 – NIT Technical Decision for validating a published hash in NDcPP
• 0090 – NIT Technical Decision for FMT_SMF.1.1 Requirement in NDcPP
The following NIT technical decisions applicable to the Network Device Collaborative Protection Profile
are not applicable to this ST for the reasons stated:
• TD0262/NIT Technical Decision for TLS server testing - Empty Certificate Authorities list
(archived)
• TD0257 - NIT Technical Decision for Updating FCS_DTLSC_EXT.x.2/FCS_TLSC_EXT.x.2 Tests
1-4 (applicable to DTLS/TLS client functionality, which is not included in this ST)
• TD0256 - NIT Technical Decision for Handling of TLS connections with and without mutual
authentication (applicable to DTLS/TLS client functionality, which is not included in this ST)
• TD0228 – Technical Decision for CA certificates - basicConstraints validation (applicable to X.509
certificate functionality, which is not included in this ST)
• TD0225/NIT Technical Decision for Make CBC cipher suites optional in IPsec (applicable to
FCS_IPSEC_EXT.1, which is not included in this ST)
• TD0224/NIT Technical Decision Making DH Group 14 optional in FCS_IPSEC_EXT.1.11
(applicable to FCS_IPSEC_EXT.1, which is not included in this ST)
• TD0223/NIT Technical Decision for "Expected" vs "unexpected" DNs for IPsec Communications
(applicable to FCS_IPSEC_EXT.1, which is not included in this ST)
• TD0201 – NIT Technical Decision for Use of intermediate CA certificates and certificate hierarchy
depth (applicable to X.509 certificate functionality, which is not included in this ST)
• TD0200/NIT Technical Decision for Password authentication for SSH clients (applicable to
FCS_SSHC_EXT.1, which is not included in this ST)
• TD0187 – NIT Technical Decision for Clarifying FIA_X509_EXT.1 test 1 (applicable to X.509
certificate functionality, which is not included in this ST)
• TD0186: NIT Technical Decision for Applicability of X.509 certificate testing to IPsec (applicable
to X.509 and IPsec certificate functionality, which is not included in this ST)
• TD0184 – NIT Technical Decision for Mandatory use of X.509 certificates (applicable to X.509
certificate functionality, which is not included in this ST)
• TD0182 – NIT Technical Decision for Handling of X.509 certificates related to ssh-rsa and remote
comms. (applicable to X.509 certificate functionality, which is not included in this ST)
• TD0169 - NIT Technical Decision for Compliance to RFC5759 and RFC5280 for using CRLs
(applicable to X.509 certificate functionality, which is not included in this ST)
• TD0168 – NIT Technical Decision for Mandatory requirement for CSR generation (applicable to
X.509 certificate functionality, which is not included in this ST)
• TD0165 – NIT Technical Decision for Sending the ServerKeyExchange message when using
RSA (applicable to TLS client functionality, which is not included in this ST)
• TD0160/NIT Technical Decision for Transport mode and tunnel mode in IPSEC communications
(applicable to FCS_IPSEC_EXT.1, which is not included in this ST)
• TD0152 – NIT Technical Decision for Reference identifiers for TLS in the NDcPP v1.0 and FW
cPP v1.0 (applicable to TLS client functionality, which is not included in this ST)
• TD0117 – NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP (applicable to
X.509 certificate functionality, which is not included in this ST)
• TD0115/NIT Technical Decision for Transport mode and tunnel mode in IPsec communication in
NDcPP and FWcPP (applicable to FCS_IPSEC_EXT.1, which is not included in this ST)
© 2017 Symantec Corporation 17 of 50 Updated 1/15/2019
• TD0093/NIT Technical Decision for FIA_X509_EXT.1.1 Requirement in NDcPP (superceded by
TD0117)
2.3 Conformance Rationale
This Security Target provides exact conformance to Version 1.0 of the Collaborative Network Device
Protection Profile (NDcPPv1.0). The security problem definition, security objectives and security
requirements in this Security Target are all taken from the Protection Profile performing only operations
defined there.
© 2017 Symantec Corporation 18 of 50 Updated 1/15/2019
3. Security Problem Definition
The security problem definition has been taken from [NDcPP] and is reproduced here for the convenience
of the reader.
3.1 Threats
The threats for the Network Device are grouped according to functional areas of the device in the sections
below.
3.1.1 Communication with Network Devices
A network device communicates with other network devices and other network entities. The endpoints of
this communication can be geographically and logically distant and may pass through a variety of other
systems. The intermediate systems may be untrusted providing an opportunity for unauthorized
communication with the network device or for authorized communication to be compromised. The security
functionality of the network device must be able to protect any critical network traffic (administration traffic,
authentication traffic, audit traffic, etc.). The communication with the network device falls into two
categories: authorized communication and unauthorized communication.
Authorized communication includes network traffic allowable by policy destined to and originating from the
network device as it was designed and intended. This includes critical network traffic, such as network
device administration and communication with an authentication or audit logging server, which requires a
secure channel to protect the communication. The security functionality of the network device includes the
capability to ensure that only authorized communications are allowed and the capability to provide a secure
channel for critical network traffic. Any other communication is considered unauthorized communication.
The primary threats to network device communications addressed in this cPP focus on an external,
unauthorized entity attempting to access, modify, or otherwise disclose the critical network traffic. A poor
choice of cryptographic algorithms or the use of non-standardized tunneling protocols along with weak
administrator credentials, such as an easily guessable password or use of a default password, will allow a
threat agent unauthorized access to the device. Weak or no cryptography provides little to no protection of
the traffic allowing a threat agent to read, manipulate and/or control the critical data with little effort.
Nonstandardized tunneling protocols not only limit the interoperability of the device but lack the assurance
and confidence standardization provides through peer review.
3.1.1.1 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.
3.1.1.2 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.
© 2017 Symantec Corporation 19 of 50 Updated 1/15/2019
3.1.1.3 T.UNTRUSTED_COMMUNICATION_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.
3.1.1.4 T.WEAK_AUTHENTICATION_ENDPOINTS
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.
3.1.2 Valid Updates
Updating network device software and firmware is necessary to ensure that the security functionality of the
network device is maintained. The source and content of an update to be applied must be validated by
cryptographic means; otherwise, an invalid source can write their own firmware or software updates that
circumvents the security functionality of the network device. Methods of validating the source and content
of a software or firmware update by cryptographic means typically involve cryptographic signature schemes
where hashes of the updates are digitally signed.
Unpatched versions of software or firmware leave the network device susceptible to threat agents
attempting to circumvent the security functionality using known vulnerabilities. Non-validated updates or
updates validated using non-secure or weak cryptography leave the updated software or firmware
vulnerable to threat agents attempting to modify the software or firmware to their advantage.
3.1.2.1 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.
3.1.3 Audited Activity
Auditing of network device activities is a valuable tool for administrators to monitor the status of the device.
It provides the means for administrator accountability, security functionality activity reporting, reconstruction
of events, and problem analysis. Processing performed in response to device activities may give indications
of a failure or compromise of the security functionality. When indications of activity that impact the security
functionality are not generated and monitored, it is possible for such activities to occur without administrator
awareness. Further, if records are not generated and retained, reconstruction of the network and the ability
to understand the extent of any compromise could be negatively affected. Additional concerns are the
protection of the audit data that is recorded from alteration or unauthorized deletion. This could occur within
the TOE, or while the audit data is in transit to an external storage device.
Note this cPP requires that the network device generate the audit data and have the capability to send the
audit data to a trusted network entity (e.g., a syslog server).
© 2017 Symantec Corporation 20 of 50 Updated 1/15/2019
3.1.3.1 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.
3.1.4 Administrator and Device Credentials Data
A network device contains data and credentials which must be securely stored and must appropriately
restrict access to authorized entities. Examples include the device firmware, software, configuration
authentication credentials for secure channels, and administrator credentials. Device and administrator
keys, key material, and authentication credentials need to be protected from unauthorized disclosure and
modification. Furthermore, the security functionality of the device needs to require default authentication
credentials, such as administrator passwords, be changed.
Lack of secure storage and improper handling of credentials and data, such as unencrypted credentials
inside configuration files or access to secure channel session keys, can allow an attacker to not only gain
access to the network device, but also compromise the security of the network through seemingly
authorized modifications to configuration or though man-in-the-middle attacks. These attacks allow an
unauthorized entity to gain access and perform administrative functions using the Security Administrator’s
credentials and to intercept all traffic as an authorized endpoint. This results in difficulty in detection of
security compromise and in reconstruction of the network, potentially allowing continued unauthorized
access to administrator and device data.
3.1.4.1 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 existing credentials, or obtaining the administrator or device credentials
for use by the attacker.
3.1.4.2 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.
3.1.5 Device Failure
Security mechanisms of the network device generally build up from roots of trust to more complex sets of
mechanisms. Failures could result in a compromise to the security functionality of the device. A network
device self-testing its security critical components at both start-up and during run-time ensures the reliability
of the device’s security functionality.
3.1.5.1 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.
© 2017 Symantec Corporation 21 of 50 Updated 1/15/2019
3.2 Assumptions
This section describes the assumptions made in identification of the threats and security requirements for
network devices. The network device is not expected to provide assurance in any of these areas, and as a
result, requirements are not included to mitigate the threats associated.
3.2.1 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. [OE.PHYSICAL]
3.2.2 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).
[OE.NO_GENERAL_PURPOSE]
3.2.3 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). [OE.NO_THRU_TRAFFIC_PROTECTION]
3.2.4 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. [OE.TRUSTED_ADMIN]
3.2.5 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. [OE.UPDATES]
3.2.6 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. [OE.ADMIN_CREDENTIALS_SECURE]
3.3 Organizational Security Policy
An organizational security policy is a set of rules, practices, and procedures imposed by an organization to
address its security needs. For the purposes of this cPP a single policy is described in the section below.
© 2017 Symantec Corporation 22 of 50 Updated 1/15/2019
3.3.1 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. [FTA_TAB.1]
© 2017 Symantec Corporation 23 of 50 Updated 1/15/2019
4. Security Objectives
The security objectives have been taken from [NDcPP] and are reproduced here for the convenience of the
reader.
4.1 Security Objectives for the Operational Environment
The following subsections describe objectives for the Operational Environment.
4.1.1 OE.PHYSICAL
Physical security, commensurate with the value of the TOE and the data it contains, is provided by the
environment.
4.1.2 OE.NO_GENERAL_PURPOSE
There are no general-purpose computing capabilities (e.g., compilers or user applications) available on the
TOE, other than those services necessary for the operation, administration and support of the TOE.
4.1.3 OE.NO_THRU_TRAFFIC_PROTECTION
The TOE does not provide any protection of traffic that traverses it. It is assumed that protection of this
traffic will be covered by other security and assurance measures in the operational environment.
4.1.4 OE.TRUSTED_ADMIN
TOE Administrators are trusted to follow and apply all guidance documentation in a trusted manner.
4.1.5 OE.UPDATES
The TOE firmware and software is updated by an administrator on a regular basis in response to the release
of product updates due to known vulnerabilities.
4.1.6 OE.ADMIN_CREDENTIALS_SECURE
The administrator’s credentials (private key) used to access the TOE must be protected on any other
platform on which they reside.
© 2017 Symantec Corporation 24 of 50 Updated 1/15/2019
5.Security Requirements
This section identifies the Security Functional Requirements for the TOE and/or Platform. The Security
Functional Requirements included in this section are derived from Part 2 of the Common Criteria for
Information Technology Security Evaluation, Version 3.1, Revision 4, dated: September 2012 and all
international interpretations.
5.1 Conventions
The CC defines operations on Security Functional Requirements: assignments, selections, assignments
within selections and refinements. This document uses the following font conventions to identify the
operations defined by the CC:
• Assignment: Indicated with italicized text;
• Refinement made by PP author: Indicated with bold text and strikethroughs, if necessary;
• Selection: Indicated with underlined text;
• Assignment within a Selection: Indicated with italicized and underlined text;
• Iteration: Indicated by appending the iteration number in parenthesis, e.g., (1), (2), (3).
• Where operations were completed in the PP itself, the formatting used in the PP has been
retained.
Explicitly stated SFRs are identified by having a label ‘EXT’ after the requirement name for TOE SFRs.
Formatting conventions outside of operations matches the formatting specified within the PP.
5.2 TOE Security Functional Requirements
This section identifies the Security Functional Requirements for the TOE. The TOE Security
Functional Requirements that appear below in Table 1 are described in more detail in the following
subsections.
Table 6 TOE Security Functional Requirements and Auditable Events
Requirement Auditable Events Additional Audit Record Contents
FAU_GEN.1 None. None.
FAU_GEN.2 None. None.
FAU_STG_EXT.1 None. None.
FCS_CKM.1 None. None.
FCS_CKM.2 None. None.
FCS_CKM.4 None None
FCS_COP.1(1) None. None.
FCS_COP.1(2) None. None.
FCS_COP.1(3) None. None.
FCS_COP.1(4) None. None.
FCS_RBG_EXT.1 None. None.
FCS_HTTPS_EXT.1 Failure to establish a HTTPS
Session.
Reason for failure
FCS_TLSS_EXT.1 Failure to establish a TLS session Reason for failure
FCS_SSHS_EXT.1 Failure to establish an SSH session Reason for failure
FIA_PMG_EXT.1 None. None.
FIA_UIA_EXT.1 All use of the identification and
authentication mechanism.
Provided user identity, origin of the
attempt
authentication mechanism. (e.g., IP
address)
© 2017 Symantec Corporation 25 of 50 Updated 1/15/2019
Requirement Auditable Events Additional Audit Record Contents
FIA_UAU_EXT.2 All use of the identification and
authentication mechanism.
Origin of the attempt (e.g., IP address).
FIA_UAU.7 None. None
FMT_MOF.1(1)/Trusted
Update
Any attempt to initiate a manual
update
None.
FMT_MTD.1 All management activities of TSF
data.
None.
FMT_SMF.1 None. None.
FMT_SMR.2 None. None.
FPT SKP EXT.1 None. None.
FPT APW EXT.1 None. None.
FPT_STM.1 Changes to the time. The old and new values for the time.
Origin of the attempt (e.g., IP address).
FPT TUD EXT.1
Initiation of update; result of the
update attempt (success or failure) No additional information.
FPT TST EXT.1 None. None.
FTA_SSL_EXT.1 Any attempts at unlocking of an
interactive session. None.
FTA_SSL.3 The termination of a remote session
by the session locking mechanism. None.
FTA_SSL.4 The termination of an interactive
session. None.
FTA_TAB.1 None. None.
FTP_ITC.1 Initiation of the trusted channel.
Termination of the trusted channel.
Failure of the trusted channel
functions.
Identification of the initiator and target
of failed trusted channels
establishment attempt.
FTP_TRP.1 Initiation of the trusted channel.
Termination of the trusted channel.
Failures of the trusted path
functions.
Identification of the claimed user
identity.
5.2.1 Class: Security Audit (FAU)
FAU_GEN.1 Audit Data Generation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:
a) Start-up and shut-down of the audit functions;
b) All auditable events for the not specified level of audit; and
c) All administrative actions comprising:
• Administrative login and logout (name of user account shall be logged if
individual user accounts are required for administrators).
• Security related configuration changes (in addition to the information that a
change occurred it shall be logged what has been changed).
• Generating/import of, changing, or deleting of cryptographic keys (in addition
to the action itself a unique key name or key reference shall be logged).
• Resetting passwords (name of related user account shall be logged).
• Starting and stopping services (if applicable)
• [no other actions];
d) Specifically defined auditable events listed in Table 6.
© 2017 Symantec Corporation 26 of 50 Updated 1/15/2019
FAU_GEN.1.2 The TSF shall record within each audit record at least the following information:
a) Date and time of the event, type of event, subject identity, and the outcome (success or
failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the functional
components included in the PP/ST, information specified in column three of Table 6.
FAU_GEN.2 User Identity Association
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be able to
associate each auditable event with the identity of the user that caused the event.
FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity,
using a trusted channel according to FTP_ITC.1
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
FAU_STG_EXT.1.3 The TSF shall [overwrite previous audit records according to the following rule: [when
the log storage has reached its configured capacity]] when the local storage space for audit data is full.
5.2.2 Class: Cryptographic Support (FCS)
FCS_CKM.1 Cryptographic Key Generation (Refined)
FCS_CKM.1.1: The TSF shall generate asymmetric cryptographic keys in accordance with a specified
cryptographic key generation algorithm: [
• RSA schemes using cryptographic key sizes of 2048-bit or greater that meet the
following: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3;
• ECC schemes using "NIST curves" [P-256, P-384, P-521] that meet the following: FIPS PUB
186-4, "Digital Signature Standard (DSS)", Appendix B.4;
• FFC schemes using cryptographic key sizes of 2048-bit or greater that meet the following: FIPS
PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.1];
• FFC Schemes using Diffie-Hellman group 14 that meet the following: RFC 3526, Section
3]
and specified cryptographic key sizes that meet the following: [assignment: list of standards].
FCS_CKM.2 Cryptographic Key Establishment (Refined)
FCS_CKM.2.1: The TSF shall perform cryptographic key establishment in accordance with a
specified cryptographic key establishment method: [
• RSA-based key establishment schemes that meets the following: NIST Special Publication 800-
56B Revision 1, "Recommendation for Pair-Wise Key Establishment Schemes Using Integer
Factorization Cryptography";
• Elliptic curve-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
• Finite field-based key establishment schemes that meets the following: NIST
Special Publication 800-56A Revision 2, “Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography”;
• Key establishment scheme using Diffie-Hellman group 14 that meet the following: RFC 3526,
© 2017 Symantec Corporation 27 of 50 Updated 1/15/2019
Section 3
] that meets the following: [assignment: list of standards].
FCS_CKM.4 Cryptographic Key Destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method [
• For plaintext keys in volatile storage, the destruction shall be executed by a [single overwrite
consisting of [zeroes]];
• For plaintext keys in non-volatile storage, the destruction shall be executed by the invocation
of an interface provided by a part of the TSF that [
o logically addresses the storage location of the key and performs a [single] overwrite
consisting of [zeroes]]
that meets the following: No Standard.
FCS_COP.1(1) Cryptographic Operation (AES Data Encryption/ Decryption)
FCS_COP.1.1(1) The TSF shall perform encryption/decryption in accordance with a specified
cryptographic algorithm AES used in [CBC, GCM] mode and cryptographic key sizes [128 bits, 256
bits] that meet the following: AES as specified in ISO 18033-3, [CBC as specified in ISO 10116, GCM
as specified in ISO 19772].
FCS_COP.1(2) Cryptographic Operation (Signature Generation and Verification)
FCS_COP.1.1(2) The TSF shall perform cryptographic signature services (generation and
verification) in accordance with a specified cryptographic algorithm [:
RSA Digital Signature Algorithm and cryptographic key sizes (modulus) [2048 bits, 3072 bits]]
that meet the following: [
For RSA schemes: FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Section 5.5, using
PKCS #1 v2.1 Signature Schemes RSASSA-PSS and/or RSASSA-PKCS1v1_5; ISO/IEC
9796-2, Digital signature scheme 2 or Digital Signature scheme 3]
FCS_COP.1(3) Cryptographic Operation (Hash Algorithm)
FCS_COP.1.1(3) The TSF shall perform cryptographic hashing services in accordance with a specified
cryptographic algorithm [SHA-1, SHA-256, SHA-384, SHA-512] and cryptographic key sizes
[assignment: cryptographic key sizes] that meet the following: ISO/IEC 10118-3:2004.
FCS_COP.1(4) Cryptographic Operation (Keyed Hash Algorithm)
FCS_COP.1.1(4) The TSF shall perform keyed-hash message authentication in accordance with a
specified cryptographic algorithm [HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-
512] and cryptographic key sizes [160, 256, 384, 512-bits] and message digest sizes [160, 256, 384,
512] bits that meet the following: ISO/IEC 9797-2:2011, Section 7 “MAC Algorithm 2”.
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with
RFC 2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement HTTPS using TLS.
FCS_HTTPS_EXT.1.3 The TSF shall establish the connection only if [the peer initiates handshake].
© 2017 Symantec Corporation 28 of 50 Updated 1/15/2019
FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in
accordance with ISO/IEC 18031:2011 using [HMAC_DRBG (any)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from [[two] software-based noise source] with a minimum of [256 bits] of entropy
at least equal to the greatest security strength, according to ISO/IEC 18031:2011 Table C.1 “Security
Strength Table for Hash Functions”, of the keys and hashes that it will generate.
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs
4251, 4252, 4253, 4254, and [5647, 5656, 6668].
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports
the following authentication methods as described in RFC 4252: public key-based, password-based.
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater
than [1522] bytes in an SSH transport connection are dropped.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms and rejects all other encryption algorithms: [aes128-cbc, aes256-cbc,
AEAD_AES_256_GCM].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses
[ssh-rsa] and [no other public key algorithms] as its public key algorithm(s) and rejects all other public
key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses
[hmac-sha1, hmac-sha-1-96, hmac-sha2-256, hmac-sha2-512] and [no other MAC algorithms] as its
MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [diffie-hellman-group14-sha1, ecdh-sha2-nistp256]
and [ecdh-sha2-nistp384, ecdh-sha2-nistp521] are the only allowed key exchange methods used for
the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections the same session keys are
used for a threshold of no longer than one hour, and no more than one gigabyte of transmitted data.
After either of the thresholds are reached a rekey needs to be performed.
FCS_TLSS_EXT.1 TLS Server Protocol
FCS_TLSS_EXT.1.1 The TSF shall implement [TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)] supporting
the following ciphersuites:
• [
o TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
o TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
o TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
o TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
o TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
o TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289]
© 2017 Symantec Corporation 29 of 50 Updated 1/15/2019
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 2.0, SSL 3.0, TLS
1.0, and [none].
FCS_TLSS_EXT.1.3 The TSF shall [perform RSA key establishment with key size [2048 bits, 3072
bits]; generate EC Diffie-Hellman parameters over NIST curves [secp256r1] and no other curves;
generate Diffie-Hellman parameters of size [2048 bits]].
5.2.3 Class: Identification and Authentication (FIA)
FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: [“!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, [ “’”, “+”,
“-“, “=”, “.”, “/”, “\”, “:”, “;”, “<”, “>”, “[“, “]”, “_”, “{“, “}”, “|”, “~” “`” ]];
b) Minimum password length shall settable by the Security Administrator, and shall support
passwords of 15 characters or greater;
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1.1 The TSF shall require the following actions prior to allowing the non-TOE entity to initiate
the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [no other actions]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that administrative user
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [none] to
perform administrative user authentication.
FIA_UAU.7 Protected Authentication Feedback
FIA_UAU.7.1 The TSF shall provide only obscured feedback to the administrative user while the
authentication is in progress at the local console.
5.2.4 Class: Security Management (FMT)
FMT_MOF.1(1)/TrustedUpdate Management of security functions behavior
FMT_MOF.1.1(1)/TrustedUpdate The TSF shall restrict the ability to enable the functions to perform manual
update to Security Administrators.
FMT_MTD.1 Management of TSF Data
FMT_MTD.1.1 The TSF shall restrict the ability to manage the TSF data to the Security Administrators.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
• Ability to administer the TOE locally and remotely;
• Ability to configure the access banner;
• Ability to configure the session inactivity time before session termination or locking;
• Ability to update the TOE, and to verify the updates using [digital signature] capability prior to
installing those updates;
• [
© 2017 Symantec Corporation 30 of 50 Updated 1/15/2019
o Ability to configure audit behavior;
o Ability to configure the list of TOE-provided services available before an entity is identified
and authenticated, as specified in FIA_UIA_EXT.1;
o Ability to configure the cryptographic functionality;]
FMT_SMR.2 Restrictions on Security Roles
FMT_SMR.2.1 The TSF shall maintain the roles:
• Security Administrator
FMT_SMR.2.2 The TSF shall be able to associate the user with roles
FMT_SMR.2.3 The TSF shall ensure that the conditions
• Security Administrator role shall be able to administer the TOE locally;
• Security Administrator role shall be able to administer the TOE remotely;
are satisfied.
5.2.5 Class: Protection of the TSF (FPT)
FPT_SKP_EXT.1 Protection of TSF Data (for reading of all symmetric keys)
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys and private keys.
FPT_APW_EXT.1 Protection of Administrator Passwords
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
FPT_STM.1 Reliable Time Stamps
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
FPT_TUD_EXT.1 Trusted Update
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently
executing version of the TOE firmware/software and [the most recently installed version of the TOE
firmware/software].
FPT_TUD_EXT.1.2 The TSF shall provide Security Administrators the ability to manually initiate updates
to TOE firmware/software and [No other update mechanism].
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE
using a [digital signature mechanism] prior to installing those updates.
FPT_TST_EXT.1: TSF Testing
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [during initial start-up (on power on),
periodically during normal operation, at the request of the authorised user, at the conditions [manual reboot]
to demonstrate the correct operation of the TSF: [AES Known Answer Test, HMAC Known Answer Test,
RNG/DRBG Known Answer Test, SHA Known Answer Test, RSA Signature Known Answer Test (both
signature/verification), DH Known Answer Test, ECDH Known Answer Test].
5.2.6 Class: TOE Access (FTA)
FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [
© 2017 Symantec Corporation 31 of 50 Updated 1/15/2019
• terminate the session]
after a Security Administrator-specified time period of inactivity.
FTA_SSL.3 TSF-initiated Termination
FTA_SSL.3.1 Refinement: The TSF shall terminate a remote interactive session after a Security
Administrator-configurable time interval of session inactivity.
FTA_SSL.4 User-initiated Termination
FTA_SSL.4.1 Refinement: The TSF shall allow Administrator-initiated termination of the Administrator’s
own interactive session.
FTA_TAB.1 Default TOE Access Banners
FTA_TAB.1.1 Refinement: Before establishing an administrative user session the TSF shall display a
Security Administrator-specified advisory notice and consent warning message regarding use of the
TOE.
5.2.7 Class: Trusted Path/Channels (FTP)
FTP_ITC.1 Inter-TSF trusted channel
FTP_ITC.1.1 The TSF shall be capable of using [TLS] to provide a trusted communication channel
between itself and authorized IT entities supporting the following capabilities: audit server 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.
FTP_ITC.1.2 The TSF shall permit the TSF, or the authorized IT entities to initiate communication via the
trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [none].
FTP_TRP.1 Trusted Path
FTP_TRP.1.1 The TSF shall be capable of using [SSH, TLS, HTTPS] to provide a communication path
between itself and authorized remote administrators that is logically distinct from other communication
paths and provides assured identification of its end points and protection of the communicated data from
disclosure and provides detection of modification of the channel data.
FTP_TRP.1.2 The TSF shall permit remote administrators to initiate communication via the trusted path.
FTP_TRP.1.3 The TSF shall require the use of the trusted path for initial administrator authentication
and all remote administration actions.
5.3 TOE SFR Dependencies Rationale for SFRs
The Collaborative Protection Profile for Network Devices contains all the requirements claimed in this
Security Target. As such, the dependencies are not applicable since the PP has been approved.
5.4 Security Assurance Requirements
The TOE assurance requirements for this ST are taken directly from the Collaborative Protection Profile for
Network Devices which are derived from Common Criteria Version 3.1, Revision 4. The assurance
requirements are summarized in the table below.
© 2017 Symantec Corporation 32 of 50 Updated 1/15/2019
Table 7 Security Assurance Requirements
Assurance Class Components Components Description
Security Target ASE_CCL.1 Conformance claims (ASE_CCL.1)
ASE_ECD.1 Extended components definition (ASE_ECD.1)
ASE_INT.1 ST introduction (ASE_INT.1)
ASE_OBJ.1 Security objectives for the operational environment
(ASE_OBJ.1)
ASE_REQ.1 Stated security requirements (ASE_REQ.1)
ASE_SPD.1 Security Problem Definition (ASE_SPD.1)
ASE_TSS.1 TOE summary specification (ASE_TSS.1)
Development ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)
Guidance Documents AGD_OPE.1 Operational user guidance (AGD_OPE.1)
AGD_PRE.1 Preparative procedures (AGD_PRE.1)
Life Cycle Support ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)
ALC_CMS.1 TOE CM coverage (ALC_CMS.1)
Tests ATE_IND.1 Independent testing – sample (ATE_IND.1)
Vulnerability Assessment AVA_VAN.1 Vulnerability survey (AVA_VAN.1)
© 2017 Symantec Corporation 33 of 50 Updated 1/15/2019
6.TOE Summary Specification
This chapter identifies and describes how the Security Functional Requirements identified above are met
by the TOE.
Table 8 TOE Summary Specification SFR Description
# TOE SFR Rationale
1 FAU_GEN.1 The TOE provides extensive auditing capabilities. The TOE generates a comprehensive set of audit logs
that identify specific TOE operations. For each event, the TOE records the date and time of each event,
the type of event, the subject identity, and the outcome of the event. The types of events that cause audit
records to be generated include identification and authentication related events, and administrative
events. Each of the events is specified in the audit record is in enough detail to identify the user for which
the event is associated (e.g. user identity, MAC address, IP address), when the event occurred, where
the event occurred, the outcome of the event, and the type of event that occurred.
The logs for all of the appliances can be viewed via the remote GUI interface or through the CLI (local or
remote). Additionally, the TOE supports remote audit logging with an external audit server. Audit
messages are entered into the log and the subset of the log contents are sent to the audit server. When
an administrative command is executed, the TOE sets up the session data structure which includes the
“user identity”. When an audit log is generated, the session data is passed along with the audit information
and the TOE extracts the “user identity” from the session data structure.
The TOE generates the following types of audit logs during operation:
• Start-up of the TOE from both cold boot and reboot,
• Shutdown of the TOE (when shut down from the local CLI, Remote CLI, and GUI),
• All administrative actions (both security relevant and non-security relevant) from the local CLI,
Remote CLI, and GUI,
• Remote administrative HTTPS/TLS connection establishment ,
• Remote administrative HTTPS/TLS connection closure,
• Failures during Remote administrative HTTPS/TLS connection establishment,
• Remote administrative SSH connection establishment,
• Remote administrative SSH connection closure,
• Failures during Remote administrative SSH connection establishment,
• Generation of self-signed certificates,
• Import of certificates,
• Deletion of certificates,
• Successful authentication attempts (from the local CLI, Remote CLI, and GUI),
• Unsuccessful authentication attempts (from the local CLI, Remote CLI, and GUI),
• All attempts to update the TOE software,
• Changes to time,
• Start of a local administrative session,
• End of a local administrative session,
• Administration session timeout (from the local CLI, Remote CLI, and GUI).
2 FAU_GEN.2 The TOE ensures that each auditable event is associated with the user that triggered the event. For
example, a human user, user identity or related session ID would be included in the audit record. For an
IT entity or device, the IPv4 address, MAC address, host name, or other configured identification is
included in the audit record. The audit record is generated with the required information and stored
plaintext on the device.
3 FAU_STG_EXT.1 The TOE provides the ability to securely transmit audit logs to an external audit server using TLS/HTTPS.
The audit server, (installed with an HTTP command line tool such as Wget or cURL) uses a script to
periodically issue the following command to retrieve audit logs:.
https://<TOE_Address>:8082/Eventlog/fetch=0xffffffff
The command/request must also contain a valid administrator’s credentials in order for the TOE to
authorize access to the audit logs. The entire Audit Log is sent encrypted using TLS/HTTPS to the audit
server where the Audit Logs contents can be verified and viewed.
The maximum size of audit records stored by the TOE can be configured by an administrator. The upper
© 2017 Symantec Corporation 34 of 50 Updated 1/15/2019
# TOE SFR Rationale
limit on local audit storage is based on the amount of available hard drive space, but an administrator can
set a lower limit if desired.
For audit records stored internally to the TOE the audit records are stored in a circular log file where the
TOE overwrites the oldest audit records when the audit trail becomes full. Only Authorized Administrators
are able to clear the local logs, and local audit records are stored in a directory that does not allow
administrators to modify the contents. However, the Authorized Administrator may do a onetime
configuration that will not allow the administrator to erase logs. This command is irreversible and does
not reset even if the machine is returned to factory defaults.
4 FCS_CKM.1 The TOE can create a RSA public-private key pair with a RSA key size of 2048 and 3072bits. The RSA
algorithm implementation is provided by the included OpenSSL cryptographic library. The RSA key pair
can be used to generate a Certificate Signing Request (CSR).
Key generation via ECC schemes using "NIST curves" P-256, P-384, and P-521 that meet FIPS PUB
186-4 Appendix B.4; FFC schemes using cryptographic key sizes of 2048-bit or greater that meet FIPS
PUB 186-4 Appendix B.1; and Diffie-Hellman group 14 per RFC 3526, Section 3 are also included since
key establishment using these schemes is included in FCS_CKM.2.
The TOE is fully compliant to both SP 800-56A and SP 800-56B. The TOE implements each “shall”
statement in each standard and does not implement any “shall not” statements in either of the standards.
5 FCS_CKM.2 In support of secure cryptographic protocols, the TOE supports key establishment schemes, including,
• FFC Diffie-Hellman as specified in NIST SP 800-56A Revision 2: Used as part of SSH and
TLS session establishment,
• Elliptic Curve Diffie-Hellman as specified in NIST SP 800-56A Revision 2: used as part of
SSH and TLS session establishment,
• RSA Key Transport as specified in SP NIST 800-56B Revision 1: Used as part of TLS session
establishment
• Diffie-Hellman group 14 per RFC 3526, Section 3: Used as part of SSH session
establishment
The TOE is fully compliant to both SP 800-56A and SP 800-56B. The TOE implements each “shall”
statement in each standard and do not implement any “shall not” statements in either of the standards.
When negotiating sessions via SP 800-56B (RSA Key Transport) the TOE always acts as the receiver.
That is the TOE only acts as a server in the exchange. If the TOE encounters a decryption error during
session establishment (when using RSA based establishment ciphersuites), a reset message is sent and
the connection is not completed.
When using Diffie-Hellman group 14 key establishment, the TOE always acts as the receiver. That is the
TOE only acts as a server in the exchange. The TOE uses the FFC Diffie-Hellman key establishment
methodology of NIST SP 800-56A Revision 2 with the exception that the prime specified in RFC 3526
Section 3 is used.
6 FCS_CKM.4 The TOE meets all requirements specified in FIPS 140-2 for destruction of keys and Critical Security
Parameters (CSPs) when no longer required for use.
The TOE store several types of keys in volatile memory in plaintext, including,
• Diffie-Hellman Private/Public Key Pair,
• Elliptic Curve Diffie-Hellman Private/Public Key Pair,
• SSH Session Encryption Key,
• SSH Session Integrity Key,
• TLS Session Encryption Key,
• TLS Session Integrity Key.
Each plaintext key stored in volatile memory is associated with a cryptographic session. In each instance,
after the session closes, the key is overwritten with the value “00” After the overwrite operation is
complete, the TOE performs a specific "read-verify" operation to confirm that the storage space no longer
contains the key.
The TOE stores RSA key pairs used for TLS and SSH in non-volatile storage. These are overwritten three
times using a random pattern provided by the SP 800-90A DRBG.
7 FCS_COP.1(1) The TOE provides symmetric encryption and decryption capabilities using AES in CBC and GCM mode
(128 and 256 bits for CBC, 256 bits only for GCM) as described AES as specified in ISO 18033-3. AES
© 2017 Symantec Corporation 35 of 50 Updated 1/15/2019
# TOE SFR Rationale
is implemented in support of the following protocols: TLS, and SSH.
8 FCS_COP.1(2) The TOE provides cryptographic signature services using RSA Digital Signature Algorithm with key sizes
of 2048 and 3072 as specified in FIPS PUB 186-4, “Digital Signature Standard”.
9 FCS_COP.1(3) The TOE provides cryptographic hashing services using SHS as specified in FIPS Pub 180-3 “Secure
Hash Standard.” SHS hashing is used within several services including, hashing, TLS/HTTPS (SHA1,
SHA256, SHA384), and SSH (SHA1, SHA256, SHA384, SHA-512). SHA-256 is used in conjunction with
RSA signatures for verification of software image integrity.
10 FCS_COP.1(4) The TOE provides keyed-hashing message authentication services using HMAC-SHA-1, HMAC-SHA-1-
96, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. The product supports the following
cryptographic parameters for MACing, as specified in ISO/IEC 9797-2:2011:
• Key length: 160, 256, 384, 512-bits
• Hash function used: SHA-1, SHA-256, SHA-384, and SHA-512
• Block size: 512, 1024-bits
• Output MAC: 160, 256, 384, 512-bits
11 FCS_RBG_EXT.1 The TOE implements a NIST-approved HMAC_DRBG, as specified in SP 800-90.
The TOE implements a random bit generator in support of various cryptographic operations, including,
RSA key establishment schemes, Diff-Hellman key establishment schemes, TLS session establishment
and SSH session establishment.
The entropy source used to seed the Deterministic Random Bit Generator (e.g. based on SP 800-
90A/B/C) is a random set of bits or bytes that are regularly supplied to the DRBG by polling four different
set of software sources in threads. All entropy is continuously health tested by the DRBG as per the tests
defined in section 11.3 of SP 900-90A before being used as a seed (instantiate, generate, reseed, and
uninstantiate). Additionally, each call to the entropy source is subject to a continuous random number
generator test to ensure that there are no stuck conditions. Any initialization or system errors during
bring-up or processing of this system causes a reboot resulting in the DRBG being reseeded.
12 FCS_HTTPS_EXT.1/
FCS_TLSS_EXT.1
In support of secure communication with external entities, the TOE supports the TLS protocol acting as a
TLS server. TLS is used to facilitate communication with the following entities,
• Remote administrators
• Remote audit servers
The communication with remote administrators is over a TLS-protected HTTPS connection.
In support of these connections, the TOE supports TLS 1.1 and TLS 1.2. Connections using other version
of TLS or SSL, such as, TLS 1.0 or SSL 3.0 are actively denied by the TOE.
The following ciphersuites are supported for communications with remote administrators:
• TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
• TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
• TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
The TLS server support the following key exchange methods,
• rsa (2048, 3072 bit keys)
• dhe_rsa (2048, 3072-bits keys)
o RSA Key Sizes: 2048, 3072-bit keys
o DHE_RSA Key Sizes: 2048-bit Keys
• ecdhe_rsa
o RSA Key Sizes: 2048, 3072-bit keys
o ECDH Curves: P-256
© 2017 Symantec Corporation 36 of 50 Updated 1/15/2019
# TOE SFR Rationale
All other proposed ciphersuites are denied.
13 FCS_SSHS_EXT.1 The TOE uses SSH for to facilitate secure remote administrative sessions (CLI). The TOE's SSH
implementation supports the following,
• Use of 2048-bit RSA keys in support of SSH_RSA for public key-based authentication;
• Dropping SSH packets greater than 1522 bytes. This is accomplished by buffering all data for
a particular SSH packet transmission until the buffer limit is reached and then dropping the
packet;
• Strict compliance with RFCs 4251, 4252, 4253, and 4254,
o No optional options included in the RFCs have been implemented;
• Encryption algorithms aes128-cbc, aes256-cbc, AEAD_AES_256_GCM to ensure
confidentiality of the session;
• Password based authentication;
• Public key based authentication;
• Hashing algorithm hmac-sha1, hmac-sha-1-96, hmac-sha2-256, hmac-sha2-512 ensure the
integrity of the session;
The TOE enforces diffie-hellman-group14-sha1, ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-
sha2-nistp521 as the only allowed key exchange method.
The TOE forces a rekey after 1 hour or 2^28 bytes (which is less than one gigabyte), whichever occurs
first.
14 FIA_PMG_EXT.1 The TOE supports the local definition of users with corresponding passwords. The passwords can be
composed of any combination of upper and lower case letters, numbers, and special characters (that
include: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”, “’”, “+”, “-“, “=”, “.”, “/”, “\”, “:”, “;”, “<”, “>”, “[“, “]”, “_”, “{“,
“}”, “|”, “~” “`” . The minimum password length is settable by the Authorized Administrator. When the TOE
is configured for "Common Criteria Compliance" the minimum password length is set to 15 characters.
15 FIA_UIA_EXT.1 The TOE requires all users to be successfully identified and authenticated before allowing any TSF
mediated actions to be performed. Administrative access to the TOE is facilitated through one of several
interfaces,
• Directly connecting to the TOE
• Remotely connecting via SSHv2
• Remotely connecting to the GUI via HTTPS/TLS
Regardless of the interface at which the administrator interacts, the TOE will enforce username and
password authentication or public-key based authentication. Only after the administrative user presents
the correct authentication credentials will access to the TOE administrative functionality be granted. No
access is allowed to the administrative functionality of the TOE until an administrator is successfully
identified and authenticated.
The TOE provides a local password based authentication mechanism.
The process for authentication is the same for administrative access whether administration is occurring
via direct connection or remotely. At initial login, the administrative user is prompted to provide a
username. After the user provides the username, the user is prompted to provide the administrative
password associated with the user account. The TOE then either grant administrative access (if the
combination of username and password is correct) or indicate that the login was unsuccessful. The TOE
does not provide a reason for failure in the cases of a login failure.
16 FIA_UAU_EXT.2 The TOE requires all users to be successfully identified and authenticated before allowing any TSF
mediated actions to be performed. Administrative access to the TOE is facilitated through one of several
interfaces,
• Directly connecting to the TOE
• Remotely connecting via SSHv2
• Remotely connecting to the GUI via HTTPS/TLS
Regardless of the interface at which the administrator interacts, the TOE will enforce username and
password authentication or public-key based authentication (for SSH connections only). Only after the
administrative user presents the correct authentication credentials will access to the TOE administrative
functionality be granted. No access is allowed to the administrative functionality of the TOE until an
administrator is successfully identified and authenticated.
FIA_UAU.7
© 2017 Symantec Corporation 37 of 50 Updated 1/15/2019
# TOE SFR Rationale
The TOE provides a local password based authentication mechanism.
The process for authentication is the same for administrative access whether administration is occurring
via direct connection or remotely. At initial login, the administrative user is prompted to provide a
username. After the user provides the username, the user is prompted to provide the administrative
password associated with the user account. The TOE then either grant administrative access (if the
combination of username and password is correct) or indicate that the login was unsuccessful. The TOE
does not provide a reason for failure in the cases of a login failure.
For all authentication, regardless of the interface, the TOE displays only "*" characters when the
administrative password is entered so that the password is obscured.
18 FMT_MOF.1(1)/
Trusted Update
The TOE does not provide automatic updates to the software version running on the TOE.
The Security Administrators (a.k.a Authorized Administrators) can query the software version running on
the TOE, and can initiate updates to (replacements of) software images. When software updates are
made available, the Authorized Administrators can obtain, verify the integrity of, and install those updates.
This verification uses digital signatures.
19 FMT_MTD.1 The TOE provides the ability for Security Administrators (a.k.a Authorized Administrators) to access TOE
data, such as audit data, configuration data, security attributes, session thresholds and updates. Access
to this data is governed by the privileges assigned to the administrative users. None of this functionality
is accessible prior to the administrator logging into the TOE.
The term “Authorized Administrator” is used in this ST to refer to any of the predefined user privilege
levels.
20 FMT_SMF.1 The TOE provides all the capabilities necessary to securely manage the TOE. The Security Administrators
(a.k.a Authorized Administrators) user can connect to the TOE using the CLI to perform these functions
via remote CLI over SSHv2, at the local console, or via remote GUI over an HTTPS connection.
The specific management capabilities available from the TOE include:
• Local and remote administration of the TOE and the services provided by the TOE via the
TOE CLI/GUI, as described above,
• Ability to configure the access banner,
• Ability to configure the session inactivity time before session termination or locking,
• Ability to update the TOE, and to verify the updates using digital signature capability prior to
installing those updates,
• Ability to configure audit behavior;
• Ability to configure the list of TOE-provided services available before an entity is identified and
authenticated, as specified in FIA_UIA_EXT.1;
• Ability to configure the cryptographic functionality
The ability to manage the cryptographic functionality which allows the Authorized Administrator the ability
to identify and configure the algorithms used to provide protection of the data, such as generating RSA
keys.
21 FMT_SMR.2 The TOE supports multiple administrative roles when accessing the administrative interface through the
local or remote CLI. These roles define the access that is allowed per role. Additionally, the TOE supports
one authorized user role when accessing the TOE through the remote GUI interface. This role has full
access to the TOE management capabilities defined in the NDcPP.
22 FPT_SKP_EXT.1 All keys stored on the TOE are protected from unauthorized modification and substitution. The TOE stores
symmetric keys only in volatile memory never on persistent media. The TOE admin interface does not
provide any mechanism to view sensitive data (passwords or keys) once stored. Unauthenticated
operators do not have write access to modify, change, or delete keys.
The TOE stores all asymmetric keys in a secure directory that is not readily accessible to administrators;
therefore, there is no administrative interface access provided to directly manipulate the keys.
23 FPT_APW_EXT.1 No passwords are ever stored as clear text. Passwords are stored on the TOE in a secured partition in
non-plaintext. Prior to writing on disks each password is hashed (SHA-256) using the PBKDF2 algorithm.
During subsequent authentication attempts passwords entered are converted using the same PBKDF2
algorithm. This is compared to the digest value for that user stored in the secured partition. Access is only
granted if the values match.
24 FPT_TST_EXT.1
The TOE runs a suite of self-tests during initial start-up to verify its correct operation. If any of the tests
© 2017 Symantec Corporation 38 of 50 Updated 1/15/2019
# TOE SFR Rationale
fail, the Authorized Administrator will have to log into the TOE to determine which test failed and why.
During the system bootup process (power on or reboot), the TOE performs various power-on self-test
(POSTs) for the cryptographic components of the TOE.
During initialization and self-test execution, the module inhibits all access to the cryptographic algorithms.
Additionally, the power-on self-tests are performed after the cryptographic systems are initialized but prior
to the underlying OS initialization of external interfaces; this prevents the security appliances from passing
any data before completing selftests. In the event of a power-on self-test failure, the cryptographic module
will force the platform to reload and reinitialize the operating system and cryptographic components. This
operation ensures no cryptographic algorithms can be accessed unless all power on self-tests are
successful. These tests include:
• AES Known Answer Test - For the encrypt test, a known key is used to encrypt a known plain
text value resulting in an encrypted value. This encrypted value is compared to a known
encrypted value to ensure that the encrypt operation is working correctly. The decrypt test is
just the opposite. In this test a known key is used to decrypt a known encrypted value. The
resulting plaintext value is compared to a known plaintext value to ensure that the decrypt
operation is working correctly.
• HMAC Known Answer Test - For each of the hash values listed, the HMAC implementation is
fed known plaintext data and a known key. These values are used to generate a MAC. This
MAC is compared to a known MAC to verify that the HMAC and hash operations are
operating correctly.
• RNG/DRBG Known Answer Test - For this test, known seed values are provided to the DRBG
implementation. The DRBG uses these values to generate random bits. These random bits
are compared to known random bits to ensure that the DRBG is operating correctly.
• SHA Known Answer Test – For each of the values listed, the SHA implementation is fed
known data and key. These values are used to generate a hash. This hash is compared to a
known value to verify they match and the hash operations are operating correctly.
• RSA Signature Known Answer Test (both signature/verification) - This test takes a known
plaintext value and Private/Public key pair and used the public key to encrypt the data. This
value is compared to a known encrypted value to verify that encrypt operation is working
properly. The encrypted data is then decrypted using the private key. This value is compared
to the original plaintext value to ensure the decrypt operation is working properly.
• DH Known Answer Test – This test takes known input to the “z” calculation for Diffie-Hellman
and compares the result to a known “z” value.
• ECDH Known Answer Test – This test takes known input to the “z” calculation for Elliptic
Curve Diffie-Hellman and compares the result to a known “z” value.
Software Integrity Test - This test is run automatically whenever the system images is loaded and confirms
through use of digital signature verification that the image file that’s about to be loaded was properly
signed and maintained its integrity since being signed. The system image is digitally signed prior to being
made available for download from Bluecoat/Symantec.
25 FPT_TUD_EXT.1 Authorized Administrator can query the software version running on the TOE, and can initiate updates to
software images. When software updates are made available, an administrator can obtain, verify the
integrity of via digital signature, and install those updates. The updates can be downloaded from
Upgrades.soleranetworks.com. The TOE image files are digitally signed so their integrity can be verified
during the boot process, and an image that fails an integrity check will not be loaded. The public keys
used by the update verification mechanism are contained on the TOE. As part of the build process, the
update image is signed with the Bluecoat/Symantec private key. This is done using an RSA 2048/SHA-
256 digital signature. Only if the signature/hash is correct, will the image be installed. If an update is
unsuccessful, a message is delivered to the user. Since the update process attempts to update a different
copy than what is currently being run, the current active image remains the same and the user continues
to run the same code that was being run before the upgrade attempt was made.
26 FPT_STM.1 The TOE provides a source of date and time information used in audit event timestamps. The clock
function is reliant on the system clock provided by the underlying hardware.
27 FTA_SSL_EXT.1 The TOE provides the administrative user to defined inactivity time out periods for administrative sessions.
The inactivity period for CLI (local and remote) and GUI (remote) administrative access are maintained
separately and are configured separately through the TOE administrative interfaces.
If an administrative session remains inactive for the configured length of time, the administrative session
is terminated. After termination, administrative authentication is required to access any of the
administrative functionality of the TOE. This is applicable from both local and remote administrative
© 2017 Symantec Corporation 39 of 50 Updated 1/15/2019
# TOE SFR Rationale
sessions.
28 FTA_SSL.3 The TOE provides the administrative user to defined inactivity time out periods for administrative sessions.
The inactivity period for CLI (local and remote) and GUI (remote) administrative access are maintained
separately and are configured separately through the TOE administrative interfaces.
If an administrative session remains inactive for the configured length of time, the administrative session
is terminated. After termination, administrative authentication is required to access any of the
administrative functionality of the TOE. This is applicable from both local and remote administrative
sessions.
An Authorized Administrator is able to exit out of both local and remote administrative sessions. When
accessing the TOE via the CLI (both local and remote), the exit command is used. When accessing the
TOE via the remote GUI, the logout button is used.
FTA_SSL.4
29 FTA_TAB.1 For TOE administration, the GUI (TLS/HTTPS), CLI (SSH) and local console CLI are available. Prior to
an administrative user authenticating, that user is presented with an access display banner which displays
an advisory notice and consent warning message regarding unauthorized use of the TOE.
This banner will be displayed prior to allowing Administrator access through those interfaces.
30 FTP_ITC.1 The TOE protects communications with authorized IT entities, as follows:
• Trusted channels with audit servers are protected via TLS.
This protects the data from disclosure by encryption and by checksums that verify that data has not been
modified.
31 FTP_TRP.1 All remote administrative communications take place over a secure encrypted session. Remote CLI
connections take place over an SSHv2 tunnel. The SSHv2 session is encrypted using AES encryption.
Remote GUI connections take place over a TLS/HTTPS connection. The TLS session is encrypted using
AES encryption. The remote administrators are able to initiate both SSHv2 and TLS/HTTPS
communications with the TOE.
The TOE rejects all insecure remote authentication attempts (e.g., telnet and HTTP).
© 2017 Symantec Corporation 40 of 50 Updated 1/15/2019
7. Extended Component Definitions
The Security Functional Components found in Table 9 below as well as in Section 5 of this Security Target
are taken directly from the Collaborative Protection Profile for Network Devices, Version 1.0. These
components claim exact conformance to the definitions within the PP and, as identified in Section 5.1 of
the PP, “are identified by having a label ‘_EXT’ at the end of the SFR name.”
Table 9 Extended Components
7.1 FAU_STG_EXT.1 Protected Audit Event Storage
FAU_STG_EXT.1 Protected audit event storage requires the TSF to use a trusted channel implementing a
secure protocol.
Management: FAU_STG_EXT.1
The following actions could be considered for the management functions in FMT:
a) The TSF shall have the ability to configure the cryptographic functionality.
Audit: FAU_STG_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) No audit necessary.
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FTP_ITC.1 Inter-TSF Trusted Channel
FAU_STG_EXT.1.1 The TSF shall be able to transmit the generated audit data to an external IT entity
using a trusted channel according to FTP_ITC.
Application Note 94
For selecting the option of transmission of generated audit data to an external IT entity the TOE relies on a
non-TOE audit server for storage and review of audit records. The storage of these audit records and the
Class Family/Component Description
FAU: Security Audit FAU_STG_EXT.1 Protected Audit Event Storage
FCS: Cryptographic Support
FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_SSHS_EXT.1 SSH Server Protocol
FCS_TLSS_EXT.1 TLS Server Protocol
FCS_RBG_EXT.1 Random Bit Generation
FIA: Identification and
Authentication
FIA_PMG_EXT.1 Password Management
FIA_UIA_EXT.1 User Identification and Authentication
FIA_UAU_EXT.2 Password-based Authentication Mechanism
FPT: Protection of the TSF
FPT SKP EXT.1
Protection of TSF Data (for reading of all
symmetric keys)
FPT APW EXT.1 Protection of Administrator Passwords
FPT TUD EXT.1 Trusted Update
FPT TST EXT.1 TSF Testing
FTA: TOE Access FTA_SSL_EXT.1 TSF-initiated Session Locking
© 2017 Symantec Corporation 41 of 50 Updated 1/15/2019
ability to allow the administrator to review these audit records is provided by the operational environment
in that case.
FAU_STG_EXT.1.2 The TSF shall be able to store generated audit data on the TOE itself.
FAU_STG_EXT.1.3 The TSF shall [selection: drop new audit data, overwrite previous audit records
according to the following rule: [assignment: rule for overwriting previous audit records], [assignment: other
action]] when the local storage space for audit data is full.
Application Note 95
The external log server might be used as alternative storage space in case the local storage
space is full. The ‘other action’ could in this case be defined as ‘send the new audit data to
an external IT entity’.
7.2 FCS_RBG_EXT.1 Random Bit Generation
FCS_RBG_EXT.1 Random Bit Generation requires random bit generation to be performed in
accordance with selected standards and seeded by an entropy source.
Management: FCS_RBG_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen
Audit: FCS_RBG_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Minimal: failure of the randomization process
Hierarchical to: No other components
Dependencies: No other components
FCS_RBG_EXT.1.1 The TSF shall perform all deterministic random bit generation services in accordance
with ISO/IEC 18031:2011 using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
FCS_RBG_EXT.1.2 The deterministic RBG shall be seeded by at least one entropy source that
accumulates entropy from [selection: [assignment: number of software-based sources] software-based
noise source, [assignment: number of hardware-based sources] hardware-based noise source] with
minimum of [selection; 128 bits, 192 bits, 256 bits] of entropy at least equal to the greatest security strength,
according to ISO/IEC 18031:2011 Table C.1 “Security Strength Table for Hash Functions”, of the keys and
hashes that it will generate.
7.3 FCS_HTTPS_EXT.1 HTTPS Protocol
FCS_HTTPS_EXT.1 HTTPS requires that HTTPS be implemented according to RFC 2818
and supports TLS.
Management: FCS_HTTPS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_HTTPS_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
© 2017 Symantec Corporation 42 of 50 Updated 1/15/2019
included in the PP/ST:
a) There are no auditable events foreseen
Hierarchical to: No other components
Dependencies: FCS_TLS_EXT.1 TLS Protocol
FCS_HTTPS_EXT.1.1 The TSF shall implement the HTTPS protocol that complies with RFC 2818.
FCS_HTTPS_EXT.1.2 The TSF shall implement the HTTPS protocol using TLS.
FCS_HTTPS_EXT.1.3 The TSF shall establish the connection only if [selection: the peer presents a valid
certificate during handshake, the peer initiates handshake].
7.4 FCS_SSHS_EXT.1 SSH Server Protocol
FCS_SSHS_EXT.1 SSH Server requires that the server side of SSH be implemented as specified.
Management: FCS_SSHS_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_SSHS_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Failure of SSH session establishment.
b) SSH session establishment
c) SSH session termination
Hierarchical to: No other components
Dependencies: FCS_COP.1(1) Cryptographic operation (AES Data encryption/decryption)
FCS_COP.1(2) Cryptographic operation (Signature Verification)
FCS_COP.1(3) Cryptographic Operation (Hash Algorithm)
FCS_SSHS_EXT.1.1 The TSF shall implement the SSH protocol that complies with RFCs
4251, 4252, 4253, 4254, and [selection: 5647, 5656, 6187, 6668, no other RFCs].
Application Note 109
The ST author selects which of the additional RFCs to which conformance is being claimed. Note that these
need to be consistent with selections in later elements of this component (e.g., cryptographic algorithms
permitted). RFC 4253 indicates that certain cryptographic algorithms are “REQUIRED”. This means that
the implementation must include support, not that the algorithms must be enabled for use. Ensuring that
algorithms indicated as “REQUIRED” but not listed in the later elements of this component are implemented
is out of scope of the assurance activity for this requirement.
FCS_SSHS_EXT.1.2 The TSF shall ensure that the SSH protocol implementation supports the following
authentication methods as described in RFC 4252: public key-based, password-based.
FCS_SSHS_EXT.1.3 The TSF shall ensure that, as described in RFC 4253, packets greater than
[assignment: number of bytes] bytes in an SSH transport connection are dropped.
Application Note 110
© 2017 Symantec Corporation 43 of 50 Updated 1/15/2019
RFC 4253 provides for the acceptance of “large packets” with the caveat that the packets should be of
“reasonable length” or dropped. The assignment should be filled in by the ST author with the maximum
packet size accepted, thus defining “reasonable length” for the TOE.
FCS_SSHS_EXT.1.4 The TSF shall ensure that the SSH transport implementation uses the following
encryption algorithms and rejects all other encryption algorithms: [selection: aes128-cbc, aes256-cbc,
AEAD_AES_128_GCM, AEAD_AES_256_GCM].
FCS_SSHS_EXT.1.5 The TSF shall ensure that the SSH transport implementation uses [assignment: List
of public key algorithms] as its public key algorithm(s) and rejects all other public key algorithms.
FCS_SSHS_EXT.1.6 The TSF shall ensure that the SSH transport implementation uses [assignment: List
of MAC algorithms] as its MAC algorithm(s) and rejects all other MAC algorithm(s).
FCS_SSHS_EXT.1.7 The TSF shall ensure that [assignment: List of key exchange methods] are the only
allowed key exchange methods used for the SSH protocol.
FCS_SSHS_EXT.1.8 The TSF shall ensure that within SSH connections the same session keys are used
for a threshold of no longer than one hour, and no more than one gigabyte of transmitted data. After either
of the thresholds are reached a rekey needs to be performed.
7.5 FCS_TLSS_EXT.1 TLS Server Protocol
FCS_TLSS_EXT.1 TLS Server requires that the server side of TLS be implemented as specified.
Management: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FCS_TLSS_EXT.1, FCS_TLSS_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Failure of TLS session establishment.
b) TLS session establishment
c) TLS session termination
Hierarchical to: No other components
Dependencies: FCS_CKM.1 Cryptographic Key Generation
FCS_COP.1(1) Cryptographic operation (AES Data encryption/decryption)
FCS_COP.1(2) Cryptographic operation (Signature Verification)
FCS_COP.1(3) Cryptographic Operation (Hash Algorithm)
FCS_RBG_EXT.1 Random Bit Generation
FCS_TLSS_EXT.1.1 The TSF shall implement [selection: TLS 1.2 (RFC 5246), TLS 1.1 (RFC 4346)]
supporting the following ciphersuites:
[selection:
○ TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268
○ TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 3268
○ TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
© 2017 Symantec Corporation 44 of 50 Updated 1/15/2019
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
○ TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
○ TLS_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
○ TLS_DHE_RSA_WITH_AES_128_CBC_ SHA256 as defined in RFC 5246
○ TLS_DHE_RSA_WITH_AES_256_CBC_ SHA256 as defined in RFC 5246
○ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
○ TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
○ TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
○ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289 ].
Application Note 119
The ciphersuites to be tested in the evaluated configuration are limited by this requirement. The ST author
should select the ciphersuites that are supported. It is necessary to limit the ciphersuites that can be used
in an evaluated configuration administratively on the server in the test environment. Note that RFC 5246
makes TLS_RSA_WITH_AES_128_CBC_SHA a mandatory ciphersuite, but it is treated as optional for the
purposes of conformance with this cPP (i.e. the selection of ‘TLS 1.2 (RFC 5246)’ will be accepted as
conformant with this SFR even if TLS_RSA_WITH_AES_128_CBC_SHA is not one of the ciphersuites
listed in the ST).
FCS_TLSS_EXT.1.2 The TSF shall deny connections from clients requesting SSL 1.0, SSL 2.0, SSL 3.0,
TLS 1.0, and [selection: TLS 1.1, TLS 1.2, none].
Application Note 120
Any TLS versions not selected in FCS_TLSS_EXT.1.1 should be selected here.
FCS_TLSS_EXT.1.3 The TSF shall [selection: perform RSA key establishment with key size
[selection: 2048 bits, 3072 bits, 4096 bits]; generate EC Diffie-Hellman parameters over NIST
curves [selection: secp256r1, secp384r1, secp521r1] and no other curves; generate Diffie-
Hellman parameters of size [selection: 2048, bits, 3072 bits]].
Application Note 121
The assignments will be filled in based on the assignments performed in FCS_TLSS_EXT.1.1.
7.6 FIA_PMG_EXT.1 Password Management
FIA_PMG_EXT.1 Password management requires the TSF to support passwords with varying composition
requirements, minimum lengths, maximum lifetime, and similarity constraints.
Management: FIA_PMG_EXT.1
No management functions.
Audit: FIA_PMG_EXT.1
No specific audit requirements.
Hierarchical to: No other components.
Dependencies: No other components.
© 2017 Symantec Corporation 45 of 50 Updated 1/15/2019
FIA_PMG_EXT.1.1 The TSF shall provide the following password management capabilities for
administrative passwords:
a) Passwords shall be able to be composed of any combination of upper and lower case letters,
numbers, and the following special characters: [selection: “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, “)”,
[assignment: other characters]];
b) Minimum password length shall be settable by the Security Administrator, and support
passwords of 15 characters or greater.
7.7 FIA_UIA_EXT.1 User Identification and Authentication
FIA_UIA_EXT.1 User Identification and Authentication requires administrators (including remote
administrators) to be identified and authenticated by the TOE, providing assurance for that end of the
communication path. It also ensures that every user is identified and authenticated before the TOE performs
any mediated functions.
Management: FIA_UIA_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to configure the list of TOE services available before an entity is identified and
authenticated
Audit: FIA_UIA_EXT.N
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) All use of the identification and authentication mechanism
b) Provided user identity, origin of the attempt (e.g. IP address)
Hierarchical to: No other components.
Dependencies: FTA_TAB.1 Default TOE Access Banners
FIA_UIA_EXT.1.1 The TSF shall allow the following actions prior to requiring the non-TOE entity to initiate
the identification and authentication process:
• Display the warning banner in accordance with FTA_TAB.1;
• [selection: no other actions, [assignment: list of services, actions performed by the TSF in response
to non-TOE requests.]]
FIA_UIA_EXT.1.2 The TSF shall require each administrative user to be successfully identified and
authenticated before allowing any other TSF-mediated actions on behalf of that administrative user.
7.8 FIA_UAU_EXT.2 Password-based Authentication Mechanism
FIA_UAU_EXT.2 The password-based authentication mechanism provides administrative users a locally
based authentication mechanism..
Management: FIA_UAU_EXT.2
The following actions could be considered for the management functions in FMT:
a) None
Audit: FIA_UAU_EXT.2
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Minimal: All use of the authentication mechanism
© 2017 Symantec Corporation 46 of 50 Updated 1/15/2019
Hierarchical to: No other components.
Dependencies: None
FIA_UAU_EXT.2.1 The TSF shall provide a local password-based authentication mechanism, [selection:
[assignment: other authentication mechanism(s)], none] to perform administrative user authentication.
7.9 FPT_SKP_EXT.1 Protection of TSF Data (for reading of all
symmetric keys)
FPT_SKP_EXT.1 Protection of TSF Data (for reading all symmetric keys), requires preventing symmetric
keys from being read by any user or subject. It is the only component of this family.
Management: FPT_SKP_EXT.1
The following actions could be considered for the management functions in FMT:
a) There are no management activities foreseen.
Audit: FPT_SKP_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) There are no auditable events foreseen.
Hierarchical to: No other components.
Dependencies: No other components.
FPT_SKP_EXT.1.1 The TSF shall prevent reading of all pre-shared keys, symmetric keys, and private
keys.
Application Note 132
The intent of this requirement is for the device to protect keys, key material, and authentication credentials
from unauthorized disclosure. This data should only be accessed for the purposes of their assigned security
functionality, and there is no need for them to be displayed/accessed at any other time. This requirement
does not prevent the device from providing indication that these exist, are in use, or are still valid. It does,
however, restrict the reading of the values outright.
FPT_APW_EXT.1 Protection of administrator passwords requires that the TSF prevent plaintext credential
data from being read by any user or subject.
Management: FPT_APW_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_APW_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) No audit necessary
Hierarchical to: No other components
Dependencies: No other components.
FPT_APW_EXT.1.1 The TSF shall store passwords in non-plaintext form.
© 2017 Symantec Corporation 47 of 50 Updated 1/15/2019
FPT_APW_EXT.1.2 The TSF shall prevent the reading of plaintext passwords.
7.10FPT_TST_EXT.1 TSF testing
FPT_TST_EXT.1 TSF Self Test requires a suite of self tests to be run during initial start-up
in order to demonstrate correct operation of the TSF.
Management: FPT_TST_EXT.1
The following actions could be considered for the management functions in FMT:
a) No management functions.
Audit: FPT_TST_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
a) Indication that TSF self test was completed
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during initial start-up (on
power on), periodically during normal operation, at the request of the authorised user, at the conditions
[assignment: conditions under which self-tests should occur]] to demonstrate the correct operation of the
TSF: [assignment: list of self-tests run by the TSF].
Application Note 133
It is expected that self-tests are carried out during initial start-up (on power on). Other options should only
be used if the developer can justify why they are not carried out during initial start-up. It is expected that at
least self-tests for verification of the integrity of the firmware and software as well as for the correct operation
of cryptographic functions necessary to fulfil the SFRs will be performed. If not all self-test are performed
during startup multiple iterations of this SFR are used with the appropriate options selected. In future
versions of this cPP the suite of self-tests will be required to contain at least mechanisms for measured
boot including self-tests of the components which perform the measurement.
Application Note 134
If certificates are used by the self-test mechanism (e.g. for verification of signatures for integrity verification),
certificates are validated in accordance with FIA_X509_EXT.1 and should be selected in
FIA_X509_EXT.2.1. Additionally, FPT_TST_EXT.2 must be included in the ST.
7.11FPT_TUD_EXT.1 Trusted update
FPT_TUD_EXT.1 Trusted Update requires management tools be provided to update the TOE firmware and
software, including the ability to verify the updates prior to installation.
Management: FPT_TUD_EXT.1
The following actions could be considered for the management functions in FMT:
a) Ability to update the TOE and to verify the updates
b) Ability to update the TOE and to verify the updates using the digital signature capability
(FCS_COP.1(2)) and [selection: no other functions, [assignment: other cryptographic functions (or
other functions) used to support the update capability]].
c) Ability to update the TOE, and to verify the updates using [selection: digital signature, published
hash, no other mechanism] capability prior to installing those updates
Audit: FPT_TUD_EXT.1
© 2017 Symantec Corporation 48 of 50 Updated 1/15/2019
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Initiation of the update process.
b) Any failure to verify the integrity of the update
Hierarchical to: No other components
Dependencies: FCS_COP.1(1) Cryptographic operation (for cryptographic signature), or FCS_COP.1(3)
Cryptographic operation (for cryptographic hashing)
FPT_TUD_EXT.1.1 The TSF shall provide Security Administrators the ability to query the currently
executing version of the TOE firmware/software and [selection: the most recently installed version of the
TOE firmware/software; no other TOE firmware/software version].
Application Note 136
The version currently running (being executed) may not be the version most recently installed. For instance,
maybe the update was installed but the system requires a reboot before this update will run. Therefore, it
needs to be clear that the query should indicate both the most recently executed version as well as the
most recently installed update.
FPT_TUD_EXT.1.2 The TSF shall provide [assignment: authorised users] the ability to manually initiate
updates to TOE firmware/software and [selection: support automatic checking for updates, support
automatic updates, no other update mechanism].
Application Note 137
The selection in FPT_TUD_EXT.1.2 distinguishes the support of automatic checking for updates and
support of automatic updates. The first option refers to a TOE that checks whether a new update is
available, communicates this to the administrator (e.g. through a message during an administrator session,
through log files) but requires some action by the administrator to actually perform the update. The second
option refers to a TOE that checks for updates and automatically installs them upon availability.
FPT_TUD_EXT.1.3 The TSF shall provide means to authenticate firmware/software updates to the TOE
using a [selection: digital signature mechanism, published hash] prior to installing those updates.
Application Note 138
The digital signature mechanism referenced in the selection of FPT_TUD_EXT.1.3 is one of the algorithms
specified in FCS_COP.1(2).The published hash referenced in FPT_TUD_EXT.1.3 is generated by one of
© 2017 Symantec Corporation 49 of 50 Updated 1/15/2019
the functions specified in FCS_COP.1(3). The ST author should choose the mechanism implemented by
the TOE; it is acceptable to implement both mechanisms.
Application Note 139
Future versions of this cPP will mandate the use of a digital signature mechanism for trusted updates.
Application Note 140
If certificates are used by the update verification mechanism, certificates are validated in accordance with
FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.2 must be
included in the ST.
Application Note 141
“Update” in the context of this SFR refers to the process of replacing a non-volatile, system resident
software component with another. The former is referred to as the NV image, and the latter is the update
image. While the update image is typically newer than the NV image, this is not a requirement. There are
legitimate cases where the system owner may want to rollback a component to an older version (e.g. when
the component manufacturer releases a faulty update, or when the system relies on an undocumented
feature no longer present in the update). Likewise, the owner may want to update with the same version as
the NV image to recover from faulty storage. All discrete software components (e.g. applications, drivers,
kernel, firmware) of the TSF, should be digitally signed by the corresponding manufacturer and
subsequently verified by the mechanism performing the update. Since it is recognized that components
may be signed by different manufacturers, it is essential that the update process verify that both the update
and NV images were produced by the same manufacturer (e.g. by comparing public keys) or signed by
legitimate signing keys (e.g. successful verification of certificates when using X.509 certificates).
7.12FTA_SSL_EXT.1 TSF-initiated Session Locking
FTA_SSL_EXT.1 TSF-initiated session locking, requires system initiated locking of an interactive session
after a specified period of inactivity. It is the only component of this family.
Management: FTA_SSL_EXT.1
The following actions could be considered for the management functions in FMT:
c) Specification of the time of user inactivity after which lock-out occurs for an individual user.
Audit: FTA_SSL_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP/ST:
a) Any attempts at unlocking an interactive session.
Hierarchical to: No other components
Dependencies: FIA_UAU.1 Timing of authentication
FTA_SSL_EXT.1.1 The TSF shall, for local interactive sessions, [selection:
• lock the session - disable any activity of the user’s data access/display devices other than unlocking
the session, and requiring that the administrator re-authenticate to the TSF prior to unlocking the
session;
• terminate the session]
after a Security Administrator-specified time period of inactivity.
© 2017 Symantec Corporation 50 of 50 Updated 1/15/2019
© 2017 Symantec Corporation All rights reserved. Symantec, the Symantec logos, ProxySG, PacketShaper, CacheFlow, IntelligenceCenter, CacheOS,
CachePulse, Crossbeam, K9, the K9 logo, DRTR, MACH5, PacketWise, PolicyCenter, ProxyAV, ProxyClient, SGOS, WebPulse, Solera Networks, the
Solera Networks logos, DeepSee, “See Everything. Know Everything.”, “Security Empowers Business”, and BlueTouch are registered trademarks or
trademarks of Symantec Corporation or its affiliates in the U.S. and certain other countries. This list may not be complete, and the absence of a trademark
from this list does not mean it is not a trademark of Symantec or that Symantec has stopped using the trademark. All other trademarks mentioned in this
document owned by third parties are the property of their respective owners. This document is for informational purposes only. Symantec makes no
warranties, express, implied, or statutory, as to the information in this document.
8. Acronyms
This section describes the acronyms used throughout this document.
Table 10 Acronyms
Acronym Definition
CC Common Criteria
CLI Command Line Interface
DH Diffie-Hellman
ECDH Elliptic Curve Diffie-Hellman
GUI Graphical User Interface
OS Operating System
POST Power On Self-Test
PP Protection Profile
SA Security Analytics
SHS Secure Hashing Standard
SSH Secure Shell
TLS Transport Layer Security