# Presentation: 483728

## Moving from Detection to PreventionNext-Generation Network Intrusion Prevention Solution

**Dave Marcus, Technical Security Evangelist (Philosopher/Geek)**

## Key points of the attacks during 2003

- The volume of outbreaks double for the year
- Worms are the common form of attack
- Single attacks are the exception, blended attacks are the now the standard
- Attacks commonly use both AV and hacker techniques
- Piggy backing previous attacks

## Key points of the attacks in 2004, so far...

- The volume of outbreaks looks to be quadrupling
- 2003 – attack every 22 3⁄4 days on average
- 2004 Q1 – attack every 4 1⁄2 days on average
- Email still the prime choice for attacks
- Users are the common method to breach security
- Updatable/controllable attacks are becoming common
- Authors are testing their attacks against security products
- Attacks commonly disabling security products
- We started to see this pioneered in 2003

## Q1 2003 vs. Q1 2004

## The need for a change in strategy 

**With:**
- The time for attacks to spread globally decreasing
- The volume of attacks “in the wild” is increasing
**Because of:**
- Virtually all attacks use multiple penetration methods
- Attacker utilise human or security weaknesses
- Hacking techniques (data theft, backdoors) are common and becoming far more sponsored. Targeted DoS/DDoS on the rise
**We need:**
- Need for more than just reactive technologies to remediate the consequences of the attack
- Focus on Prevention to lessen the financial effects of intrusions

## What is an Attack?

- “Attack” can mean different things to different people
- External penetration attempt with malicious intent
- Reconnaissance
- Unintentional event
- Network abuse and misuse
- Insider threat

**Notes:**
Attacks come from many places; internal, external, malicious or accidental in nature.  However you define an attack, you need a variety of methods to detect it.

## Anatomy of a Hack*

**Anatomy of a Hack***

**** *****Source:***** Hacking Exposed by George Kurtz, Stuart McClure & Joel Scambray***

## General Approaches

- Signature Based
- Capture the direct *manifestation* of attacks in *signatures*
- Effective for known attacks
- Anomaly Based
- Capture the *normal behavior* (direct or indirect) of the protected system in *profiles *and alarm for deviations
- Potential for detecting unknown attacks
- Profiles can be static or learning
- Multiple learning disciplines possible

**Notes:**
The two primary methods most widely used today are signature and anomaly based detection.  Signature detection matches known patterns and content in network traffic to definition files known as signatures much the same as virus scanning software.  Anomaly detection looks for deviations from the defined norm in traffic patterns, traffic types, protocol usage etc.

## Signature Based Detection

- Pros
- Quick detection
- Specificity advantage
- Cons
- Inability to detect new or variations of attacks

**A good signature based system MUST:**
- Have complete visibility to attack traffic/events
- Full de-fragmentation and reassembly of datagrams & streams
- Multiple level of detection contexts with correlation
- Wire-speed operation
- Parse application protocols as deep as required
- Normalize (scrub) traffic to remove ambiguity of interpretation

**Notes:**
Signatures can offer very specific detection of known threats by comparing network traffic to the threat database.  This process can be enhanced if traffic normalization techniques are employed to simulate the traffic as the end node would.  Attack obfuscation can quickly defeat signature based systems without this normalization.  Signature engines tend to degrade in performance as more and more definitions are added to the database.  This is a bad thing as sig databases always grow and never shrink necessitating the need for a robust platform that will accommodate today’s as well as tomorrow’s signatures.

## Signature Based Detection Requirements

- Stateful detection using accurate signatures
- Multiple-string, multiple pattern context matching after complete protocol decodes multiple protocols
- User-Defined Signatures for custom security policy enforcement
- Real-time signature updates for always up to date protection

**Notes:**
The ability for a signature engine to statefully examine traffic using multiple string/pattern matches increases accuracy and reduces false positives.  Allowing the user to write their own signatures empowers them to quickly adapt IDSs to their environment.  

## Stateful Deep-packet Inspection

- Reduce False Positives and False Negatives
- Thorough layer 3 – 7 Stateful Protocol Analysis
- Maintain State at layers 3-7 (IP/ICMP/TCP/UDP/layer6/layer7 )
- Context based multiple-trigger multiple-pattern match signatures
- Anti-evasion
- Layer 3 anti-evasion such as
- IP Fragmentation with forward and backward overlaps
- Layer 4 anti-evasion such as
- Forward and backward overlaps in TCP segments
- Ambiguities in protocol implementation
- Layer 6-7 anti-evasion such as
- Quoting in protocols such as HTTP, FTP, Telnet
- Layer 7 data fragmentation such as RPC record fragmentation

- Next Generation IDS - Ramesh Gupta

**Notes:**
Stateful packet analysis at multiple layers provides for more accurate detection by contextually analyzing patterns in traffic rather than simple string matching.  This method also reduces the chance of evasion techniques that can often foil stateless inspection.

## Traffic Normalization

**What is it?**
- Inconsistent behavior & interpretation
**Why is it necessary?**
- 	Prevention of:
- [Phantom] attack insertion
- Detection evasion
- Fingerprinting the target
- DOSing the target
**All network-based IDS MUST:**
- Take consistent interpretation with respect to targets
- Normalize the traffic when inline without destroying end-to-end protocol semantics
- Alert for occurrence of such unusual traffic

**Notes:**
Traffic scrubbing ensures that packets are analyzed with any inconsistencies removed.  Hackers will typically try to evade detection by sending attacks in out-of-order packets or adding extraneous information that could slip by and IDS.  It also can protect end nodes from reconnaissance by resetting OS fingerprinting flags issued by attackers.

## Anomaly-Based Detection

**What is an anomaly?**
- Any “abnormal” event, state, content, or behavior
- Anomaly is explicitly defined with respect to protected target
- E.g.: shellcode in user password, too many strange IP fragments, too much UDP than TCP traffic, or many more bytes in HTTP requests than in responses

**Pros:**
- Coverage advantage
**Cons:**
- Could be prone to false positives
- May not be able to provide detailed info upon detection
- Longer detection time due to the minimum observation window

**Notes:**
The most critical factor in anomaly detection is to set realistic expectations.  Anomaly detection isn’t a panacea for all unknown attacks, but rather it provides a critical buffer prior to an attack signature being developed.  Recent events have proven it’s value by alerting administrators to anomalous traffic patterns related to Microsoft DCOM DOS vulnerability, for example, without having a specific signature for the exploit.

## Anomaly-Based Detection – cont’d

**What can anomaly-based detection do?**
- Complement signature-based for coverage
- Focus on effect rather than the execution mechanics
- E.g.: new worms, new exploits, intentionally stealthy attacks, or variants of existing attacks
**All practical anomaly-based mechanisms MUST:**
- Allow for granular profiles down to per host, per application
- Profile individual measures as well as correlations among multiple measures
- Addresses the fact **ANOMALY********ATTACK**
**Anomaly-based methods MUST be integrated with signature-based methods to provide both the coverage and the accuracy!**

## Applicable Areas of Protection

**Misuse of protocol & service ports**
- Use of standard protocols with obsolete/experimental features
- Use of modified protocols for tunneling through firewalls
- Installation of backdoor services on well-known standard ports
**DoS based on crafted payloads**
- DOS can be on the network bandwidth, cpu cycles, memory resources, or application process/programs,
- e.g. process table exhaustion, IP stack crashing, web application “soft spot”
- Anomaly in service quality can be observed under DOS impact
**Buffer overflow**
- Buffer overflow is the most prevalent vulnerability
- Many exploited fields are supposedly printable ASCII’s per RFCs
- Excessive non-printable ASCII’s or shellcode embedded in these fields are sure anomalies

## Applicable Areas of Protection – cont’d

**DoS based on volume (DoS/DDoS)**
- When attacks have progressed beyond control channel actions, anomaly-based is the only general detection means to rely on;
- sophisticated attack traffic may not be distinguishable on an individual packet basis
- Traffic pattern anomaly can be observed with DDOS impact
- TCP control packet stats for TCP SYN flood
- Relative volumes of TCP, UDP & ICMP traffic for UDP or ICMP flood
- Stats on HTTP request vs. response balance for DDOS on server via normal-looking requests – difference of req. vs. resp. packet counts, difference of req. vs. resp. byte counts, and time interval between req. & resp.
- Applicable for attacks from outside to inside(O2I), from inside to outside (I2O), from inside to inside (I2I)
**Other natural networking service failures**
- Subtle failures in routers/switches  can lead to traffic re-route which manifests as traffic pattern anomaly

**Notes:**
Legitimate traffic such as ICMP or UDP can cause denial of service DoS conditions and never trip a signature.  Dynamic mapping of these types of traffic patterns that typically precede a DoS attack can identify it’s onset

## Protocol Anomaly Detection

**Built-in traffic normalization – full defrag, reassembly, & legal behavior enforcement**
- IP fragmentation overlap, options etc.
- TCP segmentation overlap, options usage etc.
- All checksum/length consistency
**Application protocol behavior – requires deep application protocol parsing**
- Illegal field values and combinations, e.g. DNS request
- Illegal commands usage, e.g. HTTP and SMTP
- Unusually long or short field lengths
- Unusual number of occurrence of particular fields/commands
- Running HTTP on port 53, running Gnutella on port 80, etc.
- Unexpected state transition sequences – suggesting service configuration vulnerability or attack attempts

## Application Payload Anomaly

- All vulnerable application fields are individually parsed
- Accurate dequoting (e.g. URL %, unicode encoding, telnet/ftp escape sequences) is applied
- Binary detection is applied to all these fields
- Shellcode detection is applied to all these fields
- Identify if shellcode is present
- Identify what architecture is the shellcode for
- Anomaly detection is correlated with signature-based checks

## Statistical Anomaly - Statistical DDoS

- Basic statistical algorithm recognizes the difference between the long-term (assumed normal) and the short-term statistical distributions with respect to a given protected environment
**DDOS is detected by detecting**
- Rare events of the difference between long and short-term distributions
- Rare occurrence of long bursts of high rate traffic
**Each critical aspect of the target behavior is modeled using an Anomaly Measure, e.g**
- TCP SYN, SYN-ACK, RST & FIN parity, activity intensity among TCP, UDP, and ICMP
- HTTP request and response balance
- Each measure can be configured with different thresholds of sensitivity
- Comprehensive measures allow differentiation between a real volume-based DDoS and harmless flash-crowd conditions

## Example of DDoS Measures

**SYN, SYN-ACK, RST, RST, FIN, FIN counts**
**ICMP echo reply rate**
**IP fragments rate**
**Malformed IP packet count**
**Malformed UDP packet count **
**Malformed ICMP packet count**
**Malformed TCP packet count**
**Count of TCP segments without context or rejected at reassembly**
**UDP packets rate**
**ICMP packets rate**
**Count of rejected IP fragments at de-fragmentation**
**Other IP datagram rates**** **

## Time

**0**
**Security & virus issues  Discovered**

**Re-Active**

- Attack
- Vulnerability

- AV Fix Posted

*CUSTOMER*

- Security Fix Posted

- Security
- Vulnerability

- Attack starts

**IPS & Vulnerability assessment**

**Applications Security & communications control**

**Anti-virus security**

- Security Behaviour

- Attack Behaviour

- Traditional AV update

**Notes:**
If we were to represent the window of vulnerability graphically, it might look like this. The clock starts ticking when the virus is discovered. Between then (time zero) and the time the fix has been deployed to all the machines on the network, the window is open. Notice there are two components to this—the time it takes for AVERT to produce a fix (often less than an hour, almost always less than four for major threats), and the time it takes for the customer to deploy that fix to the entire organization. In the past few years, we have made significant impact on the size of the AVERT component. We now turn our attention to delivering solutions that help our customers shrink the part symbolized here by the red arrow. Since that is the larger piece of the window of vulnerability, it is where we have the opportunity to make the greatest impact.

## IntruShieldTM Architecture

## Virtual IPS

**Today’s IDS can only support single policy per sensor, resulting in too many false positives or too many sensors**

**Before In-Line**

**After In-Line**

**Innovative Virtual IDS feature empowers multiple security policies per sensor, each customized to protect specific environment – leading to lower cost of ownership**

- VLAN / CIDR / Interface based VIDS definition
- Up to 1,000 VIDS sensors per device
- Highly granular policy per VIDS, down to individual host/sub-net and attack

## Defining Intrusion Prevention

- What is intrusion prevention...
- In-line operation with traffic flowing through device
- Highly selective packet and session blocking
- Extension of IDS

**In-line operation is a pre-requisite for Prevention **

- What it is NOT...
- Sending TCP reset
- Reconfiguring firewall
- Adding router filtering
- Separate from IDS

**Notes:**
Intrusion Prevention is, in some quarters, a controversial topic. One of the problems is that each vendor has defined Intrusion Prevention in a fashion most advantageous to their own cause. Along those lines, we have defined Intrusion Prevention as the ability to block attacks by dropping packets before they even reach the targeted host. TCP Resets (KILL Packets), Firewall Reconfiguration, Router ACL changes and other, similar approaches all suffer from the fact that they let the attack traffic through don’t react until after the fact. A classic case of closing the barn door after the horses have bolted, in other words.

Also, deploying the sensor in-line and allowing it to act on individual packets overcomes one of the major problems associated with firewall reconfiguration and router filtering – dependency on Source IP to identify traffic to be blocked. IP addresses can be spoofed. Also, there is not a one-to-one relationship between a Source IP and a host. Proxies and NAT are two technologies that result in a number of hosts originating from a single Source IP address. Blocking that Source IP address could potentially result in many users being blocked.

Once the realization sets in that the sensor needs to go in-line in order to provide real prevention, other questions arise. Network Engineering wants to know if the sensor will be reliable enough that network availability does not suffer – that’s why we have fail over and fail open. Network Engineering also wants to know if the performance of the sensor will keep it from being a network bottleneck – that’s why we have two sensor models with very high performance, 600 Mbps and 2 Gbps.

Other requirements also arise. Is the system accurate enough to avoid the false positives that plaque other IDS products, and that would cause an IPS to become a DoS nightmare? That’s why we have three detection engines, with correlated results. Also, VIDS allows us to tailor policies to specific hosts, eliminating attacks that have no relevance from each policy.

Finally, does blocking have to be an all or nothing proposition? Not at all. Our finely grained policies allow a user to create individual policies that implement only the degree of blocking that they desire, or feel is prudent. There is never a requirement to block an attack that might cause problems. Just treat it like an IDS would by logging an alert and the appropriate packet logs.

## Path To Prevention

**Path To Prevention**

- Prevention is an evolutionary process ... it builds upon TRUST
- An IPS must be a Highly Accurate IDS first!
- Only IntruShield Provides a Seamless Path to Prevention

**Notes:**
The Path to Prevention outlines a series of steps that a customer can take to approach the idea of prevention in a gradual fashion, at a pace that will make them comfortable. From pure detection, through in-line with no blocking, on to selective prevention and broad-based prevention, the customer can approach prevention a step at a time, verifying proper system operation at each step along the way, and before taking the next step.

## Questions?