You can integrate the Trellix IVX appliance with a remote syslog server to automatically receive event notifications when a file analysis is complete. This feature allows Security Operations Center (SOC) teams to centralize alerts and streamline threat monitoring within their existing security tools.
By default, IVX sends notifications for malicious and riskware events. To enable this integration, you must configure the syslog server settings on the IVX appliance.
Configure and send event notifications
Before you begin, ensure your system meets the following requirements:
You must have administrative or operator-level credentials for the IVX appliance CLI.
IVX appliance must have an established network connection to your remote syslog server.
Enable the event notification service
You must enable the event notification service on the IVX appliance. This acts as a master switch for sending any type of event notification.
Log in to the appliance and enter the CLI configuration mode.
hostname > enable hostname # configure terminalEnable the notification service. This command must be run only on a broker node. The configuration will then be automatically replicated across all broker nodes in the cluster.
hostname (config)# mvx notify enable
Add and configure rsyslog server
Define your remote rsyslog server as a destination for the event notifications. You must configure all server parameters for notifications to be sent successfully.
Add a new rsyslog server.
hostname (config)# mvx notify rsyslog server <server-name>Example: hostname (config) # mvx notify rsyslog server notifyserver
Specify the IP address or hostname and the port of your remote server.
hostname (config)# mvx notify rsyslog server <server-name> host <ip_address/hostname> port <port_number>Example: hostname (config) # mvx notify rsyslog server notifyserver host 10.12.12.13 port 514
Select concise or normal JSON formats for the notification messages.
json-concise: Contains basic information such as the alert type, ID, malware name, and hostname.json-normal: Contains more detailed information and abstracts without redundant data.
hostname (config)# mvx notify rsyslog server <server-name> format <format>Example: hostname (config)# mvx notify rsyslog server notifyserver format json-concise
Sample output (for Concise format): {"uuid": "3a119a2a-9a0d-4662-8a1e-b316059d4554","type":"dual","verdict":"malicious", "status":"success","name":"highrisk_WL-c8fb766a2b5749d1d22f8e1532565f9b-0.json", "md5":"15eceac6f09bcc8458c7c0916c902252","signature_name":"Malware.Parent.DUAL", "sha256":"370139e97a850e244f482e4cceb8f04b99fc029829094703357e0d9512324d01", "size":74240,"submission_time":"2025-10-27T04:47:53.142191", "complete_time":"2025-10-27T04:50:07.201963","submitter_name":"icap", "compute_node":"ivx167","submission_properties":{"is_sensor_sub":false,"analysis_type":"2","priority":"3"}}Note
If the JSON message size exceeds 8 KB, the JSON structure may appear truncated or broken on the rsyslog server. To prevent this, you must increase the message size to maximum on the rsyslog server.
For a detailed description of all available notification fields, refer to the JSON fields for the event notification table.
Set the transport protocol. You can send notifications using either TCP or UDP.
hostname (config)# mvx notify rsyslog server <server-name> protocol <tcp/udp>Example: hostname (config) # mvx notify rsyslog server notifyserver protocol tcp
Enable the server configuration. After defining the server details, you must enable it to begin sending notifications.
hostname (config)# mvx notify rsyslog server <server-name> enableExample: hostname (config) # mvx notify rsyslog server notifyserver enable
Verify the rsyslog configuration
After configuring your server, you can view the current settings to ensure they are correct.
Run the show mvx notify config command.
Review the output to confirm the notification service is enabled and your rsyslog server details are listed correctly.
Example output:
Notification Status : Enabled Rsyslog Server Configuration: Server Name : notifyserver Status : Enabled Protocol : tcp Host : 10.12.12.13 Port : 514 Format : json-normal
Monitor the MVX notification health status
You can check the operational status of the mvx_notification service using the CLI command. This specifically tracks the delivery status of notifications to your configured TCP remote logging servers.
hostname (config)# show health metadata-streaming Review the output for the MVX notification status:
Healthy: Everything is operating correctly, and notifications are being sent.
Warning: One or more TCP remote syslog servers are not receiving event notifications.
Critical: The mvx_notification service is down or is not sending event notifications to all TCP connected remote logging servers.
Example output:
vx105 (config) # show health metadata-streaming
Health Status:
Last Updated at : 2025-10-03T10:25:00
.
.
.
Service : MVX Notification Status
Health Status : Healthy
Details : HealthyTest the connection to the rsyslog server
To validate that the appliance can successfully connect and send data to your remote server, use the test-fire command. This will send a dummy notification to all configured rsyslog servers.
Note
The UDP protocol is a connectionless communication method, so while the appliance sends the notification, successful end-to-end delivery requires verifying that the remote server is pingable, is configured to accept notifications on the specified port, and that no firewall is blocking the traffic path.
Execute the test command.
hostname (config)# mvx notify test-fireCheck the output for a success or failure message.
Successful connection: UDP 10.128.84.146 -> Sent successfully
Failed connection: TCP 10.128.84.146 -> connect error: Connection refused
Save your configuration
Once you have confirmed that your settings are correct and the connection is successful, save the configuration by executing the write memory command.
hostname (config)# write memory JSON fields for event notification
The following table details the fields included in the JSON notification messages sent to the remote syslog server.
Field | Description |
|---|---|
uuid | Unique identifier for the file submitted for analysis |
type | File Type under analysis (For example, pdf, htm, dll, exe, docx, url) |
Verdict | Analysis result of file/object under analysis. It can be either of Malicious, Riskware or Non Malicious |
Status | Analysis status of a submission: success, queued, static analysis only, submission duplicate |
name | nameSample name, for urls, it is complete url |
md5 | md5sum of submitted file/url |
mitre-mapping | MITRE mapping details given by BALE/yara rules (Covers all MITRE codes flagged for the submission) |
mitre-mapping : name | MITRE code name |
mitre-mapping:id | MITRE sub-technique ID |
mitre-mapping: tactic | MITRE tactic info |
signature_name | Signature name derived by BALE engine from analysis results |
sha256 | sha256 hash of file being analyzed |
size | Size of file in bytes |
submission_time | File Submission time in UTC |
complete_time | Analysis complete time in UTC |
submitter_name | User who submitted the file for analysis |
compute_node | Hostname of IVX which analyzed this file (Helps identify analysis node in a Cluster of IVX) |
sub_properties | Indicates some of the properties selected during submission of file |
sub_properties: analysis_type | Indicates type of submission (1 - Live Mode, 2 - Sandbox Mode) |
extracted_objects | Extracted urls or child objects within a submission, also includes the main submission object in it |
extracted_objects: uuid | Unique identifier for extracted object |
extracted_objects type: | File type of extracted object (For example, pdf, exe, dll, docx, url etc) |
extracted_objects: verdict | Analysis result of extracted file/object. It can be either of Malicious, Riskware or Non Malicious |
extracted_objects: name | Name of file/URL extarcted from main submission file/object |
extracted_objects: md5 | md5 sum of extracted object |
extracted_objects: sha256 | sha256 hash of extracted object |
extracted_objects: size | Size of extracted object/file. Its 0 for extracted URLs |
extarcted_objects: submission_time | Analysis time for extracetd object in UTC |
extracted_objects: complete_time | Analysis completion time for extracted object in UTC |
extracted_objects: anomaly_types | Anomaly types of a submission FEBETA, RISKWARE etc |
extracted_objects: parent_uuid | UUID of file/object from which this file/URL/object is extracted |