DEFINED SECURITY POLICY
One of the best presents a manager could give an analyst, besides a workstation with dual
21-inch LCD monitors, is a well-defined security policy for the sites being monitored.1
“Well-defined” means the policy describes the sorts of traffic allowed and/or disallowed
across the organizational boundary. For example, a fairly draconian security policy may
authorize these outbound protocols and destinations:
• Web surfing using HTTP and HTTPS to arbitrary Web servers
• File transfer using FTP to arbitrary FTP servers
• Name resolution using DNS to the site’s DNS servers
• Mail transfer using SMTP and POP3 to the site’s mail servers
• VPN traffic (perhaps using IPSec or SSL) to the site’s VPN concentrators

To meet the organization’s business goals, the security policy would allow these
inbound protocols to these destinations:
• Web surfing using HTTP and HTTPS to the site’s Web servers
• Name resolution to the site’s DNS servers
• Mail transfer using SMTP to the site’s mail servers
Notice that for each item, both the protocol and the system(s) authorized to use that
protocol are specified. These communications should be handled in a stateful manner,
meaning the response to an inbound VPN connection is allowed.
In the context of this security policy, anything other than the specified protocols is
immediately suspect.

In fact, if the policy has been rigorously enforced, the appearance
of any other protocol constitutes an incident. In Chapter 1, I quoted Kevin Mandia and
Chris Prosise to define an incident as any “unlawful, unauthorized, or unacceptable
action that involves a computer system or a computer network.”2 At the very least, the
appearance of a peer-to-peer protocol like Gnutella would be an “unauthorized” event.
Without a defined security policy, analysts must constantly wonder whether observed
protocols are authorized. Analysts have to resolve questions by contacting site administrators.
Once a responsible party validates the use of the protocol, analysts can move on
to the next event. Analysts working without well-defined security policies often define
their own “site profiles” by listing the protocols noted as being acceptable in the past.
Creating and maintaining these lists wastes time better spent detecting intrusions.

PROTECTION
NSM does not include protection as a traditional aspect. NSM is not an active component
of an access control strategy, and the theory does not encompass intrusion prevention
or intrusion protection systems (IPSs). An IPS is an access control device, like a
firewall. An IDS or NSM sensor is an audit or traffic inspection system. The fact that an
access control device makes decisions at OSI model layer 7 (application content) rather
than layer 3 (IP address) or 4 (port) does not justify changing its name from “firewall” to
“IPS.” Any device that impedes or otherwise blocks traffic is an access control device,
regardless of how it makes its decision. The term “IPS” was invented by marketing staff
tired of hearing customers ask, “If you can detect it, why can’t you stop it?” The marketers
replaced the detection “D” in IDS with the more proactive protection “P” and gave birth
to the IPS market.
There’s nothing wrong with devices making access control decisions using layer 7 data.
It’s a natural and necessary evolution as more protocols are tunneled within existing protocols.
Simple Object Access Protocol (SOAP) over HTTP using port 80 TCP is one
example. If application designers restricted themselves to running separate protocols on
separate ports, network-based access control decisions could largely be made using information
from layers 3 and 4. Unfortunately, no amount of engineering is going to put the
multiprotocol genie back into its bottle.
While NSM is not itself a prevention strategy, prevention does help NSM be more
effective. Three protective steps are especially useful: access control (which implements
policy), traffic scrubbing, and proxies.

ACCESS CONTROL
When access control enforces a well-defined security policy, heaven shines on the NSM
analyst. Earlier we looked at the benefits of a security policy that says what should and
should not be seen on an organization’s network. When access control devices enforce
that policy, unauthorized protocols are prevented from entering or leaving an organization’s
network. This strategy allows analysts to focus on the allowed protocols. Instead of
having to watch and interpret hundreds of protocols, analysts can carefully examine a
handful.
If analysts identify a protocol not authorized by the security policy, they know the
access control device has failed. This may be the result of malicious action, but it is more
often caused by misconfigurations. I am personally familiar with several intrusions specifically
caused by accidental removal of access control rules. During the period when
“shields were dropped,” intruders compromised exposed victims.
When NSM works in conjunction with well-defined security policies and appropriately
enforced access control, it offers the purest form of network auditing. Deviations
from policy are easier to identify and resolve. The traffic load on the sensor is decreased if
its field of view is restricted by access control devices. An organization’s bandwidth is
devoted to the protocols that contribute to productivity, not to sharing the latest pirated
movie over a peer-to-peer connection. Intruders have many fewer attack vectors, and
NSM analysts are intently watching those limited channels.