Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Fine-Tuning a Security Policy

    This topic provides a suggested workflow for getting started and fine-tuning a security policy. It includes the following subtopics:

    Fine-Tuning Security Policies Process Overview

    You want to tune a security policy so that it is:

    • Comprehensive—Detects all possible attacks on specific hosts in your network.
    • Optimized—Each attack object specified in an IDP rulebase rule has a performance cost. In general, you want more rules with a few attack objects in each rather than fewer rules with many attack objects. In addition, we recommend that a single rule includes only the attack objects that are applicable to the rule destination server and only those of a severity that concerns you.
    • Precise—Generates few false positives.
    • Maintainable—As you refine your rules, you want to leverage as much of the predefined logic as possible. In your IDP rulebase rules, for example, you want to use the application identification feature, dynamic attack object groups, recommended attack objects, and recommended actions as much as possible, knowing the Juniper Networks Security Center team updates these as needed (even daily).

    Fine-tuning is an iterative process. The process involves the following steps:

    1. Getting Started with the Recommended Security Policy
    2. Refining Rule Matching Properties
    3. Reducing False Positives
    4. Adding Rulebases

    Getting Started with the Recommended Security Policy

    When you add the IDP Series device to the NSM Device Manager, NSM automatically pushes the recommended policy to the IDP Series device. The recommended policy protects destination servers from the most frequent and severe attacks.

    Table 1 summarizes the properties of the Recommended security policy.

    Property

    Value

    Rulebase

    IDP rulebase

    Rules

    Nine rules, distinguished by attack object

    Source

    Any

    Destination

    Any

    Service

    Default, meaning the matching property is based on the service bindings of the attack object specified by the rule

    Attack objects

    Recommended IP, Recommended TCP, Recommended ICMP, Recommended HTTP, Recommended SMTP, Recommended DNS, Recommended FTP, Recommended POP3, Recommended IMAP, Recommended Trojan, Recommended Virus, Recommended Worm

    Note: All of the attack objects included in the predefined policies are client-to-server attacks.

    Action

    Recommended, meaning the action is specified by the attack object

    Notification

    Logging

    Refining Rule Matching Properties

    The source and destination matching parameters for template rules are set to Any. These broad settings provide comprehensive protection, but they entail a performance cost and might result in more logs than are necessary. We recommend you customize these settings.

    Run the Profiler for several days to gather information about the hosts and applications running in your network. After several days, you should have the data you need to complete the following tasks:

    • Create NSM address objects that identify groups of internal servers. When you configure rules to examine client to server traffic, you specify the internal servers as the rule’s destination servers.
    • Create an address object that defines your internal network. When you configure rules to examine traffic from your network to hosts on the world wide web, you can specify the internal network address object as the rule’s source.
    • Create NSM service objects to identify services running on internal servers. In most cases, you can specify Default for service so the rule uses the service relevant to the attack object. However, there might be cases where you want to specify a service object or service group.
    • Identify predefined attack groups related to services (or create your own attack group, if necessary).
    • Refine the IDP rulebase rule set so that each rule is focused on a single destination server (client to server traffic) or service (server to client traffic).

    Reducing False Positives

    A false positive is a log record that reflects an event on your network that you are not concerned about and no longer want to see in your logs. The IDP security policy found traffic that matched your rule, but over time you realize you do not need to track such events.

    To determine whether a log is a false positive, you need to understand why the IDP Series device triggered the log and whether or not the traffic poses a real risk to the target server.

    Suppose your security policy rule includes the following attack object: Predefined :: HTTP: Windows Media Services NSIISlog.DLL Buffer Overflow. It generates a log when it identifies the attack pattern in traffic through the IDP Series device. Use the reference information in the details pane below the log table to learn more about the attack. You can click the hypertext linked name of the attack object in the summary tab to display reference information for the attack, as shown in Figure 1.

    Figure 1: Using NSM Log Viewer Attack Reference Information

    Image s036755.gif

    In this example, we learn that the threat detected applies only to Microsoft Windows 2000 Server SP4. It is a false positive because all of the Windows servers in our network are Windows Server 2008. You can use the NSM Log Viewer flag and comment features to mark logs as false positives. In Figure 2, we have marked the log ID 20090806/416967 as a false positive because the attack targets server versions not present in our network.

    Figure 2: Using NSM Log Viewer Flag and Comment Features

    Image s036753.gif

    There are a number of ways you can tune your security policy to reduce false positives. Table 2 summarizes some basic tunings.

    Table 2: Actions to Take To Reduce False Positives

    Type of False Positive

    Tuning Required

    You trust the source.

    Add an Exempt rulebase rule to “whitelist” the trusted source.

    The attack applies to a hardware or software version that does not match your destination server.

    You have many options:

    • Delete the attack from the rule.
    • Modify an attack group to exclude the object.
    • Add an Exempt rulebase rule to whitelist the non-offending attack object.
    • Modify rule action so traffic is stopped or permitted differently from before.
    • Modify the rule severity so that you can filter these events differently from before.

    Your team has already patched the vulnerability detected by the attack.

    Same as previous.

    Upon examination, benign traffic crosses thresholds that trigger protocol anomaly events.

    Use the NSM Device Manager to modify protocol anomaly thresholds.

    Adding Rulebases

    The IDP rulebase is the primary rulebase in an IDP security policy. When you have sufficiently tuned your IDP rulebase rules so that the security policy generates the level of logs you want, you can add additional rulebases to enable additional detection methods.

    Take the same approach to tuning these additional rulebases. Instead of refining the group of attack objects that are relevant, you tune the IDP runtime parameters that set thresholds for detection mechanisms.


    Published: 2011-02-08