IPS/IDS – Exploring Networking, Security, and AWS Integrations

NSX Distributed IPS/IDS inspects all traffic inside an SDDC without any dependency on its architecture, which contrasts with traditional IPS/IDS solutions where networking architecture needs to be taken into significant consideration when deploying an IPS/IDS solution.

Security administrators can create a virtual zone in a SDDC using the DFW and IDS/IPS features. IPS/IDS can detect and prevent the lateral movement of attackers who infiltrate data centers, leveraging attack signatures on top of the prevention mechanism of micro-segmentation and implementing a multi-tiered security approach.

Customers with regulatory requirements may also need to implement IPS/IDS to protect data from being stolen or leaked. It is relevant to achieve regulatory compliance with Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Security Standards Council (PCI) or Sarbanes-Oxley Act (SOX) standards.

The IPS/IDS feature leverages signature detection engines to detect and block malicious traffic patterns. Malicious traffic patterns are matched against signatures, and other techniques such as protocol compliance and anomaly detections are leveraged. As attacks and vulnerability exploitations constantly evolve, IDS/IPS stays updated with the latest threat signatures and anomaly detection algorithms to identify malicious activity inside an SDDC.

As with the DFW architecture, the uniqueness of the IPS/IDS capability is its distributed nature. This eliminates the traditional centralized monitoring and enforcement that all traffic must pass through, known as a hairpin, and instead distributes the inspection task to all the vNICs inside an SDDC. Traffic hairpinning is illustrated in the following figure:

Figure 2.30 – The traffic hairpinning problem with centralized IPS/IDS

Distributed IPS/IDS throughput capacity scales linearly as new hosts add additional workloads to the cluster. It enables the complete coverage of all traffic that enters, and hosts don’t need to choose which traffic can be inspected due to architecture or throughput constraints, eliminating blind spots in the data center.

The following figure shows traffic passing between two VMs in an SDDC being inspected through IPS/IDS, without hairpinning:

Figure 2.31 – DFW distributed across all hosts in an SDDC

The IDS/IPS engine has rich context for each guest VM. It can match signatures to account for both the application context and the sensitivity of the protected workload – for instance, prioritizing the domain controller alerts over other workloads and filtering for only attacks relevant to domain controllers. This helps the cloud admin quickly respond to threats and enable policies based on workload sensitivity and context.

Layer 7 (app ID) capabilities enable deep packet inspection across all vNICs within an SDDC, on top of the IPS/IDS capabilities described in the following section.

Leave a Reply

Your email address will not be published. Required fields are marked *