In today’s rapidly evolving threat landscape, effective security operations hinge on two critical pillars: automation and context aggregation. As organizations grapple with increasingly sophisticated attacks, the ability to seamlessly integrate diverse security solutions becomes paramount. This challenge is easily resolved through the successful integration of VMware vDefend Advanced Threat Prevention (ATP) with Security Information and Event Management (SIEM) systems.

ATP and SIEM – Better Together

ATP natively supports exporting security-related event logs via the SIEM’s REST API. While syslog is often chosen as the protocol to transmit events due to its nearly universal support, REST API logging allows far more comprehensive data formats, i.e., JSON, enabling ATP to send complex, structured security events with full context. This allows ATP to send the entire spectrum of security events, including both detection (IDS events, network anomalies, file and process analyses) as well as campaigns, which are higher-level detection objects correlated by vDefend Network Detection and Response.

Since each exported detection event is also paired with a link pointing back to ATP, the following showcases how to effectively respond and remediate using Intelligent Assist for VMware vDefend, an interactive chatbot powered by a Large Language Model (LLM) deeply integrated into vDefend user interface. This co-pilot explains detection events in plain English, helping security teams comprehend the full impact of threats while accelerating the remediation process.

As a result, this integration allows ATP data to be seamlessly incorporated into current Security Operations Center (SOC) operations, providing customers with enhanced visibility into East-West network traffic. 

Next, let’s explore the configuration steps, the types of security events exported by ATP, and ultimately, how this combined approach provides security specialists, CISOs, and CTOs with a unified, comprehensive view for enhanced threat detection and response.

Configuration

As detailed in the technical documentation available here, configuring the SIEM integration is a straightforward process that involves adding a new “SIEM Configuration” (located in the “Server Configuration” administration section), which requires specifying the endpoint URL and type (see Figure 1). In some cases, for example, when integrating with the Splunk HTTP Event Collector, it might also be necessary to specify the authorization token, which can be done by adding an Authorization header in the related field.

Figure 1: Configuration dialog to configure SIEM integration

Note that the integration natively supports ARIA Operations for Log as a SIEM server; in that case, the endpoint type should be left to “Default” and the endpoint URL set to the vRLI IP address suffixed with the pathname “/api/v2/event”. In this case, no additional headers are required. However, it is important to notice that the proxy configuration (available in the same “Server Configurations” section) does not apply to the SIEM configuration, meaning that any usage of cloud-based connectors like Exabeam would require Internet connectivity.

In general, ATP supports custom endpoint configurations, making it easy to connect with other leading SIEM solutions such as Microsoft SIEM, ELK stack, SIEMplicity, Splunk, and Google Chronicle. By leveraging custom endpoints and configurable headers, organizations can tailor the integration to their specific SIEM environment, ensuring compatibility and efficient data flow. This flexibility empowers security specialists, CISOs, and CTOs to consolidate security data into a single pane of glass, streamlining operations and improving overall threat detection and response capabilities.

The next section will showcase what security events are exported, and how SOC analysts can best leverage the provided value.

Security Events

ATP exports two primary types of security events to provide comprehensive visibility into your threat landscape: detection events and campaign events. 

Detection Events

Detection events include alerts generated by several vDefend components: Security Intelligence for network anomalies, Malware Prevention System for file and process detections, and IDS/IPS for IDS signature hits. When aggregated by vDefend Network Detection and Response, all these detection events share the same underlying alert schema, and as such, some properties can easily be leveraged to further sift through the logs, pivot through the data, or just build dashboards as well as custom alerting logic.

Table 1 details all the fields included in the JSON document exported via the REST API each time a detection event is generated by ATP.

Table 1: Fields used by a security event representing a detection event (note: examples of opaque types such as hashes or UUIDs are omitted for the sake of clarity).

Besides the usual time attributes (“start_time” and “end_time”), it is possible to filter detection events by “impact”, for instance, by considering only those detection events with HIGH or CRITICAL impact, i.e., with impact values greater than 70. If the integration aims to populate a custom dashboard, a SOC analyst might be designed to group events by MITRE tactic and technique. The fields “mitre_tactic_id” and “mitre_technique_id” can be used to quickly highlight the detection events related to a specific attack phase of the ATT&CK framework.

The field “is_src_target” is something unique to vDefend Network Detection and Response, and it highlights the workload that was affected by a given detection. Consider for example, the case of an attempted CVE exploit: the workload of interest is the destination of the network connection, meaning that in this instance the field “is_src_target” would be set to false. 

The report describes this scenario: an attacker exploited a critical remote code execution vulnerability in Confluence installed on a Windows server. The workload of interest in this case is the Windows server, and the field “is_src_target” would be set to false. A different case is the detection of a workload compromised by malware, which is attempting to establish a C2 channel to an external and malicious server; in this case, the field “is_src_target” is set to true to reflect that the workload “of concern” is the source of the network connection. This scenario can be seen in the report where a Cobalt Strike beacon was executed on a breached workstation. The beacon then connected to IP addresses managed by CloudFlare, which acted as a proxy server between the victim network and the C2 server. In this case, the field “is_src_target” would be set to true. The fields “threat_name” and “url” provide instead a quick and effective ways to extract details about the actual threat; while the former is self-explanatory, the latter allows the SOC analyst to directly open ATP user interface loaded with the details of the detection event.

The field “detection_type” is used to discriminate between all types of detection events. The possible values are:

• IDS for IDS signature hits as detected by the IDS/IPS.
• NETWORK_ANOMALY for NTA anomalies identified by Security Intelligence.
• FILE and FILE_TRANSFER for analyzed files detected either on a workload or on the wire by the Malware Prevention System.
• PROCESS for (potentially file-less) process executions detected on a workload by the Malware Prevention System. 

Detection events of type “IDS” will store inside “ids_signature_id” the signature identifier responsible for the alert. In case of a signature designed to detect a specific CVE exploitation, the CVE ID will also be stored inside the “cve” field. The field “signature_name” will detail the name of the IDS signature, and in case of a custom IDS signature, the field “original_signature_id” provides the identifier of the IDS signature from which the custom IDS signature is derived.

Network anomalies can be found by looking for detection events of type “NETWORK_ANOMALY”. In this context, the field “threat_name” represents the name of the NTA detector responsible for the alert. Given the behavioral nature of the detection, focusing on a specific MITRE tactic and technique is an effective way to quickly identify alerts of interest; for example, to identify attempted data exfiltrations, it is possible to filter network anomalies where the “mitre_tactic_name” is “Exfiltration”. For example, the threat actor in the report described here, used Restic to exfiltrate data from a file server. “mitre_tactic_name” would be set to “Exfiltration” for this step of the campaign.

File detections (detection event type “FILE” and “FILE_TRANSFER”) can either originate from a given workload (because of a new file being created, see “file_action”) or from a given file transfer as intercepted by the Gateway Firewall. In either case, “file_sha1_hash” and “file_sha256_hash” can be quickly used to search for the file artifacts on other external services such as VirusTotal, while “file_magic” and “file_mime_type” allow for filtering by the type of file (“file_mime_type” being much more fine-grained than “file_magic”). This report describes a lateral movement technique with the help of RDP, where a threat actor dropped on disk and executed malware samples, executable network tools, and scripts to steal credentials. In all the cases, hashes of the dropped files will be stored in “file_sha1_hash” and “file_sha256_hash”.

The last type of detection events is the “PROCESS” type. In this context, the aggregated information comprises the execution path of the process (“process_executable_path”) and the command line (“​​process_command_line”); this is essential to focus on specific executables only when used for non standard purposes; for example an analyst might want to filter on those events where the process is PowerShell, i.e., the executable path is “C:\Windows\System32\WindowsPowerShell\v1. 0\powershell.exe” but only when it is used to execute obfuscated commands (the string ‘-EncodedCommand’ is part of the “process_command_line” field). In the attack described here, where Brute Ratel was used for remote access, the threat actor used Brute Ratel to retrieve credentials to access Veeam Backup & Replication (a backup application) via a PowerShell command “powershell -nop -exec bypass -EncodedCommand <base64>” where the Base64-encoded string contained code to download and execute Veeam-Get-Creds.ps1.

In conclusion, regardless of the task at hand, a SOC analyst can effectively surface the desired security events by leveraging the right attributes.

Campaign Events

Campaigns are higher-level detection objects that correlate different detection events together to represent the different steps undertaken by a potential attacker. Each time a new campaign is created (by correlating existing detection events) or updated (by adding new detection events to an existing campaign), ATP emits a new security event of type “CAMPAIGN”. Table 2 lists all the fields that are part of the security event. 

Since campaigns may evolve over time as new detection events are correlated, each security event has a ‘detections_added’ field containing the UUIDs of the detection events newly correlated to the campaign, as identified by the ‘uuid’ field. There is also a possibility that two groups of detection events belonging to two different campaigns might eventually be merged. Consider for example a set of detection events detailing a workload reaching out to an external C2 server, and another set of data exfiltration anomaly events referencing apparently unrelated workloads: these two different activities might be merged by vDefend Network Detection and Response component after Security Intelligence identifies an intermediate lateral propagation event between the two workloads; the field ‘campaigns_merged’ will contain the UUIDs of the campaigns being merged.

Table 2 contains all the fields used by a “CAMPAIGN” security event.

Table 2: Fields used by a security event representing a campaign event (note: examples of opaque types such as hashes or UUIDs are omitted for the sake of clarity).

Response and Remediation

Both campaign and detection events enable SOC analysts to gather more contextual details by opening the link contained in the ‘url’ field, which points back to the ATP user interface. This allows leveraging the whole extent of functionalities provided by ATP, especially for remediating a security incident using bespoke network policies. In particular, Intelligent Assist for VMware vDefend is an interactive chatbot powered by a Large Language Model (LLM) that enables the automatic generation of security policies.

Figure 2 shows a possible conversation between a SOC analyst and Intelligent Assist. Based on the details of the security event (threat type, affected workloads, etc), Intelligent Assist first explains the security event, and then assembles a potential remediation plan. Since any remediation can potentially impact legitimate traffic, Intelligent Assist further asks the risk tolerance for the response, and presents a choice between a targeted or a more comprehensive response. Once a selection is made, based on the type of detection event, Intelligent Assist will propose a selection of Intrusion Detection and Prevention System (IDS) or Distributed Firewall (DFW) policies; the affected workloads will only comprise those detailed in the security event; one last click creates (in disabled state) the proposed policies.

Figure 2: Intelligent Assist for vDefend proposing a security policy to drop (prevent) further detection events matching a specific IDS signature.

Conclusion

The integration of ATP with SIEM solutions provides a unified and comprehensive view of the threat landscape, significantly enhancing an organization’s ability to detect and respond to sophisticated attacks. By leveraging ATP’s rich, contextualized security events, including IDS, network anomalies, file and process analyses, and correlated campaigns, security specialists, CISOs, and CTOs gain unparalleled visibility into both North-South and East-West network traffic.

This is possible through the unique traffic interception capabilities offered by ATP, which can collect traffic from the edge, virtualized workloads, and bare metal endpoints via the NDR sensor. This detailed insight, combined with the power of SIEM for centralized logging and analysis, streamlines security operations and empowers proactive threat hunting.

Ultimately, the seamless integration of ATP with existing SIEM platforms is not merely a technical advantage but a strategic imperative. It addresses the critical need for automation and context aggregation in modern security operations, enabling organizations to move beyond reactive incident response to a more resilient and anticipatory security posture. This combined approach ensures that security teams are equipped with the necessary tools and information to effectively combat the evolving threat landscape, thereby protecting critical assets and maintaining operational continuity.

For more information about ATP and SIEM integration, go here.