Advanced Intrusion Defense

Joel SnyderOpus One

Acknowledgements

http://infosecuritymag.techtarget.com/

Massive Support from Marty Roesch, Ron Gula, Robert Graham

Products from ISS, Cisco, and Tenable

Cash and Prizes from Andy Briney and Neil Roiter

This is an IDS alert…

• IDS saw a packet aimed at a protected system

• IDS magic decoder technology correctly identifies this as “Back Orifice!”

This IDS alert ain’t no good

• Last time I checked, FreeBSD 4.9 was not one of the supported platforms for BackOrifice…

Please don’t call that a False Positive

• IDS developers will jump down your throat

• “False Positive” means the IDS cried wolf when there was no such attack Usually the result of

poorly written signatures

• Instead, let’s invent a complex multisyllable term:“non-contextual alert”

The IDS lacks “context”

• IF the IDS knew that the destination system was not running Windows…

• IF the IDS knew that the destination system was not running Back Orifice…

• IF the IDS knew that there was no such destination system…

• IF the IDS knew that the destination system was more hops away then TTL allowed…

IF IF IF the IDS knew more…

• THEN the IDS could tell the IDS operator more about this attack

• Ron Gula (Tenable) says that alerts are “raw intelligence.” They are data, but are not information yet. We need to turn them into “well-qualified intelligence” to start a war.

Roesch: “Target-Based IDS”

• Target-based IDS Sensor The sensor has

knowledge about the network

The sensor has knowledge about the hosts

• Target-based Event Correlation The output of the

sensor is compared to knowledge of vulnerabilities

Target-based IDS has two components

Target-based IDS sensor

• Network Flight Recorder (NFR) and Internet Security Systems (ISS) claim to be shipping IDS sensors that have target-based IDS technology in them

• Sourcefire is working on putting this into its sensor

• Other vendors may be including this technology (but I don’t know about them)

Target-based IDS Consoles

• Information Security asked me to look at three “Target-based IDS” consoles

Internet Security Systems “Fusion” Cisco “Cisco Threat Response” Tenable Security “Lightning Console”

Start with a normal IDS…

1. IDS sensors generate enormous dinosaur-sized piles of alerts;alerts are sent to the IDS console

2. Operator gets enormous dinosaur-sized headache looking at hundreds of thousands of alerts … and add

brains!

Brains=knowledge + process

Knowledge

• Somehow figure out lots of information about What systems are

out there What software they

are running What attacks they

are vulnerable to

Process

• Evaluate each alert with the additional contextual knowledge and decide To promote the

alert To demote the alert That we don’t know

Approach 1: ISS Fusion

1. NetMgr schedules scanning using ISS Scanner

2. Scan info, including ports & vulnerabilities, flow into SiteProtector

3. Sensor alerts also flow into SiteProtector

4. Fusion reads alerts and assigns priorities for the operator

Variation 2: Tenable Lightning

1. NetMgr schedules “active scans” using Nessus or NeWT

2. Results are sent to Lightning Console

3. Passive scan results are collected by NeVO

4. Passive results are sent to Lightning

What is “Passive Scanning?”

By simply watching the traffic fly by, you can learn a great deal

• TCP connections have “fingerprints” Fingerprints are useful for identifying the TCP

stack (hence: the O/S) involved Existence proof

• Applications (client & server) have “banners” Banners can reveal application names, version

numbers, and patch levels

Tenable (continued)

5. IDS sensors send alerts to console (Bro, Snort, ISS, Enterasys, NAI)

6. Lightning compares every alert to the known vulnerability database, rejecting all that don’t match an identified vulnerability

Approach 3: Cisco CTR

1. IDS sensors send alerts to their native console

2. Copies of alerts also go to CTR

3. CTR investigates alerts4. Alerts plus

investigation are available to operator

Scan before vs after

• If you scan before… You can’t verify that

an attack actually succeeded

Your scan will always be out of date

• If you scan/verify after… You can verify that

an attack did something

You might be a day late (and a dollar short) to catch things

You potentially can create a DoS condition

Do they work?

• Yes, but… Be careful what you

wish for

• All products had a significant reduction in IDS alerts

• Caveats CTR - rolling

window of only 1000 events!

Lightning - only shows events with matched vulnerabilities!

What about scanning?

• When you scan is important

• How you scan is important

• Where you scan is important

• Caveats Scanning after the

fact can be a problem

Scanning before the fact can be a problem

Passive scanning can miss things

Active scanning can miss things

Can this quiet my IDS down?

• It could…

• But none of the products I looked at have a feedback loop to the IDS!

• Why don’t the scanners tell the IDS what ports to look on?

• Why don’t the scanners tell the IDS what signatures to ignore?

Is this right for you?

YES!• “I already have an IDS

and I care about the alerts and I need some way to help prioritize them because I am drowning in alerts!”

• “I need to get an IDS for alerts but don’t have the manpower to analyze the alerts.”

NO!• “If I get this, my IDS

will be a self-tuning smooth-running no-maintenance machine.”

• “I have no network security policy that says what to do when an alert occurs.”

Advanced Intrusion Defense

Joel SnyderOpus One

jms@opus1.com

Questions?

Submit your questions to Joel by clicking on the Ask A

Question link on the lower left corner of your screen.

More information

Thank you for participating in this SearchSecurity webcast. For more information on intrusion defense, visit our Featured Topic: http://www.searchSecurity.com/featuredTopic/IntrusionDefense