Agent-manager communication

Deep Security Manager and the agent or appliance communicate using the latest mutually-supported version of TLS.

Topics in this article:

Configure the heartbeat

A heartbeat is a periodic communication between Deep Security Manager and Deep Security Agent (or appliance). During a heartbeat, the manager collects the following information:

  • The status of the drivers (on-line or off-line)
  • The status of the agent or appliance (including clock time)
  • The agent or appliance logs since the last heartbeat
  • Data to update counters
  • A fingerprint of the agent or appliance security configuration (used to determine if it is up to date)

The heartbeat can be configured on a base or parent policy, on a subpolicy, or on an individual computer.

You can configure the following properties of the heartbeat:

  • Heartbeat Interval: The amount of time that passes between heartbeats.
  • Number of Heartbeats that can be missed before an alert is raised: The number of consecutively missed heartbeats that triggers an alert. For example, a value of 3 causes the manager to trigger an alert on the fourth missed heartbeat.

    If the computer is a server, too many missed heartbeats in a row may indicate a problem with the agent, appliance, or the computer itself. However, if the computer is a laptop or any other system that is likely to experience a sustained loss of connectivity, this option should be set to Unlimited.

  • Maximum change (in minutes) of the local system time on the computer between heartbeats before an alert is raised: On Windows, for agents that can detect changes to the system clock, these events are reported to the manager as the agent event 5004. If the change exceeds the clock change listed here, then an alert is triggered. For agents that do not support this capability, the manager monitors the system time reported by the agent at each heartbeat operation and triggers an alert if it detects a change greater than the permissible change specified in this setting.

    Note that once a Computer-Clock-Changed alert is triggered, it must be dismissed manually.

  • Raise Offline Errors For Inactive Virtual Machines: Defines whether or not an offline error is raised when the virtual machine is stopped.

To perform configurations:

  1. Open the Policy editorClosedTo open the Policy editor, go to the Policies page and double-click the policy that you want to edit (or select the policy and click Details). or the Computer editorClosedTo open the Computer editor, go to the Computers page and double-click the computer that you want to edit (or select the computer and click Details). for the policy or computer to configure.
  2. Go to Settings > General > Heartbeat.
  3. Change the properties as required.
  4. Click Save .

Configure communication directionality

Bidirectional communication is enabled by default.

You can define the artifact that initiates communication. This artifact can be the agent, the appliance, or the manager. Communication includes the heartbeat and all other communications. The following options are available:

  • Bidirectional: Typically, the agent or appliance initiates the heartbeat and also listens on the agent's listening port number for connections from the Deep Security Manager (see Deep Security port numbers). The manager can contact the agent or appliance to perform required operations. The manager can apply changes to the security configuration of the agent or appliance.
    The Deep Security Virtual Appliance can only operate in bidirectional mode. Changing this setting to any other mode for a virtual appliance will disrupt functionality.
  • Manager Initiated: The manager initiates all communication with the agent or appliance. These communications include security configuration updates, heartbeat operations, and requests for event logs. If you select this option, it is strongly recommended that you Protect Deep Security Agent so that it only accepts connections from known Deep Security Managers.
  • Agent/Appliance Initiated: The agent or appliance does not listen for connections from the manager. Instead, they contact the manager on the port number where the manager listens for the agent heartbeats (see Deep Security port numbers). Once the agent or appliance has established a TCP connection with the manager, all normal communication takes place: the manager first asks the agent or appliance for its status and for any events. This is the heartbeat operation. If there are outstanding operations that need to be performed on the computer (for example, the policy needs to be updated), these operations are performed before the connection is closed. Communications between the manager and the agent or appliance only occur on every heartbeat. If an agent or appliance's security configuration has changed, it is not updated until the next heartbeat.

    For instructions on how to configure agent-initiated activation and use deployments scripts to activate agents, see Activate and protect agents using agent-initiated activation and communication.

To enable communications between the manager and the agents and appliances, the manager automatically implements a hidden firewall rule (priority four, Bypass) that opens the listening port number for heartbeats on the agents and appliances to incoming TCP/IP traffic. By default, it accepts connection attempts from any IP address and any MAC address. You can restrict incoming traffic on this port by creating a new priority 4, Force Allow or Bypass firewall rule that only allows incoming TCP/IP traffic from specific IP or MAC addresses, or both. This new firewall rule would replace the hidden firewall rule if the settings match the following settings:

  • action: force allow or bypass
  • priority: 4 - highest
  • packet's direction: incoming
  • frame type: IP
  • protocol: TCP
  • packet's destination port: the agent's listening port number for heartbeat connections from the manager, or a list that includes the port number (see agent listening port number)

    • While the preceding settings are in effect, the new rule replaces the hidden rule. You can then type packet source information for IP or MAC addresses, or both, to restrict traffic to the computer.

To perform configurations:

  1. Open the Policy editorClosedTo open the Policy editor, go to the Policies page and double-click the policy that you want to edit (or select the policy and click Details). or the Computer editorClosedTo open the Computer editor, go to the Computers page and double-click the computer that you want to edit (or select the computer and click Details). for the policy or computer to configure.
  2. Go to Settings > General > Communication Direction.
  3. In the Direction of Deep Security Manager to Agent/Appliance communication menu, select one of the three options: Manager Initiated, Agent/appliance Initiated, Bidirectional, or select Inherited. If you select Inherited, the policy or computer inherits the setting from its parent policy. Selecting one of the other options overrides the Inherited setting.
  4. Click Save.

Agents and appliances look for the Deep Security Manager on the network by the manager's hostname. Therefore, the manager's hostname must be in your local DNS for agent- or appliance-initiated or bidirectional communication to work.

Supported cipher suites for agent-manager communication

Deep Security Manager and the agent or appliance communicate using the latest mutually-supported version of TLS.

The Deep Security Agent supports the following cipher suites for communication with the manager:

For specifics on the cipher suites supported by Deep Security Manager, contact Trend Micro. If you need to know the cipher suites supported by the Deep Security Virtual Appliance, determine the version of the agent embedded on the appliance, and then look up that agent in the list.

The cipher suites consist of a key exchange asymmetric algorithm, a symmetric data encryption algorithm and a hash function.

Deep Security Agent 9.6 cipher suites

Deep Security Agent 9.6 supports the following TLS 1.0 cipher suites:

  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Deep Security Agent 10.0 cipher suites

Deep Security Agent 10.0 supports the following TLS 1.2 cipher suites out-of-the-box:

  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256

Deep Security Agent 10.0 Update 16 and later supports the following TLS 1.2 cipher suites, and only these suites, if strong cipher suites are enabled:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Deep Security Agent 11.0, 12.0, and 20 cipher suites

Deep Security Agent 11.0 and later supports the following TLS 1.2 cipher suites:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

In FIPS mode, the following TLS 1.2 suites are supported:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256