Basic Concepts

Table of Contents

3.1. Terminology
3.1.1. Event
3.1.2. Event Count and Volume
3.1.3. Behavior
3.1.4. Tuning
3.1.5. Business group
3.1.6. Problem
3.1.7. Normal and Abnormal Traffic
3.1.8. Score
3.1.9. Sensors and Regions
3.1.10. Applications and Activities
3.1.11. Devices, Interfaces and their Groups
3.1.12. Servers and Clients
3.1.13. Data Streams and Types
3.2. Initial setup
3.3. Ongoing usage and maintenance

3.1. Terminology

nLive introduces certain new terminology and concepts which are explained below.

3.1.1. Event

An Event is a complete transaction such as a TCP connection. It is a report of a communication flow between two hosts. Events are reported by analysis of packets or netflow. In the case of packet analysis, nLive keeps track of the states of the client and server using a state machine. Traffic Events are reported at the completion of the flow, or when timeout, reset etc occurs, or at periodic intervals for long duration flows. In the case of unidirectional netflow, nLive keeps track of the flows in both directions, and creates events by combining them.

3.1.2. Event Count and Volume

Event Count is the number of events that occurred within a specified amount of time. This is like number of connections. There are usually fewer events than packets. Volume is the amount of data transferred. This is like the bandwidth consumed. In the reports, dashboards, and other user interface elements, event count or volume is often used. Event count is particularly useful in observing whether there are frequent connections form a host, such as one infected with a worm. Volume is useful in determining bandwidth utilizations.

3.1.3. Behavior

Behavior is an interpretation of what a host is doing on the network, from the packet flow or netflow perspective. The behavior is usually interpreted by nLive using the statistical nature of traffic in and out of a host.

3.1.4. Tuning

Tuning (or learning) is the process by which a profile of the normalcy of the network traffic is created and stored. Tuning needs the user to pick a time frame based upon which a normal profile has to be established. During tuning, nLive observes traffic and creates its statistical parameters that represent the nature of the normal traffic. These are stored in a profile. After the profile is established, traffic is constantly compared against it to see if it is normal or abnormal.

Tuning can create profiles that are sensitive to time of the day or day of the week (optional). For instance, if a certain hosts has one behavior during the day and another at night, a profile that takes this into account can then determine if the host is behaving abnormally by comparing its behavior to the expected behavior at the same time of the day.

3.1.5. Business group

A business group is a collection of hosts as defined by the user. Each business group can be defined using a set of terms that are separated by commas. Each term in this comma-separated list can take the forms listed below:

	 10.10.2.12	 
	 10.10.2.0/26
	 10.10.2.0/255.255.255.0
	 10.*.2.12
	 10.10.2-4.2
	 10.10.*.0    - 10.10.*.3
	 10.10.*.0/24 - 10.10.*.3/24
	 10.10.*.0/24 - 10.10.*.3/255.255.255.0	 
	 10.10.2-4.0/24
	 192.*.3-8.0/24	 
	 10.9-11.2-4.0/24 
	

Business groups can be used to represent departments, business units, or divisions in a company. They can also be used to group certain kinds of servers or clients in a network. A host can belong to no more than one business group. nLive comes with two special business groups pre-defined: Internal Space and External Space. The group Internal Space is defined at the time of setup of nLive and represents all internal hosts that do not belong to any other business group. Typically all private addresses can belong to Internal Space, which will then be represented by the definition: 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8. The group External Space defines all hosts that are outside of the company network, such as the hosts on the Internet. The business groups are looked up for each host using a priority number. The lowest look up priority is for External Space, and the next is for Internal Space . All other business groups one defines will have a higher priority than these. For instance, if one defines a business group called Accounting to represent the hosts in the accounting department, it will have a higher priority than the Internal Space. All hosts that belong to Accounting cannot belong to any other group but Accounting . Therefore, any internal hosts left over that do not belong to the accounting department will then belong to the group Internal Space (assuming one has not defined any other business group besides Accounting and Internal Space ).

[Caution]Caution

Please note that Internal Space only contains those hosts that do not belong to any other group. Therefore, Internal Space will not encompass all internal hosts in a network, contrary to what its name may suggest.

3.1.6. Problem

nLive Smart and Enterprise editions refer to problem detection. Problems, as defined by nLive are sources of abnormal behavior in the network. They need not always refer to actual problems. The word 'problem' is used in a loosely-defined sense here. Whenever nLive detects that a host's traffic event stream is deviating from the statistical normal behavior for that host (as determined at the time of profiling), nLive creates what is known as a Problem. The Problem can have severity levels 1 through 3, where 1 is the least severe and 3 is the most severe. Problems last for a while, and then they often end when the corresponding hosts' behavior changes.

3.1.7. Normal and Abnormal Traffic

nLive Smart and Enterprise editions can compare the traffic observed against a profile to determine whether the traffic is similar to what is normal. If it is determined to be dissimilar, then that is labeled as abnormal. The standard editions of the product cannot tell abnormal traffic from normal.

3.1.8. Score

nLive Smart and Enterprise editions assign a score to each host in the network based on how abnormal it is behaving. Higher scores indicate higher abnormality. When the scores become very large, it can create a Problem. One can observe scores on the charts in various dashboards and reports.

3.1.9. Sensors and Regions

As previously explained, the nLive Enterprise edition can support multiple sensors. One can also define Regions in it, where each region is simply a collection of one or more sensors. A sensor can belong to more than one region. When reports are made by searching, one can narrow the reporting to certain regions. Regions are provided for convenience of reporting.

3.1.10. Applications and Activities

Applications are defined inside nLive based on the source and destination location (direction of traffic) and the port/protocol combination. Activities are categories of applications. For example, an application called 'Gnutella' is in a category called 'Peer to peer activity'.

3.1.11. Devices, Interfaces and their Groups

nLive Flow can receive netflow from one or more devices, such as routers. Each router has two or more interfaces. The devices and interfaces can be grouped in nLive Flow. Each device (router) can belong to one or more flow device group. However, each interface can only belong to one interface group.

3.1.12. Servers and Clients

The traffic or flow Events in nLive have clients and servers. Each event is assumed to have started by a client which sends the first packets to the server. The server then responds to the client by sending return packets. The direction of the first communication established the client and server. However, under special circumstances such as missing packet information, the correct client and server status are assigned using heuristics.

3.1.13. Data Streams and Types

All traffic, scores, and problems are stored in nLive sensors in various databases. These databases are constantly growing. Therefore, they are called data streams. There is a traffic data type which stores the traffic in aggregate form. This type has several data streams - the basic ones being All Traffic and Abnormal Traffic. The other traffic-type data streams are generated by applying filters to the basic traffic data stream. Then there is a score data type or stream which stores the scores of each host in the network. Finally, there is a problem data stream which stores the problems associated with each host in the network.

For searching through the data streams, one chooses a stream first and then selects the search criteria.

The resolution of storage for each of these streams is five minutes. Traffic is stored in aggregate form only - each event is not stored separately. How long to keep the stored streams is set up through the user interface. For traffic data type alone, the depth of storage, or the number of details of the traffic, is controlled by the user. If too many details are required to store all the conversations of clients and servers, then only the most important ones are stored (as determined by the volume of traffic).

Search Preferences: One can choose the types of reports, graphs, and tables that are obtained while searching or drilling down. This is accomplished by activating the Search Preferences dialog under the Reporting and Search::Search Preferences menu. It is also available under the Search-tab. This is useful when you want more details and sub-tabs in a table than what is provided by default.


Windows Help & PDF formats available hereVigiliti Systems, Inc.