A network behavior analysis (NBA) system examines network traffic or statistics on network traffic to identify unusual traffic flows, such as distributed denial of service (DDoS) attacks, certain forms of malware (e.g., worms, backdoors), and policy violations (e.g., a client system providing network services to other systems). This section provides a detailed discussion of NBA technologies. First, it covers the major components of the NBA technologies and explains the architectures typically used for deploying the components. It also examines the security capabilities of the technologies in depth, including the methodologies they use to identify suspicious activity. The rest of the section discusses the management capabilities of the technologies, including recommendations for implementation and operation.
Components and Architecture
This section describes the major components of typical NBA solutions and illustrates the most common network architectures for these components. It also provides recommendations for the placement of certain components.
Typical Components
NBA solutions usually have sensors and consoles, with some products also offering management servers (which are sometimes called analyzers). NBA sensors are usually available only as appliances. Some sensors are similar to network-based IDPS sensors in that they sniff packets to monitor network activity on one or a few network segments. Other NBA sensors do not monitor the networks directly, but instead rely on network flow information provided by routers and other networking devices. Flow refers to a particular communication session occurring between hosts. There are many standards for flow data formats, including NetFlow and sFlow. Typical flow data particularly relevant to intrusion detection and prevention includes the following:
* Source and destination IP addresses
* Source and destination TCP or UDP ports or ICMP types and codes
* Number of packets and number of bytes transmitted in the session
* Timestamps for the start and end of the session.
Network Architectures
As with a network-based IDPS, a separate management network or the organization’s standard networks can be used for NBA component communications. If sensors that collect network flow data from other devices are used, the entire NBA solution can be logically separated from the standard networks.
Sensor Locations
In addition to choosing the appropriate network for the components, administrators also need to decide where the sensors should be located. Most NBA sensors can be deployed in passive mode only, using the same connection methods (e.g., network tap, switch spanning port) as network-based IDPSs. Passive sensors that are performing direct network monitoring should be placed so that they can monitor key network locations, such as the divisions between networks, and key network segments, such as demilitarized zone (DMZ) subnets. Inline sensors are typically intended for network perimeter use, so they would be deployed in close proximity to the perimeter firewalls, often between the firewall and the Internet border router to limit incoming attacks that could overwhelm the firewall.
Security Capabilities
NBA products provide a variety of security capabilities, divided into four categories: information gathering, logging, detection, and prevention, respectively. Some NBA products also provide security information and event management (SIEM) capabilities.
Information Gathering Capabilities
NBA technologies offer extensive information gathering capabilities, because knowledge of the characteristics of the organization’s hosts is needed for most of the NBA product’s detection techniques. NBA sensors can automatically create and maintain lists of hosts communicating on the organization’s monitored networks. They can monitor port usage, perform passive fingerprinting, and use other techniques to gather detailed information on the hosts. Most products also allow administrators to specify detailed firewall rule set-like policies for host-to-host communications, including permitted or forbidden port numbers.) Information typically collected for each host includes the following:
* IP address
* Operating system
* What services it is providing, including the IP protocols and TCP and UDP ports it uses to do so other hosts with which it communicates, and what services it uses and which IP protocols and TCP or UDP ports it contacts on each host.
NBA sensors constantly monitor network activity for changes to this information. Additional information on each host’s flows is also collected on an ongoing basis.
Logging Capabilities
NBA technologies typically perform extensive logging of data related to detected events. This data can be used to confirm the validity of alerts, to investigate incidents, and to correlate events between the NBA solution and other logging sources. Data fields commonly logged by NBA software include the following:
* Timestamp (usually date and time)
* Event or alert type
* Rating (e.g., priority, severity, impact, confidence)
* Network, transport, and application layer protocols
* Source and destination IP addresses
* Source and destination TCP or UDP ports, or ICMP types and codes
* Additional packet header fields (e.g., IP time-to-live [TTL])
* Number of bytes and packets sent by the source and destination hosts for the connection
* Prevention action performed (if any).
Some NBA sensors that directly monitor network traffic are able to log limited payload information from packets, such as authenticated user identifiers. This allows actions to be traced to specific user accounts.
Detection Capabilities
NBA technologies typically have the capability to detect several types of malicious activity. Most products use primarily anomaly-based detection, along with some stateful protocol analysis techniques, to analyze network flows. Most NBA technologies offer no signature-based detection capability, other than allowing administrators to manually set up custom filters that are essentially signatures to detect or stop specific threats. This section discusses the following aspects of NBA software detection capabilities:
· Types of events detected
· Detection accuracy
· Tuning and customization
· Technology limitations.
Types of Events Detected
The types of events most commonly detected by NBA sensors include the following:
Denial of service (DoS) attacks: (including distributed denial of service [DDoS] attacks). These attacks typically involve significantly increased bandwidth usage or a much larger number of packets or connections to or from a particular host than usual. By monitoring these characteristics, anomaly detection methods can determine if the observed activity is significantly different than the expected activity. Some NBA sensors are aware of the characteristics of common DoS tools and methods, which can help them to recognize the threats more quickly and prioritize them more accurately.
Scanning: Scanning can be detected by atypical flow patterns at the application layer (e.g., banner grabbing), transport layer (e.g., TCP and UDP port scanning), and network layer (e.g., ICMP scanning).
Worms: Worms spreading among hosts can be detected in more than one way. Some worms propagate quickly and use large amounts of bandwidth. Worms can also be detected because they can cause hosts to communicate with each other that typically do not, and they can also cause hosts to use ports that they normally do not use. Many worms also perform scanning; this can be detected as previously explained.
Unexpected application services: (e.g., tunneled protocols, backdoors, use of forbidden application protocols). These are usually detected through stateful protocol analysis methods, which can determine if the activity within a connection is consistent with the expected application protocol.
Policy violations. Most NBA sensors allow administrators to specify detailed policies, such as which hosts or groups of hosts a particular system may or may not contact, and what types of activity are permissible only during certain hours or days of the week. Most sensors also detect many possible policy violations automatically, such as detecting new hosts or new services running on hosts, which could be unauthorized.
Most NBA sensors can reconstruct a series of observed events to determine the origin of a threat. For example, if worms infect a network, NBA sensors can analyze the worm’s flows and find the host on the organization’s network that first transmitted the worm to other hosts.
Detection Accuracy
Because NBA sensors work primarily by detecting significant deviations from normal behavior, they are most accurate at detecting attacks that generate large amounts of network activity in a short period of time (e.g., DDoS attacks) and attacks that have unusual flow patterns (e.g., worms spreading among hosts). NBA sensors are less accurate at detecting small-scale attacks, particularly if they are conducted slowly and if they do not violate the administrator-set policies (e.g., the attack uses common ports and protocols).
Detection accuracy also varies over time. Because NBA technologies use primarily anomaly-based detection methods, they cannot detect many attacks until they reach a point where their activity is significantly different from what is expected. If a DoS attack starts slowly and increases in volume over time, it is likely to be detected by NBA sensors, but the point during the attack at which the NBA software detects it may vary considerably among NBA products. By configuring sensors to be more sensitive to anomalous activity, alerts will be generated more quickly when attacks occur, but more false positives are also likely to be triggered. Conversely, if sensors are configured to be less sensitive to anomalous activity, there will be fewer false positives, but alerts will be generated more slowly, allowing attacks to occur for longer periods of time.
False positives can also be caused by benign changes in the environment. For example, if a new service is added to a host and a few hosts start using it, an NBA sensor is likely to detect this as anomalous. However, typically this would be a low-priority alert, and not reported as an attack, so it is debatable whether this can truly be considered a false positive. If a major service is moved from one host to another and a thousand hosts start using it one day that might inadvertently trigger an alert.
Tuning and Customization
NBA technologies rely primarily on observing network traffic and developing baselines of expected flows and inventories of host characteristics. NBA products automatically update their baselines on an ongoing basis. As a result, typically there is not much tuning or customization to be done, other than updating firewall ruleset-like policies that are offered by most products. Also, administrators might adjust thresholds periodically (e.g., how much additional bandwidth usage should trigger an alert) to take into account changes to the environment. Thresholds can often be set on a per-host basis or for administrator-defined groups of hosts. Most NBA products also offer whitelist and blacklist capabilities for hosts and services. Another common feature of NBA products is customization of each alert (e.g., specifying which prevention option it should trigger). Unlike network-based IDPSs, code editing features are generally not applicable to NBA products.
A few NBA products offer limited signature-based detection capabilities. The supported signatures tend to be very simple, and primarily look for particular values in certain IP, TCP, UDP, or ICMP header fields. This capability is most helpful for inline NBA sensors because they can use the signatures to find and block attacks that a firewall or router might not be capable of blocking. For example, suppose that there is a DDoS attack that uses a flood of specially crafted HTTP traffic against a Web server. A firewall or router might not be able to block the attack without blocking all HTTP activity to the Web server, but an inline NBA sensor could be configured with a customized signature to block just the attack activity if it has a unique set of characteristics. On the other hand, an inline NBA sensor might be able to block the attack anyway because of its flow patterns.
Besides reviewing tuning and customizations periodically to ensure that they are still accurate, administrators should also ensure that significant changes to hosts, such as new hosts and new services, are reflected in NBA settings. Although it might not feasible to automatically link NBA systems with change management systems, administrators could review change management records regularly and adjust host inventory information in the NBA to prevent false positives.
Technology Limitations
NBA technologies offer strong detection capabilities for certain types of threats, but they also have significant limitations. Some of these limitations are described in Tuning and Customization. An important limitation is the delay in detecting attacks. Some delay is inherent in anomaly detection methods that are based on deviations from a baseline, such as increased bandwidth usage or additional connection attempts. However, NBA technologies often have additional delay caused by their data sources, especially when they rely on flow data from routers and other network devices. This data is often transferred to the NBA system in batches; depending on the product’s capabilities, network capacity, and administrator preferences, this could occur relatively frequently (e.g., every minute, every two minutes) or relatively infrequently (e.g., every 15 minutes, every 30 minutes). Because of this delay, attacks that occur quickly, such as malware infestations and DoS attacks may not be detected until they have already disrupted or damaged systems.
This delay can be avoided by using sensors that do their own packet captures and analysis instead of relying on flow data from other devices. However, performing packet captures and analysis is much more resource-intensive than analyzing flow data. A single sensor can analyze flow data from many networks, or perform direct monitoring (packet captures) itself generally for a few networks at most. Therefore, to do direct monitoring instead of using flow data, organizations might have to purchase more powerful sensors and/or more sensors.
Ron