Symantec Information Security product migration to the Google Cloud Platform: What you need to know

16109

06 May 2021

06 August 2020

Update history for this notification:

Date

Change

May 6, 2021

Migration to the Google Cloud Platform has been completed. This document will no longer be updated. 

February 21, 2021

Added Saleforce as a SaaS example for source IP restriction.  Changed GCS whitelist URL to *.storage.googleapis.com in Appendix to indicate subdomain support. 

January 27, 2021

Added Update for DLP Cloud Detection Service to indicate CDS for Europe has been migrated, and all remaining CDS migrations will occur by February 5, 2021.  

New date: Components of CloudSOC in AWS will no longer work as of February 19, 2021. Added links to detailed schedules for EU and other CloudSOC migrations to GCP. See the section "Actions you need to take, and timing."

December 28, 2020

Added: Upgrade to SpanVA version 1.15.3.130.0-39rc must happen no later than January 15, 2021.

December 18, 2020

Added that migrations have begun for the the DLP Cloud Detection Service, and added link to the Service Status page. 

November 30, 2020

SpanVA version 1.15.3.130.0-39rc is available for download. 

November 10, 2020

Updated information about GCP-ready SpanVA version (available November 30).

November 5, 2020

Added information that CloudSOC components in AWS will no longer work as of February 17, 2021. 

October 20, 2020

Modified deployment timing information for CASB Gateway customers not using WSS, and for CASB Gateway customers who are using WSS and CASB separately. Customers should plan for these deployments in the late November/December timeframe. 

October 16, 2020

For customers using DLP Cloud Service for Email in Reflecting Mode, added a link to the Knowledge Base article Verifying your DLP Cloud Service installation in advance of the migration to the Google Cloud Platform - for customers using O365 in Reflecting mode.

While no additional detail has been added to this Advisory for updating the DLP trust store, additional information may be found in the linked Knowledge Base article Replacing the Cloud Services Enforce Truststore prior to migration of DLP Cloud Service to Google Cloud Platform.

October 2, 2020

Updated the Appendix to remove IP addresses and to indicate there are no static fixed static network blocks for GCS. Added note about accessing and subscribing to the service status page. Updated information about GCP-ready SpanVA version. 

September 23, 2020

Added IMPORTANT note in the Appendix. If you are a CloudSOC Audit customer and have added GCS IP addresses to your firewall setup prior to September 24, you will need to update them to new IP addresses, which are pending further communication from Google.

September 18, 2020

Updated Appendix with GCP regional URLs and IP information. Updated firewall details for CASB Audit customers. Updated Cloud Workload Assurance information.   

September 11, 2020

Added SpanVA Auto Update information for GCP-ready version.

September 8, 2020

Changed format, adding additional content for WSS. 

September 3, 2020

Updated to indicate DLP versions earlier than 15.1 MP1 need to update trust store.

September 2, 2020

Updates for Gateway migration and ingress/egress securelisting.

August 28, 2020

Corrected DLP trust store information; IP addresses can be added to (not replace) current configurations.

August 26, 2020

Consolidated SpanVA items, indicated upgrade to latest version in preparation to upgrade to GCP-ready version.

August 25, 2020

Added information about DLP trust store updates.

 

What is being migrated? And why?

Symantec Information Security is migrating the platform for its cloud services from Amazon Web Services (AWS) to Google Cloud Platform (GCP). The following Information Security product families are affected:

  • Cloud Workload Assurance
  • Secure Access Cloud
  • Data Loss Prevention
  • CloudSOC CASB

The migration will help accelerate the Symantec cloud roadmap and strengthen integrations across backend systems and applications. The migration will include significant enhancements to scalability, reliability, and performance. 

 Benefits include:

  • Homogenous compute and networking environments 
  • Reduced latency for service-to-service communications
  • Common platform components across services
  • Increased support of systems and applications within the Broadcom internal Information Technology teams

Note: Migrating from AWS to GCP does not impact GDPR compliance. Broadcom policies regarding GDPR compliance are described at the Data Processing and Data Transfers site. 

Actions you need to take, and timing

Depending on the products you use and the capabilities utilized, there may be configuration changes required. 

An overview of required actions include: 

  • Complete pre-migration steps before September 30, 2020. All customers will need to evaluate if they require a securelist (allowlist) update for a new IP address range. Details about securelisting are provided later in this article, as are any other product-specific pre-migration steps. 
  • For DLP Cloud customers, if you are not using a current version of the Enforce Server, you may need to perform a specific compatibility update, described below.
  • For customers of CASB Audit and Gateway, you'll need to upgrade and deploy on-premises software.

The “Go Live” date, which represents when the products will be available in GCP, is Q4 2020 for all products.

For CloudSOC CASB customers, components of CloudSOC in AWS will no longer work as of February 19, 2021.

UPDATE JANUARY 27, 2021: For specific dates of the EU CloudSOC CASB migration to GCP, and the list of affected components, click here. For specific dates of all other CloudSOC CASB migrations to GCP, and the list of affected components, click here

General information about IP securelisting is provided in the next section; additional required actions and timing details are provided for each product in the following sections: 

Note: To view the current operational status of your service and for up-to-date messages about each service during the migration period, you can access the service status page. Be sure to Subscribe to the page to be automatically notified of updates. 

About IP securelisting, and new IP addresses

This section provides general information about what IP addresses you’ll need to securelist as well as the new IP address block. See the sections for your specific product for more information about securelisting. 

Enabling access to the new IP addresses and opening the requisite ports will not negatively affect your security posture. You need to make the required changes to continue uninterrupted access to Symantec Cloud Services.

IP securelisting requirements (what to securelist)

There are generally two areas that a customer should check and update with the IP securelist:

  • Firewall changes to allow connection to the Broadcom service ingress IP list. 

The ingress IP list (provided in the next section) includes the IP addresses from which the Broadcom service can receive client requests. You should check your corporate firewall rules to allow connections to these IP addresses at specified ports from your corporate network. These are needed when applications running in your on-premises environment require access to Broadcom services.

  • Accept Broadcom service egress IP list in your SaaS applications.

The egress list (provided in the next section) consists of the IP addresses that your SaaS application (such as Box.com) will see when a request is sent from a Broadcom service to the application. For example, when a CloudSOC Securlet scans documents in your corporate Box application, the Box application will see the CloudSOC egress IP address.

Some web applications may restrict what client IP addresses are allowed. If such a securelist of source IP addresses is used in a web application, you must update its configuration to allow the Broadcom egress securelist specified here.

New IP addresses 

The IP range for IP securelisting (except for CASB Gateway and Secure Access Cloud) is: 144.49.240.0/21. 

This CIDR block includes both CASB and DLP egress and ingress IP address lists. The IP range is the same for both US and EU customers. Please see product specific sections below for port numbers that should be open.

CASB Audit and Gateway customers have additional egress and ingress IP addresses that should be processed:

Migration steps for Cloud Workload Assurance customers

Required action: No additional actions are needed (IP securelisting is not required).

Timing: 

  • Go Live time frame: Q4 2020.
  • Migration time frame: Q4 2020. 

Migration steps for Secure Access Cloud customers

Required action: Customers are required to securelist the new IP block. 

Timing: 

  • Customers should complete securelisting by September 30, 2020. 
  • Go Live time frame: Q4 2020.
  • Migration time frame: Q4 2020.

Migration steps for Data Loss Prevention Cloud customers

Required action for customers using versions earlier than DLP 15.1 MP1: Customers will need to update their trust store on the Enforce Server to trust DigiCert CAs. For details on how to replace the Enforce Server trust store, see this Knowledge Base article.

Timing: Customers should complete updating the trust store by September 30, 2020.

Required action for customers using DLP Cloud Service for Email in Reflecting Mode: Customers using DLP Cloud Service for Email in Reflecting Mode need to update their Office 365 configuration to allow the IP range maintained by Broadcom. The new IP addresses can be added to those you have for AWS. To verify that you have correctly configured your DLP Cloud Service for Email environment, see this Knowledge Base article. 

Timing: Customers should complete updating their Office 365 configuration by September 30, 2020.

Required action for customers who configure on-premises firewall rules to connect to the DLP Cloud:  If you currently have firewall rules configured for the Enforce Server, to continue accessing Symantec Cloud Detectors, you need to allow connecting to port 443 for the IP range maintained by Broadcom.

Timing: Customers should complete the port configuration update by September 30, 2020.

For DLP Cloud customers who have configured the use of URL in existing firewall rules: No updates are required; you can continue to use the URLs in your firewall rules without a change. 

For customers of DLP Cloud Detection Service for Web Security Services, DLP Cloud Service for Email in Forwarding Mode, and DLP Cloud Detection Service integrations with CloudSOC CASB: No additional changes are required.  

Timing for all DLP Cloud products: 

UPDATE JANUARY 27, 2021: As of today, all DLP Cloud Detection Services in Europe have been successully migrated. 

All remaining Cloud Detection Service migrations will be completed by February 5, 2021. 

For more information about migration activity, see the Service Status page. Subscribe to the page to be automatically notified of updates. 

Migration steps for CloudSOC CASB customers 

Required actions: All CASB customers are required to securelist the new IP block.

For reference, IP addresses for CloudSOC CASB that you may have previously securelisted include:

The new securelisting consists of two actions: (1) firewall rule changes to allow connections to CASB ingress IP list and port numbers; (2) your Securlets and Gatelets SaaS applications access control changes to accept CASB egress IP list in those applications that restrict source IP addresses.

CASB Audit and Gateway customers have additional IP address ranges and port numbers to consider beyond the common new IP range 144.49.240.0/21; see the following table.

CASB Customer Features

CASB Ingress IP List and Port Number

CASB Egress IP List

Apps to Accept Egress IP

All CASB Customers

144.49.240.0/21 Port 443

144.49.240.0/21

Securlet SaaS Apps

Customers with Audit

144.49.240.0/21 Port 22 if SFTP is used

144.49.240.0/21

 

Google Cloud Storage service at port 443 if SpanVA is used

Customers with Gateway

WSS Ingress IP List and Ports

WSS Egress IP List

Gatelet SaaS Apps

 

(1.1) Required action: Firewall changes for all customers.

All CloudSOC CASB customers need to allow connection to port 443 for the new CASB IP range.

If you are using the CloudSOC non-online services (CloudSOC console, Securlets, and Audit services) and currently have firewall rules configured with URL rules, you can continue to use the URL rules without a change. Symantec recommends that you explicitly add the new IP range above.

(1.2) Required action: Additional firewall changes for CASB Audit customers.

For an Audit service customer who directly uses SFTP to upload logging files to CloudSOC SFTP, you also need to allow connecting to SFTP port 22 for the new IP range.

CASB Audit customers typically use CloudSOC SpanVA software for logging file upload or Active Directory user synchronization to CloudSOC. The SpanVA software doesn’t connect to the CloudSOC SFTP service. An Audit customer who uses SpanVA doesn’t need to open the port 22. Such a customer needs to allow access to Google Cloud Storage (GCS) at port 443; see GCS access instructions.

Note that the existing firewall rules that allow SpanVA to access AWS S3 at port 443 or your direct CloudSOC SFTP service access shouldn’t be deleted until Q1 2021 when CloudSOC CASB in AWS isn’t used anymore.

Timing: Customers should complete firewall IP list and port changes by September 30, 2020.

(1.3) Required action: Additional firewall changes for CASB Gateway customers.

The CASB Gateway will use Broadcom Web Security Service (WSS) as its network ingestion point in the new architecture, leveraging its broad global deployments worldwide for close proximity to customers. The WSS comes with an additional set of egress and ingress IP addresses that are distinct from the common IP range above.

See new WSS IP addresses below for securelisting.

Timing: Gateway customers should complete firewall IP list and port changes by October 15, 2020. 

(2.1) Required action: Allow CASB egress IP for access to your Securlet SaaS Apps.

If your Securlet SaaS app is configured to restrict source IP addresses, change it to allow the new CASB IP range. The Salesforce application, for instance, allows source IP restriction; make sure to check if your tenant has activated a Salesforce Securlet. 

(2.2) Required action: Allow CASB egress IP for access to your Gatelet SaaS Apps.

For CASB Gateway customers, if your Gatelet SaaS app is configured to restrict source IP addresses, change it to allow the new WSS egress IP list.

Timing: Customers should complete egress IP list changes by September 30, 2020.

Additional pre-migration and migration steps are described for Audit and Gateway customers in the following sections.

Migration steps for CASB Audit customers

In addition to the steps described in the previous sections,  a CASB Audit customer also needs to perform the following migration steps.

Required action: You will need to upgrade SpanVA. Specifically:

  • You must be on SpanVA version 1.15.3.120-7rc in preparation for a subsequent upgrade to the final GCP-ready version. If you are not currently running this version, you must upgrade SpanVA to this version in preparation for the following step.  Timing: As soon as possible. See the product advisory for End of Service dates for CloudSOC SpanVA versions. 
  • You must upgrade to the GCP-ready SpanVA version prior to the GCP cutover in mid-December.  The GCP-ready date for SpanVA will be November 30. UPDATE: The GCP-ready SpanVA version 1.15.3.130.0-39rc is available for download as of November 30. 

Update December 28, 2020: You must upgrade to SpanVA version 1.15.3.130.0-39rc no later than January 15, 2021. After that date, versions of SpanVA older than 1.15.3.130.0-39rc will not be able to download the appropriate software to communicate with GCP.

New WSS IP addresses and port numbers for CASB Gateway customers

The CASB Gateway will use the Symantec Web Security Service (WSS) as its network ingestion point in the new architecture. The WSS service uses WSS Agent in user desktops for traffic steering to the WSS proxy in the Broadcom cloud. There are multiple access methods to steer user traffic to the WSS such as proxy chaining from an enterprise proxy. The use of WSS Agents is the primary method.

The WSS Agent replaces the CASB Reach Agent that is currently used by Gateway customers. The WSS Agent setup in user devices needs to access WSS management servers that may run in ports other than TLS port 443. The WSS ingress IP and port numbers are listed below.

 A CASB Gatelet web application will see incoming source IP addresses from the WSS. The WSS service has distinct egress IP addresses from that of the prior CASB Gateways.

WSS Ingress IP List and Port Numbers

WSS egress IP address list

  • Link to egress IP addresses for Americas
  • Link to egress IP addresses for APAC
  • Link to egress IP addresses for EMEA

 These must be accepted by a customer's Gatelet applications if an application restricts source IP addresses. 

A global customer that has users in all the three global regions (Americas, APAC and EMEA) should allow connections from all the IP addresses listed in the above. A user’s request to a website is steered by the WSS Agent in a user’s device to the closest WSS proxy server to the user’s location. A customer may configure and choose what WSS service regions that it wants to send its user traffic. In this case, the customer may just open connections to only the WSS service IP addresses that the customer uses. 

Go back to the CASB securelisting section.

Migration steps for CASB Gateway customers

CASB Gateway will leverage Symantec Web Security Service (WSS) for network ingestion. Different migration steps should be taken based on whether you are an existing WSS customer and whether your WSS service has been used with your CASB account.

  • CASB Gateway customers who are not currently using WSS
  • CASB Gateway customers who have been using WSS and CASB together
  • CASB Gateway customers who are using WSS and CASB separately 

 

CASB Gateway customers who are not currently using WSS

If you are a CASB Gateway customer but not currently using WSS, there are new WSS IP addresses for which you need to allow access; and, you’ll need to set up WSS.

Note that no WSS service or WSS Agent license purchase is needed for CASB customers. The WSS entitlement comes with the CASB integration.

Required actions: The primary migration effort for a non-WSS customer is to install and configure the use of the WSS service. There are two WSS components that you should plan to deploy for migration:

  • WSS desktop agents need to be deployed to end-user computers for traffic steering if you are currently using Reach Agent for traffic steering. The WSS Agent replaces the Reach Agent. 
  • For customers who use the CASB browser plugin with a PAC file or proxy forwarding traffic steering methods instead of the Reach Agent, change to use the similar WSS Proxy Forward access method. The WSS Agent method is preferred to the WSS Proxy Forward method for the current CloudSOC Browser Plugin customers.
  • For some customers, an on-premises software called WSS AuthConnector needs to be deployed in the corporate network. The AuthConnector accesses your corporate Active Directory for user authentication and user provisioning to the WSS.

In addition, you’ll need to configure WSS to connect to the CASB Gateway.

Timing: Customers should plan for this deployment in the late November/December timeframe for prompt migration. 

 

Existing WSS Customers with integrated CASB Gateway 

Required actions: There are no mandatory actions for existing WSS customers with CASB Gateway. For customers who use the WSS Agent access method to steer traffic to the CASB Gateway, Symantec recommends that you upgrade the WSS Agent to the latest version as a standard software practice.

For customers who use legacy Unified Agents, refer to the WSS support guidelines for software upgrade requirements. There are no mandatory CASB support requirements for the agent upgrade itself. 

 

CASB Gateway customers who are using WSS and CASB separately

If you are a CASB Gateway customer using the Reach Agent while you use the WSS Agent for some use cases with WSS, you should have had IP securelisting in your firewall for the WSS IP addresses.

Required actions:

  1. Review and configure your CASB SaaS applications for the WSS egress IP address acceptance.
  2. Confirm the WSS tenant and CASB service tenant that should be linked. Broadcom will contact you for such confirmation. In rare cases, a new WSS tenant might be created to serve for the CASB use cases if you need to retain the existing WSS tenant.
  3. If a new WSS tenant is required, Broadcom will work with you to provision a new tenant. Then follow the action needed as that described for a CASB only customer above to install WSS software.

Symantec recommends that you upgrade the WSS Agent for the software support best practice. For customers who use legacy Unified Agents, refer to the WSS support guidelines for software upgrade requirements. There are no mandatory feature requirements for the CASB migration itself.

Timing: Customers should plan for this deployment in the late November/December timeframe for prompt migration. 

 

Appendix: Google Cloud Storage (GCS) IP addresses for corporate firewall setup

For customers who use a firewall that supports URL filtering, you may use host in the firewall rule setup for the outbound access to GCS including its subdomains as follows. 

*.storage.googleapis.com at port 443

IMPORTANT For CloudSOC Audit customers who use SpanVA, the following information was updated on October 2. For customers who may have previously added GCS addresses to their firewall setup, please read the following updated information. 

Google Cloud Storage (GCS) IP addresses consist of many blocks. GCS uses the same netblocks as all other Google APIs and services. These netblocks change periodically. There are no simple fixed static network blocks from Google. Google provides the following recommendations in determining its service IP address blocks for a customer’s firewall rule use.

  • Use the complete list of IP ranges that Google publishes to the internet in a JSON file goog.json.
  • These IP ranges are updated approximately two to four times per year. Use a script to monitor the file change, and update firewall rules accordingly.
  • Use firewalls to securlist *.storage.googleapis.com if possible to avoid monitoring the IP range changes. If this isn’t feasible, use a script to manage rules based on the Google-published IP address list file goog.json, adding and removing ranges resulting from the changes.

Google Cloud Storage doesn’t provide regional URLs and IP ranges. It uses a global load balancer to route traffic to the region where a GCS storage bucket resides. The bucket name is in the GCS URL path rather than in the hostname when the GCS is accessed. The Broadcom CloudSOC Audit Service uses GCS in EU regions for customers in the EU, and GCS in the US for other customers.