Customize advanced system settings

Several features for advanced users are located on Administration > System Settings > Advanced.

You can automate system setting changes using the Workload Security API. For examples, see Whois

Whois can be used to look up which domain name is associated with an IP address when you review logged intrusion prevention and firewall events. Enter the search URL using "[IP]" as a placeholder for the IP address to look up.
(For example, "[IP]&type=nameserver".)


You can replace the Workload Security logo that appears on the login page, at the top right of the Workload Security console, and at the top of reports. Your replacement image must be in PNG format, be 320 px wide and 35 px high, and have a file size smaller than 1 MB.

Click Import Logo to import your own logo, or click Reset Logo to reset the logo to its default image.

Manager AWS Identity

You can configure cross-account access. Select either:

  • Use Manager Instance Role: The more secure option to configure cross-account access. Attach a policy with the sts:AssumeRole permission to the Workload Security instance role, then select this option. Does not appear if Workload Security does not have an instance role.
  • Use AWS Access Keys: Create the keys and attach a policy with the sts:AssumeRole permission before you select this option, and then type the Access Key and Secret Key.

Application control

Each time you create an Application Control ruleset or change it, it must be distributed to all computers that use it. Shared rulesets are bigger than local rulesets. Shared rulesets are also often applied to many servers. If they all downloaded the ruleset directly from the manager at the same time, high load could cause slower performance. Global rulesets have the same considerations.

Using Deep Security Relays can solve this problem. (For information on configuring relays, see Distribute security and software updates with relays.)

Steps vary by whether or not you have a multi-tenant deployment.

Single tenant deployments

Go to Administration > System Settings > Advanced and then select Serve Application Control rulesets from relays.

local vs. shared ruleset

Multi-tenant deployments

The primary tenant (t0) can't access other tenants' (tN) configurations, so t0 relays don't have tN Application Control rulesets. (Other features like IPS don't have this consideration, because their rules come from Trend Micro, not a tenant.)

Other tenants (Tn) must create their own relay group, then select Serve Application Control rulesets from relays.

tN ruleset relay

Verify compatibility with your deployment before using relays. If the agent doesn't have any previously downloaded rulesets currently in effect, and if it doesn't receive new Application Control rules, then the computer won't be protected by Application Control. If an Application Control ruleset fails to download, a ruleset download failure event will be recorded on the managerandon the agent.

Relays might either change performance, break Application Control ruleset downloads, or be required; it varies by proxy location, multi-tenancy, and global/shared vs. local rulesets.

Required for... Faster performance for... Slower performance for... Don't enable for...

Agent > Proxy > Manager

In Deep Security Agent 10.0 GM and earlier, agents didn't have support for connections through a proxy to relays. If a ruleset download fails due to a proxy, and if your agents require a proxy to access the relay or Workload Security, then you must either:

Shared rulesets

Global ruleset

Local rulesets

Multi-tenant configurations when non-primary tenants (tN) use the default, primary (t0) relay group:

  • Agent (tN) > DSR (t0) > DSM (tN)
  • Agent (tN) > Proxy > DSR (t0) > DSM (tN)