Migrate from Deep Security to Workload Security

Deep Security administrators preparing to migrate their deployment to Trend Cloud One - Endpoint & Workload Security can use the instructions in this article as a roadmap to a successful migration.

You must be on Deep Security Manager 20.0.513 (20 LTS Update 2021-10-14) or later.

In general, the order of operations for a successful migration is:

  1. Configure Workload Security account, users, roles, and authentication
  2. Create a role and an API key
  3. Prepare a link to Workload Security
  4. Migrate policies
  5. Migrate common objects
  6. Migrate cloud accounts
  7. Migrate agents
  8. Migrate other Deep Security settings
  9. Configure network and communication settings

Configure Workload Security account, users, roles, and authentication

You need a Trend Cloud One account to use the Workload Security service. Set up an account before migrating any settings, policies, or computers to the service.

SAML has two levels of support in Trend Cloud One: for Workload Security specifically, and at the common level. These instructions describe connecting Deep Security with Workload Security.

Trend 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 Cloud One accounts.

If you have a new Trend Cloud One account, there is a new Identity and Access Management system in place. Review the Trend 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 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.

Integration with Active Directory for authentication is not supported in Workload Security unless delegated through SAML via ADFS.

Create a role and an API key

Follow the instructions to create a custom role. Assign the predefined permission "Deep Security Migration" of service "Workload Security" to the role. The "Deep Security Migration" permission is preconfigured and managed by Workload Security with rights to perform migration of agents or policies. The associated rights may change in the future, as additional migration features are implemented. After creating the role, follow the instructions to create an API key with the created role.

We strongly recommend that you do not assign the "Full Access" role to the API key. This role will work, but it creates security concerns.

Prepare a link to Workload Security

The role permission Allow management of Workload Security Link must be assigned for users to manage Workload Security Link.

  1. In upper-right corner of the Deep Security Manager console, select Support > Migrate to Workload Security.

    Screenshot of Manager window with Support menu displayed

  2. On the Link to Workload Security Account page that appears:

    Screenshot of "Link to Workload Security Account" window

    1. Enter the API key that you created in the previous section.
    2. Select the region where your Workload Security account is located.
    3. Select Save.

    If you previously set up a connection between Deep Security and Workload Security and want to change the link, make sure all migration-related tasks using the previous connection are completed before changing the link. Otherwise, you may experience unexpected behavior.

    Each Deep Security Manager tenant allows only one Workload Security Link.

    During the Workload Security Link creation, Deep Security Manager connects to Workload Security to authenticate the link and retrieve information. If the Deep Security Manager installation requires a proxy to connect to Workload Security (https://workload.<region>.cloudone.trendmicro.com), configure the proxy for Workload Security.

  3. The Migrate to Workload Security page appears with the Migrate Configurations tab selected.

    The role permission Allow migration to Workload Security must be assigned for users to be able to process all the migration tasks.

    Migration Configurations tab

Next, migrate your policies to Workload Security.


Migrate other Deep Security settings

Next, migrate these items, if you're using them in your Deep Security environment:

VMware connector and data center gateway

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

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.

Proxy configuration

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.

Event and alert logging

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.

Additional configuration

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 (XDR) enrollment

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.

Configure network and communication settings

Evaluate these items:

Required ports, protocols, and URLs

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.

Proxy configuration

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.

Bandwidth utilization

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.

Relay configuration

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.

Migrate using the Deep Security and Workload Security APIs

This article and its related articles describe how to use the Deep Security Manager and Workload Security UI to perform migration. If you prefer to use the API:

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 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