School of NBAD Series: NBAD Relationship Anomaly Detection

School of NBAD Series: NBAD Relationship Anomaly Detection

POSTED BY Charles Herring on 05.20.2014

Part 5: NBAD Relationship Anomaly Detection

In addition to monitoring for anomalies at the host level, NBAD can monitor for anomalous traffic patterns at the relationship level. A relationship consists of two enclaves/host groups of IP addresses. One representing the client and the other representing the server. Additionally, relationships can be constrained to monitor specific services or applications moving from one host group to another. These relationship objects can be used to create baselines/thresholds as well as maintaining counters against them.

Traffic Accumulation Monitoring

One of the most venerable relationship counters is Total Traffic. This is a counter that represents the total amount of data that has moved across the relationship. On a day by day basis, baselines of normal traffic transfers are established. When the aggregate total of traffic across that relationship exceeds established norm, an alarm can be generated. Note the alarm triggered below when the counters for traffic between the Internet and the Web Servers are exceeded.

Counters for traffic between the Internet and the Web Servers are exceeded.

Traffic Rate Monitoring

In addition to monitoring relationships for total traffic, traffic rates (normally in bps) can be baselined and monitored. Note the alarm below when bps between the Web Servers and the Database Servers is excessively high.

Traffic rates can be baselined.

When traffic is excessively high, an alarm is triggered.

Traffic Type Monitoring

Relationships can be configured to observe for changes in traffic profiles. On the relationship below, it is configured to only monitor the traffic that is not categorized as HTTPS. In this scenario, all normal traffic would be categorized in a separate relationship that only monitored the HTTPS traffic and this relationship would monitor for anything else. The traffic threshold for this relationship should be very low.

You can exclude services from monitoring.

In the histogram below, note the change in application traffic. This would trigger an alarm for high traffic rate and high total traffic because the anticipated volumes for both would be near 0.

A change in application traffic can trigger an alarm.

DDoS Monitoring

In the previous installment on NBAD Behavioral analysis, some DDoS algorithms were discussed. In addition to monitoring the attacking and target hosts associated in a DDoS attack, NBAD can reveal problems on the relationship level.

In the alarm below, a threshold for the number of inbound SYN packets was established through baseline. When the counter for the SYN packets was exceeded, an alarm was generated for a “Relationship SYN Flood.”

Excessive inbound SYN packets trigger an alarm.

Wrap Up

Observing specific traffic relationships on the network can reveal data theft, advanced threats and denial of service.

Over the course of the last five installments, we have looked at the history of NBAD and the detection methodologies it employs to provide early detection of advanced and insider threats.

CATEGORIES: