Migrate from Deep Security to Workload Security
Deep Security administrators preparing to migrate their deployment to Trend Micro Cloud One - Workload Security can use the instructions in this article as a roadmap to a successful migration.
In general, the order of operations for a successful migration is:
- Configure Workload Security account, users, roles, and authentication.
- Migrate Deep Security settings, policies, and common objects (lists, contexts, malware scan configurations, and so on).
- Configure network and communication settings.
- Reactivate agents from Deep Security Manager to Workload Security.
You will need a Trend Micro Cloud One account to use the Workload Security service. Set up an account before migrating any settings, policies, or computers to the service.
Trend Micro Cloud One has two types of accounts: new accounts that were created on or after August 4, 2021 and legacy accounts created before that date. If you're not sure which type of account you have, see Changes to Trend Micro Cloud One accounts.
If you have a new Trend Micro Cloud One account, there is a new Identity and Access Management system in place. Please review the Trend Micro Cloud One Account and User Management Documentation for in-depth understanding of how to correctly manage users and roles when transitioning to Workload Security.
If you have a legacy Trend Micro Cloud One account, you will need to manually migrate user and role permissions from your Deep Security implementation to the legacy account in Workload Security. User and role configurations in legacy accounts are nearly identical to the Deep Security software implementation and replicate existing functionality.
If you are using SAML with Deep Security Manager, you will need to configure SAML in the Workload Security console and import the appropriate service provider metadata exported to the identity provider performing authentication and role mapping. SAML is not yet supported at the Trend Micro Cloud One level.
Integration with Active Directory for authentication is not supported in Workload Security unless delegated through SAML via ADFS.
Next, migrate these items, if you're using them in your Deep Security environment:
- Cloud connectors
- VMware connector and data center gateway
- Computer groups and smart folders
- Proxy configuration
- Event and alert logging
- Additional configuration
- Trend Micro Vision One (XDR) enrollment
You may want to use the same policies in Workload Security as you used in Deep Security. You can manually re-create the policies in Workload Security, or automate the policy migration using one of these methods:
- Migrate policies directly using the Deep Security migration tool, available in Deep Security Manager 20.0.513 (20 LTS Update 2021-10-14) or later. For instructions, see Migrate policies and agents to Workload Security
- Migrate policies directly using the Deep Security policy migration API and Workload Security Link feature, available in Deep Security Manager 20.0.463 (20 LTS Update 2021-07-22) or later. For instructions, see the tip near the top of Migrate policies and agents to Workload Security.
- Export the policy XML from Deep Security and then use the Workload Security Policy Import API. If you're using an older version of Deep Security or if a direct connection from Deep Security to Workload Security is not possible, you can export policies from Deep Security 12 or later and then import them into Workload Security using the Policy Import API. For details, see Migrating policies to Workload Security in the Deep Security 12 help.
Policies containing SAP Scanner module configurations can be migrated or imported, but those settings will not be visible unless your Workload Security account is also licensed for the SAP Scanner.
Policies containing VMware agentless configurations are not supported in Workload Security.
Because cloud connectors contain stored credentials, connectors to public cloud platforms (AWS, Azure, GCP) cannot be migrated automatically to Workload Security. You should create new connectors in your Workload Security account for all protected public cloud instances. This can be done before or after hosts are migrated and reactivated, but we recommend setting it up prior to host migration.
To learn how to set up cloud connectors in Workload Security, see these articles in the Workload Security help:
- About adding AWS accounts
- Add a Microsoft Azure account to Workload Security
- Add a Google Cloud Platform account
- Add virtual machines hosted on VMware vCloud
Virtual machines running in a VMware environment can have agents deployed and activated to the Workload Security service the same as any other workload. If you want to connect to a VMware vCenter to retrieve a VM inventory, Workload Security needs to communicate with vCenter. This is done through the data center gateway. For instructions on setting up the data and importing the vCenter inventory, see Add a VMware vCenter to Workload Security.
Computer groups and smart folders do not yet have a direct migration method. Deep Security and Workload Security have APIs for listing and creating computer groups, so migration of large numbers of groups could be automated by scripting the appropriate API calls. There is currently no API for smart folders so they must be recreated manually.
Currently, there is no method for automatically migrating proxy configurations from Deep Security to Workload Security. You can manually configure proxy configurations for agent communications in Workload Security according to the instructions in Configure proxies.
You do not need to configure a proxy for the manager because it is part of the Workload Security service and is maintained by Trend Micro.
A major difference between Deep Security and Workload Security is the retention of event and alert data within the manager. Workload Security retains security events 32 days and system events 91 days. If you need to retain events longer, we recommend exporting events to a SIEM or log server.
Customers already using event logging may require some infrastructure change for how alerts/events are received. In a traditional on-premises deployment where Deep Security Manager sends all alerts and events via syslog to a local syslog server, that syslog server may not be directly accessible from Workload Security. Consider these alternatives:
- Create a new syslog server that is accessible from the Workload Security service, following these instructions: Forward Workload Security events to a Syslog or SIEM server.
- Configure agents to send events directly to a local syslog server rather than through the manager. Note that to use TLS encryption with syslog, events must be forwarded from the Workload Security service; agents do not currently support TLS encryption of syslog events.
- Use Amazon SNS as an alternative to syslog. See Set up Amazon SNS.
Configuration of other items such as system settings, reports, event-based and scheduled tasks, tags, version controls, and API keys is not currently part of an automated migration feature. They can be recreated manually in Workload Security. Many of these items are configurable in both the Deep Security and Workload Security APIs and could be automated.
Some system settings may not be supported or applicable when migrating from Deep Security to Workload Security, and caution is advised when automating the migration of these settings via API calls. Contact support for guidance on these settings.
Trend Micro Vision One is included with Workload Security but must be enabled via an enrollment token in the Workload Security console. You can also enable Activity Monitoring in your policies or computer settings. For details, see Integrate Workload Security with Trend Micro Vision One.
Next, evaluate these items:
Network communication between the Deep Security Agent and Workload Security is different from the communication between the agent and Deep Security Manager. There are also several URLs that must be specifically allowed in environments where outbound internet access is restricted. For a full list, see Port numbers, URLs, and IP addresses.
For information about the configuration of proxies for agent communication to the Workload Security service, see Configure proxies.
SOCKS4 and SOCKS5 proxies are not supported for agent communications. If you need to use a proxy for agent communication, implement an HTTP proxy before agents are activated to the Workload Security service.
When considering network planning for deployment of the Deep Security Agent, consider the overall life cycle of the agent, both for agent download and activation, as well as for ongoing operations and security pattern updates.
Existing Deep Security Agents do not need to be reinstalled, only reactivated to the Workload Security service. New deployments that are done via activation script can expect the following bandwidth usage:
- Agent download and activation: 5 MB on Linux, 25 MB on Windows
- Download of initial security update: 50 MB Linux, 102 MB Windows
Ongoing agent traffic is highly variable, depending on detection activity, policy configuration, and module usage. Expect a baseline usage for administrative traffic similar to the following guidelines:
- Security Updates (1x daily, Smart Scan on): 60 MB
- Security Updates (1x daily, Smart Scan off): 120 MB
- Heartbeat overhead: 40 KB per heartbeat. Default interval is 10 minutes, ~5.7 MB daily per agent
For more information about Smart Scan, see Smart Protection in Workload Security.
Beyond baseline traffic, any detections result in additional bandwidth consumption as agents communicate with the Workload Security and Vision One services. This is difficult to predict, but expect usage in a range of 0.1 MB per hour for a low quantity of detections and up to 2-3 MB per hour for elevated detection rates, per agent.
In most cases, the relays provided by the Workload Security service are sufficient. There are some scenarios where operations may be improved using relays. For details, see How relays work and Deploy additional relays.
As mentioned in the bandwidth utilization section, both Deep Security and Workload Security use the same agent software. The versions and platforms supported do vary, so check the Agent platform support table to determine whether the agents running in your environment are supported in Workload Security.
There are several methods to choose from for the reactivation process:
- If your Deep Security environment meets the requirements listed in Migrate policies and agents to Workload Security, you can follow the instructions in that article to use the Deep Security migration tool to migrate agents to Workload Security.
- If your environment contains sufficient automation tools, you can reactivate agents by extracting the activation command from deployment scripts within the Workload Security console. New hosts that don't have an agent should run the entire script. Hosts with existing up-to-date agents can just run the dsa_control command located in a comment at the end of the deployment script. If proxies are in use, note the several lines preceding this command and execute them with the correct values prior to running the activation command. Reactivation does not require a reboot or cause loss of protection during the process.
- Environments without sufficient automation infrastructure can use the Deep Security MoveAgent API, if they are running a recent enough Deep Security Manager and agent versions. This reactivates agents automatically, using the Workload Security Link configured for the target Workload Security account. For details on configuring the Workload Security Link and using the MoveAgent API, see Migrate policies and agents to Workload Security.
Notes about programmatic migration using the Deep Security and Workload Security APIs
Items that are not currently supported via in-product migration features can generally be migrated using a combination of Deep Security and Workload Security APIs to read the pertinent setting or object from a Deep Security deployment and write it to a Workload Security account.
Some items are not available in the current API but are accessible via the legacy REST and SOAP APIs, and some features exist in Deep Security only and are not supported for migration.
Unsupported features in Workload Security:
- Deep Security multi-tenancy settings, as per the /tenants API. Multiple account management in Trend Micro Cloud One supersedes traditional on-premises multi-tenancy and these settings are not applicable in Workload Security.
- Agentless protection for VMware environments
Features in the legacy REST API that are not in the current API:
- Status monitoring
- SAML configuration
- Proxy configuration, control, and assignment
- Event retrieval
Features in the SOAP API that are not in the current API:
- Proxy configuration, control, and assignment
- Event retrieval
- Actions (update agent, run scans, etc.)
- Rule configurations