Advanced Intrusion Defense. Joel Snyder Opus One. Acknowledgements. Massive Support from Marty Roesch, Ron Gula, Robert Graham Products from ISS, Cisco, and Tenable Cash and Prizes from Andy Briney and Neil Roiter. 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
IDS magic decoder technology correctly identifies this as “Back Orifice!”This is an IDS alert…
Last time I checked, FreeBSD 4.9 was not one of the supported platforms for BackOrifice…This IDS alert ain’t no good
IDS developers will jump down your throat supported platforms for BackOrifice…
“False Positive” means the IDS cried wolf when there was nosuchattack
Usually the result of poorly written signatures
Instead, let’s invent a complex multisyllable term:“non-contextual alert”Please don’t call that a False Positive
IF supported platforms for BackOrifice…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…The IDS lacks “context”
Target-based IDS Sensor supported platforms for BackOrifice…
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 vulnerabilitiesRoesch: “Target-Based IDS”
Target-based IDS has two components
IDS sensors generate enormous dinosaur-sized piles of alerts;alerts are sent to the IDS console
Operator gets enormous dinosaur-sized headache looking at hundreds of thousands of alertsStart with a normal IDS…
… and add brains!
Somehow figure out lots of information about
What systems are out there
What software they are running
What attacks they are vulnerable to
Evaluate each alert with the additional contextual knowledge and decide
To promote the alert
To demote the alert
That we don’t knowBrains=knowledge + process
By simply watching the traffic fly by, you can learn a great deal
If you scan before… alerts;
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 conditionScan before vs after
Yes, but… alerts;
Be careful what you wish for
All products had a significant reduction in IDS alerts
CTR - rolling window of only 1000 events!
Lightning - only shows events with matched vulnerabilities!Do they work?
When you scan is important alerts;
How you scan is important
Where you scan is important
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 thingsWhat about scanning?
It could… alerts;
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?Can this quiet my IDS down?
“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.”
“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.”Is this right for you?
Submit your questions to Joel by clicking on the Ask A Question link on the lower left corner of your screen.
Thank you for participating in this SearchSecurity webcast. For more information on intrusion defense, visit our Featured Topic: http://www.searchSecurity.com/featuredTopic/IntrusionDefense