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:
Log In to the Deep Security Manager:
Create or Retrieve Tenant Name:
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):
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:
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.
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)
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 |