Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Current »

Overview

Trend Micro Deep Security is a comprehensive security solution designed to protect physical, virtual, cloud, and container environments. It provides a range of security features, including Log Inspection for analyzing system logs to identify suspicious activity.

Trend Micro Deep Security Collector Migration Guide

No changes are required from version v1.3.0 to v1.4.0.

Devo collector features

Feature

Details

Allow parallel downloading

not allowed

Running environments

  • collector server

  • on-premise

Populated Devo events

table

Flattening preprocessing

No

Allowed source events obfuscation

No

Data sources

This collector uses the Trend Micro Deep Security API to pull data from the services mentioned above. The data is then sent to Devo for further analysis and visualization. The services are only available through Trend Micro Deep Security Legady API endpoints. These are the defined services:

  • Alerts: Returns Alert events

  • Anti-malware: Returns Anti-Malware events

  • Integrity: Returns Integrity Monitoring events

Data Source

Description

API Endpoint

Collector Service Name

Devo Table

Available from release

Alerts Events

Returns Alert events

/alert-types

/alerts

alerts

av.trendmicro.deepsec.alerts

v1.0.0

Anti-malware Events

Returns Anti-malware events

/events/antimalware

antimalware-events

av.trendmicro.deepsec.antimalwareevents

v1.0.0

Integrity Events

Returns Integrity events

/events/integrity

integrity-events

av.trendmicro.deepsec.integrityevents

v1.0.0

API Limits

API rate limits are set on API endpoints to prevent large spikes in API calls that could degrade Deep Security Manager performance.

API call rates are measured as the number of API calls that Deep Security Manager receives within sixty seconds. When a rate limit is exceeded, the manager stops processing requests until the call rate falls below all rate limits. When a call is made and an API rate limit is exceeded, the response code is 429 with the message Too many API requests.

Rate limits are applied to the following entities:

  • User: The number of API calls that the manager can receive from an API key per minute.

  • Tenant: The number of calls a tenant (including the primary tenant) can receive per minute. This limit effectively sets a collective limit on all API keys created on a tenant. For example, if users are limited to 300 calls per minute and tenants are limited to 1000 calls per minute, the total calls from 4 API keys could reach the tenant limit without exceeding the user limit.

  • Manager node: The number of calls a manager node can receive per minute. This limit effectively sets a collective limit on calls made to all tenants on a single instance of Deep Security Manager. Multiple tenants can collectively exceed their node's rate limit without any of them having exceeded the tenant limit.

The limits apply to each user, tenant, and node. You cannot set a different limit for an individual entity.

The rate limits you use for your Deep Security Manager instances depend on the resources available in your manager's computer, and the API traffic they receive. The following rate limits are set by default:

  • User: 500

  • Tenant: 1000

  • Node: 5000

If you run the collector in standalone mode, do not forget to whitelist the access to the Deep Security Manager API address: *.trendmicro.com.

Minimum Configuration Required for Basic Pulling

For legacy authentication:

Setting

Details

tenantname

REQUIRED The tenant name is required to authenticate the requests

username

REQUIRED The username is required to authenticate the requests.

password

REQUIRED The password is required to authenticate the requests.

For Cloud One:

Setting

Details

tenantname

REQUIRED The tenant name is required to authenticate the requests

api_secret_key

REQUIRED The api_secret_key is required to authenticate the requests.

base_url_cloudone

REQUIRED The base_url_cloudone is required to initiate a session for the requests.

Accepted Authentication Methods

Authentication method

Details

Legacy: user/pass

You will need your username and password to connect to the hostname_value.

Cloud One: api_secret_key

You will need an api_secret_key to connect to the base_url_cloudone.

Treat Your Secret Key Like A Password

The security of your Deep Security application is tied to the security of your user and password or secret key. Secure them as you would any sensitive credential. Don't share it with unauthorized individuals or email it to anyone under any circumstances!

Vendor setup

To get a tenant name, username, and password for the Trend Micro Deep Security API, follow these steps:

  1. Log In to the Deep Security Manager:

    • Access the Deep Security Manager console using the URL provided during the sign-up process.

  2. Create or Retrieve Tenant Name:

    • The tenant name is usually provided during the account creation process. If you need to retrieve it, navigate to the account settings or contact your administrator.

  3. Create or Retrieve Username and Password:

    • Navigate to the Administration section in the Deep Security Manager.

    • Go to User Management and create a new user or retrieve an existing user's credentials.

    • Ensure the user has the necessary permissions to access the API.

  4. API Key (Optional):

    • If the authentication is performed through Cloud One, use an API secret instead of a username and password. Navigate to Administration > API Keys to generate a new API secret.

By following these steps, you will obtain the necessary credentials to authenticate and interact with the Trend Micro Deep Security API.

Connectivity Requirements

This application communicates with the Trend Micro Deep Security service on SSL TCP port 443.

Flattening Preprocessing

No flattening is applied before sending the data to Devo.

Source Event Obfuscation

No obfuscation is applied before sending the data to Devo.

Run the collector

Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).

Collector services detail

This section is intended to explain how to proceed with specific actions for services.

All The Services

 Devo Categorization And Destination

Please check the section Data Sources to learn about the target tables for each service.

 Restart the persistence

This collector uses persistent storage to download events in an orderly fashion and avoid duplicates. In case you want to re-ingest historical data or recreate the persistence, you can restart the persistence of this collector by following these steps:

  1. Edit the configuration file.

  2. Change the value of start_time to a newer one.

  3. Save the changes.

  4. Restart the collector.

The collector will detect this change and will restart the persistence using the parameters of the configuration file or the default configuration in case it has not been provided.

Note that this action clears the persistence and cannot be recovered in any way. Resetting persistence could result in duplicate or lost events.

 Troubleshooting

This collector has different security layers that detect both an invalid configuration and abnormal operation. This table will help you detect and resolve the most common errors.

Error Type

Error Id

Error Message

Cause

Solution

TrendMicroDeepSecPullerSetupException

1

Failed to initiate the session with Trend Micro Deep Security API

The API login operation failed

Check if the service is available

TrendMicroDeepSecPullerSetupException

2

Failed to close the session with Trend Micro Deep Security API

The API logout operation failed

Check if the service is available

TrendMicroDeepSecPullerException

3

The execution of the Trend Micro Deep Security Alerts request got an unexpected response

The Deep Security API request failed when retrieving the alert list

Review the error and act accordingly

TrendMicroDeepSecPullerException

4

The execution of the Trend Micro Deep Security Alerts Types request got an unexpected response

The Deep Security API request failed when retrieving the alert types

Review the error and act accordingly

TrendMicroDeepSecPullerException

5

The execution of the Trend Micro Deep Security Events request got an unexpected response

The Deep Security API request failed when retrieving the event list

Review the error and act accordingly

TrendMicroDeepSecInitVariablesException

100

Service not supported

The configuration has a service that is misspelled or nonexistent

Review and fix the configuration service names

TrendMicroDeepSecInitVariablesException

101

"start_time" value does not fulfill the format: "YYYY-MM-DDTHH:MM:SS.mmmZ"

The start_time parameter in the configuration has the wrong format

Review and fix the parameter in the service configuration

Collector operations

This section is intended to explain how to proceed with the specific operations of this collector.

 Verify collector operations

This is for the standalone mode only. Check the information in the following sections to verify the correct collector operation.

Initialization

The initialization module validates the given configuration and runs the setup, the input (pulling logic), and output (delivering logic) services. A successful run has the following output messages for the initializer module:

2023-01-10T15:22:57.146 INFO MainProcess::MainThread -> Loading configuration using the following files: {"full_config": "config-test-local.yaml", "job_config_loc": null, "collector_config_loc": null}
2023-01-10T15:22:57.146 INFO MainProcess::MainThread -> Using the default location for "job_config_loc" file: "/etc/devo/job/job_config.json"
2023-01-10T15:22:57.147 INFO MainProcess::MainThread -> "\etc\devo\job" does not exists
2023-01-10T15:22:57.147 INFO MainProcess::MainThread -> Using the default location for "collector_config_loc" file: "/etc/devo/collector/collector_config.json"
2023-01-10T15:22:57.148 INFO MainProcess::MainThread -> "\etc\devo\collector" does not exists
2023-01-10T15:22:57.148 INFO MainProcess::MainThread -> Results of validation of config files parameters: {"config": "C:\git\collectors2\devo-collector-<name>\config\config.yaml", "config_validated": True, "job_config_loc": "/etc/devo/job/job_config.json", "job_config_loc_default": True, "job_config_loc_validated": False, "collector_config_loc": "/etc/devo/collector/collector_config.json", "collector_config_loc_default": True, "collector_config_loc_validated": False}
2023-01-10T15:22:57.171 WARNING MainProcess::MainThread -> [WARNING] Illegal global setting has been ignored -> multiprocessing: False

Events delivery and Devo ingestion

The event delivery module is in charge of receiving the events from the internal queues where all the events are injected by the pullers and delivered using the selected compatible delivery method. A successful run has the following output messages for the initializer module:

2023-01-10T15:23:00.788    INFO OutputProcess::MainThread -> DevoSender(standard_senders,devo_sender_0) -> Starting thread
2023-01-10T15:23:00.789    INFO OutputProcess::MainThread -> DevoSenderManagerMonitor(standard_senders,devo_1) -> Starting thread (every 300 seconds)
2023-01-10T15:23:00.790    INFO OutputProcess::MainThread -> DevoSenderManager(standard_senders,manager,devo_1) -> Starting thread
2023-01-10T15:23:00.842    INFO OutputProcess::MainThread -> global_status: {"output_process": {"process_id": 18804, "process_status": "running", "thread_counter": 21, "thread_names": ["MainThread", "pydevd.Writer", "pydevd.Reader", "pydevd.CommandThread", "pydevd.CheckAliveThread", "DevoSender(standard_senders,devo_sender_0)", "DevoSenderManagerMonitor(standard_senders,devo_1)", "DevoSenderManager(standard_senders,manager,devo_1)", "OutputStandardConsumer(standard_senders_consumer_0)",

Sender services

The Integrations Factory Collector SDK has 3 different sender services depending on the event type to deliver (internal,
standard, and lookup). This collector uses the following Sender Services:

Logging Trace

Description

Number of available senders: 1

Displays the number of concurrent senders available for the given Sender Service.

Sender manager internal queue size: 0

Displays the items available in the internal sender queue.

This value helps detect bottlenecks and needs to increase the performance of data delivery to Devo. This can be done by increasing the concurrent senders.

Total number of messages sent: 44, messages sent since "2022-06-28 10:39:22.511671+00:00": 21 (elapsed 0.007 seconds)

Displays the number of events from the last time the collector executed the pull logic. Following the given example, the following conclusions can be obtained:

  • 44 events were sent to Devo since the collector started.

  • The last checkpoint timestamp was 2022-06-28 10:39:22.511671+00:00.

  • 21 events were sent to Devo between the last UTC checkpoint and now.

  • Those 21 events required 0.007 seconds to be delivered.

By default, these traces will be shown every 10 minutes.

Sender statistics

Each service displays its performance statistics that allow checking how many events have been delivered to Devo by type:

Logging Trace

Description

Number of available senders: 1

Displays the number of concurrent senders available for the given Sender Service.

Sender manager internal queue size: 0

Displays the items available in the internal sender queue.

Standard - Total number of messages sent: 57, messages sent since "2023-01-10 16:09:16.116750+00:00": 0 (elapsed 0.000 seconds

Displays the number of events from the last time the collector executed the pull logic. Following the given example, the following conclusions can be obtained:

  • 57 events were sent to Devo since the collector started.

  • The last checkpoint timestamp was 2023-01-10 16:09:16.116750+00:00.

  • 0 events were sent to Devo between the last UTC checkpoint and now.

  • Those 0 events required 0.00 seconds to be delivered.

 Check memory usage

To check the memory usage of this collector, look for the following log records in the collector which are displayed
every 5 minutes by default, always after running the memory-free process.

  • The used memory is displayed by running processes and the sum of both values will give the total used memory for the collector.

  • The global pressure of the available memory is displayed in the global value.

  • All metrics (Global, RSS, VMS) include the value before freeing and after previous -> after freeing memory

  INFO InputProcess::MainThread -> [GC] global: 20.4% -> 20.4%, process: RSS(34.50MiB -> 34.08MiB), VMS(410.52MiB -> 410.02MiB)
  INFO OutputProcess::MainThread -> [GC] global: 20.4% -> 20.4%, process: RSS(28.41MiB -> 28.41MiB), VMS(705.28MiB -> 705.28MiB)

Differences between RSS and VMS memory usage:

  • RSS is the Resident Set Size, which is the actual physical memory the process is using

  • VMS is the Virtual Memory Size which is the virtual memory that process is using

Change log

Release

Released on

Release type

Details

Recommendations

v1.4.0

2024-10-25

IMPROVEMENT

Improvements

  • Updated DC SDK from v1.11.1 to v1.13.1

  • Updated Docker Base image to v1.3.1

  • Collector transformed to the template model

Recommended version

v1.3.0

2024-04-17

IMPROVEMENT

Improvements

  • Updated DevoCollectorSDK to v1.11.1

  • Updated Docker Base image to v1.2.0

  • Changed the way of executing the controlled stopping

Update

  • No labels