---
title: "Trend Micro Deep Security collector"
canonical: "https://docs.devo.com/space/latest/1086586881/Trend%20Micro%20Deep%20Security%20collector"
format: markdown
---
> Macro (toc)

## 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`<br>`/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 (<u>Cloud collector</u>), or deploy and host the collector in your own machine using a Docker image (<u>On-premise collector</u>).

> Macro (rw-ui-tabs-macro)
> 
> > Macro (rw-tab)
> 
> We use a piece of software called Collector Server to host and manage all our available collectors.
> 
> To enable the collector for a customer:
> 
> 1. In the **Collector Server** **GUI**, access the **domain** in which you want this instance to be created
> 2. Click **Add Collector** and find the one you wish to add.
> 3. In the **Version** field, select the latest value.
> 4. In the **Collector Name** field, set the value you prefer (this name must be unique inside the same Collector Server domain).
> 5. In the sending method select **Direct Send. Direct Send** configuration is optional for collectors that create `Table` events, but mandatory for those that create `Lookups`.
> 6. In the **Parameters** section, establish the **Collector Parameters** as follows below:
> 
> ### Editing the JSON configuration
> 
> ```json
> {
>   "global_overrides": {
>     "debug": false
>   },
>   "inputs": {
>     "trendmicro_deepsec": {
>       "id": <short_unique_id>,
>       "enabled": true,
>       "credentials": {
>         "tenantname": "<tenant_name_value>",
>         "username": "<username_value>",
>         "password": "<password_value>",
>         "api_secret_key": "<api_secret_key_value>",
>         "base_url_cloudone": "<base_url_cloudone_value>"
>       },
>       "services": {
>         "alerts": {
>           "alerts_types_filter": [
>             "<alerts_types_filter_values>",
>             "<alerts_types_filter_values>"
>           ]
>         },
>         "antimalware-events": {
>           "start_time": "<start_time_value>"
>         },
>         "integrity-events": {
>           "start_time": "<start_time_value>"
>         }
>       }
>     }
>   }
> }
> ```
> 
> > ℹ️ All defined service entities will be executed by the collector. If you do not want to run any of them, just remove the entity from the `services` object.
> 
> The following table outlines the parameters available for configuring the collector. Each parameter is categorized by its necessity (mandatory or optional), data type, acceptable values or formats, and a brief description.
> 
> | **Parameter** | **Data Type** | **Requirement** | **Value Range / Format** | **Description** |
> | --- | --- | --- | --- | --- |
> | `short_unique_id` | `int` | Mandatory | Min length: 1 | A short unique ID for input service, used in persistence addressing. Avoid duplicates to prevent collisions. |
> | `tenant_name_value` | `str` | Mandatory | Min length: 1 | Tenant name used for authentication. |
> | `username_value` | `str` | Mandatory* | Min length: 1 | User name for authentication. |
> | `password_value` | `str` | Mandatory* | Min length: 1 | Password for authentication. |
> | `api_secret_key_value` | `str` | Mandatory* | Min length: 1 | API secret key for authentication. |
> | `base_url_cloudone_value` | `str` | Mandatory* | Min length: 1 | Base URL for authentication. This URL depends on the region where the account was registered. For instance, `<https://workload.us-1.cloudone.trendmicro.com/rest`> |
> | `alerts_types_filter_values` | `List of str` | Optional | Comma-separated list of strings | **Only for alerts**: If present, the alerts will be retrieved from these types only. |
> | `start_time_value` | `str` | Optional | `"YYYY-MM-DDTHH:MM:SS.mmmZ"` | **Only for anti-malware or integrity events**: It will be the start date and time for pulling events. Example: `2024-07-01T03:00:00.000Z` |
> 
> `*` For the authentication you must have one of these pairs:
> 
> - Legacy API: `username_value` and `password_value`
> - Cloud One: `api_secret_key_value` and `base_url_cloudone_value` (This authentication method uses the Legacy_API_Key)
> 
> > Macro (rw-tab)
> 
> This data collector can be run on any machine with the Docker service available because it runs as a Docker container. The following sections explain how to prepare all the necessary configurations for the data collector to run.
> 
> ### Structure
> 
> The following directory structure should be created:
> 
> ```
> <any_directory>
> └── devo-collectors/
>     └── <product_name>/
>         ├── certs/
>         │   ├── chain.crt
>         │   ├── <your_domain>.key
>         │   └── <your_domain>.crt
>         ├── state/
>         └── config/ 
>             └── config.yaml
> ```
> 
> > ⚠️ Replace `<product_name>` with the proper value.
> 
> ### Devo credentials
> 
> To send data securely to the Devo platform, you will need to download X.509 Certificates from your Devo Domain:
> 
> 1. Login to your Devo tenant.
> 2. On the left menu, click on **Administration** and later click on **Credentials**
> 3. Download your Certificate by clicking on **Certificate**
> 4. Download your Private Key by clicking on **Private Key**
> 5. Download your Chain CA by clicking on **Chain CA**
> 6. Move the downloaded files to `<product_name>/certs/` folder
> 
> For more information about how to get the Devo certificates, please visit [Devo Docs](https://docs.devo.com/space/latest/94763741/X.509+certificates).
> 
> > ⚠️ Replace `<product_name>` with the proper value.
> 
> ![image](media://f7b6375c-8878-4efc-9903-d423d7b10e75)
> 
> ### Editing the config.yaml file
> 
> An example of the `config.yaml`:
> 
> ```yaml
> globals:
>   debug: false
>   id: not used
>   name: trendmicro-deepsec
>   persistence:
>     type: filesystem
>     config:
>       directory_name: state
> outputs:
>   devo_1:
>     type: devo_platform
>     config:
>       address: <devo_address>
>       port: 443
>       type: SSL
>       chain: <chain_filename>
>       cert: <cert_filename>
>       key: <key_filename>
> inputs:
>   trendmicro_deepsec:
>     id: <short_unique_id>
>     enabled: true
>     credentials:
>       tenantname: <tenant_name_value>
>       username: <username_value>
>       password: <password_value>
>       api_secret_key: <api_secret_key_value>
>       base_url_cloudone: <base_url_cloudone_value>
>     services:
>       alerts:
>         alerts_types_filter: [<alerts_types_filter_values>, <alerts_types_filter_values>]
>       antimalware-events:
>         start_time: "<YYYY-MM-DDTHH:MM:SS.000Z>"
>       integrity-events:
>         start_time: "<YYYY-MM-DDTHH:MM:SS.000Z>"
> ```
> 
> The following table outlines the parameters available for configuring the collector. Each parameter is categorized by its necessity (mandatory or optional), data type, acceptable values or formats, and a brief description.
> 
> | **Parameter** | **Data Type** | **Requirement** | **Value Range / Format** | **Description** |
> | --- | --- | --- | --- | --- |
> | `short_unique_id` | `int` | Mandatory | Min length: 1 | A short unique ID for input service, used in persistence addressing. Avoid duplicates to prevent collisions. |
> | `tenant_name_value` | `str` | Mandatory | Min length: 1 | Tenant name used for authentication. |
> | `username_value` | `str` | Mandatory* | Min length: 1 | User name for authentication. |
> | `password_value` | `str` | Mandatory* | Min length: 1 | Password for authentication. |
> | `api_secret_key_value` | `str` | Mandatory* | Min length: 1 | API secret key for authentication. |
> | `base_url_cloudone_value` | `str` | Mandatory* | Min length: 1 | Base URL for authentication. This URL depends on the region where the account was registered. For instance, `<https://workload.us-1.cloudone.trendmicro.com/rest`> |
> | `alerts_types_filter_values` | `List of str` | Optional | Comma-separated list of strings | **Only for alerts**: If present, the alerts will be retrieved from these types only. |
> | `start_time_value` | `str` | Optional | `"YYYY-MM-DDTHH:MM:SS.mmmZ"` | **Only for anti-malware or integrity events**: It will be the start date and time for pulling events. Example: `2024-07-01T03:00:00.000Z` |
> 
> `*` For the authentication you must have one of these pairs:
> 
> - Legacy API: `username_value` and `password_value`
> - Cloud One: `api_secret_key_value` and `base_url_cloudone_value` (This authentication method uses the Legacy_API_Key)
> 
> ### Download the Docker image
> 
> The collector should be deployed as a Docker container. Download the Docker image of the collector as a .tgz file by clicking the link in the following table:
> 
> | **Collector Docker image** | **SHA-256 hash** |
> | --- | --- |
> | [collector-trend_micro_deep_sec-docker-image-1.4.0.tgz](https://drive.google.com/file/d/1fWJrfHygIP6haDTmVKwMuKOSgGojvR3m/view?usp=drive_link) | `965cc703191c673dbd085cd94e5d137756978cca7620fe4ba8a2e666244d0be7` |
> 
> Use the following command to add the Docker image to the system:
> 
> ```
> gunzip -c <image_file>-<version>.tgz | docker load
> ```
> 
> > ⚠️ Once the Docker image is imported, it will show the real name of the Docker image (including version info). Replace `<image_file>` and `<version>` with a proper value.
> 
> The Docker image can be deployed on the following services:
> 
> #### Docker
> 
> Execute the following command on the root directory `<any_directory>/devo-collectors/<product_name>/`
> 
> ```
> docker run 
> --name collector-<product_name> 
> --volume $PWD/certs:/devo-collector/certs 
> --volume $PWD/config:/devo-collector/config 
> --volume $PWD/state:/devo-collector/state 
> --env CONFIG_FILE=config.yaml 
> --rm 
> --interactive 
> --tty 
> <image_name>:<version>
> ```
> 
> > ⚠️ Replace `<product_name>`, `<image_name>` and `<version>` with the proper values.
> 
> #### Docker Compose
> 
> The following Docker Compose file can be used to execute the Docker container. It must be created in the `<any_directory>/devo-collectors/<product_name>/` directory.
> 
> ```
> version: '3'
> services:
>   collector-<product_name>:
>     image: <image_name>:${IMAGE_VERSION:-latest}
>     container_name: collector-<product_name>
>     volumes:
>       - ./certs:/devo-collector/certs
>       - ./config:/devo-collector/config
>       - ./credentials:/devo-collector/credentials
>       - ./state:/devo-collector/state
>     environment:
>       - CONFIG_FILE=${CONFIG_FILE:-config.yaml}
> ```
> 
> To run the container using docker-compose, execute the following command from the `<any_directory>/devo-collectors/<product_name>/` directory:
> 
> ```
> IMAGE_VERSION=<version> docker-compose up -d
> ```
> 
> > ⚠️ Replace `<product_name>`, `<image_name>` and `<version>` with the proper values.

## Collector services detail

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

### All The Services

<details>
<summary>Devo Categorization And Destination</summary>

Please check the section [Data Sources](https://devodocs.atlassian.net/wiki/spaces/latest/pages/1086586881/Trend+Micro+Deep+Security+collector#Data-sources) to learn about the target tables for each service.
</details>

<details>
<summary>Restart the persistence</summary>

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.
</details>

<details>
<summary>Troubleshooting</summary>

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 |
</details>

## Collector operations

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

<details>
<summary>Verify collector operations</summary>

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:

```log
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:

```log
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.<br>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:<br>- 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.<br>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:<br>- 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. |
</details>

<details>
<summary>Check memory usage</summary>

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

```log
  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
</details>

## Change log

| **Release** | **Released on** | **Release type** | **Details** | **Recommendations** |
| --- | --- | --- | --- | --- |
| `v1.4.0` | 2024-10-25 | [IMPROVEMENT] | **Improvements**<br>- 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**<br>- Updated `DevoCollectorSDK` to `v1.11.1`
- Updated Docker Base image to `v1.2.0`
- Changed the way of executing the controlled stopping | Update |