Network traffic recommendations

Recommended traffic mix, Sensor placement, and encapsulation guidance for NDR.

Vectra recommends deploying the Vectra platform with special attention to network traffic engineering to realize the most value from features and services available.

What traffic should Vectra Detect see?

Vectra Detect for Network performs best when it sees the right level of network traffic to accurately identify behaviors associated with attack vectors and campaigns. Monitoring end-user compute traffic to the internet, user traffic to the data center and other critical resources, traffic within the data center, and data center traffic to the internet, allows Vectra to detect threat behaviors along multiple phases of the attack lifecycle.

The following protocols are particularly desirable for Vectra’s machine learning models to analyze to ensure Vectra’s full capabilities are far realized:

• Dynamic Host Configuration Protocol (DHCP)

• Internet Control Message Protocol (ICMP)

• Domain Name System (DNS)

• HyperText Transfer Protocol (HTTP)

• Transport Layer Security (TLS)

• Encrypted traffic for behavior analysis

  • See Advice for Encrypted / Decrypted traffic forwarded to Sensors below:

• Remote Desktop Protocol (RDP)

• Traffic from remote management tools

• Server Message Block (SMB)

• Distributed Computing Environment/Remote Procedure Calls (DCE/RPC)

• Windows NT LAN Manager (NTLM)

• Lightweight Directory Access Protocol (LDAP)

• Kerberos

• Session data (full and incremental)

  • Similar to Session state and should include as much as possible (flags, acknowledgements, etc)

• Host-based artifacts: Examples shown in next section. Essentially network artifacts that can provide data for HostID.

What traffic improves Vectra HostID attribution?

Vectra HostID attribution is the product of intelligent analysis over 14 host artifacts to uniquely identify a host with a high degree of confidence. HostID is a vital component of the Vectra platform for machine learning algorithms as well as customer usage. The following traffic and resources help to provide the greatest HostID attribution for detection accuracy and validation:

• NetBIOS

• DHCP

• Kerberos

• Internal DNS

• Reverse DNS

• DHCP logs

• Kerberos logs

• Carbon Black Response integration

• CrowdStrike Falcon integration

• VMware vCenter integration

What traffic should be excluded from analysis?

The following network traffic is insignificant to Vectra and potentially problematic for analysis:

• Multiprotocol Label Switching (MPLS)

• Core routing protocols

• Session Initiation Protocol (SIP)

• High-performance computing (HPC) workloads high in bandwidth

• HPC workloads that are well isolated

• Video multicast

• Storage array network file systems (SMB OK)

• High-bandwidth backup data

Which types of Encapsulation are supported ?

Vectra supports the following encapsulation protocols for traffic analysis:

• IEEE_802.1Q

• Generic Routing Encapsulation (GRE)

• IEEE 802.1ad (known as QinQ)

• Virtual Extensible LAN (VXLAN)

• IPSec Authentication Header (IPSec AH)

• GENEVE (added in v6.15)

Where should Vectra sensors and mixed-mode brains be located?

Physical placement of sensors that capture network traffic will provide for a highly improved deployment and value of the Vectra platform. Vectra sensors and mixed-mode appliances can process normal IP packets as well as some packets with encapsulation. Single layer of encapsulation such as virtual LAN (VLAN), virtual extensible LAN (VXLAN), generic route encapsulation (GRE) and IPSec AH (authentication header) are supported. Vectra appliances will automatically remove these encapsulation headers from incoming packet streams and does not parse the encapsulating header data itself.

Vectra software does not support overlapping IP addresses, MPLS encapsulation or an arbitrary number of encapsulation layers. Vectra sensors can handles double VLAN (QinQ, 802.1ad) and GRE inside of VLAN, but GRE inside of VXLAN will result in dropped packets. Vectra sensors also support packets encapsulated with GENEVE.

Lastly, Vectra sensors should also be placed outside of any demilitarized zones (DMZ) and should capture as much traffic as possible from enterprise DNS and DHCP servers.

Advice for Encrypted / Decrypted traffic forwarded to Sensors

The vast majority of Vectra AI network traffic related detections do not require decryption. For more information, please see our whitepaper "The AI Behind Vectra AI" . The section on page 12 covering Encrypted Command and Control Channels addresses this topic directly, but the entire paper is worth reading. It covers how data science is Vectra's north star and how data science and AI, if used properly, can turn the tables in our fight against cyberattacks and give the advantage to defenders. Give that decryption is not necessary for detection, there are still reasons to decrypt data before being sent to a Vectra Sensor:

• For users of Recall, Stream, Instant Investigation, or Advanced Investigation, the decrypted traffic metadata can be useful.

• If using Vectra Match, decryption can be useful and allow certain rules to fire that would otherwise not fire with only encrypted data.

Guidelines when decrypting traffic to be sent for analysis to Vectra Sensors:

• When you want both encrypted and decrypted traffic to be analyzed by Vectra, this should be done in parallel pipelines.

  • A second Sensor (or as many as are needed for your specific throughput/architecture requirements) should be used that is paired to a different Brain appliance.

  • Vectra supports virtual Sensors, Brains, and Stream appliances and does not charge for their use outside of normal licensing metrics for your environment.

• If you do not use a parallel processing pipeline and send both decrypted and encrypted traffic to the same Sensors / Brain, Vectra's deduplication will see the same 5 tuple traffic in multiple data streams and will discard the duplicate data that arrives last. This would typically be the decrypted data as the decryption process adds overhead on the sending side.