Summary Overview for Migrating from SpanVA 1.15.3.153.0-* to 1.15.3.166.0-*

Products

CASB Gateway Advanced CASB Advanced Threat Protection CASB Audit CASB Gateway CASB Security Advanced CASB Security Advanced IAAS CASB Security Premium CASB Security Premium IAAS CASB Security Standard CASB Securlet IAAS CASB Securlet SAAS

Issue/Introduction

There is no "Click to Install" upgrade because these SpanVAs use two different OS and multiple versus single disk.

Refer to SpanVA Tech Docs for most current information, additional details, source

SpanVA 1.15.3.153.0-* has two disks, CentOS 7 OS, may still function for a while but is EOS - no longer supported after 27 Mar 2025.

NOT recommended to remain on version 1.15.3.153.0-* There will not be any new OS Security updates, product fixes, or features developed for this deprecated version.
SpanVA 1.15.3.166.0-* is Oracle-linux-based, released 30 Jan 2025. OVA has one 200 GB Disk with 72 GB Partition for OS, 128 GB Partition for Logs, & latest features

See "Resolution" section below for summary of SpanVA Migration from 1.15.3.153.0-* to 1.15.3.166.0-* high level overview of steps.

See "Additional Information" section for shorter parallel install steps (no migration)

Resolution

SpanVA Migration Summary:

Summary of steps to be able to retain same data source (DS) feeds, tokenization, continue with same DS history in CloudSOC Audit .

Migration requires having backup of SpanVA 1.15.3.153.0-* to use to import system state, and saved token, to new SpanVA 1.15.3.166.0-*

Please refer to SpanVA Tech Docs for full details and latest updates. Summary high level overview below are derived from these same SpanVA Tech Docs.

Review existing SpanVA Settings, and copy all configs to text editor for reuse later. Get existing SpanVA 1.15.3.153.0-* name, Network Tab settings, DSS settings (all profiles), NTP, Backup/restore, U/N & PW Credentials, any custom settings.
Configure SpanVA Backups on existing SpanVA 1.15.3.153.0-* to a local Linux server that supports SCP/SFTP server is easiest. Or backup to a Windows box with a SCP/SFTP server type utility running (configured to listen for backups from SpanVA)

Minimum 40 GB total space for SpanVA system state backups. Note: Daily 12 AM UTC SpanVA Backups do NOT save any Proxy / FW logs.
Download new Oracle linux-based SpanVA 1.15.3.166.0-* OVA (or Hyper-V) image from CloudSOC Settings / CloudSOC SpanVA - and provide it to your Hypervisor Admin to import
SpanVA 1.15.3.166.0-* has one Disk with two partitions. Default Partition 1 is 72 GB for OS / Partition 2 is 128 GB for Logs. Total default disk size 200 GB. Can be increased later.
Hypervisor Admin - Power up the new SpanVA 1.15.3.166.0-* VM. Login to CLI from Hypervisor Admin Console. Start / Register.
CloudSOC SysAdmin login via web browser (https://IP or FQDN) to new SpanVA 1.15.3.166.0-* GUI - as admin. Configure NTP Tab.
Backup Current SpanVA 1.15.3.153.0-* Backup should be listed in Backup/Restore Tab and also exist on destination backup server - (confirm before proceeding). Save Backup Server IP address, path, U/N & PW credentials to be able to configure backups / restore system state later into each new SpanVA 1.15.3.166.0-* you are migrating to.
In Hypervisor - Shutdown (Power Off) the old interim SpanVA 1.15.3.153.0-* via Hypervisor Admin console and wait 10 minutes.
After 10 minutes - In CloudSOC / Settings / CloudSOC SpanVA - select the old shutdown SpanVA 1.15.3.153.0-* - Revoke token / Save SpanVA Token to notepad.
Login via web browser (https://IP address or FQDN) to new SpanVA 1.15.3.166.0-* GUI as admin - import the Saved Token from the old SpanVA 1.15.3.153.0-* into the new SpanVA 1.15.3.166.0-* - New SpanVA should then show Active / linked to CloudSOC after few minutes.
Configure settings on SpanVA 1.15.3.166.0-* Backup/ Restore Tab and Test Connection. Restore backup of the last system state from old SpanVA 1.15.3.153.0-* to the new 1.15.3.166.* SpanVA that is replacing it..
.
Review settings in SpanVA 1.15.3.166.0-* Tabs that everything looks correct on new SpanVA (similar to pre-migration). Run Diagnostics to confirm all is green on the new SpanVA
If not all green - resolve issues.
In SpanVA Monitoring Tab - Check for logs found. If using same IP / FQDN after some minutes – you should see new Proxy / FW logs starting to be imported and uploaded to CloudSOC successfully. If not seeing successful log uploads getting processed through new SpanVA - check from datasource side. Does it show logs successfully feeding new SpanVA or are there errors? Fix any errors with datasource then recheck SpanVA Monitoring Tab
Check CloudSOC / Audit / Device Logs / details tabs – After 20-30 minutes - check if incoming Proxy /FW logs are queued or successfully processing inside CloudSOC Audit
(Could take several hours to a half day or more to fully process logs within CloudSOC Audit - depending upon queue size, log file sizes, upload frequency, etc)
If DSS is being used – Check that AD Sync (DSS) is successfully syncing
Check CloudSOC / CloudSOC SpanVA / details tab on each new SpanVA migrated to see if resource utilization is acceptable
(CPU / Mem / Disk utilization may be high at first but should decrease to low level after log processing spikes subside)
Next day – check that CloudSOC Audit / Device Logs “Latest Date” for the Data Source is either today’s date or previous day.
Check CloudSOC Settings / CloudSOC SpanVA / Details - Resource usage. Increase CPU, Disk, or Memory in Hypervisor on SpanVA VM if needed.
If VM disk size is increased in the Hypervisor then, after restart, in SpanVA Settings - via slider at bottom of page - log partition size can be increased.
CloudSOC / Audit / Services – GUI should look normal at this point. Volume of logs processed consistent with previous days/weeks & patterns (assuming same DS configurations)

If additional questions / issues - please log CASB Support case.

See "Additional Information" section for SpanVA Upgrade Parallel - No Migration - Overview

Additional Information

SpanVA Upgrade Parallel - (No Migration) - Overview:

Reminder- there is no direct upgrade from CentOS 7 SpanVA versions to the Oracle Linux-based OS SpanVA versions. There is no "Click to Install" upgrade between these two different OS.

If Migrating is too difficult to orchestrate - installing new SpanVA and new Data Source (DS) parallel during normal shift and phasing out old SpanVA & DS may be more suitable for some clients.

Overview of steps to install new SpanVA 1.15.3.166.0-* parallel to existing CentOS7 based SpanVA 1.15.3.153.0-*

Note: CentOS7 based SpanVA 1.15.3.153.0- version may technically still function – but will no longer be supported after EOS date 27 Mar 2025.

Ensure SpanVA 1.15.3.166.0-** Pre-Reqs are met.
Deploy new SpanVA 1.15.3.166.0-*
After login to SpanVA GUI check that SpanVA Diags are all green, shows “Alive” upper left corner.
Copy configs from old SpanVA 1.15.3.153.0-* All Tabs including Network, NTP, DSS, Backup / Restore, etc. to text editor for use later as needed to paste in new SpanVA.
Stop sending logs from DataSource(s) to old SpanVA 1.15.3.153.0-* Leave old SpanVA running to finish processing remaining logs in queues.
Create new Data Source and start sending logs to the new SpanVA 1.15.3.166.0-* ensuring that logs are being received / processed successfully in SpanVA Monitoring tab.
Within CloudSOC several hours to one day or so later. CloudSOC Audit / Device Logs/ DataSource “Latest Date” should be within last day.
Check CloudSOC Settings /CloudSOC SpanVA/ Details for resource utilization. If needed increase resources on the new SpanVA 1.15.3.166.0-* VM.

Note: Resource usage fluctuating during processing may be normal as long as values are not staying continually high and Data Source Latest Date is current (or prior day if in the AM)
In CloudSOC - Leave old SpanVA 1.15.3.153.0-* and it's Data Source (DS) in CloudSOC until historical Audit logs from that DS are no longer useful per Client Corp policy.

Remove extra SysAdmin email addresses from old DS config at bottom. The “no new data” alerts to remaining SysAdmin should stop after approx. 30 days.
After all is working fine with new SpanVA 1.15.3.166.0-* Client could power down old CentOS7 SpanVA from within their hypervisor stack.
After deemed no longer needed per corporate policy - In CloudSOC - client can remove old Data Source (DS) and then SpanVA 1.15.3.153.0-* from GUI in CloudSOC

Note: Audit will no longer show historical Services / Users activity for a deleted Data Source (DS) and it is non-recoverable.