Key Benefits of Correlating Data with STRM in …...and known intrusion detection service (IDS) evasion techniques, as well as suspicious patterns such as multiple failed logins followed

Application Note

Juniper Networks, Inc.1194 North Mathilda AvenueSunnyvale, California 94089 USA408.745.20001.888 JUNIPERwww.juniper.net

Key Benefits of Correlating Data with STRM in Juniper Secure and Assured Networks Juniper Security Threat Response Management Enables Threat and Log Management, Compliance and IT Efficiency

Part Number: 350125-001 Feb 2008

Copyright ©2008, Juniper Networks, Inc.2

Key Benefits of Correlating Data with STRM in Juniper Secure and Assured Networks

Table of ContentsIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Search for Enterprise-Wide Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

The Challenge Posed by Millions of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Keeping Pace with Emerging Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Threats Posed by Insiders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Compliance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

STRM 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

STRM 2500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Description and Deployment Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Centralized Log Collection, Analysis and Reporting Across Juniper’s Security Portfolio . . . . . . . . 5

Deep Juniper Interoperability Combined with Broad Multivendor Support . . . . . . . . . . . . . . . . . 6

Enabling an Enterprise-Wide View of Network Behavior from JFlow . . . . . . . . . . . . . . . . . . . . . . 6

Discrete Juniper Product Events Correlated with Network Behavior and Asset/VA Knowledge . . . 7

Cross-Portfolio Event Correlation that Identifies Complex Enterprise Threats . . . . . . . . . . . . . . . 7

Correlation Scenarios in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Complex Attack Detection: Zero-Day Client Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Log Aggregation and Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Contextual Analysis of Assets and Network Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Compliance and Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Two-Phased Correlation and Analysis of Juniper Security Events: Event Management and Offense

Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Phase 1: Event Management Determines the Severity of the Event . . . . . . . . . . . . . . . . . . . . . 12

Phase 2: Creating and Managing Offenses with the Offense Manager . . . . . . . . . . . . . . . . . . . . 14

Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Deployment Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Summary of Integration Steps (Refer to STRM Admin Guide and Relevant Juniper Device

Guides for Full Deployment Instructions) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

STRM integration with Juniper NSM Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Technical Notes: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

About Juniper Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Copyright ©2008, Juniper Networks, Inc. 3


IntroductionOnce they have deployed the necessary detection and enforcement points in their networks, organizations of any size face the challenge of stepping back from the multitude of individual product views in order to see and maintain their effectiveness in the context of solving enterprise-wide policy and security issues .

The Search for Enterprise-Wide VisibilityAccess control points, VPNs, firewalls, and intrusion protection and protection appliances (IDPs) are critical elements of a defense-in-depth security architecture . Increasingly, so are the routers and other elements of the network that those security devices are ultimately charged with protecting . Thus, the ability to view, analyze and respond to information across this entire infrastructure must be enabled, as the sum of all these products will provide a more meaningful security and policy view than the individual components .

The Challenge Posed by Millions of EventsWith the necessary proliferation of detection and enforcement points in the network, operators are constantly under an avalanche of information produced by any product with logging capability . Events and alerts constitute the critical evidence needed to understand threats across the network, but the Sisyphean task posed is how to effectively collect, analyze and prioritize this evidence when tens of millions of event records stream out daily from devices . Threat data and alarms come in many forms, such as host logs, firewall, IDP, network flow data, and VPN logs or alerts . This creates an enormous challenge for IT staff who must analyze data from a multitude of sources to understand the threats they are facing and determine what actions to take .

Keeping Pace with Emerging ThreatsSecurity will always be a game of changing offense and improving defense . As threats continue to evolve, administrators must improve their network security posture by using multiple defense perspectives to catch the harbingers of attacks that are difficult to accurately detect/prevent through one single technology . While access control initiatives such as unified access control (UAC), coupled with industry-leading signature development and distribution to IDP products, provide critical safeguards against the constant update race, zero-day attacks are still likely to emerge that challenge any defense-in-depth posture . This further emphasizes the need for visibility into all points of the network, regardless of whether or not security devices exist at all of these points .

Threats Posed by InsidersNetwork and security operators have long known that in addition to combating the emerging threats that seek to penetrate their enterprises, they also have to worry about the problem of insider threats . An unhappy employee turned saboteur, an unwitting employee using unsecured devices and applications, an untrained employee taking shortcuts with key corporate data all represent a larger challenge than external threats for some organizations . In addition to firewalls, VPN, UAC and IDP, there is also a need to look at employee, application and device behavior within a network and to connect seemingly disparate security information into a more complete picture of network-wide activity .

Compliance RequirementsOnce the defense posture against internal and external threats has been optimized, the poor administrator still doesn’t get to put his or her feet up . All organizations are increasingly open to scrutiny from internal and external audit groups . The implementation and validation of a company’s compliance with internal policy or external regulation (such as the PCI Standard) is yet another challenge that lands in the lap of the overburdened network and security team . Implementation requires that the correct visibility and alerting capabilities be in place to conform to particular control standards (for example, multiple failed logins to database admin accounts followed by a successful login should be alerted on) . Validation requires that reports to support the existence and effectiveness of the control standards be available at any time, across all relevant technology elements .



With all of these challenges in mind, combining Juniper Networks security and routing products with Juniper’s Security Threat Response Management (STRM) platform provides four essential benefits to network and security operators drowning in these challenges .

1 . Threat Detection—detect events that would otherwise be missed by product or operational silos .

2 . Log Management—respond to the right threats at the right time through the effective management of millions of log files .

3 . Compliance—implement a compliance and policy safety net with comprehensive event storage and reporting .

4 . IT Efficiency—extract IT value that is latent but lost from existing network and security investments .

ScopeThis application note will help Network Operation Center (NOC) administrators, Security Operation Center (SOC) administrators, engineers and compliance auditors understand the value of collecting, correlating and analyzing discrete Juniper Networks security and network infrastructure information in a centralized location .

This document highlights key integrations between the Juniper Networks product portfolio and Juniper’s Security Threat Response Management (STRM) . This document will illustrate how events and alerts from separate products can be efficiently aggregated and analyzed in order to deliver an enterprise-wide threat management view that encompasses both the network and the security operation’s span of control .

This application note covers in detail how events, alerts and flow logs from discrete products are correlated and processed to effectively prioritize and manage large amounts of infrastructure data .

This document does not cover in great detail the specifics of configuring Juniper devices for event correlation or STRM for event analysis and management . It is assumed that the reader will access relevant product manuals and guides for detailed deployment information .

Design ConsiderationsJuniper Networks STRM comes with two models that offer full correlation, collection, analysis and reporting all in one easy to use and management appliances:

STRM 500 Can support up to 500 events per second•

Can support up to 15,000 flows per minute•

STRM 2500Support up to 2500 events per second•

Support up to 100K flows per minute•

(Please review the STRM data sheet for detailed information .)

Deployment of STRM depends on many factors .

The number of events per second•

Flows per minute•

Number hosts and applications•

Number of users•

We will not go into details of each factor in a typical environment, but a minimum of STRM500 needs to be deployed to get the full benefit of STRM .



Figure 1: STRM 2500 typical deployment

Description and Deployment Scenario

Centralized Log Collection, Analysis and Reporting Across Juniper’s Security Portfolio STRM serves as a command and control center for all Juniper security technologies deployed within a customer environment . Events and alerts from the firewall, Secure Access SSL VPN, Integrated Security Gateway (ISG), Secure Services Gateway (SSG), Intrusion Detection and Prevention (IDP), Infranet Controller and NetScreen-Security Manager (NSM) families are aggregated in a single location where they can be viewed and queried . In addition, events from different devices that indicate similar or identical security threats are normalized and categorized in order to enable easier analysis . Examples of STRM categories to which Juniper events from multiple devices are sent include:

Recon• : Events relating to scanning and other techniques used to identify network resources, for example, network or host port scans .

DoS• : Events relating to Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks against services or hosts such as brute force network DoS attacks .

Authentication• : Events relating to authentication controls, group or privilege change such as login or logout .

M-series

E320

WXC590

J2300 Switch

IDPSSG

IC 4000

NS-5400ISG2000

SA 4000

STRM2500

1000 - 2500 eps50K - 100K fpm6 x 250 GB HD

Network DevicesExporting Flow Data

Multi-Vendor SecurityDevices Exporting Logs

STRM Web Console



Access• : Events where a communication or access has occurred such as firewall accept or deny .

Exploit• : Events relating to application exploits and buffer overflow attempts such as buffer overflow or Web application exploits .

Malware• : Events relating to viruses, trojans, backdoor attacks or other forms of hostile software . These may include a virus, trojan, malicious software or spyware .

Suspicious• : The nature of the threat is unknown but behavior is suspicious, including protocol anomalies that potentially indicate evasive techniques . Examples are packet fragmentation and known intrusion detection service (IDS) evasion techniques, as well as suspicious patterns such as multiple failed logins followed by a successful login .

System• : Events related to system changes, software installation or status messages .

Policy• : Events regarding corporate policy violations or misuse .

In addition to using STRM as a centralized dashboard for collecting, analyzing and querying Juniper security events, administrators can create and customize reports that reflect activity across all devices within the Juniper security portfolio . Not only is this a single repository for any kind of operator or executive-level report for security information, it also includes the ability to generate key reports about network behavior, application traffic and network performance .

Deep Juniper Interoperability Combined with Broad Multivendor SupportSTRM has interoperability with Juniper Networks security and networking portfolio:

STRM event collection and correlation capabilities are available for all products within the •Juniper security portfolio including Juniper Networks Unified Access Control 2 .0 .

STRM interoperates with Juniper Networks NSM Profiler in order to prepopulate asset •information and query any IP address from any device against the Profiler database .

∑ STRM leverages Trusted Computing Group’s Trusted Network Connect (TCG-TNC) standards to send remediation recommendations to UAC and the Infranet Controller .

STRM leverages JFlow from the Juniper router family . •

STRM gathers user identity data from multiple Juniper products in order to tie network •offenses to attacker identity .

For details on how STRM processes information from discrete Juniper devices, see Appendix A .

In addition to this deep interoperability with Juniper products, STRM also provides broad support to many other best-of-breed security device types and vendors as well as other flow sources including NetFlow . This enables Juniper network and security devices to smoothly complement the events, alerts and flow information that may come from other areas of an organization’s network .

Enabling an Enterprise-Wide View of Network Behavior from JFlowSTRM surveys the entire network using JFlow sources in a customer’s routing infrastructure to form Layer 3 and Layer 4 analysis of application behavior and a detailed history of all network flow activity . Leveraging JFlow as a source, STRM discovers the rate, volume and nature of network traffic to detect issues that affect service levels, and offers early detection of security threats that would otherwise go unnoticed (such as a mail virus that leverages the corporate Simple Mail Transfer Protocol SMTP server in the middle of the night) . Additionally, STRM QFlow collectors can be connected to the network at strategic points (the network core, perimeter and in front of key server farms) to monitor critical network traffic . STRM analyzes these traffic flows to create a flow record that contains details of the conversation, including a deep packet inspection that identifies the actual application (regardless of port) .

What STRM detects from JFlow also helps to create a picture of the assets that exist within an environment, their vulnerability level and business value . These asset profiles are then used as a contextual correlation source for other incoming Juniper security events .



Discrete Juniper Product Events Correlated with Network Behavior and Asset/VA KnowledgeCollection and normalization of events from multiple security devices and device types are valuable to network and security administrators . Of equal value, however, is the information that STRM provides from discrete Juniper products in terms of contextual correlation . Contextual correlation refers to the capability to prioritize the severity of reported security events against what is known about the existence, vulnerability and business value of targets .

Passive vulnerability information, as well as active vulnerability data from a customer’s vulnerability assessment (VA) scanner (such as Qualys, nCircle, Nessus), can be used in judging the priority of every single Juniper security event regardless of emitting device . This prioritization is not limited to just vulnerability status but also includes the business value or weighting that has been assigned to the asset in question . In a Juniper product environment, these asset profiles can also be prepopulated in STRM with the data that Juniper NSM Profiler may already have gleaned about the hosts that it has observed in the network . Another key area of interoperability between STRM and Juniper products is the ability for any IP within the STRM system to be queried against Juniper’s rich NSM Profiler database (See Appendix C) . Contextual correlation also enables correlation of that security event with network activity before, during and after the event’s firing, which helps to determine the impact of a particular threat .

Example: Events are received from a Juniper IDP indicating a Windows service attack and the target’s asset profile indicates that the targeted port is open and that there is a vulnerability on the machine . STRM performs network flow analysis for five minutes on all flows between the attacker and the target, as well as on other flows being sent out from the target of the attack . The results will help determine the priority of that event as well as any chaining that has taken place between the original target and any hosts it is now attempting to infect .

Through correlation against asset profiles and observed network information, individual Juniper security device events are more accurately and correctly prioritized based on a complete knowledge of the customer’s network environment .

Cross-Portfolio Event Correlation that Identifies Complex Enterprise ThreatsOnce correlation and testing have been conducted on discrete events from Juniper devices, STRM further delivers enterprise-wide prioritization by correlating information across multiple device types and from multiple network segments . If the correlation of discrete product events has helped to prioritize data, then the correlation of multiple device types (firewalls, IDP, VPN, UAC) helps to further prioritize that information and significantly reduce the crush of the millions of events that can be produced in an enterprise .

Example: A single attacker launches a DoS attack within a network and successfully executes a buffer overflow on one of the targets . The exploited host then performs reconnaissance on additional assets in the network and attempts to escalate privilege on a mail server, which ultimately fails . While different security devices (firewall and IDP) will correctly report 6500 events covering four different categories targeting 1200 hosts over a period of one hour, this should be viewed as a single offense against the network .

Hidden in the deluge of events that can come from even moderate deployments of firewalls, VPNs and IDPs on a high-traffic network are the piece parts that constitute a prelude to something much more damaging . Indeed, attacks like this may take many days to evolve . While individual security devices normally do their part in flagging activity peculiar to the segment or traffic they are monitoring, greater visibility is required across all devices incorporating network and security activity, as well as the important contextual elements mentioned earlier that help prioritize the severity and relevance of threats .



STRM accomplishes this important prioritization and data reduction through the creation of offenses, which are a complete record of all security events, network transactions and additional contextual information (derived from correlation tests) observed during an attack . The purpose of offense management across many different types of Juniper devices is to answer the following question: In the context of your business, what threats are the most severe?

Correlation Scenarios in Action

Complex Attack Detection: Zero-Day Client ExploitScenario: A user clicks on a link that leads to a Web site . Embedded in this Web site is new malicious code that installs a backdoor onto the computer . The victim machine makes an Internet Relay Chat (IRC) connection over a non-standard port in order to hide the connection from security devices . Once it connects to the IRC server, it joins a channel and waits for a command to scan certain subnets for open mail servers (port 25) and return the results back to a chat room . Once the results have been returned, the attacker then sends a command to the backdoor telling it to send out mail to those hosts with open mail ports .

The Juniper firewall and IDP are effective at logging firewall accepts, some malformed headers and the scan for mail servers . STRM correlation is required to tie these events together with the missing network behavior analysis that detects IRC on a non-standard channel (botnet) and the victim host that is sending mail .

Figure 2: STRM Offense Summary Screen



Log Aggregation and PrioritizationScenario: Juniper Networks firewalls, IDP and VPN products are deployed within a network and are producing events and alerts based on discrete packet flow and activity that they are observing .

STRM correlation of events from the multiple device types helps to prioritize those 800,000 events into a smaller number of accurate and relevant offenses (11) against the network that needs to be investigated .

Figure 3: STRM Offense Summary Dashboard

Contextual Analysis of Assets and Network BehaviorScenario: An exploit targeting the Apache Chunked Encoding vulnerability is attacking multiple hosts within a network . One host is vulnerable and is exploited, which results in new connections back to the attacker .

The Juniper NSM correctly identifies the Apache Chunked Encoding attack in multiple event messages . STRM correlation is required to tie these events together, and contextual correlation against host and network knowledge shows that not only is one of the hosts vulnerable, it also was exploited .



Figure 4: STRM Annotations on Normalized Juniper Device Events

Compliance and PolicyScenario: An internal user scans for services on port 443 using nmap . Once the user finds an interesting device, one that happens to be governed by a particular compliance regulation, the user tries to connect to it . After a number of failed login attempts, the user is finally successful . Subsequent policy-violating activity includes launching and using peer-to-peer traffic in a bandwidth-sensitive area of the network .

Juniper firewalls and IDP products correctly identify the relevant firewall accepts and network scanning information . STRM correlation ties together the authentication failures followed by success, as well as the discovery of “out of policy” application traffic .



Figure 5: STRM Offense Summary Screen

SummaryThe combination of Juniper Networks product portfolio and Juniper’s Security Threat Response Management (STRM) data collection, normalization and correlation helps customers detect threats they would otherwise miss, respond to the right threats at the right time, implement appropriate compliance and policy controls, and above all maximize the value of their existing Juniper investments .



Appendix A

Two-Phased Correlation and Analysis of Juniper Security Events: Event Management and Offense ManagementSTRM essentially puts the network and security information it receives from Juniper products through two distinct layers of correlation and analysis . The first deals with the management and processing of raw events within the Event Processor . The second deals with the creation and management of offenses within the Offense Manager .

Phase 1: Event Management Determines the Severity of the EventSTRM has thousands of out-of-the-box normalization and correlation rules that it applies as it processes events from Juniper devices . It performs unique correlations depending on the category of the event . The purpose of event processing and management is to answer the following question: “In the context of current network activity and asset posture, how severe is this event?”

Figure 6: STRM Internal Processing of Juniper Security Events and Flows

An Event Processor processes the security events that STRM collects and correlates the information, assigns a category to each Juniper device event, and distributes it to the appropriate Correlation Group for processing . (See page 5 for examples of correlation groups .)

The Correlation Groups perform tests on the events to determine factors such as vulnerability data, relevance of the targets, importance or credibility of the events . For each event category, the Correlation Group determines the correlation rules (tests) that are performed on each event, then performs each test and assigns a value between 0-10 . Once all tests are complete, the test results are weighted and the data for the event appears in the event viewer .

STRM’s network analysis of JFlow from Juniper routers and the resultant knowledge empower many of the correlation tests that are performed within the Event Processor . Correlation tests also leverage asset information that is gathered from Juniper’s NSM Profiler . These tests ensure that events are more accurately and correctly judged based on a complete knowledge of the customer’s network and security infrastructure .

Note: The symbol ‘**’ denotes tests that are uniquely available to STRM through JFlow-enabled contextual network knowledge .

JuniperFirewall

ISG/SSG

Juniper SA Juniper NSM

(Offense Management)

Events

Juniper IDPInfranet

Controller

DB Storage

Routing

DoSRecon AssetPro�les

PassiveNetwork

Knowledge

MalwareExploit

EventsSTRM Event Processor

Authentication

Custom Rule Engine

Network Anomaly Events

Additional NetworkFlow Content

J-Flowand

Pro�lerData



Device credibility: The credibility rating can be applied to each device, allowing users to associate credibility with the device based on the level of trust for the device and the validity of the produced event . For example, a highly tuned Juniper IDP in front of a key server may have a credibility of seven while a newly installed IDP outside the corporate network may have a credibility of three .

Event rate: Determines if the event rate of this event type is greater than normal . This is determined on a category-by-category basis .

**Attacker: Determines if the attacker is one of the configured assets within the network .

**Target: Determines if the target is one of the configured assets within the network .

Source port: Determines if the source port is less than 1024 . If the port is less than 1024, the attacker may be attempting to fool a stateless firewall .

**Attacker age: Determines the relative importance of how long the attacker has been known to the system . If the attacker is new, its relevance increases .

**Target age: Determines the relative importance of how long the target has been known to the system .

**Attacker network: Determines the relative importance of the attacker network .

**Target network: Determines the relative importance of the target network .

Target port: Determines if the target port is included in the list of most attacked ports provided by the incident’s org data .

**Attacker risk: Determines the overall risk assessment value for the attacker based on the asset profile data .

**Target risk: Determines the overall risk assessment value for the target .

Time of the attack: Determines the time of attack . For example, if the attack occurs in the middle of the night, which is deemed to be a low-traffic time, this indicates a higher relevance of the attack .

**Vulnerable targeted port: If the port is open, determines if the targeted port is vulnerable to the current exploit .

Vulnerable port: Determines if the port is vulnerable to any type of attack or exploit .

**Open target port: Determines if the target port is open .

**Remote Target: Determines if the target network is defined as a remote network within STRM .

**Geographic Location: Determines the relative importance of the geographic location of the target .

**Remote attacker: Determines if the attacker network is defined as a remote network in STRM views .

Attacker IP address: Determines if the attacker IP address is included in the list of IP addresses that are highlighted as suspicious

The results of the Correlation Group tests appear as annotations within the offenses and event categories that are viewed from the STRM dashboard . These annotations are a simple description of why groups of events, or offenses, have been escalated or assigned a higher priority than others . Also, STRM applies custom rules to additional events for specific incident recognition . Once it has completed these activities, the Event Processor stores the event in a database and, in some circumstances, performs real-time flow analysis on network traffic associated with that event or target asset .

For example: Events are received indicating a DDoS attack and the target’s asset profile indicates that the targeted port is open . STRM performs network flow analysis (JFlow data) for five minutes on all flows between the attacker and the target, as well as on other flows being sent out from the target of the attack . The Event Processor then delivers event information to the Offense Manager, which creates offenses and subsequently displays them in the STRM console .



Phase 2: Creating and Managing Offenses with the Offense ManagerSTRM’s Offense Manager brings together the security events, asset profiles/vulnerabilities and traffic flows, relating them to policy violations, misuse and threats to your business . It is within the Offense Manager that the true benefits of converging network and security knowledge from Juniper devices can be seen as opposed to more traditional security management technologies .

Offenses bring together events and network flows that may span time or network location . They are a complete record of all security events, network transactions and additional contextual information (derived from correlation tests) observed during an attack .

The magnitude that the JSL assigns to an individual offense is the metric that highlights the most important offenses within the network . Magnitude is a consistent measurement throughout STRM and it is applied to the individual event categories that end up creating an offense . The magnitude, represented on a scale of 0-10, is the result of combining three different criteria: severity, credibility and relevance as they apply to monitored information .

Severity: Indicates the amount of threat an attacker poses in relation to how prepared the target is for the attack . This value is mapped to an event category that is correlated to the offense .

Credibility: Indicates the integrity or validity of an offense as determined by the credibility rating from devices reporting the individual security events . The credibility can increase as multiple sources report the same event .

Relevance: Determines the significance of an event or offense in terms of how the target asset has been valued within the network . For example, attacks against customer databases are more relevant than the same attacks directed against print servers .

An offense is initially created from knowledge of an attacker, a target network (or asset), events and a period of time . Thousands of security and network events (often from different categories) may indicate one offense against a network or asset .

The magnitude of an offense can be modified at any time due to real-time changes observed within the network and also the analysis that is performed on incoming events by the Offense Manager . Using the elements of severity, credibility and relevance, STRM associates the Juniper device events from the processor with an offense and passes them though a number of different Offense Analysis Modules . The results of each module contribute weight to the overall severity, credibility and relevance of the entire offense . As a result, the overall magnitude of the offense either increases or decreases .

The following Offense Analysis Modules are applied to events as they enter STRM’s Judicial System Logic .

Aggregation: The aggregator rolls up events into their designated offenses .

Target Event Analysis: For security events that are targeted at local assets (remote-to-local or local-to-local attacks), this analysis function weighs the number of reported events, the number of targets reported in the events, and the number or relevant targets that actually exist within the network . This weighting contributes to the overall relevance of an attack (for example, if only 20 percent of the reported targets actually exist within the network, the relevance is lowered) . For remote-to-remote or local-to-remote attacks, the number of relevant targets that exists is unknown, so only the number of reported targets and the number of events can be weighted .

Flow Context Analysis: If STRM performs flow context analysis on an event in the Event Processor, this next analysis layer contributes relevance and severity to that output based on the targeted network and the observed change in the target’s communication patterns .

Defense Perspectives Analysis: The number of distinct types of security devices (such as IDPs, ISGs and firewalls) that are being monitored and the number of total instances (two firewalls, two ISGs and one IDP) are weighted in order to contribute a credibility factor to the events that make up an offense .



Figure 7: STRM Offense Processing

Offense Chaining Analysis: STRM analysis links attackers to their targets . This shows how many offenses a particular attacker is part of, as well as how many of the attacker’s targets have now become attackers themselves (such as during worm or virus propagation) . This contributes a relevance factor to the offense .

Custom Rules Engine (CRE) Analysis: If the administrator configures custom rules, this module associates those offense rules to the notification options that exist within STRM .

Offense Description: In this analysis module, low-level event categories (assigned in the Event Processor) are organized according to time sequence and made available as a summary of the offense (for example, Recon followed by DDoS, followed by a buffer overflow on a server) .

Predictive Analysis: This module creates the “threat under” value of an asset and the “threat posed” value of an attacker . Based on 15-minute intervals, the “threat under” calculation is assigned to an asset as a result of the severity, credibility and relevance of events directed toward it . The “threat posed” calculation is based on the severity, credibility and relevance of the offense itself . These values decay over time (every interval that an attacker or target is not seen reduces the value) .

Security and Policy Event Analysis: This analysis module names and annotates“Sentries” from STRM’s network behavioral analysis engine (where security or policy anomalies are detected) .

Offense Annotation: Additional annotations or offense context are added within this final analysis module including:

Rate analysis•

The magnitude of an attacker (which contributes to the attacker’s overall histroy )•

Any modifications or descriptions that are appended to an offense based on the CRE•

Juniper Events from Event Processor

Offense Manager

Offense Manager in STRM Console

Aggregator

Target Event

Flow C

ontext

Defense

Perspectives

Offense C

hain

Custom

Rules

Offense

Describer

PredictiveA

nalysis

Security

and Policy

Offense

Annotation

OFFENSE MAGNITUDE

Credibility

Offense Analysis Modules

RelevanceSeverity



Offenses populate the STRM console and it is from this console view that STRM administrators should derive their understanding and manage their response to issues within the network and security infrastructure . All annotations that occur as a result of the Offense Analysis Modules are appended to the offense and can be read as a simple description of how the offense’s magnitude has been increased or decreased by the passage through each module .

The end result of STRM’s two-phased correlation and analysis of Juniper information means that events are “smartened” based on contextual knowledge gathered from the Profiler about network assets, and from JFlow about network activity . Then these events are intelligently associated with offenses and these offenses are in turn “smartened” by a weighted analysis of all the information they contain . Administrators are therefore presented with information that is more accurate, more concise, better prioritized and more actionable .

Appendix B

Deployment Steps

Summary of Integration Steps (Refer to STRM Admin Guide and Relevant Juniper Device Guides for Full Deployment Instructions)1 . Deploy STRM management appliances within the network .

Ideally the STRM appliances should be located with other key management servers . STRM is •centrally managed by a secure, browser-based interface that supports full role-based access control, well suited for use in an NOC or an SOC .

2 . Direct security log and event data from Juniper security products including firewall, SA, ISG, SSG, Infranet Controller, Juniper NSM and IDP to STRM . Consult your device-specific instructions for syslog export .

3 . Note that STRM will auto-detect event streams from Juniper devices and begin processing events without requiring any configuration at the STRM admin console .

Direct other heterogeneous security logs and events to STRM if applicable .•

4 . Direct NetFlow or J-Flow surveillance data from Juniper routers to STRM management appliance .

Routers will need to be configured to send either a NetFlow Data Export (NDE) or a J-Flow •export to the STRM management appliance . These export sources provide a Layer 4 analysis of traffic with applications being identified from the TCP port .

Direct other NetFlow-compliant devices to STRM if necessary .•

5 . Import pre-existing information about the network assets that already exists within Juniper’s NSM Profiler (see Appendix C for information) .

Appendix C

STRM integration with Juniper NSM ProfilerThe integration between STRM and Juniper Networks NSM allows STRM to take advantage of information that has been collected from across the network through Juniper IDP sensors . Juniper’s NSM Profiler data is integrated into STRM in two ways:

1 . This data contributes to the asset profiles contained inside of STRM, allowing users to view detailed profiles of individual hosts . Users can now view the OS, open port and corresponding service information collected by the Profiler Database inside of STRM on demand or by scheduling future scans . By combining this host data with known vulnerability information collected through vulnerability scanners, STRM is able to greatly reduce the number of false positives and offer greater detail on valid network incidents .

2 . Any IP address within STRM can be directly queried against the relevant NSM Profiler direct from the STRM console . This integration speeds forensic investigation and provides a richer set of information about the asset in question .



Figure 8: STRM Integration with NSM Profiler (Right – Click)

Figure 9: IDP profiler data displayed from STRM

18

Copyright 2008 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

CORPORATE HEADQUARTERS AND SALES HEADQUARTERS FOR NORTH AND SOUTH AMERICAJuniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: 888.JUNIPER (888.586.4737) or 408.745.2000 Fax: 408.745.2100www.juniper.net

EAST COAST OFFICEJuniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886-3146 USA Phone: 978.589.5800 Fax: 978.589.0800

ASIA PACIFIC REGIONAL SALES HEADQUARTERSJuniper Networks (Hong Kong) Ltd. 26/F, Cityplaza One1111 King’s RoadTaikoo Shing, Hong KongPhone: 852.2332.3636 Fax: 852.2574.7803

EUROPE, MIDDLE EAST, AFRICA REGIONAL SALES HEADQUARTERSJuniper Networks (UK) Limited Building 1 Aviator Park Station Road Addlestone Surrey, KT15 2PG, U.K. Phone: 44.(0).1372.385500 Fax: 44.(0).1372.385501

To purchase Juniper Networks solutions, please contact your Juniper Networks sales representative

at 1-866-298-6428 or authorized reseller.


18

Technical Notes:STRM interacts with Juniper Networks NSM through the profilerDb Postgres Database . Data is queried from the corresponding tables to create individual records on a per-port basis for each host . The results are fed into the STRM Asset database and the transfer is complete . STRM queries the following tables: os, host, profile, value and context .

About Juniper NetworksJuniper Networks, Inc . is the leader in high-performance networking . Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network . This fuels high-performance businesses . Additional information can be found at www .juniper .net .

Documents

Key Benefits of Correlating Data with STRM in …...and known intrusion detection service (IDS) evasion techniques, as well as suspicious patterns such as multiple failed logins followed