A Network Security Platform (NSP) policy is a set of rules or instructions that define the

malicious activity you want the Sensors to detect and how you want the Sensors to
respond if a malicious activity is detected.

In this module, you will learn about NSP policy basics, such as the definition of a security
policy, policy component, the preconfigured policies that the NSP provides, how policies
work.

Network Security Platform (NSP) provides refining tools for Intrusion Protection System
(IPS) management. These tools bring together exceptions and rule sets for initial
configuration and ongoing management.

You will also learn fundamentals about policy tuning, such its purpose and configuration.
You will also learn about noise, false positives, and the important of monitoring high-
volume attacks.
The Sensor identifies attacks and threats through pattern matching (matching a signature),
anomaly detection (deviation from standard behavior), and statistical and heuristic
algorithms (deviation from defined thresholds and patterned behavior).

NSP goes one step further than detection to perform prevention, as shown in the figure.
The Sensor examines incoming packets. If it identifies a threat, it will respond based on its
configured policy; for example:
• Scrub packets
• Drop or block packets (inline mode only)
• Send an alert (default response)
• Quarantine the infected host
• Send a packet log (copy, of the packet information) to the Manager database
• Reset a TCP connection
• Send an ICMP host unreachable message to the source of UDP or ICMP attacks
In Network Security Platform, all the major features, including IPS, are policy based. For
example, for IDS/IPS, you use IPS policies and recon policies. Similarly, for the Firewall
feature, you use the Firewall policies. This module introduces the security policies in
Network Security Platform, and provides the conceptual details for IPS policies. Other
security policies such as the Firewall policies and Advanced Malware policies will also be
covered in their respective sections.

Generally, a security policy in NSP is a set of rules defining the activity you want the
Sensors to detect and how you want to respond if that activity is detected. The activity that
a rule is to detect doesn’t have to be a malicious one always. For example, you can define a
Firewall rule to always allow all types of traffic from the CEO's laptop. Creating a policy
enables you to define a set of rules that define the different services, protocols, and/or
product implementations in the network.
A policy basically identifies the malicious activity you want to detect on the network and
how you want to respond when this activity is detected.
Instead of having a one size fits all implementation, the creation of policies allows you to
define the environment to protect by the different operating systems, applications, and
protocols in the network.
A security policy, or IPS policy, is a set of rules that governs what traffic is permitted across
the network, and how to respond to misuse of the network. An effective policy is one that is
customized to the network environment being monitored.
Security policies can set rules for protocols (HTTP, UDP), operating systems (NT, Solaris),
and other types of information transmitted across the network. Knowing what types of
traffic cross the different segments will help you determine the types of policies you will
require to efficiently and successfully protect the network against intrusions and misuse.
Creating a policy enables you to define an environment to protect by the different
operating systems (OSs), applications, and protocols in the network. These parameters, or
rules, relate to all of the attacks defended against by NSP.
The best practice for protecting against misuse is not to apply a one-size-fits-all policy to
the entire network, but to create multiple specific policies which focus on the specific
needs of unique segments of the network. NSP enables you to create policies for the
network resources right down to individual sub-flows of network traffic.
The policy determines what traffic analysis the Sensors will perform. NSP provides a
number of policy templates to get customers started toward their ultimate goal: prevent
attacks from damaging the network, and limit the alerts displayed in the Threat Analyzer to
just those which are valid and useful for analysis. The pre-defined IPS policies are provided
as a generic starting point; customers should customize one of
these policies to best suit their needs.

There are two stages to this process: initial policy configuration and policy tuning. Policy
tuning is renowned to be a tedious task. However, because networks and attacks
constantly evolve, the policy tuning process is never truly complete. Instead, you might
equate it to a disk defragmentation; the more often you do it, the less time each check
takes. The ultimate goal of policy tuning is to eliminate false positives and noise and avoid
overwhelming quantities of legitimate, but anticipated alerts.
An IPS policy is one of the many types of security policies used in NSP. A Sensor uses the
assigned IPS policy to determine if the detected traffic is free of attacks according to that
policy. An IPS policy is for detecting exploit attacks, policy violations, and DoS attacks. Also,
the IPS policy determines how a Sensor responds when it detects traffic that violates an
IPS policy.

The main components of an IPS policy are the attack set profiles and the Attack definitions.
An IPS policy is essentially a set of attack definitions for various protocols (HTTP, UDP),
operating systems (Windows, NT, Solaris), and other types of information transmitted
across the network. In addition to other anomalies in the detected traffic, the Sensor also
checks if that traffic matches with what is defined in an attack. If a match is found, that
means the corresponding attack was attempted.

In an IPS policy, an attack set profile for inbound and an attack set profile for outbound is
specified. It can be the same attack set profile for both inbound and outbound or different
ones. The attack set profiles specified in the IPS policy determine the attack definitions to
be included in the IPS policy.
To create and use IPS policies, familiarize yourself with the terminologies discussed here.

Attack Set Profile— The best practice is to create multiple, specific IPS policies that focus
on the specific needs of unique zones in the network, rather than a one-size-fits-all policy
for the entire network. The attack definitions are internally classified based on:
• Whether they are exploits, malwares, policy violation, and so on
• The relevant protocols, such as FTP, HTTP, RADIUS, and so on
• The relevant operating systems
• The applications such as Skype and Google Search that attacks are relevant for
• The chances of attacks being false-positives

In an attack set profile, you can specify the categories of attacks that must be included and
the categories that must be excluded. Then when you specify this attack set profile in the
IPS Policy, the Manager processes the Signature Set and identifies the attack definitions
according to what you specified in the attack set profile. Only these attack definitions are
then included in the IPS policy.

In the Manager, there are several provided attack set profiles which match the
preconfigured policies. Customers can view, clone (copy), and customize these attack set
profiles for their own use.

Continued on the next page

Rules— You specify the categories of attacks to be included and the ones to be excluded in
an attack set profile. To do so, you define rules in an attack set profile. Each rule in a set is
either an include rule or an exclude rule. An include rule which should always start an
attack set profile is a set of parameters that encompasses a broad range of well-known
attacks for detection. An exclude rule removes elements from the include rule to focus the
policy's attack set profile. By broadening (includes) and narrowing (excludes) the rules, you
can enable detection for the attacks that affect the intended environment.
If you have an exclude rule, an include rule added afterward might negate the exclusion.
For example, if you specify an exclude rule for the DNS protocol, then later include multiple
protocols including DNS, the exclusion rule is negated.

Signature Set— This is the complete set of attack definitions developed and provided by
McAfee Labs. The Signature Set enables Network Security Platform to properly detect and
protect against malicious activity. The Manager and the Sensors must be frequently
updated with the latest signatures and software patches made available to you via the
Update Server.

Attack definitions and signatures— Network Security Platform defines an attack as being
comprised of one or more signatures, thresholds, anomaly profiles, or correlation rules,
where each method is used to detect an attempt to exploit a particular vulnerability in a
system. These signatures and checks might contain specific means for identifying a specific
known exploit of the vulnerability, or more generic detection methods that aid in detecting
unknown exploits for the vulnerability. Combined in an attack, the signatures provide for
maximum accuracy and coverage in attack detection.

Custom Attacks— There could be unique security requirements that would not be possible
to be covered in the McAfee-supplied signature set. For such cases, customers have the
option of developing their own attack definitions. Such user-defined attacks are referred to
as custom attack definitions or custom attacks. The Manager factors in the Custom Attacks
as well when it calculates the attack definitions to be included according to an attack set
profile. Custom Attacks are exclusively covered in the McAfee Network Security Platform
Custom Attack Definitions Guide.
The Policy tab, in the Manager, enables you to view, edit, and configure different policies
when the corresponding options are selected. It provides many different pages that bring
together ignore rules and attack set profiles for final customization before deployment.

Using IPS policies, customers can select the exact Exploit and Denial of Service (DoS)
attacks they want to protect against, the types of automatic responses they need to block
current or further impacts, and the methods of notification that will help their teams
respond to malicious use of the network, in the most expeditious time.

In this section we’ll take a look at each page, starting with the Policy Manager.
The Policy Manager is new to the 8.2 release. It gives customers a one stop shop to policy
management.

Here on the Interfaces tab, you have grouped devices listed. There is a row listed for each
and every interface, on each device. And at a glance we can view what IPS policy, what
Advanced Malware, Inspection Options, etc. are assigned to the particular device. Here you
can compare and contrast policies across each interface, and even across devices, very
quickly.

Note that you can use the Quick Search feature to find specific policies, and you can also
filter each column, using the column header.
You can double-click on any policy and change the settings. You can change the settings
and save it, and you can also edit the specific policy or add to it using the + (plus) and
pencil icon buttons, within each policy section. This makes the Policy Manager a very
powerful feature that you can use to create, edit and assign policy much more logically and
faster over the previous releases. You can even bulk edit interfaces and even across
devices! This allows customers to update multiple interfaces when needed, very quickly.
You can also create Policy Groups, where as the name implies you can have a group of
policies. This is very helpful for environment where they tend to place similar policy
combinations to their device deployments. Maybe they use a specific outbound traffic
inspection policy on interface one, for their application server environments, and a
different policy for interface two because that is generally designated for their DMZ
networks, etc.
The IPS Policies page contains attack definitions for signature-based attacks, such as
exploits, policy violations, Denial-of-Service (DoS), and Reconnaissance attacks.
You use the IPS Policies page to manage policies and rule sets. You access the IPS Policies
page by clicking IPS Policies within the Intrusion Prevention folder on the Policy tab.

McAfee supplies preconfigured rule sets and policies for immediate application.
IPS policies can be assigned to an admin domain, an IPS sensor, or one of its interfaces (or
sub-interfaces). The Default Inline IPS policy is applied by default to in-line Sensors when
initialized.

The Default IPS Attack Settings policy lets you manage default settings. If for example, the
customer has an attack definition, that is included in all of their policies, and they want to
disable it, they can open this policy to disable it globally, in whatever policy it may exist.
Modern advanced malware based attacks pose acute security threats to enterprises.
NSP provides several features to detect and prevent the advanced threats prior to
infection. You can also detect post infection by monitoring the bot command and control
server activity. NSP provides visibility across multiple network vectors (host, IP, user, and
so on) and the ability to correlate this information over a period of time. Once a threat is
identified, understanding the root cause and exposure are critical to avoid similar threats in
the future.

The primary functionality of the Advanced Malware Protection feature is to provide a

prioritized list of hosts that need remediation based on a risk score determined on a set of
threat vectors and events correlated over time.

You configure the anti-malware options in an Advanced Malware policy and then assign it
to the required Sensor monitoring resources such as ports, interfaces, and subinterfaces.
A malware policy is a set of rules that scans the traffic across the network, and determines
how to respond to malware detected in the network. An effective policy is customized to
the network environment being monitored.

A McAfee malware policy is a set of rules that define the traffic to be scanned for the
detection of malware and how you want to respond if the malicious activity is detected.
Creating a policy enables you to define an environment to protect by the different
operating systems, applications, and protocols in the network. These parameters, or rules,
relate to all of the attacks defended against by NSP.
A malware policy has various components. The malware policy allows you to select
the Protocols to Scan. You can select the protocol streams which are monitored by the
Sensor according to the configured malware policy. The Sensor can extract files from the
HTTP, FTP, and SMTP traffic for scanning. Various Malware Engines are supported to scan
the selected file types in the network traffic. You can configure one or more supported
engines for a specific file type.

In general, when a user downloads a file, it might either be a file that was downloaded as a
complete file or one that was downloaded as many segments and then reassembled to
form the original file. Files are, at times, split by browsers or download managers to speed
up the download. The Sensor can scan and analyze files that are downloaded as a
complete file or as many segments.
Let’s take a look now at the Inspection Options Policies page. You can create inspection
options policies for configuring traffic inspection, advanced botnet detection, endpoint
reputation analysis, heuristic analysis of web servers and prevention of denial of service on
web servers.
The Inspection Options Policies page gives us the option to have a named policy, for IPS,
malware, etc. Clicking New allows you to create a new policy. Give it a name, and a
description. Click Next and then what you see here on this page can be used to customize
the policies as well as to configure the inspection options at the interface level.

Note that Inbound traffic is traffic received on the port designated as "Outside" (that is,
originating from outside the network) in Inline or Tap mode. Typically, inbound traffic is
destined to the protected network, such as an enterprise intranet. Outbound refers to any
traffic that originated from the internal network. Outbound traffic is that traffic sent by a
system in the intranet, and is on the port designated as "Inside" (that is, originating from
inside the network) in Inline or Tap mode.
Another change in the 8.2 release involves moving the Reconnaissance attacks to the IPS
Policies. The only reason this page shows up is if the environment still has a device added
that is running a version other than 8.2 or greater. In a pure 8.2 environment, this page will
not even exist.

In the past, reconnaissance policies where assigned at the device level. IPS policies where
assigned at the interface level. In 8.2, the Sensor and NSM made a change to be able to
now push out all of those settings on a per-interface basis. So there is no longer that
limitation that we had to assign reconnaissance attacks at the device level. You now get
the benefit of being able to merge them.

If a customer has both 8.1 and 8.2 Sensors, for example, the Reconnaissance Policies page
is there for backwards compatibility. They will still be able to manager their original
policies as before.
Connection Limiting Policies consist of a set of rules that enable the Sensors to limit the
number of connections a host can establish or a connection rate.

The Sensor provides the ability to define threshold values to limit number of connections
(three-way handshakes for TCP) that a host can establish. The number of connections or
the connection rate that is less than or equal to the defined threshold value is allowed,
whereas the same exceeding the value will be dropped. This helps in minimizing
connection-based DoS attacks on the network.

The integration of this technology with McAfee GTI IP Reputation helps to define the
connection limiting rules for traffic to and from external hosts based on reputation and
geographical-location of the external hosts. These defined Connection Limiting policies
can also be assigned at the interface and subinterface levels.

Examples:
• When 100 active HTTP connections are limited from a single source, subsequent
connections are dropped.
• When 500 active overall connections (all TCP and UDP) are limited from a single
source, subsequent connections are dropped.
• When 200 DNS requests per second are limited from a single source, subsequent
connections within this time interval are dropped.
Firewall policies are ordered rules for permitting and denying traffic from reaching a
Sensor's IPS/IDS engine and continuing on through the network. Firewall policies can
maximize a Sensor's detection and prevention capabilities by preventing, that is dropping
or rejecting, specified traffic without requiring full inspection.

In Network Security Platform, a Firewall policy consists of an ordered set of rules that
govern what traffic is allowed to pass to a Sensor's inspection engine and beyond. These
rules also govern which traffic should be denied, that is either dropped from the network
or rejected (TCP traffic only).

To configure the Firewall feature, first create the required rule objects, define the Firewall
policy, and then define the access rules for that policy. After you create the Firewall policy,
you can assign it to the required Sensor resource.

Some of the advantages of using Firewall policies include:

• Visibility to a very granular level. For example, you can identify the users who are trying
to use a blocked application, such as Facebook.
• Enforce different policies based on time. For example, you can allow gaming
applications on weekends but block them during weekdays.
• Control traffic based on geographical locations.
• Control specific phases of an application. For example, you can allow chatting using
Yahoo! Messenger but deny file transfers.
Quality of Service (QoS) Policies help in avoiding traffic congestions, controlling the actual
traffic flow within the permissible limit of the network, and limiting traffic surges in the
network. McAfee Network Security Platform provides three traffic management features —
- Rate Limiting, DiffServ tagging, and IEEE 802.1p (VLAN) tagging.

You create a QoS policy using the QoS rules as the building blocks. Then you need to
assign the policy to the required Sensor ports.
The Exceptions category contains multiple pages. We’ll take a look at each of these,
starting with Ignore Rules.

Ignore Rules are rules that filter attacks/attack responses, based on source IP address,
destination IP address, or both. When Ignore Rules are assigned to an attack definition, that
attack is ignored when seen between the source and destination. No alert is generated and
none of the configured response action is taken.

NOTE: Exception Objects and the Assignments pages are deprecated from this version
release. In a pure 8.2 environment, these pages are not available.
On the File Hash Exceptions page, you can add the MD5 hash values of files to the blacklist
or whitelist and import the resulting fingerprints into NSP. The Sensor scans the specified
file types for any potential malware and compares it with the blacklisted and whitelisted
hashes. If a blacklisted match is found, it enforces a response action.
Sensors can inspect DNS response packets to detect exempted and blacklisted domains.
Domains, which are known to be safe are exempted and the domains known to be
malicious are blacklisted. The exempted domains are referred to as domain name
exceptions or whitelisted domains.

On the Domain Name Exceptions page, customers have the ability to exclude certain
domains from DNS-based analysis for botnet detection. They can include all such domains
in the domain name exceptions list in the Manager. They can also use the domain name
exceptions list to exclude domains blacklisted by the callback detectors.
Using the Global Auto-Acknowledgement feature, you can set up the Manager to
automatically acknowledge alerts based on the severity levels of the corresponding
attacks. Note that the Sensor plays its usual role here. That is, it detects the attack and
sends an alert and the takes the other configured response actions. If you enable this
feature, the Manager automatically acknowledges the alerts for the specified attacks. This
prevents the Real-time Threat Analyzer and Dashboards from being flooded with
information regarding insignificant alerts.
In 8.2, a new page was created for managing the assignment of policies, Intrusion
Prevention > Objects > Policy Groups.

In the Policy Groups page, you can create and manage a group of policies. After creating a
policy group, it is then assigned to the corresponding Sensor interfaces and sub-interfaces
to manage the inbound and outbound traffic.
When creating or editing a policy group, you can select the IPS policy from the drop-down
list, for each individual policy assignment.
Individual policy assignments include:
• IPS : Specifies the type of IPS policy. Example: Default inline IPS.
• Advanced Malware : Specifies the inbound and outbound type of advanced malware
policy.
• Inspection Options : Specifies the type of Inspection Options policy.
• Connection Limiting : Specifies the type of connection limiting policy.
• Firewall : Specifies the type of Firewall policy.
• QoS : Specifies the type of inbound and outbound QoS policy.
Rule Objects are mappings to one or more components related to the network traffic. You
use rule objects to define Firewall, QoS, and Quarantine Zone access rules. As the page
implies, rule objects are the building blocks that enable you to scale the security policies.
Customers can define a mail server object, for example, and use it in multiple policies, and
if the IP address of the mail server ever changes, they can update the object instead of
having to update all the policies themselves.
The Attack Set Profiles, under Objects, was called rule sets in previous versions. These
profiles provide a scalable way to control the attack definitions, that are included in IPS
policies.

Attack Set Profiles enable the use of a powerful tool for defining the exact environment
resources a customer wants to protect. They consist of select attacks that are specific to a
network environment, such as the operating systems employed, the installed applications
(email, chat), and the transport and application protocols (HTTP, FTP) used for data
delivery. Each rule configured narrows the detection focus of the Sensor interfaces, where
the policy is applied.
With the new profiles, there’s no change in functionality per say, but now when you create
a brand new policy; You give it a name, description and then for Policy Direction, can
choose from Ignoring Direction to Consider Direction. And based on that it will ask you to
choose one or two Attack Set Profiles. You can also add and edit profiles right away using
the + (plus) and pencil icon buttons.
To use the Rate Limiting technique for QoS, you need Rate Limiting Profiles. Rate limiting
profiles map the classes defined in QoS policies to the constraints of physical interfaces.
You create the Rate Limiting profiles at the domain level. Then you assign one Rate
Limiting profile for inbound and one for outbound of an inline port pair. You can also
inherit the Rate Limiting profiles from a parent domain.

Creating a Rate Limiting profile involves distributing the throughput capacity of a

monitoring port among 7 classes. Any unallocated bandwidth is automatically assigned to
a hidden class 0. You cannot explicitly assign a bandwidth to class 0. The bandwidth of
class 0 corresponds to the traffic that does not match any of the Rate Limiting rules.
Quarantine zones dictate where endpoints can and cannot go on the network. When you
configure Quarantine at the admin domain and Sensor port level, you need to specify
the Quarantine Zone which must be used to quarantine hosts.

To quickly configure Quarantine, some pre-defined Quarantine Zone are provided. If these
do not meet your requirements, you can clone them and edit them. If not, you can create a
new Quarantine Zone according to your requirements.

NOTE: You cannot edit or delete the pre-defined Quarantine Zone.

Network Security Platform supports capturing data packets on ingress traffic in the
network. When captured, these data packets can be used to perform forensics analysis that
help in identifying network security threats. Analysis of the captured data packets can help
you monitor whether the data communication and network usage of the production
environment complies with the outlined policies of the organization. The captured data
packets can also be used for troubleshooting Sensor issues. Data packets can be captured
in the port mode or file mode.

Packet capture rules tell the device which traffic to capture. Packet capture rule templates
provide a way to define and group multiple capture rules at a time, which makes it easy to
assign the same group of rules to multiple devices. Use this page to manage packet capture
rule templates.
Custom Attack Editor provided in the Manager is the tool that you use to create custom
attacks. Launching the Custom Attack Editor opens a new Java window.
The Custom Attack Editor enables you to create McAfee Custom Attacks as well as in Snort
Custom Attacks. Using this tool, you can also import custom attacks in bulk versus defining
them individually.
Customers that upgraded to NSP version 8.2 can use this utility to update the
reconnaissance attack definitions in their IPS policies, with the same settings from their
deprecated reconnaissance policies.
Network Security Platform validates standard ports used across various protocols using
the signature set. If necessary, you can configure the Sensor can look for non-standard
UPD/TCP ports. You can add more than one non-standard port per protocol.
Network Security Platform gives you the ability to create/clone a policy on a non-
production Manager server, then import the new policy/ignore rule to the production
Manager. Also, you can export custom policies/filters from the Manager to a non-
production machine for editing or other purposes.

• Exporting policies — Export policies from the Manager to your client machine.
• Importing and comparing policies — Import policies to the Manager.
Each policy contains inbound and outbound rule sets and attack definitions.

Rule sets consist of select attack definitions specific to a network environment, such as the
operating system(s) used, the installed applications (email, chat), and the
transport/application protocols (HTTP, FTP) used for data delivery.

Inbound and outbound refer to the direction that traffic is flowing in regards to the
network. Inbound refers to traffic destined for the internal network, and outbound refers to
traffic destined for the external network.

McAfee regularly supplies you with its own attack definitions (signature set) to protect the
network. It also provides ad hoc signatures in case of emergencies and zero-day
vulnerabilities. McAfee's research team develops and tests these signatures thoroughly
before their release.

NSP supports the creation of custom attack definitions for unique situations; for example,
emergencies and for forensic analysis. There are two types of custom attack definitions:
McAfee Format (signature-based) and Imported Snort Rules (rule-based, written using the
Snort rules language).
In a hierarchical manner, you can select from a list of options provided by McAfee for
creating attack definitions:
• Category of attacks (Reconnaissance, Policy Violation, Exploit, Volume DoS)
• Available protocols for an attack category
• Operating system (for example, Mac, AIX, Solaris, Windows)
• Application (for example, aix-ftpd, aix-telnetd, acrobat_reader, and so forth)
• Severity level (informational, low, medium, high
• Benign trigger possibility (probability of false positive)

Together these parameters determine exactly what a Sensor watches for in a network. The
definitions can be grouped into a rules with include and exclude statements, much like an
access control list (ACL). These rules are then grouped in to a rule set. Inbound and
outbound rule sets are then assigned to a policy.

While it sounds like a complicated process, McAfee has created predefined rule sets and
policies for immediate use. Until you become very familiar with the network and
monitoring requirements and need to make alterations, these default rule sets and polices
are available for immediate use.
In the Manager, go to Intrusion Prevention > IPS Policies. Here you can edit or create new
IPS Policies.

McAfee supplies a set of preconfigured policies for immediate application in a number of

different network environments. These policies are "starting points," designed to help
customers get the system up and running quickly. They can use any of the default
scenarios initially, or they can clone and modify these and apply new policies. In fact, the
Default Inline IPS policy, is applied by default, which enables customers to begin
monitoring their network immediately, and actually begin blocking attacks right out of the
box (if deployed in inline mode). As they tune the IPS, they will modify these policies to
best suit their particular environment.

Each preconfigured policy is designed to address the most common attacks targeting
specific network environments. To provide the most efficient attack detection options,
these policies take into account distinct factors such as protocols (HTTP, SMTP), services
(email, FTP, Web), and implementations (Apache, IIS).
The preconfigured policies protect against most common attacks types and also address
networking considerations, such protocols (HTTP, SMTP), services (email, FTP, Web), and
implementations (Apache, IIS). All preconfigured policies except for the All-Inclusive
without Audit and All-Inclusive with audit protect against attacks with a minimum Severity
of 2 (Low) and a maximum Benign Trigger Probability of 4 (Medium). The Severity and
Benign Trigger Probability settings exclude known noisy signatures in an effort to limit
spurious (unnecessary) alerts.
When creating a new policy or editing an existing one, you’re presented with two tabs,
Properties tab and Attack Definitions tab. The Properties tab is to manage the basic
properties such as name, description, DoS response sensitivity, and the attack set profile
for inbound and outbound (or both directions).
The Attack Definitions tab lists the inbound and outbound attack definitions included in
the IPS Policy. An IPS Policy typically contains thousands of attack definitions. So, the
Attack Definitions tab has some useful filtering options to locate attack definitions, that
you may need to edit or disable or enable.

To set the display of attack definitions click on the column header and then select or type
in the Filters options. There are two options to filter the displayed attack definitions: List
based filter and String based filter. List based filter is based on selecting a specific criteria
listed in the column. String based filter is based on the criteria typed in the text field of
the Filters option.
Double-clicking on an attack opens a new attack details panel. You can configure and
update the attack settings either by inheriting the settings from the master IPS policy or set
them explicitly in the attack details panel. The attack details panel has two tabs:
Settings and Description.

On the Settings tab, you can set the configurable fields for Sensor and Manager actions.

The Description tab is a read-only tab where you can view the attack and signature details.

NOTE: Attack Definitions can contain more than one signature.

As previously mentioned, the Policy Manager gives customers a one stop shop to policy
management. You can perform many management tasks on this page, including adding,
editing and assigning policies.

Here on the Interfaces tab, you have grouped devices listed. There is a row listed for each
and every interface, on each device. And at a glance we can view what IPS policy, what
Advanced Malware, Inspection Options, etc. are assigned to the particular device. Here you
can compare and contrast policies across each interface, and even across devices, very
quickly.
After a new Sensor is installed, a policy is inherited from the admin domain and enforced
on all Sensor interfaces. In large deployments or ones that have a significant number of
policies configured in the Manager, it can take a long time to download the signature sets
and apply the policy changes to the Sensors. You define policies at the admin domain level.
This becomes the Baseline Policy. When two or more Sensor interfaces protect similar
types of traffic, you can assign the same baseline policy to each of these interfaces, and
optionally customize specific attack settings per interface, as required. This helps in
minimizing scalability issues, and enhances the overall policies management process in the
Manager. The baseline policy is assigned to the interface and now functions as a starting
point for the local attack settings.

Multi-port Sensors support multiple applied IPS policies for interfaces and subinterfaces.
Meaning that each subinterface created within an interface can have a specific IPS policy
applied. This is particularly useful if the environment has segmented their network traffic
by VLAN tags or CIDR addressing.
On the Devices tab, you can view and edit the policy assignments at the device level.
The Devices tab displays the summary of the device-level assignments.
You can assign different policies to the Sensor interfaces and subinterfaces through the
Policy Manager page, but an alternative method is to assign an IPS policy from the IPS
Policies page itself. This is especially useful when you want to define an IPS policy and
then quickly assign it to Sensor interfaces and subinterfaces.

The Assignments column displays the current assignment count for each policy. It also
links to an assignment page where you can view or change the policy assignments for the
Sensor resources(s).
A visual representation is provided here. You can assign policies to the entire Sensor,
individual ports, or a sub-interface. You control the granularity, based on your
requirements.
• Entire Sensor: All interfaces inherit policies are applied at the Sensor level if the
interfaces do not have their own custom policy or if the interfaces’ custom policy is
deleted.
• Individual Ports (interfaces): It can be useful to define policies at the interface level. In
this instance, you can create policies specific to the traffic on a particular network
segment; for example, using only policies with rules for Windows systems when only
Windows systems are present.
• Sub-Interfaces (Virtual IPS): You can define policies for the sub-flow level using the
sub-interface feature of the Sensor. These sub-interfaces (also called Virtual IPS) can
be based on Classless InterDomain Routing (CIDR) IP addresses or VLANs.
After the policy configuration and assignment is complete, the final step is to deploy the
changes out to the Sensors. You can deploy the configuration changes to all the devices in
the admin domain from the Global tab.

Alert: The device must be active to deploy changes.

Alternatively, you can deploy the configuration changes at a device level. Shown here are
the Device level Deploy Pending Changes page.
Editing an IPS policy lets you make the changes necessary to match the policy with the
traffic being monitored. This includes configuration on the Exploit Attack, the Sensor
Response, Sensor Actions and Logging.
To edit the attacks for an existing policy, complete these steps from the IPS Policies page.
1. Select a policy.
2. Click Edit. This will open the policy, as shown in the image. The Attack Definitions tab
will displayed;

The attack set profiles specified in the IPS policy determine the attack definitions to be
included. You can view/edit a single attack or multiple attacks.
• Double-click on a single attack, and select an option from the Settings panel.
• Select multiple attacks to bulk edit, and then select an option from the Settings panel.
In the Attack Definitions tab, double-click on the row of the attack that you want to
configure and update the settings. The attack details are displayed on the right panel
displaying the settings under the Settings tab. Here is where you can configure the
settings for the attack definitions.

The fields in the Sensor Actions section are not displayed for malware attack definitions
that support advanced malware policies, as these settings are configured in the malware
policy. However, the Manager actions are configurable for such malware attacks.

Fields in the Capture Packets and Manager Actions sections are displayed only when
alerting (Alert field option) is enabled or inherited.
Sensor Actions are responses the Sensor can enact to prevent or deter further attacks. The
most effective of these is Enable Blocking, which is only available when the Sensor is
deployed with inline mode.
In most cases, attack packets reach the intended target before a preventative action can be
enforced. Blocking drops the offending transmission during sensor inspection preventing
the attack from ever arriving at its destination. This option must be enabled in the
Response section of any Exploit or Denial of Service (DoS) attack during policy creation, or
cloning. Use the following options to view and configure Sensor Actions options.
• Block: Enable/Disable Blocking and Smart Blocking.
• Quarantine: Enable Quarantine for All Hosts, Disable, Remediate.
• TCP Reset: Disconnect the Source, Destination, or Both Source & Destination ends of
the transmission.
• ICMP Message: Send ICMP Host Unreachable to Source message for ICMP
transmissions.
• Alert: A message is sent with information pertaining to the attack name, severity,
detected time, and so on.
• Capture Packets: Enable Capturing of the attack and 128 Bytes of Application Data
prior to the attack. It can also be configured to capture packets after (post) the attack.

Logging attack packets for analysis, by an expert, is an effective means of preparing for
future attacks of the same nature.
By default, a Sensor sends alerts to the Manager whenever an attack is detected; however,
you can configure additional actions for selected attacks.

Action options include:

• Syslog
• SNMP
• E-Mail
• Pager
• Script
• Auto-Acknowledge Alert

You do not have to set a Manager action for every attack. With the exception of the alert
sent to the Manager, Intel Security recommends that customers only set notifications for
attacks that warrant their immediate attention.
Every attack detected by McAfee Network Security includes an attack description.
The Description tab provides additional information about an attack. It also displays the
signature descriptions, and reference information.

The Signatures section displays the list of attack signatures.

The primary functionality of the Advanced Malware Policies protection feature is to
provide a prioritized list of hosts that need remediation based on a risk score determined
on a set of threat vectors and events correlated over time.

A McAfee malware policy is a set of rules that define the traffic to be scanned for the
detection of malware and how you want to respond if the malicious activity is detected.
Creating a policy enables you to define an environment to protect by the different
operating systems, applications, and protocols in the network.

You configure the anti-malware options in an Advanced Malware policy and then assign it
to the required Sensor monitoring resources such as ports, interfaces, and subinterfaces.
Each file type is scanned by a Malware engine. Multiple malware engines can be selected to
scan various file types.
The Advanced Botnet Detection framework provides an effective solution to detect and
identify bot infected machines in a network. It takes a two-fold approach to detect bots:
• Correlate multiple different attacks being carried out in different network sessions.
• Use a heuristic based approach that detects behaviors of bots.

The bot-like behavior is usually identified in several phases (each identified by a single
attack ID), such as exploitation and infection, download of dropper files, download of
configuration files, and attack and propagation. Each of the phases is typically carried out
in a single network session.

Advanced botnet detection provides detailed information retrieved from different attack
phases at the end of a successful correlation. This approach allows the framework to
detect both known and 0-day bots.
In a Denial-of-Service (DoS) attack, attackers take advantage of many hosts across the
Internet, which they had previously compromised, to launch a brute-force attack that
starves the target of its essential resources.

The objective of a DoS attack is to deprive organizations access to services or resources. If

a website is hit by a DoS attack, millions of users are denied access to the website. By
preventing authorized and legitimate access, DoS attacks cause aggravation and cost to the
target customer. Distributed Denial-of-Service (DDoS) uses multiple compromised systems
to launch an attack. This amplifies the effect of an attack.

In NSP, DoS attacks are classified into two main categories based on their design.
Volume-based attacks are largely bandwidth attacks. When a DoS attack is launched, it is
detected as a significant change in the statistical composition of the network traffic.
In a flood attack, server or network resources are exhausted by a flood of packets.

The NSP architecture employs a combination of threshold-based, self-learning, profile-

based detection techniques to detect DoS and DDoS attacks.
The threshold method provides administrators with a way to trigger alerts if a
preconfigured traffic volume threshold is exceeded.

You can customize the learning mode for DoS attack definitions using Default IPS Attack
Settings. At the interface and subinterface levels, the DoS attack definitions are inherited
from the IPS policy applied at the Sensor level. This includes the DoS learning attack
definitions as well as the DoS threshold attack definitions.

DoS related alerts are listed in the Alerts page of the Threat Analyzer. DoS related alerts
are either alerts relating to threshold violations or statistical attacks.
Reconnaissance policies enable you to prevent correlation-based attacks. These include
host sweeps, TCP or UDP port scans, email recons, brute force password guessing, and
possibly indexing of public Web servers to find CGI holes or other system vulnerabilities
that might later be exploited. The user interfaces for Reconnaissance policies and the
method of implementing them are to some extent similar to that of IPS policies. Therefore,
familiarize yourself with how to work with IPS policies before proceeding to use
Reconnaissance policies.
Firewall policies are ordered rules for permitting and denying traffic from reaching a
Sensor's IPS/IDS engine and continuing on through the network. Firewall policies can
maximize a Sensor's detection and prevention capabilities by preventing, that is dropping
or rejecting, specified traffic without requiring full inspection.

To configure the Firewall feature, first create the required rule objects, define the Firewall
policy, and then define the access rules for that policy. After you create the Firewall policy,
you can assign it to the required Sensor resource.

You can enforce Firewall policies with the monitoring ports in SPAN, tap, or inline mode.
To tune the NSP deployment, customers should do the following:
• Take advantage of the Sensor's ability to apply multiple policies to multiple interfaces.
Instead of applying a single policy to the entire Sensor, try applying different policies
to dedicated interfaces of the Sensor. You can go a step further and segment the traffic
into Virtual LAN (VLAN) tags or CIDR blocks, create and apply policies to the Sensor's
sub-interfaces.
• Tune the policies. Customers should pick the policy that best matches their needs and
clone the policy (or create a policy from scratch). Then remove any irrelevant attacks,
add any additional attacks, and configure appropriate response actions to respond to
detected attacks.
• Generate reports and view alerts. Look at the data generated by the system to help
further tune the policies, and if necessary, implement more granular monitoring or
delegation of monitoring activities to others.
Security
Speed (Want Maximum IPS performance)
Fuel efficiency (Want to reduce Analyst expenses)
No accidents (Want to harden the policy for maximum protection)
Maintenance (Monitor Constantly)
Scaling
McAfee Network Security Manager (NSM) can handle up to 150 alerts per second.
Each alert is ~650 bytes. If you sustain alerts at that rate, then it equates to a
bandwidth rate of 780 Kbps resulting in 67.392 Gigabytes (GB) of alerts space per
day!
A tuned NSM can now manage more sensors across the organization, and it also
saves precious network bandwidth and storage.
Performance
The bulk of IPS engine resources are consumed in protocol parsing. This entails
doing a deep packet inspection, protocol anomaly detection, parsing protocol
content against respective vulnerability signatures etc. Therefore the greater the
number of unwanted attack signatures that are included, the more bulky the IPS
engine becomes. It also increases the possibility of false positives.
A customized and relevant IPS policy is crucial to providing best protection.
The initial tuning of the NSP is very important in establishing the solution’s credibility and
usability. Though each network environment will have its own characteristics, there are
some best practice steps that will make tuning more efficient and effective.
Setting expectations about tuning is very important. A proper security implementation
includes multiple tuning phases. False positives and excess noise are routine for the first 3
to 4 weeks. Once properly tuned, however, they can be reduced to a rare occurrence.
Attack definitions are written to accommodate many different types of customers.
Therefore, they will not be perfect in every environment. Before you begin, be aware of the
network topology and the hosts in the network, so you can enable the policy to detect the
correct set of attacks for the environment.
There is a difference between evaluation tuning and tuning for the production
environment. An initial reaction is to install the Network Security Platform into the busiest
part of the network and just see what it is detecting. However, you can minimize the need
for tuning by focusing the IPS policy on a hot spot, for example, Web Server attacks. Then,
you determine sources of devices in the network that would be known false positive
offenders–such as SNMP Managers, Vulnerability Scanners, and so forth.
You can further tune by having Wireshark (formerly Ethereal) installed and ready on a
client PC to view captured traffic, if necessary.
There are two phases to policy tuning. One is generally owned by the security architecture
team, and the other by security operations team.
Phase 1
The first phase is relevant from a security design, where you make sure that Sensors are
placed in the appropriate locations and are protecting with correct configured policies. If
there are Linux servers behind a VIPS and you have not enabled the Linux OS attacks in the
policy, then policy is not protecting the Linux servers. Similarly if you have placed the
Sensor with just one VIPS and all default policy, whereas the network behind is far more
diverse, then the Sensor cannot do its job efficiently or effectively. Review the security
architecture before going to second phase.
Phase 2
The second phase is the day-to-day operations of IPS alerts. If you get 100,000 alerts per
day, of course it is going to take the time of the security analysts to review those. And if you
keep getting those repetitively, then there is something you need to review. If those
100,000 are all attacks, then of course you need to block the source of attacks and find a
way to reduce the attack reporting. But if a bulk of those 100,000 are not attacks, then you
need to ensure that they do not show up every day. In our experience, 70% or more of
those repeating alerts can be eliminated, without impacting security and improving the
efficiency of the security operations team.
To better manage the security risks using any IDS/IPS devices, it's very important to
understand the exact meanings of different types of alerts so that appropriate response
can be applied. With Network Security Platform, there are three types of alerts that are
often taken as “false positives”:
With incorrectly-identified events, these alerts typically result from overly aggressive
signature design, special characteristics of the user environment, or system bugs. For
example, typical users will never use nested file folders with a path more than 256
characters long; however, a particular user may push the Windows' free-style naming to the
extreme and create files with path names more than 1024 characters. Issues in this
category are rare. They can be fixed by signature modifications or software bug fixes.
With correctly-identified events, that are subject to interpretation by the usage policy,
the events of this type include those alerting on activities associated with Instant
Messaging (IM), Internet Relay chat (IRC), and Peer to Peer programs (P2P). Some security
policies forbid such traffic; for example, within a corporate common operation
environment (COE); others may allow them to various degrees, such as Universities. Tune
out these events by creating a custom policy with these attacks disabled, or create ignore
rules to suppress the alerts.
Some events are correctly-identified, but are uninteresting to the user. For example, NSP
detects a UDP-based host sweep when a given host sends UDP packets to a certain
number of distinct destinations, within a given time interval. Some users might consider
alerts from this type of event as noise; however, others will take notice because it indicates
possible reconnaissance activity.
False positives tend to result in a high attack count. This is because the traffic creating the
false positive is usually commonplace on the particular network. The approach to
identifying and removing false positives therefore starts with identifying the attacks with
the highest attack counts.
Look for a pattern within each attack. For example, if you see that the attack is originating
from the same group of sources and is taking place at a regular interval, there is a pretty
good chance the alert is a false alarm. If those source hosts happen to be internal, you can
often figure out what service they have in common by having a closer look at a subset of
the group. You can then temporarily shut down services on those hosts until the culprit
service is isolated.
Be sure to leverage the knowledge of someone who is very familiar with the network. He
may recognize a source or destination address as belonging to a host with a special
function.
Also consult attack descriptions for clues; the attack in question might just have a high
Benign Trigger Probability.
If there is no obvious pattern or convincing attack information, take advantage of NSP
options to capture additional packets. Use the capture to analyze the attack yourself. If still
not able to isolate the pattern, save the capture file as part of an evidence report and bring
it to the attention of McAfee Support.
Enterprise HTTP caching servers, DNS servers, and even outbound mail relays, are
susceptible to false positives. These types of hosts are constantly receiving requests from
many different clients and, in turn, making requests to many different hosts to service
those clients. Vulnerability assessment software will also generate false positives as it
scans the network. Check the source and destination addresses within the attack details for
these known internal hosts. If you find such a false positive, use an exception or ACL for
that host.

Once you determine that an alert is indeed a false positive, take measures to “reduce the
noise.” The most secure way is to create an ignore rule for the hosts and attacks in
question.

Vulnerability assessment software will also generate false positives as it scans the network.
Check the source and destination addresses within the attack details for these known
internal hosts. If you find such a false positive, define an exception or ACL for that host.
One of the options in Manager is to create Access Control Lists (ACLs). You can configure
an ACL to process specific traffic without sending it through the IDS engine. So if you have
a need to not process traffic to or from a given host or range of hosts, ACLs make it easy to
do so.
The single most effective way to prevent false positives is to apply a scanning policy that is
specific to the network at hand. It is therefore imperative to understand the details of the
protocols and applications used on the network you aim to protect. For example, if a
sensor port is connected to a network containing only Windows workstations, there is no
reason to use a policy that looks for attacks against UNIX hosts, Web servers, and so on.
Once you have identified the network configuration, use an applicable default policy or
create a custom one.

Also consider virtualization of the IPS to refine scanning by VLAN tag or CIDR address. If a
DMZ contains isolated networks of Web and mail servers, for example, you can prevent
false positives by creating sub-interfaces and applying policies specific to Web and mail
servers, respectively.

The noise-to-incorrect-identification ratio can be fairly high, particularly in the following

conditions:
• The configured policy includes a lot of Informational alerts, or scan alerts which are
based on request activities (such as the All Inclusive policy).
• Deployment links where there is a lot of hostile traffic, such as in front of a firewall.
• Overly coarse traffic VIDS definition that contains very disparate applications, e.g. a
highly aggregated link in dedicated interface mode.
Users can effectively manage the noise level by defining appropriate VIDS and customize
the policy accordingly.
When a particular alert is declared as a false positive, the next decision is whether to
disable the corresponding attack altogether OR apply a particular ignore rule (exception) to
that attack that will disable alerting for a particular IP address or range of IP addresses. In
almost all cases, it is a best practice to implement the latter.

For instance, an SMS server may be generating the alert Netbios: Copy Executable file
attempt during the legitimate transfer of login scripts. Rather than disable the alert
altogether, and cancel the possibility of finding a real attack of this nature, we recommend
creating an Ignore Rule for the SMS server and apply it to the attack.

Every exception created is globally stored, so that the filter can be applied to any Exploit or
Reconnaissance attack.

It is also a best practice to document all tuning activities. The Report section can be used to
assist the documentation process. The IPS Sensor configuration report will deliver reports
that list exceptions that have been applied and attacks that have been otherwise
customized.
The Create Ignore Rule interface, available in the Threat Analyzer, gives you the flexibility
to eliminate alerts that do not actually pose a threat to the network or those that constitute
as noise. You can achieve this by creating and assigning ignore rules to different attack
types in a single interface.

Consider the following scenario: You receive an alert about communication between
specific hosts. When you further analyze the alert, you notice that the attack is valid, but
not between the specific hosts. In this case, you can create and assign an ignore rule object
from the Threat Analyzer which ignores the attack taking place between the two hosts for
the moment.
Over the course of time, you will become very familiar with the Network Security
Platform alert data as you perform forensic analysis using the Threat Analyzer. At some
point, you may even become tired of seeing some of the same alerts time and again.
Network Security Platform provides multiple options for suppressing alerts, that is,
lessening the number of alerts in either the Threat Analyzer and/or database, so that you
can work on higher priority issues. One option, is to disable alerting.

Consider the following scenario:

Many employees in the network are using Yahoo! instant messaging and Facebook chat.
You are receiving numerous alerts due to this activity in the network. However, the
company's corporate policy does not prevent employees from using such applications.
Another method of preventing false positives is to disable attacks; for example, you can
edit the policy to disable all exploit attacks that have a severity level 4 or lower. To do this
you can sort the attacks by severity and attack category. For these attacks, you can change
the State to Disabled.

You should also disable all attacks that are obviously not applicable to the hosts being
protected. For example, if the environment only uses Apache Web servers, they can safely
disable IIS-related attacks.
The large set of alerts can be categorized into three categories.
Valid Alerts: In this case, the alerts are pertinent to the network and taken as attacks. The
impact of the attack may be critical, or moderate, or none. In this scenario, you’ve a
challenge if you see 1000’s of alerts being generated for the same attack, yet analyzing one
alert is same as analyzing all those 1000’s alerts. Then it becomes important how to design
the configuration so that it reduces the number of alerts, without impacting security. Alert
Throttling feature can help in this situation.

Irrelevant Alerts: By default NSP will raise alerts when it detects P2P traffics. Now that may
be relevant for some administrators, and may not be relevant for some. It depends on the
company policy of specific customer. Another scenario is where you see 100’s of UDP
sweeps or probes. NSP, by default, has certain thresholds defined for detecting such
reconnaissance attacks. Those thresholds may need to be changed for the network
scenario. Alternately, a massive set of alerts are being generated from a IT approved
scanner, then you need to white-list the scanner or use granular set of exceptions.

False Positives: These refer to incorrectly identified events by the IPS. An example is a
Vendor signature alerts an attack, where the attack was not there at all. This signifies an
error in vendor signature. This is actually false positive. False Positives are error on part of
a Vendor IPS inspection. In contrast, False negative is when a vendor protection delivered
for an attack is completely missing to detect the attack.
A high-level bottom-up approach to tuning can be summed up, as follows:
1. Access the Threat Analyzer.
2. Identify the noisiest event.
3. Investigate the event and correlate with network resources.
4. Understand the characteristics of the event.
5. Determine the criticality of the event and of the components involved.
6. Decide on an action to remediate/tune the event and commence with Corporate
Governance (CG) and Policy for taking action.
7. Depending on action to be taken, proceed with the proper response procedures.

Repeat the process, as needed.

Analyzing events can be done in two ways, either by starting on the IPS Dashboard and
using the filtering capabilities of the Dashboard or by jumping straight into the Alerts view
and sorting events from there. As shown in the diagram, the dashboard gives a quick
glimpse of attacks over time, top hosts under attack, and allows you to drill down using
various alert properties.
The following screenshot shows alerts sorted by attack name. The view also shows the
alert count and severity. This is a good starting point to point to investigating the relevancy
and applicability of the highest volume alerts.
When editing attack settings, it’s important to understand that Default Attack
Settings customizes the attack definition for all the IPS policies. If you select Local Policy,
the customization applies only to the local IPS policy, that is the customized IPS policy
applied on the corresponding interface or subinterface, if available. If you select Baseline
Policy, the customization applies to the IPS policy that is applied at the admin-domain
level.