Normal traffic is anything that is expected to belong on an organization’s network.
HTTP, FTP, SMTP, POP3, DNS, and IPsec or SSL would be normal traffic for many
enterprises. Suspicious traffic appears odd at first glance but causes no damage to corporate
assets. While a new peer-to-peer protocol may be unwelcome, its presence does not
directly threaten to compromise the local Web or DNS server. An example of this sort of
traffic appears below and in a case study in Chapter 14. Malicious traffic is anything that
could negatively impact an organization’s security posture. Attacks of all sorts fit into the
malicious category and are considered incidents.
To fully appreciate the three classes of traffic, let’s take a look at a simple mini case
study. While writing this chapter I received the following alert in my Sguil console. (Sguil
is an open source interface to NSM data described in Chapter 10.)
The two elements of the signature that do the real work are shown in bold. The M
means Snort watches to see if the More fragments bit is set in the IP header of the packet.
The 25 means Snort checks to see if the “Data” or packet payload is fewer than 25 bytes.18
Fragments are an issue for IDSs because some products do not properly reassemble them.
There’s nothing inherently evil about fragmentation; it is IP’s way of accommodating
protocols that send large packets over links with smaller MTUs.
Let’s use ICMP as an example of a protocol than can send normal or fragmented traffic.
First take a look at normal ICMP traffic, such as might be issued with the ping command.
The –c switch says send a single ping.19
Analysts using NSM tools and tactics have the data they need to validate
events. Validation in NSM terms means assigning an event into one of several categories.
NSM practitioners generally recognize seven incident categories developed by the Air
Force in the mid-1990s. The Sguil project adopted these categories and defines them as
• Category I: Unauthorized Root/Admin Access
A Category I event occurs when an unauthorized party gains root or administrator control
of a target. Unauthorized parties are human adversaries, both unstructured and
structured threats. On UNIX-like systems, the root account is the “super-user,” generally
capable of taking any action desired by the unauthorized party. (Note that so-called
Trusted operating systems, like Sun Microsystem’s Trusted Solaris, divide the powers of
the root account among various operators. Compromise of any one of these accounts
on a Trusted operating system constitutes a Category I incident.) On Windows systems,
the administrator has nearly complete control of the computer, although some powers
remain with the SYSTEM account used internally by the operating system itself. (Compromise
of the SYSTEM account is considered a Category I event as well.) Category I incidents
are potentially the most damaging type of event.
• Category II: Unauthorized User Access
A Category II event occurs when an unauthorized party gains control of any nonroot
or nonadministrator account on a client computer. User accounts include those held by
people as well as applications. For example, services may be configured to run or interact
with various nonroot or nonadministrator accounts, such as apache for the Apache
Web server or IUSR_machinename for Microsoft’s IIS Web server. Category II incidents
are treated as though they will quickly escalate to Category I events. Skilled attackers
will elevate their privileges once they acquire user status on the victim machine.
• Category III: Attempted Unauthorized Access
A Category III event occurs when an unauthorized party attempts to gain root/administrator
or user-level access on a client computer. The exploitation attempt fails for one
of several reasons. First, the target may be properly patched to reject the attack. Second,
the attacker may find a vulnerable machine but may not be sufficiently skilled to execute
the attack. Third, the target may be vulnerable to the attack, but its configuration prevents
compromise. (For example, an IIS Web server may be vulnerable to an exploit
employed by a worm, but the default locations of critical files have been altered.)
• Category IV: Successful Denial-of-Service Attack
A Category IV event occurs when an adversary takes damaging action against the
resources or processes of a target machine or network. Denial-of-service attacks may
consume CPU cycles, bandwidth, hard drive space, user’s time, and many other
• Category V: Poor Security Practice or Policy Violation
A Category V event occurs when the NSM operation detects a condition that exposes
the client to unnecessary risk of exploitation. For example, should an analyst discover
that a client domain name system server allows zone transfers to all Internet users, he
or she will report the incident as a Category V event. (Zone transfers provide complete
information on the host names and IP addresses of client machines.) Violation of a client’s
security policy also constitutes a Category V incident. Should a client forbid the
use of peer-to-peer file-sharing applications, detections of Napster or Gnutella traffic
will be reported as Category V events.
• Category VI: Reconnaissance/Probes/Scans
A Category VI event occurs when an adversary attempts to learn about a target system
or network, with the presumed intent to later compromise that system or network.
Reconnaissance events include port scans, enumeration of NetBIOS shares on Windows
systems, inquiries concerning the version of applications on servers, unauthorized
zone transfers, and similar activity. Category VI activity also includes limited
attempts to guess user names and passwords. Sustained, intense guessing of user names
and passwords would be considered Category III events if unsuccessful.
• Category VII: Virus Infection
A Category VII event occurs when a client system becomes infected by a virus or worm.
Be aware of the difference between a virus and a worm. Viruses depend on one or both
of the following conditions: (1) human interaction is required to propagate the virus,
and (2) the virus must attach itself to a host file, such as an e-mail message, Word document,
or Web page. Worms, on the other hand, are capable of propagating themselves
without human interaction or host files. The discriminator for classifying a Category VII
event is the lack of human interaction with the target. Compromise via automated code
is a Category VII event, while compromise by a human threat is a Category I or II event.
If the nature of the compromise cannot be identified, use a Category I or II designation.
These categories are indicators of malicious activity, although classifying an event as a
Category I or II incident generally requires a high degree of confidence in the event data.
Typically the process of identification, validation, and escalation of high-impact events is
done in an integrated fashion. Analysts watching well-protected sites encounter few Category
I or II events, so these events often stand out like a sore thumb against the sea of
everyday Category III and VI events.
Formal definitions of indications and warnings tend to break down when the model
involves recognition of actual compromise. The definitions here are based on military
indications and warning (I&W) concepts. The military’s I&W model is based on identifying
activity and deploying countermeasures prior to the enemy’s launch of a physical,
violent attack. If this physical attack, involving aircraft firing missiles or terrorists exploding
bombs, is compared to an intrusion, there’s no need to talk in terms of indications or
warnings. Once shells start flying, there’s no doubt as to the enemy’s intentions.
For NSM, it’s a fuzzier concept. If an analyst discovers an intrusion, one stage of the
game is over. Talk of indications and warnings seems “overcome by events.” The victim is
compromised; what more is there to do or say? However, it’s crucial to recognize there’s
no “blinking red light” in NSM. Even when analysts possess concrete evidence of compromise,
it may not be what they think.
Thus far each step has been a thought exercise for the analyst. The sensor transforms
all traffic into a subset of observed traffic. Analysts access that traffic or are provided
alerts based on it. They perform identification by judging traffic as normal, suspicious, or
malicious. At the point where they are ready to physically classify an event, they must
have a mechanism for validating the information presented by their NSM console.
Sguil (see Chapter 10) provides the following open source example of validating an
event. Look at the process of validating an event in Sguil. First, the analyst reviews alerts
and observed traffic information on her console (see Figure 11.13).
All of the alerts in this Sguil console are unvalidated. The “ST” column at the far left of
each of the top three panes reads “RT,” which means “real time.” The highlighted alert
shows an “MS-SQL Worm propagation attempt.” This is the result of the SQL Slammer