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
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
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
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
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
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:
Log In to the Deep Security Manager:
Access the Deep Security Manager console using the URL provided during the sign-up process.
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.
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.
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
Please check the section Data Sources to learn about the target tables for each service.
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:
Edit the configuration file.
Change the value of start_time to a newer one.
Save the changes.
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.
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
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.
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:
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
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
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.
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
