Edge SWG

Certificate

Approved Algorithms (29)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Edge SWG
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>upgrade<br/>downgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status output<br/>self-test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Edge SWG
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>upgrade<br/>downgrade</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status output<br/>self-test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Symantec, A Division of Broadcom Edge SWG Version 7.4 FIPS 140-3 Security Level: 1 Document Version 1.2 Date: November 2024 Prepared by: www.acumensecurity.net

Introduction Federal Information Processing Standards Publication 140-3 — Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) run the Cryptographic Module Validation Program (CMVP). The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. About this Document This non-proprietary Cryptographic Module Security Policy for the Edge Secure Web Gateway (SWG); running the Secure Gateway Operating System (SGOS) version 7.4, provides an overview of the product and a high-level description of how it meets the overall Security Level 1 security requirements Federal Information Processing Standards (FIPS) Publication 140-3. The Edge SWG may also be referred to as the “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Broadcom shall have no liability for any error or damages of any kind resulting from the use of this document. its subsidiaries. For more information, go to www.broadcom.com. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies. Broadcom reserves the right to make changes without further notice to any products or data herein to improve reliability, function, or design. Information furnished by Broadcom is believed to be accurate and reliable. However, Broadcom does not assume any liability arising out of the application or use of this information, nor the application or use of any product or circuit described herein, neither does it convey any license under its patent rights nor the rights of others. Notices notice.

Contact Information Symantec, A Division of Broadcom

San Jose, CA 95131 www.broadcom.com

This document describes the security policy for the Edge SWG (SW version: SGOS 7.4) cryptographic module. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The module type is software-hybrid and has a multi-chip standalone embodiment.

The Edge SWG appliances from Symantec provide companies with the ability to deploy a scalable proxybased security solution to protect their organization against advanced threats. The Edge SWG acts as gateway between web users and the Internet: a single point where all web traffic can be monitored and corporate policies for web use can be enforced. This strategic position makes the Edge SWG a natural place to build additional network security technologies that defend against a very wide range of cybercrimes, malware, and phishing. The Edge SWG offers the following features.

• High-speed decryption and re-encryption of SSL/TLS traffic, so attackers cannot use encryption to conceal malware or command and control traffic into and out of the corporate network
• Universal Policy Enforcement (UPE) from Symantec allows organizations to enforce acceptable web use policies for employees who connect through the Edge SWG. Symantec allows you to centralize your policy creation, maintenance, and installation for simplified, unified administration.
• Out of the box protection
• Recommended, strong, and maximum policies crafted by security experts.
• Immediate protection with the broadest advanced threat integrations
• Direct cloud application visibility and real-time controls
• Unmatched performance and reliability
• Logs and reports on how users connect to websites.
• Strong user authentication can be incorporated into the policies, supporting a wide variety of identity sources, including NTLM, LDAP, RADIUS, one-time passwords, and certificates
• When paired with other Symantec technologies, it can provide:
• Malware detection using multiple anti-malware engines and detection methods
• Multi-layered deep content inspection and analysis to detect spam and application-level threats in the payloads of network traffic
• Data Loss Prevention (DLP) to identify confidential information and block it from leaving the corporate network
• Cloud Access Security Broker (CASB) features to monitor and control what applications users can access and how documents and files are sent to the cloud
• Web (browser) isolation to create a safe browsing experience, prevent malware from moving from browsers onto employees’ systems, and block sharing of credentials on suspicious websites
• Integration the world’s largest civilian threat intelligence dataset with the Symantec Global Intelligence Network (GIN)

The Symantec Global Intelligence Network (GIN), which monitors more than 175 million endpoints and Edge SWGs protects 80 million users. It uses artificial intelligence to analyze over 3.7 billion lines of telemetry to identify and categorize emerging threats and suspicious and malicious URLs and websites. Key data is continually forwarded to hardware and virtual Edge SWGs in data centers and in cloud deployments and to hosted SaaS platforms. See Figure 1 below for a typical deployment scenario for the Edge SWGs. Figure 1 - Typical Deployment of a Secure Web Gateway Virtual Appliance The security provided by the Edge SWG can be used to control, protect, and monitor the Internal Network’s use of controlled protocols on the External Network. The controlled protocols 1 implemented are: • Windows Media Optimization (Microsoft Media Streaming (MMS)) These protocols are not executed by the cryptographic module.

•   Microsoft Smooth Streaming Optimization •   Real Media Optimization •   Real-Time Streaming Protocol (RTSP) Optimization •   Real-Time Messaging Protocol (RTMP) Optimization •   QuickTime Optimization (Apple HTTP Live Streaming) •   Adobe Flash Optimization (Adobe HTTP Dynamic Streaming) •   Bandwidth Management •   DNS proxy •   Advanced DNS Access Policy •   Hypertext Transfer Protocol (HTTP)/Secure Hypertext Transfer Protocol (HTTPS) Acceleration •   File Transfer Protocol (FTP) Optimization •   Secure Sockets Layer (SSL) Termination/Protocol Optimization •   TCP 2 tunneling protocols (Secure Shell (SSH)) •   Secure Shell •   Telnet Proxy •   ICAP Services •   Netegrity SiteMinder •   Oblix COREid •   Peer-To-Peer •   User Authentication •   Onbox Content Filtering (3rd Party or BCWF2) •   Offbox Content Filtering (via ICAP) •   SOCKS Access control is achieved by enforcing configurable policies on controlled protocol traffic to and from the Internal Network users. The policy may include authentication, authorization, content filtering, and auditing. The module is validated at the overall security level 1 and the following FIPS 140-3 Section levels in Table 1. Table 1 - Security Levels Transmission Control Protocol

2. Cryptographic Module Specification For the FIPS 140-3 validation, the module was tested on the following operational environments listed in Table
3. Table 2 - Tested Operational Environments Additionally, the vendor affirms that the cryptographic module is also fully supported on the following platforms and operational environments: Table 3 - Vendor Affirmed Operational Environments No claim can be made as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment, which is not listed on the validation certificate.

The module is a software-hybrid module and has a Multi-Chip Standalone embodiment, that meets overall Level 1 FIPS 140-3 requirements. The module was tested and found complaint on a Dell The module software consists of Symantec’s proprietary operating system, SGOS v7.4. Acting as the guest OS in the respective hypervisors, this full-featured operating system includes both OS-level functions as well as the application-level functionality that provides the appliance’s optimization and proxying services. The module software version 7.4 contains the following cryptographic libraries:

• SGOS Cryptographic Library v5.1.1
• VA Blue Coat Boot Loader v5.31

The cryptographic boundary of the module (shown by the yellow line in Figures 2 & 3) consists of the SGOS v7.4 (which contains the VA Blue Coat Boot Loader v5.31, and the SGOS Cryptographic Library v5.1.1) and the processors for cryptographic acceleration as listed in Table 2. The Tested Operational Environment’s Physical Perimeter (TOEPP) of the module is the SSP S410 and Dell PowerEdge R440 platforms, in which the module executes. Intel Xeon 4210 Figure 2 - Cryptographic Boundary Block Diagram for SSP S410 Intel Xeon 4216 Figure 3 - Cryptographic Boundary Block Diagram for Dell PowerEdge R440

Figure 4 - Intel Xeon Silver 4210 Figure 5 - Intel Xeon Silver 4216

The module supports two modes of operation: Approved and Non-Approved. The module will be in Approved mode once the initialization steps mentioned in Section 11.1.1 are completed. See Tables 4 and 5 for a list of Approved or Allowed algorithms. To transition from Approved mode to Non-Approved mode, the operator should execute “fips-mode-disable” which will trigger zeroization via module reboot. To transition from Non-Approved mode of operation to Approved mode, the operator must run the command “fips-mode enable” along with the initialization instructions as specified in Section 11.1.1. If the initialization steps are not followed as specified in Section 11.1.1, then the module may be operational, in a non-compliant state.

The module implements the Approved algorithms 3 listed in the table below: There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any Approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an Approved service of the module.

6.1 SP800-90Arev1 4 If CTR_DRBG is used, then the caller shall ensure that the derivation function is enabled.

Table 4 - Approved Algorithms Not applicable to RSA Signature Generation. Only for Non-digital signature and legacy use, all other SHAs acceptable for hash functions applications.

encryption is redundant/not required for security (No security claimed)

Table 5 - Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation NOTE: No parts of the TLS, SSH, and SNMP protocols, other than the KDF, have been reviewed or tested by the CAVP and CMVP. Per IG D.H, the vendor affirms symmetric keys and seeds for asymmetric keys are generated per SP800133rev2 (unmodified output from a DRBG).

The Crypto-Officer can monitor and configure the module via the CLI (serial port or SSH). The Crypto-Officer should monitor the module’s status regularly. If any irregular activity is noticed or the module is consistently reporting errors, customers should consult Symantec’s Documentation portal and the administrative guidance documents to resolve the issues. If the problems cannot be resolved through these resources, Symantec customer support should be contacted. Key sizes less than what is specified shall not be used. The Crypto Officer password, “enabled” mode password, “Setup” password and “User” password must be at least 8 characters in length.

The User is only able to access the module remotely via SSH (CLI). The User must change his or her password at the initial login. The User must be diligent to pick strong passwords (alphanumeric with minimum 8 characters) that will not be easily guessed and must not reveal their password to anyone. Additionally, the User should be careful to protect any secret/private keys in their possession, such as TLS or SSH session keys. The User should report to the Crypto-Officer if any irregular activity is noticed. Please refer to Section 11.1.1 for initialization procedures.

The Crypto-Officer may issue the “show-version” command to view the module identifier and version (SGOS 7.4.0.0 SWG Edition). The module identifier “SWG” denotes the module name “Edge SWG”. The version of Edge SWG listed in this Security Policy, 7.4, can be verified by the version of SGOS printed out as part of the “show version” command.

AES GCM IV Generation The module’s AES-GCM implementation conforms to IG C.H scenarios 1a, 1d, 2 and 5. Scenario 1a TLS 1.2

The module is compliant with TLS 1.2 protocol per SP800-52rev2. The AES-GCM IV generation is compliant with RFC5288. The module supports acceptable AES-GCM ciphersuites from Section

The module explicitly checks that the nonce_explicit part of the IV (i.e., counter) has not reached the maximum number of potential values (264-1) for a given session key. Upon detecting exhaustion of the counter, the module returns an error indication, prompting either connection abortion or initiation of a handshake to establish a new encryption key. If the module experiences power loss and subsequently the power is restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are redistributed. Scenario 1d SSHv2 The IV generation is in compliance with SSHv2 and used for AES-GCM encryption. The module is compliant with RFC4252, 4253 and 5647. Scenario 2 Random internal IV generation The module also supports an internal IV generation using the module’s Approved DRBG, which is complaint with IG C.H and SP800-38D Section 8.2.2. The AES-GCM IV is generated randomly internal to the module using module’s Approved DRBG. The DRBG seeds itself from the entropy source. The GCM IV is 96 bits in length. Per Section 9, this 96-bit IV contains 96 bits of entropy. Scenario 5 TLS 1.3 The module supports a compliant TLS 1.3 as defined in RFC8446. The module uses the ciphersuites found in Appendix B.4 of RFC8446 and the acceptable AES-GCM ciphersuites from Section 3.3.1 of SP800-52rev2. The ciphersuites explicitly select AES-GCM as the encryption/decryption ciphers. The module implements, within its boundary, an IV generation unit for TLS 1.3 that keeps control of the 64-bit counter value within the AES-GCM IV. If the module experiences power loss and subsequently the power is restored, the calling application must ensure that any AES-GCM keys used for encryption or decryption are redistributed. Upon detecting exhaustion of the counter, the module returns an error indication, prompting either connection abortion or initiation of a handshake to establish a new encryption key. PBKDF Per IG D.N, keys generated using PBKDF shall only be used in data storage applications. The minimum password length allowed is 8 characters and the maximum password length is 64. The worst-case probability of guessing the value is 62^8 assuming all characters are digits, upper-case letters and/or lower-case letters. The operator shall choose the password length and the iteration count in such a way that the combination will make the key derivation computationally intensive. PBKDF is implemented to support option 1a specified in section 5.4 of SP800-132. The keys derived from SP800-132 map to section 3.1 of SP800-133rev2 as indirect generation from DRBG. The minimum iteration count enforced

is 10000 and the value is chosen considering both the security that it provides and the performance of the process. The derived keys may only be used in storage applications. Key Agreement ECDH (Elliptic Curve Diffie-Helman) cipher suites or ECDH keypair generated by the module cannot be used in any configuration in the Approved mode of operation. Only DH (Diffie-Hellman) can be used in Approved mode.

3. Cryptographic Module Interfaces The module’s physical ports can be categorized into the following logical interfaces defined by FIPS 140- 3: As a software-hybrid module, the virtual appliance has no physical characteristics. The module’s physical and electrical characteristics, manual controls, and physical indicators are those of the host system (Dell PowerEdge R440 and S410 Server) and out of scope of this validation. The hypervisor provides virtualized ports and interfaces for the module. Interaction with the virtual ports created by the hypervisor occurs through the host system’s Ethernet port. Management, data, and status traffic must all flow through the Ethernet port. Direct interaction with the module via the host system is possible over the serial port; however, the Crypto Officer must first map the physical serial port to the module using vSphere Client. The mapping of the module’s logical interfaces in the software to FIPS 140-3 logical interfaces is described in Table 7 below. Table 7 - Ports and Interfaces Data input and output are the packets utilizing the services provided by the modules. These packets enter and exit the module through the Virtual Ethernet ports. Control input consists of Configuration or Administrative data entered into the modules. Control input enters the module via the Virtual Ethernet and Virtual Serial Port interfaces (SSH CLI, and Serial CLI). Status output consists of the status provided or displayed via the user interfaces (such as SSH CLI, and Serial CLI) or available log information. Status output exits the module via the user interfaces (such as SSH CLI, and Serial CLI) over the Virtual Ethernet or Virtual Serial Ports. The module does not implement a control output interface.

4. Roles, Services, and Authentication

The module supports both Crypto-Officer(CO) and User role. Before accessing the modules for any administrative services, COs and Users must authenticate to the module according to the methods specified in Table 9. The module offers Command Line Interface:

• Command Line Interface (CLI): Accessible locally via the serial port (provides access to the Setup Console portion of the CLI which requires the additional “Setup” password to gain access) or remotely using SSH. This interface is used for management of the modules. This interface must be accessed locally via the serial port to perform the initial module configurations (IP address, DNS server, gateway, and subnet mask) and placing the modules into the Approved mode. When the module has been properly configured, this interface can be accessed via SSH. Management of the module may take place via SSH or locally via the serial port. Authentication is required before any functionality will be available through the CLI. When managing the module over the CLI, COs and Users both log into the modules with administrator accounts entering the “standard”, or “unprivileged” mode on the module. Unlike Users, COs can enter the “enabled” or “privileged” mode after initial authentication to the CLI by supplying the “enabled” mode password. Additionally, COs can only enter the “configuration” mode from the “enabled” mode via the CLI, which grants privileges to make configuration level changes. Going from the “enabled” mode to the “configuration” mode does not require additional credentials. The details of these modes of operation are found below: Crypto-Officer role and privileges:
• The CO is an administrator of the module that has “enabled” mode access while using the CLI.
• When the CO is using the CLI, and while in the “enabled” mode of operation, COs may put the module in its Approved mode, reset to the factory state (local serial port only) and query if the module is in Approved mode. In addition, COs may do all the services available to Users while not in “enabled” mode.
• Once the CO has entered the “enabled” mode, the CO may then enter the “configuration” mode via the CLI. The “configuration” mode provides the CO management capabilities to perform tasks such as account management and key management. User role and privileges:
• The User is an administrator of the module that operates only in the “standard” or “unprivileged” mode and has not been granted access to the “enabled” mode in the CLI.
• The User may access the CLI for management of the module.

The module supports role-based authentication. COs and Users must authenticate using a user ID and password, or a Client RSA Public Key (SSH only). Secure sessions that authenticate Users have no interface available to access other services (such as Crypto Officer services). Each CO or User SSH session remains active (logged in) and secured until the operator logs out. The authenticated user never leaves the Approved mode, the only services they may call are “Approved” or “Allowed

in the Approved mode” (Tables 4 and 5). Services in Table 6 would require the module to not be in Approved mode and would require a re-initialization of the module. There is no default password, and passwords are configured while creating the operators (CO/User) during initialization (Section 11.1.1).

Table 9 - Roles and Authentication

Descriptions of the services available to a Crypto Officer (CO) and Users are described below in Table 10. For each service listed below, COs and Users are assumed to already have authenticated prior to attempting to execute the service. Please note that the keys and CSPs listed in the table indicate the type of access required using the following notation:

• G = Generate: The module generates or derives the SSP
• R = Read: The SSP is read from the module (e.g. the SSP is output)
• W = Write: The SSP is updated, imported, or written to the module
• E = Execute: The module uses the SSP in performing a cryptographic operation
• Z = Zeroise: The module zeroizes the SSP.

Descriptions of the FIPS 140-3 relevant services available to the Crypto-Officer role are provided in Table 10 below. Additional services that do not access SSPs can be found in the following documents:

• ProxySG Content Policy Language Reference, Version 7.4
• ProxySG Command Line Interface Reference, Version 7.4 The link for all documentation can be found here: https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-networksecurity/proxysg/7-4.html

Descriptions of the FIPS 140-3 relevant services available to the User role are provided in Table

10 below. Additional services that do not access SSPs can be found in the following documents:

• ProxySG Command Line Interface Reference, Version 7.4

Table 11 - Non-Approved Services The CO and User roles may monitor the health and status of the modules using SNMPv3. SNMPv3 privacy and authentication keys must be generated by an external application as the module is not capable of generating the keys internally. The keys are not tied to the CO’s CLI credentials

The module supports self-initiated cryptographic capability to establish secure connections to external services for licensing and subscription downloads. To prevent inadvertent output due to a single error, this capability is turned on only after obtaining confirmation from the CO: To properly function, this appliance will need to initiate cryptographically secure connections to external services such as licensing and subscription downloads. Do you wish to proceed? (y/n)[n]: y Please enter‘ ’y' again to confirm? (y/n)[n]:

5. Software/Firmware Security The module performs pre-operational integrity test using HMAC-SHA-1 and RSA 2048 Signature Verification with SHA2-256. The integrity test can be executed on demand by power-cycling the host platform. The form of the module is a single image file "7.4.0.0_build_279954_system_gdb.bcsi". The module performs software loading and software load test but does not support complete image replacement.
6. Operational Environment Per FIPS 140-3 specifications the module operates in a modifiable operational environment. The module runs on general purpose computers listed in Table
7. Additionally, the module only allows the loading of software through the software load test, which ensures the image is appropriately signed by Broadcom, Inc. As such, the applicable modifiable operational environment requirements do apply. Please refer to Table 2 of this document regarding the Cryptographic Module Tested Configurations. Except guidelines and installation instructions specified in Sections 2 and 11 of this Security Policy, no other security rules or restrictions to the configuration of the operational environment are required. Note: The platforms listed in Table 3 are vendor-affirmed per FIPS 140-3. Broadcom, Inc. has verified the module's functionality in the operational environments specified in Table 3 and confirmed that it operates in the same manner as the operational environments listed in Table 2.
8. Physical Security The module type is software-hybrid and has a multi-chip standalone embodiment running on a production grade chassis.
9. Non-Invasive Security This section is not applicable. The module does not implement non-invasive security measures.

9. Sensitive Security Parameter Management Master Encryption Key SSH session negotiation only uses RSA key pairs of 2048-bits. RSA key pairs of 3072-bits and 4096-bits are only used for TLS session negotiation.

Table 12 - SSPs Keys and passwords that exit the module during a configuration backup are encrypted using an Approved encryption algorithm via the TLS or SSH session key. During the backup process, the CO can additionally use either AES-128 CBC or AES-256 CBC mode to encrypt the archive file; however, there is no security claimed on this use of encryption because the key used for encryption is generated using a non-conformant key derivation The CO can return the module to its factory state by entering the “enabled” mode on the CLI, followed by the “fips-mode disable” command. This command will automatically reboot the module and zeroize the MEK. The RSA Private Key, Crypto Officer password, User password, “Enabled” mode zeroized, decryption involving the MEK becomes impossible, making these CSPs unobtainable by an attacker. In addition, rebooting the module causes all temporary keys stored in volatile memory (SSH Session key, TLS session key, DRBG entropy values, and ENT (P) entropy values) to be zeroized. The Crypto-Officer must wait until the module has successfully rebooted to verify that zeroization has completed.

Table 13 - Non-Deterministic Random Number Generation Specification 10. Self-Tests If the module fails the Integrity Test (Pre-operational Self-Test), the following error is printed to the CLI (when being accessed via the serial port): PKCS7 Signature verification failed, signature does not match. If any other self-tests fail, the following error is printed to the CLI (when being accessed via the serial port): **********************SYSTEMERROR*********************** The SG Appliance has failed the FIPS Self test. System startup cannot continue. ******************SYSTEM STARTUP HALTED**************** E)xit FIPS mode and reinitialize system R)estart and retry FIPS selftest Selection: When either of these errors occurs, the module enters hard error state and halts operation and provides no functionality. The only way to clear the error and resume normal operation is for the Crypto-Officer to reboot the module. The status output provided above is shown only over the CLI (when being accessed via the serial port). The sections below describe the self-tests performed by the module. All the self-tests specified in Section 10.1 are implemented in VA Blue Coat Boot Loader v5.31. All the self-tests specified in Section

• Software integrity check using RSA SigVer (2048-bit with SHA2-256) and HMAC-SHA-1 12,13 (A3192)

Conditional cryptographic algorithm self-tests (CASTs): The preoperational self-tests are performed by VA Blue Coat Boot Loader v5.31 library which covers entire image file “7.4.0.0_build_279954_system_gdb.bcsi”. The module executes the RSA SigVer 2048-bit and HMAC-SHA-1 KATs prior to running the pre-operational selftest. Both the integrity tests are sequentially performed on the entire image file “7.4.0.0_build_279954_system_gdb.bcsi”.

CAVP Cert. A2936: •    AES-ECB Encrypt KAT (128-bit) (covers AES-CBC) •    AES-ECB Decrypt KAT (128-bit) (covers AES-CBC) •    AES-GCM Encrypt KAT (256-bit) •    AES-GCM Decrypt KAT (256-bit) •    SHA-1 KAT •    SHA2-256 KAT (covered by HMAC-SHA2-256 KAT) •    SHA2-512 KAT •    SHA3-256 KAT (additional KAT, not required by any service/algorithm) •    HMAC-SHA2-256 KAT •    SP800-90Arev1 CTR-DRBG KAT using AES-128 •    SP800-56Arev3 DH “Primitive Z” KAT (2048) •    PBKDF KAT •    TLS 1.2 KDF KAT •    TLS 1.3 KDF KAT •    SSH KDF KAT •    SNMP KDF KAT •    SP 800-90B Start-up health tests •    Section 11 CTR_DRBG CAST (Instantiate, Reseed, Generate, Uninstantiate) •    RSA Signature KAT (2048-bit with SHA2-256 and PKCS v1.5) •    RSA Verification KAT (2048-bit with SHA2-256 and PKCS v1.5) •    SP 800-90B Continuous health tests •    Software Load Test using RSA Signature Verification (2048-bit) CAVP Cert. A3192: •    RSA Verification KAT (2048-bit with SHA2-256) •    HMAC-SHA1 KAT Conditional pair-wise consistency tests (PCTs): •    RSA Pairwise consistency check upon generation of a keypair •    DH Pairwise consistency check upon generation of a keypair No data output occurs via the data output interface until all pre-operational self-tests have been completed. The module also performs a validity check on the installed license. If the license is not valid, the module will not operate. Self-tests can be executed on demand by rebooting the module. Note the module includes additional self-tests for algorithms that are not callable or used by any service.

11. Life-Cycle Assurance The module can be delivered pre-installed on the SSP-S410 appliance, or via the Broadcom Secure download portal: https://support.broadcom.com/security/download-center

The module meets FIPS-140-3 Level 1 requirements. The section below describes how to place and keep the module in Approved mode of operation. Caveat: This guide assumes that a virtual environment is already set up and ready for accepting a new virtual appliance installation. The Crypto-Officer is responsible for initialization and security-relevant configuration and management of the module. Please see the ProxySG Command Line Interface Reference, November 16 2022 for more information on configuring and maintaining the module. Caveat: While the Proxy SG may hold and boot from multiple software images, only the software image documented in this Security Policy (SGOS Software Version: 7.4) may be used for booting to remain compliant. Booting from any other software image will void the validation.

Physical access to the module’s host hardware shall be limited to the Crypto-Officer, and the CO shall be responsible for putting the module into the Approved mode. Please read the following guide for installation direction for the ESXi operational environment: https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-networksecurity/proxysg/7-4/Overview_ISG_SGW_VA.html. Once the module has been configured based on the above guide, the CO must place the module in the Approved mode using the Console Tab which provides access to the virtual serial connection.

1. Press Enter three times. When the system displays Welcome to the SG Appliance Setup Console , it is ready for the first-time network configuration.
2. Enter the properties for the following: a. Interface number b. IP address c. IP subnet mask d. IP gateway e. DNS server parameters

3. The module will prompt for the console account authentication information: You must configure the console user account now. Enter console username: Enter console password: Enter enable password:
4. The module will prompt to secure serial port, select ‘n’
5. When the system displays Successful Configuration Setup, press Enter to confirm the configuration.
6. Press Enter three times.
7. Select option #1 for the Command Line Interface.
8. Type enable and press Enter.
9. Enter the enable mode password.
10. Enter the following command: fips-mode enable. When prompted for confirmation, select Y to confirm. Once the reinitialization is complete, the module displays the prompt “The system is in FIPS mode”. • NOTE 1: The fips-mode enable command causes the device to power cycle, zeroing the Master Encryption Key and returning the configuration values set in steps 1 and 2 to their factory state. • NOTE 2: This command is only accepted via the CLI when accessed over the serial port.
11. After the system has finished rebooting, press Enter three times.
12. Enter the properties for the following: a. Interface number b. IP address c. IP subnet mask d. IP gateway e. DNS server parameters
13. The module will prompt for the console account credentials: You must configure the console user account now. Enter console username: Enter console password: Enter enable password:
14. Configure the setup password to secure the serial port which must be configured while in Approved mode. The system displays the following:

The serial port must be secured, and a setup password must be configured. Enter setup password:

15. Choose Yes or No to restrict workstation access.
16. The operator should not configure below ciphers to be in approved mode of operation: • TLS v1.0/1.1 for syslog • ECDH cipher-suites for SSH (curve25519-sha256@libssh.org, ecdh-sha2-nistp521, ecdhsha2-nistp384, ecdh-sha2-nistp256) and syslog (ECDHE-RSA-AES256-GCM-SHA284, ECDHERSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES256-SHA, ECDHE-RSA-AES128-SHA)
17. When creating or importing key pairs, such as during the restoration of an archived backup configuration, the CO must ensure the “no-show” argument is passed over the CLI as shown in Figure
18. Figure 6 - no-show command Upon completion of these initialization steps, the module is considered to be operating in Approved mode of operation. If the steps are not followed exactly as listed here, the module could still be operational but in a non-compliant state.
19. Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-3 Level 1 requirements for this validation.